ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25

2007-04-30 15:18:56

John C Klensin wrote:

I believe that we cannot "make it permissible" to silently drop
messages

Yes, that part makes me also very nervous without going into some
details under which conditions it's permissible.  One thing that's
apparently common practice is to delete mails identified as worms
by some piece of software.  The justification is that it's not
acceptable to put them into the mailboxes of clueless users, and
that it's of course also not acceptable to forward them to the
alleged senders claiming that it's a case of "MUST bounce".  But
my ISPs at least all asked me to permit this practice for worms
sent to me.  Or one ISP didn't ask me but "informs" me when it
deleted mail for me, where it thought that it might be a worm or
phish - resulting in hundreds of notifications per day :-(

Any strategy where users (or some years ago postmasters) are
supposed to wade through tons of spam, and try to identify the
false positives is a hopeless fig-leaf for "silently drop".

there are all sorts of perfectly good reasons why one would not
be able to validate the forward and reverse paths at the same
time.

There are also all sorts of perfectly stupid reasons to avoid
this trouble, based on "2821 allows accept and bounce", or it
actually propagates "accept and bounce".  And that's wrong, it
should propagate "reject a.s.a.p. or else you're in deep sh*t".

I believe that people who are advocating such things need to
generate documents and push them through on the standards track,
creating new requirements and new mechanisms, but paying
attention to the whole set of issues associated with keeping
mail delivery predictable and reliable,

Most SPF folks did propose standards track _and_ IETF Last Call,
they also did *not* support to close MARID precisely at the time
when the WG concluded that MS Sender-ID is technically flawed.
<http://purl.net/xyzzy/home/test/MARID.appeal.txt> (unconfirmed)

If you ever wonder why I'm so interested in all these procedural
questions, which is kind of overkill for two I-Ds.  Here we're not
discussing the merits of SPF, or if it's the most baroque solution
for an in essence simple 2821 problem, here we need to mitigate
the 2821 problems for folks deciding to use SMTP without SPF.

For starters 2821bis has to admit that there are serious problems
in its post-821 design, and that those 2821 design problems force
receivers to prefer "reject" instead of "accept" at their border.

Because if they don't do this and drop accepted mails silently
the whole design renders SMTP unreliable.  And continuing to send
bounces to innocent bystanders also doesn't cut it when the error
reports are automatically trashed as noise.  The design has to
encourage that "good" bounces are sent to the originator.  But I
don't see how 2821-SMTP can _enforce_ this without getting into a
"trash as noise" trap, with a similar effect as "drop silently".

if we destroy whatever system is being attacked in order to
fight off the attacks, the bad guys win.

If we ignore the attack and stick to "accept and bounce" the bad
guys also win.  We've to move the defenses to the border, where
they belong.

I think that is the tip of a much larger iceberg.

Yes, and the iceberg has a number, 2821.

Frank