Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> wrote:
From: John Leslie <john(_at_)jlc(_dot_)net>
This is where I must disagree. Whitelisting something as easily
forged as the From address is simply wrong -- and if it is published
rule, we're sure to see spammers forging whitelisted From addresses
as their standard operating practice.
As is true of many theories about what spammers do or will do, practice
differs from (simplistic) theory.
You're welcome to build your organization on the assumption that
spammers will continue doing the same thing they do today -- I choose
to design for what they're likely to do next month...
In the real world, whitelisting by sender works fine and is not abused
often enough to matter.
Seems to be true today...
Whether it works today because it is rarely used is a secondary issue
good for no more than trying to predict the future.
I draw a distinction between "predicting" the future and "planning for"
the future. "Planning for" the future requires being ready for things
which may not be the "most likely" outcome.
Thus, I'm not betting on what spammers will do next month. I'm hoping
to be prepared for a number of different scenarios.
Yes, I know that spammers often forge source addresses. I get more
than my fair share of demands from lusers that I unsubscribe them from
this or that stream of porn or other offensive spam.
Good to know you're aware of this.
Nevertheless, such problems are trivial in this context.
Today, maybe...
That reasoning involves a second error common to IETF talk about spam
and mailing list noise. It is the academic pretense that all failures
are of equal gravity and completely unacceptable.
I really don't know who you're talking about here. Certainly I have
said nothing remotely like that.
In this case, the failure mode that supposedly makes whitelisting by
sender unacceptable is merely leaking a little spam.
I work on a simple-minded principle: if you want more of something,
arrange to reward it. I choose not to reward spammers for forging
_obvious_ From addresses.
If, OTOH, Vernon would like to whitelist the combination of From
address and IP address of the sending SMTP server, that could be a
very worthwhile practice, virtually immune to spammer forging.
If you mean manual whitelisting,
No, I don't.
that sounds good in theory, but fails in practice. I've experience
with various sorts of whitelisting, because the DCC depends on
whitelists to distinguish solicited from unsolicited bulk mail.
Whitelisting by IP address fails in practice because so much bulk
mail comes from so many different and changing SMTP clients.
I'd actually enjoy discussing this issue.
However what I was discussing was whitelisting the _combination_
of From address and the IP address that sender normally sends from.
Until senders figure out how to forge the IP addresses of sending
SMTP servers, this should make the whitelist pretty safe.
For an example at the small end of the spectrum of bulk mail sources,
I've had to regularly change the whitelisting for IETF mailings.
Bigger legitimate bulk mailer often have too many SMTP clients for
outsiders to count, not to mention manually whitelist.
I seriously doubt we need to worry about IETF contributors who
send through more than a few dozen IP addresses. Even if we do, it's
still easily automated. I see no scaling problems even with 1,000
different IP addresses a contributor sends through.
You must find other ways to whitelist them.
Perhaps, if you're doing it manually...
However, whitelisting bulk mail by IP address is trivial compared
to whitelisting private mail by IP address. I use greylisting (see
http://www.dcc-servers.net/dcc/greylist.html ) which can be described
as automated whitelisting by the triple (sender,sender-IP-address,
target).
An interesting concept. I haven't tried it -- though I have used
something a bit close -- imposing 50% packet loss on IP ranges which
seem to contain many open relays. I find that legitimate email gets
through, while spam is significantly slowed. (Obviously I don't
consider this a "solution", just a stop-gap.)
It works well, but only because it is automated and it uses 4yz
soft failures. Many ISPs start sending a single message from one
IP address and switch to another after a few minutes--lather and
repeat for up to half a dozen different IP addresses for a single
message.
Certainly an ill-suited tactic. (I can't help thinking we'd do
well to write up an info RFC about stupid SMTP tricks...)
It would be hopeless to try to manually whitelist the IP addresses
used by customers of such ISPs.
Not really, the way I'm thinking about it. Any combination not
already evaluated goes to a spam-evaluator (whether automatic or
manual): if evaluated as spam, an error is returned, if evaluated
as valid, the combination is whitelisted. I see no reason for any
manual process, with the possible exception of spam-evaluation;
and that I'd give the benefit of pre-processing by the likes of
SpamAssasin.
The ISPs that do this sort of thing are among the largest.
The largest ISPs seem to have the most broken email services.
I find _many_ people are learning to avoid those broken services.
Fortunately, there are easily-available alternatives -- which we
may need to strongly encourage because, alas, the largest ISPs
have the worst record for shutting down spammers.
--
John Leslie <john(_at_)jlc(_dot_)net>