On Fri, Nov 19, 2004 at 02:28:39PM -0500, Vivien M. wrote:
| it was sent from. I must admit I know far too little about DomainKeys, but
| it might be a step in that direction, except that it works based on domains
| rather than end-users...
If:
a sender domain does two things:
- publishes IP-based SPF records and
- signs outbound mail with DomainKeys
and if a receiver domain does two things:
- checks IP-based SPF
- checks the signature
Then:
if either one passes, I know the message is authentic
if both fail, I know the message is a forgery
- unless the corner case on page 22 of the whitepaper occurred
Use of both IP-based and crypto-based schemes can be
described by SPF:
v=spf1 a mx dk -all
I had always envisioned the need for a "dk" or "iim" or some
other such mechanism: hence the very specific language about
bailing out with "unknown", but also not bailing out until
the unknown mechanism was encountered.
* * *
To address the original, quoted, point:
DomainKeys supports localpart customization with the use of
selectors, just as SPF supports localpart customization with
the use of exists:%{l}. So both systems support localparts.
I have always believed that crypto will be a part of the
final solution, and frankly any of SES, DK, or IIM will
suffice.
I strongly recommend that folks reread the latest
documentation for DK, IIM, and SES if they wish to comment
on cryptographic solutions.
http://www.ietf.org/proceedings/02mar/slides/plenary-3/sld012.htm