From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Stuart
D. Gathman
Sent: Thursday, June 10, 2004 10:31 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] a "never relays" parameter
On Thu, 10 Jun 2004, Seth Goodman wrote:
Here are some ideas on how to get SPF to do originating address
validation,
[ some excellent ideas ... ]
Just wanted to point out that the the recipient selects their forwarders,
and is responsible if the forwarder is incompetent or spam friendly.
Regardless of SPF, allowing any joe to forward mail to your addresses
is problematic. So called "legitimate" sender forgeries should not
be accepted, unless the forger stops forging the MAIL FROM. (They
can still forge the 2822 headers, leaving the problem for layer 2 to
deal with.)
Agree with all of the above.
The user is responsible to select forwarders who are responsible.
There is also no reason for greeting card sites, etc. to forge MAIL FROM:.
They can operate like mailing lists and put their address in both MAIL FROM:
and Sender: and the claimed address of the person requesting the message
into From:. This will pass SPF and CID. The fact that they don't want the
bounces is just too bad, IMHO. They are originating a message on behalf of
an unknown third party to a recipient who did not give permission to send
them mail. They benefit from either charging the sender money or making
them, or the recipient, view advertising. If the message bounces, it's
_their_ problem and they should accept that. What's the big deal if they
get bounces, anyway? They don't really need to do anything with them.
The need to validate the originating address arises from the belief
that forwarders are likely to be incompetent or malicious.
Is this belief justified? In the case of independent domains,
probably not. I think the problem comes with AOL and their ilk. Their
millions of users will have no clue on whether a forwarding
service is legit.
Even if they did, it is difficult for AOL to check an individual
authorized forwarder list for every user. However, AOL *could* have its
own preauthorized list of forwarding services, and inform users that
only these forwarding services will work.
The problem is not that the forwarders are incompetent or malicious, but
that your MTA can't tell the difference between a forwarder that your user
sets up and a forger who is posing as a forwarder from a throw-away domain
with an SPF record. Unless you force all your users to whitelist their
individual forwarders, you can't tell the forwarders from the forgers.
Having a global trusted forwarder list for your site is one solution, but
then you have to qualify each forwarder on the list, since this gives them
permission to forward to any user on your site.
Message originator checks sidestep at least some of these issues. In fact,
if you validate originator, it becomes redundant to validate forwarders.
Recognizing that the whole world will never do any one thing, and most
people are lazy, why not allow SPF to operate in either hop-by-hop mode
(default, easiest for sender) or end-to-end mode (harder for sender, more
secure for both parties) as long as the domain owner provides the DNS
services to make that possible and advertises it in their SPF record? It
also provides an automatic audit tool to make sure that forwarders are
well-configured. Any forwarded message that fails the originator test says
there is either a transient problem or the forwarder is not doing their job
on incoming.
Any recipient that blindly relays or bounces any mail claiming to be
forwarded deserves to be blacklisted. Of course, without SPF they
have no way of knowing. And with SPF, the recipient needs one of these
to detect unauthorized forwards:
a) SRS in a recognized format
b) RSR or SUBMITTER
This will let recipients detect all forwards. However, without a whitelist,
how can they detect _unauthorized_ forwards? Though you can trust the
return-path from authorized forwarders, an unauthorized forwarder is
probably a forger and the return-path is probably forged. Without a
whitelist to tell the difference between authorized and unauthorized
forwards, you can't trust the return-path when there is a forwarder. This
is where checking originating addresses can help. I see this as an
alternative to whitelisting your forwarders. While per-user whitelisting
may be practical at a small site, it sounds hard for a large one. Global
whitelisting is more practical at large sites, since they have the resources
to audit the forwarders. Validating originating addresses directly, where
possible, is an alternative to whitelisting forwarders.
Note that SES/CBV and DBBF are incompatible in the sense that if
a forwarder
implements DBBF only, there is no way to extract the originating domain
for SES/CBV.
Yeah, I've been aware of that. A DBBF forger is virtually impossible to
detect, unless you have a whitelist of trusted forwarders. Perhaps you
should only accept DBBF forwards from a trusted forwarder list? I'm not
sure what a good answer is here.
So making SES with CBV (preferably via DNS) available as a tool for
the mail recipient is great. But ultimately, the sender is depending
on the vast majority of mail recipients in the world to behave
responsibly.
Not the vast majority of them, just enough of them to reduce the delivery
rate of forgeries. By taking away their trojaned proxies, and having a
significant fraction of sites able to reject forged forwards, we may be able
to reduce their delivery rate enough to make them unprofitable.
If the recipients behave responsibly, the existing SPF+SRS set up is
adequate.
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. If you
can't detect a forgery before DATA and you won't do any 2822 tests until
after the end of DATA, you will accept a lot of stuff you shouldn't.
Unfortunately, the vast majority of systems that receive mail
have clueless
sysadmins. It is often claimed that SES protects the sender from bounced
forgeries. This is only true if the recipient machine behaves
responsibly by
rejecting mail it can't accept or sending DSN for mail it found a virus
in or whatever. What actually happens is that the the recipient
machine sends
regular mail to the ostensible sender for every spam it receives,
becoming a
relay for spam. Windows anti-virus software is the worst culprit.
So my point is that so far the focus has been on combatting evil/clueless
mail *senders*. I can't see at the moment how anything proposed
combats evil/clueless *recipients* who reply to all the spam they receive.
Blacklisting is problematic because there are far more Windoze users
than spammers. Content filtering works by learning to recognize these
bogus mail scanner replies. However, the goal of SPF IMHO is to
reduce the
volume of spam that gets past DATA.
Nothing can stop anyone from doing anything. You can give people the means
to detect forgeries, but they don't have to use it. The better you make
those tools, the more junk the responsible providers can reject before DATA.
Irresponsible recipients will continue to spew viruses to innocent third
parties disguised as DSN's until people get sick enough of it to start
blacklisting them. I don't think anything else will get them to do
anything. They are clueless, not malicious, and they don't even know they
are contributing to the problem. They probably think their virus "warnings"
are a service to others.
Until such time as sites that spew viruses, worms and virus warnings to
innocent third parties become the target of blacklists, it makes a lot of
sense to try and protect yourself from the bogus bounces. If you want to be
responsible, you should also either limit your forwarders to a trusted list
or come up with some way to validate originating addresses so that you don't
contribute to the problem.
Even if we have the system in place to validate the original sender,
it doesn't stop the vast majority of forged bounces.
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
blacklisted, site admins will eventually realize that to recognize
forgeries, and thus stop sending DSN's to them, they need to either
whitelist their forwarders or check originating addresses. I suggest that
having both mechanisms in place increases the likelihood that one of them
will be implemented, once the clueless are forced to realize they have to do
something. But I do realize that whitelisting trusted forwarders
accomplishes the same thing as doing originating sender checks. The key
question here is, "can the majority sites implement a trusted forwarder
whitelist"? If they can, originating address validation is unnecessary. If
they can't, this is an automatic process that doesn't require continual
updating and is easy to implement for recipients. It does require senders
to provide the DNS infrastructure to answer the queries. However, if a
sender wants additional spoofing protection for their domain name, it is a
relatively inexpensive way to get it.
--
Seth Goodman