From: Stuart D. Gathman
Sent: Thursday, June 10, 2004 4:08 PM
On Thu, 10 Jun 2004, Seth Goodman wrote:
<...>
SPF+any rewriting scheme is still vulnerable to forged forwards
from valid,
but disposable, forwarding domains. Unless the recipients implement an
authorized forwarder whitelist, they can't tell the difference.
Yes. My point was that IMHO responsible recipients use a forwarder
whitelist. After all, *they* selected the legit forwarders. *They*
should refuse to relay mail for self proclaimed forwarders they did
not in fact select. SPF gives them the means to determine which
mail is really from their authorized forwarders. SRS/RSR/DBBF gives
them the means to detect that mail is forwarded rather than direct.
SRS/RSR (but not DBBF) lets them discover the originating address
and possibly do CBV (preferrably via DNS).
I guess this is the heart of the matter. If recipients do maintain an
authorized forwarder whitelist, there is really no reason to perform any
originator checks. As you pointed out, if a sender does not provide the DNS
resources to do the originator check, you cannot validate that address
anyway.
Small sites can maintain trusted forwarder lists and user feedback will lead
you to discover any forwarders that accept garbage. As a seat-of-the-pants
initial qualification, you could send a new forwarder a couple of different
forged messages and make sure they are rejected. I suppose it would be
possible to create an automated script that would let a user add a forwarder
by first testing them in this manner. Large sites have the resources to
develop a more sophisticated audit, should they care to. So it is probably
feasible to maintain trusted forwarder lists, given some effort.
Since you propose that recipient MTA's should all maintain trusted forwarder
lists, is there really any need for originator tests? Playing the devil's
advocate here, if all recipients maintained trusted forwarder lists, there
really isn't any need for SRS, either. If we need SRS because not all sites
have forwarder whitelists, we also need originator tests, since those
recipients can't distinguish a trusted forwarder from a forger. How do we
reconcile this?
Considering the complications and objections to SRS, SUBMITTER and RSR, the
vulnerabilities of all three and our inability to force senders to provide
DNS validation of originating addresses, maybe maintaining trusted forwarder
lists is a better overall solution than address rewriting? If we dump the
address rewriting protocols altogether, the trusted forwarder whitelist
would either have to operate by HELO string domain being on the list with
validation by SPF check or by listing specific IP's. This requires you to
check every SMTP-client against the trusted forwarder list. For any
SMTP-client not on the trusted forwarder list, you instead do an SPF check
using MAIL FROM:. Alternatively, you could do an SPF check using MAIL FROM:
for every incoming message, and in the case of failures, check the
SMTP-client against the trusted forwarder list. Forwarders don't need to do
anything except implement SPF on incoming messages. You can safely send
DSN's to the message originator.
Using RSR or SUBMITTER with a trusted forwarder list is an optimization,
since you can distinguish a forward from an original message, yet it is a
lot simpler than SRS. If the message is a forward, you verify that the
forwarder is whitelisted, then do an SPF check to validate the IP. If the
message is not a forward, you do an SPF check using MAIL FROM:. I don't
know if this savings is worth the extra effort of implementing RSR or
SUBMITTER. At a large site, it probably would be, but that's a guess.
<...>
Until we make it uncomfortable enough for the clueless who are
responding to
forgeries with DSN's, that is certainly true. If these sites
start to get
If they would actually respond with DSN's, they wouldn't need to bother
recognizing forgeries. SES would take care of it. I'm not asking them
to necessarily get with the SPF program. I am asking them to follow
basic RFC guidelines, and stop originating non-DSN mail to whoever some
spammer or virus tells them.
I haven't thought about this for a long time, since all this stuff is
removed by my content filters. Since they are from end-user systems, you
are obviously right that they are replies rather than DSN's. If these
domains publish SPF records, there is nothing we can do besides content
filtering. It may be worthwhile to consider an effort to contact and
educate anti-virus software vendors. Alternatively, we could lobby
blacklists to start listing sites that send these messages, perhaps in a
separate zone. They do meet the definition of spam: both unsolicited and
bulk. See http://www.spamhaus.org/definition.html
--
Seth Goodman