ietf-smtp
[Top] [All Lists]

Re: Anything else on the content?

2006-10-29 22:55:52

Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

...MON (mail originating network) + MRN (mail receiving network) .

The MON + MRN abstraction is much simpler, there's a sending
side, no matter how they organize it, e.g. MUA + MSA + "mail
out" (this could be already two ADMDs, if "MUA" is actually
an arbitrary customer of one or more mail providers).  Throw
in a 3rd party (DKIM signer or what else), and it is still a
single MON - but with ADMDs you'd already have three ADMDs in
this scenario.

And there's a receiving side MRN, starting with the MX, no
matter how that's organized on behalf of the receiver.  It
could be an outsourced backup MX + primary MX + 3rd party for
virus checking + MDA + (independent) end user, resulting in
four ADMDs.  But for the architecture the abstraction "MRN"
would cover it, anything else is the internal business of the
MRN.

All details within a MON or MRN (like how many ADMDs) aren't
interesting, the critical point is when an MTA has to lookup
the MX, i.e. when an "unknown stranger" talks with a server.

At that point the responsibilty for delivery passes from the
MON to the MRN, that's where the MRN either must be sure that
it can deliver, or it must be sure that it can report errors
to the originator, or it must reject the mail.  Otherwise it
screwed up, and is forced to drop the mail, or to participate
in abuses of forged envelope sender addresses.

   I don't agree with Frank's ultimatum-like tone here, but this
is a real issue; and we need a way to talk about it.

   Backscatter is sometimes intended as a Denial-of-Service,
though more often simply a way to get spam past folks that
check for a "valid" RFC2821.MailFrom. Regardless, it often
exceeds the volume of useful email, and its volume is growing.
I expect folks will be finding themselves blacklisted for
"generating" too much of it.

   The issue lies exactly where Frank says: any MX server that
accepts email which it _may_ not be able to deliver has a
responsibility to evaluate the likelihood that the 2821.MailFrom
is useful: no later MTA will be in any better position to do so.

   IMHO, we'll never eliminate backscatter; but there must be
alternatives to blindly accepting millions of probably-false
2821.MailFroms.

   If we don't discuss it here, we're doomed to watch email
become even less useful as misguided folks implement "solutions"
which shift "responsibility" even farther from the point where
something reasonable can be done.

--
John Leslie <john(_at_)jlc(_dot_)net>