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;±¤Ö¤Íµø?¡