The most common use of a digital signature is to verify that the sender of the email is who he claim he is. This is done using the keys of the sender, and using the From: address to get the public key to verify the signature. There are variations on how this public key will be retrieved - key server, included in the message or using a different protocol.

Another case is a mail server using it's digital signature on all outgoing mails. The receiver can use the domain name to locate the signature and decide if he wants to trust the message. The user can use a key server, but more likely the signature can be CA-issued and available using HTTP or other simple protocol. It could also be made available using DNS like in SPF. Like in SPF, this case doesn't mix well with forwarding or people using multiple identities, which are covered by the other cases. The sender MTA would use this kind of signature only for mail using the MTA's domain.

A third case is an MTA which has verified and trusts a user for relay purpose, and is using it's MTA digital signature to sign the outgoing message. This only indicates that the user is  authorized by the MTA and he  could be eventually traced to a valid account. It doesn't mean the address used is one the MTA is reponsible to. This cover the case of people using multiple email addresses, web mail systems, forwarding ( the sender may be another MTA that is authorized for transmission ).

A major problem with SPF and "Caller ID" is that it locks out small SMTP servers - like those used by most linux users who send their own mail without a provider MTA in the middle. It also locks out or make forwarding difficult, and disables an important use case - multiple identities.

Like SPF, it relies on the sender to provide additional information about the mail beeing sent. Instead of using this information over a single hop and breaking the forward model of email, we encode this as a digital signature that is added to the mail.

Signature also provide more flexibility on the receiver side - in SPF and other mechanism relaying on verification of the sender MTA, it has to be implemented in the receiving MTA. Signatures can be verified by the receiver MTA but also by the receiving user.

Another important aspect is that signatures of the first type will work without any modification in any existing MTA, using only existing infrastructure. It is most powerfull when used by MTAs but it doesn't lock anyone out.

There is another aspect -  customization. The receiving MTA may provide a lot of value-added services allowing the user to fine tune the recognized signatures, and sender MTA may decide what kind of services they provide ( allow only it's own domain or allow user identities as an add-on service ).

More later.