spf-discuss
[Top] [All Lists]

Re: Opening Debate on SPF vs. SenderKeys

2004-08-20 22:33:10

SPF "-all" attempts to say semantically that "email not from a certain IP
is forgery" where from a senders perspective "any email I send is not a
forgery".

Another way of saying that SPF "-all" is a gross oversimplication of sender
identity.  It attempts to say that senders are IP addresses of mail relays,
when in fact senders are human beings.  The closer you can get to signing
actions the humans do to send, the closer you are not making a false
assumption.

You are correct for RFC 2822 senders.  However, SPF is concerned with
the RFC 2821 sender, AKA Return-Path.  This is not a person, but
a set of machines tied to a domain name.  Mapping this to a set of
IPs is entirely reasonable.  Since your scheme is concerned with
authentication persons (i.e. RFC 2822 headers), perhaps you should
troll another mailing list.  SPF is about authenticating RFC 2821.

You might try the sender-ID or MARID lists, since they are dealing with RFC
2822 headers.


Clever but you won't be able to escape the semantics that if you want 
anti-forgery protection of human addresses, then you need to match the semantic 
model to human sending.

If that were true then I would mostly agree with you, but that is not what I 
understand the merged SPF and CallerID = SenderID to be, where the "responsible 
address" is the sender, not a mail server + message hash.

More succinctly, if SPF "-all" verifiers only match Return-Path to SPF records, 
then it is useless as an anti-forgery protection for senders, because a spammer 
can just insert the sender address in "From:" with a different "Return-Path:" 
domain that matches the spammers mail server.

Anti-forgery protection for mail servers is what you would end up with, which 
does not stop phishing or spoofing.  Sorry does not compute logically.

Thanks,
Shelby