Hello,
I've been reviewing the SPF proposal, in particular the objections listed at
http://spf.pobox.com/objections.html
I have a couple of things I'd like to comment on. I wasn't able to find an
archive of this list obviously linked from the subscription/user options
page, but please point me at it if it exists and these suggestions have been
raised before.
(1) If the SPF proposal is widely adopted, I'd expect spammers just to start
sending spams with null envelope senders, i.e.
MAIL FROM:<>
RCPT TO:<me(_at_)mydomain(_dot_)com>
(Arguably this is what they should have been doing all along!) That would
make spams indistinguishable from bounces. I can't see how SPF addresses
that problem; and any solution which risks losing bounces could potentially
damage confidence in the reliability of E-mail, as people are used to a high
probability that either their E-mail is delivered, or they receive a bounce.
It would be a shame if a simple config change to spamware defeated the whole
SPF mechanism at a stroke.
The only solution I can see is the cryptographic signing of sender
addresses, for example in the way proposed in SRS, for *all* outgoing mails
(not just forwarded mails). An ideal place to do this would be on the ISP's
smarthost, as only the ISP knows the secret value used to generate the
crypto checksums which will be validated for incoming mails. The smarthost
function is "forwarding" of a sort anyway.
SRS-signing outgoing messages is easily implemented an ISP. And as soon as
they have done that, they can configure their inbound MTA to reject incoming
bounces which are not to SRS-signed addresses. Let's say example.com is a
vanity domain handled by example.net as the ISP:
outgoing (after going through smarthost):
MAIL
FROM:<srs0+hash+ts+example(_dot_)com+b(_dot_)candler(_at_)example(_dot_)net>
RCPT TO:<someone(_at_)somewhere(_dot_)com>
bounce:
MAIL FROM:<>
RCPT
TO:<srs0+hash+ts+example(_dot_)com+b(_dot_)candler(_at_)example(_dot_)net>
250 valid bounce
MAIL FROM:<>
RCPT TO:<b(_dot_)candler(_at_)example(_dot_)com>
550 Bounce message is not cryptographically signed
That's good, and the implementation is entirely local - it doesn't depend on
any configuration on any other site. But consider the consequences. From now
on, we know that all mail received *from* anyone(_at_)example(_dot_)com will be
signed.
So at receiving mail systems, a simple 'callback' SMTP probe can be used to
validate the address, the same as many spam filters use already. If the
callback looks like a bounce, it will be rejected if unsigned.
Hang on - suddenly we seem to have the same sort of protection that SPF is
supposed to give, without having implemented SPF at all!
FORGED SPAM
# session to mx.somewhere.net
MAIL FROM:<b(_dot_)candler(_at_)example(_dot_)com>
RCPT TO:<someone(_at_)somewhere(_dot_)net>
at mx.somewhere.net's: perform SMTP callback
# session to mx.example.net (MX receiver for example.com)
MAIL FROM:<>
RCPT TO:<b(_dot_)candler(_at_)example(_dot_)com>
550 Bounce message is not cryptographically signed
550 Your sender is invalid, go away
GENUINE MESSAGE
# session from client PC to smtp.example.net
MAIL FROM:<b(_dot_)candler(_at_)example(_dot_)com>
RCPT TO:<someone(_at_)somewhere(_dot_)net>
# session from smtp.example.net to mx.somewhere.net
MAIL
FROM:<srs0+hash+ts+example(_dot_)com+b(_dot_)candler(_at_)example(_dot_)net>
RCPT TO:<someone(_at_)somewhere(_dot_)net>
at mx.somewhere.net's: perform SMTP callback
# session to mx.example.net (MX receiver for example.com)
MAIL FROM:<>
RCPT
TO:<srs0+hash+ts+example(_dot_)com+b(_dot_)candler(_at_)example(_dot_)net>
250 valid bounce
250 Go ahead
In other words:
- signing your outgoing mails with SRS and rejecting unsigned bounces, is
similar to publishing an SPF policy
- implementing callback filtering on a receiving host is sufficient to
honour that policy
Both ends get benefits individually by implementing those things. And the
more widely both parts are implemented, the bigger the benefits become.
It wouldn't just be smarthosts who could do this: any permanently-connected
Internet host could implement srs0 locally. This would be appropriate for a
host which runs mailing lists and doesn't relay via a smarthost, for
example.
Mail relays which receive srs0-signed messages could convert them into srs1
messages, as per the SRS specification; but actually if you drop the whole
SPF business because it's no longer needed, then I don't think srs1 is
needed either. Forwarding machines can simply forward mail, without
rewriting the envelope sender at all; the forwarding problem vanishes.
That's a bit radical, and surely someone has thought of it already :-)
(2) I see little mention on spf.pobox.com of the role of smarthosts at ISPs
and how SPF could help them.
If you were to configure SPF on your smarthosts, it could actually help to
discourage spammers from operating on your network - for example, you would
not relay messages from one of your customers claiming to be
anyone(_at_)aol(_dot_)com
if aol.com had declared in SPF that such messages should only originate from
their network.
As well as being neighbourly to the rest of the Internet, and helping reduce
spam even for non-SPF-aware recipients, it would reduce complaints to your
own abuse department.
This is perhaps where SPF can add value over SRS: in point (1) the ISP
smarthost would sign any MAIL FROM: address given by the client, which of
course may be forged. Now, we are still protected from joe-jobbers; any
bounce will be returned to the ISP who owns the forged domain, who will
reject it because it wasn't signed by them. However if concerns about
protecting use of the domain name and associated "reputation" are more
important, then it could be an issue.
But at that point, you're really more interested in protecting the domain
name in the From: or Reply-To: headers (since that's what the client will
reply to in their MUA), rather than the envelope, and that's something which
SPF doesn't seem to address strongly at the moment.
Sorry for a long post, and thanks for listening :-)
Brian Candler.