On Fri, Feb 13, 2004 at 01:43:41PM -0500, George Schlossnagle wrote:
Yes. The key point is one that was raised by Shevek in an earlier
thread today. SPF does not prevent all spam - that's not in it's
design. It simply serves to verify that a user is representing their
messages as coming from a domain that they are authorized to do so.
It's great for joe-jobs, address spoofing and worm reduction. And
those are all plenty to make it worthwhile in my book.
Please correct me if I'm wrong, but I can't see that SPF is going to make a
significant impact on the received noise from joe-jobs until the majority of
Internet providers implement SPF filters AND the majority of domains declare
SPF info.
In the mean time, if I enable SPF then I prevent myself being used as a
relay for joe-jobs for some domains, but I will still receive joe-job
bounces for messages sent to other ISPs. So I receive very little benefit
myself until some unspecified date in the future when everyone else returns
the favour.
I can't see any solution to this apart from having a message signature or
cookie which lets me prove that an incoming bounce was in response to a
message I sent. Such a cookie could go:
(1) in the envelope-sender address (VERP)
(2) in a message header, although this relies on the bouncing MTA quoting
back at least the headers of the message it is bouncing, which not all
MTAs do [and certainly not all are RFC 3462 compliant].
(3) in the SMTP DSN envelope identification string [RFC 3461] - although it
seems DSN is not widely implemented at present
(4) in some other extension to SMTP, to be defined
So I'd be interested in what is going on in this area. Once this problem is
fixed, I think that envelope-sender address spoofing becomes a non-issue,
because for successfully-delivered messages the envelope-sender isn't used
anyway - it just appears in Return-Path: which is generally hidden from
users anyway.
Of course there is still the issue of From: header address spoofing, and
maybe people would want to filter their headers against SPF as well as the
envelope. That requires either the MTA to munge headers, or the MUA to be
SPF-aware. The latter is more difficult as the source IP address of the
message is typically lost by then, or buried in Received: headers which may
themselves be forged.
Regards,
Brian.