spf-discuss
[Top] [All Lists]

RE: Using headers instead of SRS

2004-01-26 12:36:00
OK, I think we're getting closer to agreement here.

On Mon, 26 Jan 2004, Julian Mehnle wrote:

: But to create somewhat reliable reputation systems (RHSBLs, domain
: blacklists) for SPF to actually do its part in the fight against spam,
we : need people to *recognize* forgeries in the first place.  Nobody,
not even : experts, will want having to examine the full headers of
*every* : potentially address-forged message to find out.


Agreed. If SPF makes the claim of being able to stop forgeries, then taking it to the next logical level makes sense. To me, the next logical level for the spammer is to send
 Return-Path: bad(_at_)spammer(_dot_)com
 From: support(_at_)microsoft(_dot_)com
Or worse:
 Return-Path: support@(other domain with no spf)
 From: service(_at_)paypal(_dot_)com


--tv+spf(_at_)duh(_dot_)org wrote:
The experts already examine the full headers.  The end users normally
don't give a damn about "forgeries"; rather they care about "spam".  Let
the ISP's normal "report spam" process contain the proper information
(which it already does).

I'm not sure I would 100% agree with "end users usually don't care about forgeries". The natural thing users assume is that the From: address is correct, and the message really is from kjcf8g9d0(_at_)altavista(_dot_)com, and it's usually a rude awakening when they find that it is forged. It's not intuitive: every user needs to be educated on that aspect.

We have mostly stopped referring to SPF as "it will solve spam" - at best it is one of many "necessary but sufficient" steps in the ongoing war. But, we *do* make a big deal about how it will stop forgery/joe-jobs when used correctly.

So, that was the essence of my suggestion - that we should first figure out if a strong correlation already exists, and possibly insert a "security warning" in the headers (or even in the body) if an anomaly is found.

I do agree with Todd that end users don't often examine full headers. SPF has, after much (much) discussion, held true to its origins and uses only the envelope sender to make its decision. This is the right thing to do, but may be of limited value to the end user. Assuming spammers are crafty (and they are) and that quite a number of users are thick (and they are) then "apparent forgeries" still slip through. Important domain owners get much less value out of SPF if there is a disconnect between envelope sender and the rest of the headers. Phishers phish on.

: I suggested the "Sender:" header, because I think it's conceptually the
: same as the envelope sender, or could at least be made so without
: significant problems.

One particular issue I've found with Sender: is its use with S/MIME....

*shrug* I give up.  I'm afraid that rewriting a header (as opposed to just
the envelope, or just adding a header) will lead to even more nasty
implementation in the wild, and may decrease the possibility of acceptance
by MTA authors.  Feel free to write the patches and submit them; I'm just
tired of trying to separate the two concepts.

If I had to settle on a header, I'd vote only for adding a
"Resent-Sender:", not munging any existing field in the original message.



My original suggestion was that we should seriously *investigate* whether there is already a strong link between envelope sender and one of the more user-visible headers. It's currently beyond my power to say for sure whether there is one.

I think I lean toward Todd's argument that just replacing an existing header is probably risky. I would probably lean toward adding a "Security warning" in headers and possibly in the body if there is a huge disconnect between envelope-sender and certain key headers. This is sort of like, "So you have invested in SPF. Wouldn't you like to make the most of your investment?"

I would also advocate that any application that rewrites the envelope (such as SRS) should make sure it matches Resent-Sender:

Thanks to both of you for the feedback.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki: 
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡