spf-discuss
[Top] [All Lists]

Re: [spf-discuss] The problems with SPF

2005-08-27 19:52:03
Dennis Willson writes:
Dick St.Peters wrote:
Speaking as a commercial forwarder who has *already* substituted
forwarding with envelope sender rewriting, I think what's important to
users is not who the envelope sender is but whom the mail is really
from.

Users care so little about who sent their mail that most MUAs don't
even bother to display the envelope sender.  They do display a "From:"
header address, and it's the authenticity of that address that
matters, not how the mail got to the user.

Question:
      Do you set the "reply to" to the old "mail from" address if the "reply 
to" isn't already specified? This looks like a nice neat 
solution to one of SPFs problems. It also looks simpler to implement than SRS 
(at least to me). Also what do you rewrite the from 
address to be? Is it the To address that originally came in? That would make 
it so the user could tell that it came from their 
forwarder. And to you add a header that indicates the original "mail from" 
address? This would allow a knowledgeable user to look at 
the headers and determine alot about the origin of the eMail. Also I assume 
that you check SPF before accepting the eMail to forward.

What I do isn't simpler than SRS, it *is* SRS.  Replies don't go to
the "mail from", only bounces do, so there's no need to set a
Reply-To.  I don't change the "from" address, only the "mail from"
address and Return-Path.  They are set to an SRS address with an
@netheaven.com domain part.  Yes, I add an X-Envelope-From header, and
I check both SPF and SID before accepting the mail.  I also check any
plain DomainKeys or DKIM signature, although at this point I don't yet
use the result.

SRS isn't all that hard, thanks to the work of a few people.

The fact that a sender can send an eMail and get an SPF pass and the user see 
a spoofed eMail address (because the spoofed eMail 
address was specified in the Data in the From header and that's all most 
email clients display) still bothers me and looks like a 
hole in the system. IMHO

This is why SPF is only a partial solution to the mail authenticity
problem.

--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com 

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com