Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
IMHO, I think that we should focus on RFC2821 HELO and in-addr.arpa
first since they seem to break the least amount of things.
That's a funny reason -- sounds a lot like the drunk searching for
his keys next to the street-light because "the light's so much better
here!".
We should be working to fix the most things. One can always break
the least things -- by doing nothing.
Also, if HELO arguments are domains then it is possible to apply
reputation and accreditation services based on domain names.
I'd be delighted to talk about those -- but I really believe it
will be ruled out-of-scope.
(OTOH, perhaps the chairs won't actually rule anything out of scope
until the IESG acts on our charter. If you want to chance it, I'm game.)
I am less enthusiatic about MAIL FROM checking since I do not see
how it will reduce spam in the long run without reputation (i.e.
vanity domains).
Reputation mechanisms (blacklists and whitelists) will certainly
continue regardless of what we do. And most of these will be pretty
orthogonal to what we do.
Most of us believe we'll have to encode authorization for RFC2822
From headers (etc.) to have a big effect on spam. People agree to
postpone that work because it's harder and will take longer.
If the entire purpose of MAIL FROM checking is to introduce a
hook for reputation, than HELO with domain names will satisfy that.
That is simply _not_ "the entire purpose". I don't even believe
it is a major purpose. The purpose of RFC2821 MAIL-From checking is
to get a useful bounce address, so that we don't have to catch all
the problems during the SMTP session. (Otherwise we're faced with
the _serious_ problem of error messages not reaching someone who
can fix the error, and the slightly less serious problem of error
messages confusing persons in no way involved in the transaction.)
Simply reducing bounces from joe jobs does not seem a good enough
reason for me to break the store and forward functionality of email
and forbid many legit uses.
At some point, we need to outline and discuss all these "legit
uses" which will supposedly break. The majority of us (IMHO) don't
believe there are very many of them which aren't _already_ broken.
The main problem here is how to tell whether an MTA should be
trusted.
"Authorized" is an entirely different concept from "trusted".
(Among other things, they're at different ends of the transaction.)
Because something is "authorized" by the "sending" domain doesn't
mean the "receiving" domain will trust it. (That's where reputation
services come in.)
And "trusted" does no good if errors can't be reported to
someone capable of fixing problems.
HELO or in-addr.arpa checking combined with reputation/accreditation
systems should be sufficient for that.
In case you missed it, the majority of spam now comes with forged
RFC2822 From headers. Many perfectly "trustworthy" MTAs copy this
into the RFC2821 MAIL-From. The ones _I_ consider "trustworthy"
would do something about the problem if they learned a machine
they trust (yes, they legitimately "trust" machines which may later
be compromised) is spamming. But misdirected error messages greatly
reduce the chances they'll learn about the problem promptly.
Once you establish a trust level of a given MTA, than you can trust
that MTA to provide you with non-forged headers and bounce addresses.
You're welcome to "trust" whatever you want. (Many people trust
Congress to write good laws! I can't stop them.)
But I certainly won't "trust" that far -- because I know what
conditions those folks are working under, and working under those
conditions no human being could prevent forged headers. And even
if they could supply good bounce addresses, bureaucratic inertia
would keep it from happening.
If you trust a specific MTA to trust its incoming MTAs further
down the line, then you might be able to keep the store and forward
functionality intact.
Trust is seldom transitive. (Never say "never"!)
Besides, we're not going to "break" store-and-forward. Really!
Many domains are going to continue to channel outgoing email through
well-known systems they consider "trustworthy". They will include
those systems in their "known-good" set. And many domains will have
receiving SMTP servers outside their firewalls, distributing to
systems inside their firewalls; and it will be those initial systems
which implement the rejection of email from "non-trusted" MTAs. So
long as error messages are returned promptly and correctly, any
problems will be quickly fixed.
I've been dealing with the spam problem long enough to know that
problems like that are _much_ simpler than dealing with two or more
misdirected bounces per good eamil. Users will be _much_ happier to
deal with resending the relatively few emails which don't go through.
(They're used to that already!)
As for From and Sender headers, I think that other mechanisms can
do the job better such as DomainKeys
Yahoo, right? Public-key cryptography has been promised for so
long that it's beginning to resemble Brooklyn-Bridge-selling. ;^)
Seriously, I wish them all the best; but I wouldn't bet on it.
or passing the informaton explicitly in SMTP such as in SMTP AUTH's
MAIL FROM extension for passing author's address.
SMTP AUTH has an important role to play, IMHO, but that isn't it.
Its role is to enable travelers and mobile users to authenticate
from unexpected locations -- a small minority of email usage.
I don't want to minimize the difficulty of solving very much of
the spam problem with DNS information about RFC2822 From headers.
But it can have excellent results for a large class of users that
are happy to send everything through the same (few) MTAs; and that
includes many of the most serious problems. (It might even stop
the continual storm of "latest Microsoft update" viruses!)
--
John Leslie <john(_at_)jlc(_dot_)net>