Paul Smith wrote:
I haven't seen anyone really advocate switching to using
accept and bounce instead of immediate reject - because of
the forged email address issue, and subsequent back scatter.
It's the other way around, (2)821 advocates "above all try to
deliver or forward" with 'reject' as exception and 'drop' as
worst case. It was designed for a system where the majority
of SMTP sessions were not attacks or side-effects of attacks.
I hope we have consensus that 'drop' still is the worst case.
All 2821i can do is swap the top priorities, avoid to 'accept'
blindly because 'accept and drop' is worse than 'reject'.
Most details how that's done are out of scope, but timeouts
might be relevant, If we'd manage it that many legit mails
are never accepted it's "game over - tilt" for SMTP.
there need to be several things in RFC 2821 bis
- a reduction of the recommended timeout values, eg for the
post-DATA timeout to be reduced to 1 minute
Modifications of timeout parameters in a protocol are tricky,
we're not interested to break interoperability for conforming
(2)821 implementations. If existing clients are "impatient"
it's of course their problem, and maybe some (2)821 timeouts
are a bit too generous.
But generally changing any protocol parameters is as dangerous
as adding or removing critical dots in the ABNF of commands.
(Remember, in all this discussion, no one has requested that
the suggested timeouts in 2821 be increased, so if they were
used, 'keep alives' wouldn't be needed).
Indeed, let's ignore "impatient" (non-conforming) clients.
- a clarification that any checks for RFC 2821 timeouts
should be the time until the final reply code, not
continuation reply codes.
ACK, 2821bis should be no part of a "teergrubing FAQ".
- a discussion of accept/bounce later cf reject immediately,
and consequences of using either technique
Yes, strictly compatible with (2)821, but get rid of the legend
that "bounce later" is always the best and/or required way. It
is abuse, dumping the side-effects of a major 1123 design flaw
into the mailboxes of innocent bystanders.
- a discussion of what to do with time consuming email
validation techniques (eg reject immediately, quickly, and
then either accept/bounce or accept/discard later,
depending on trustworthyness of sender email address).
IMHO the fine print of various wannabe-antispam solutions is
out of scope. 2821bis only needs a different POV on the same
SMTP as we know it. The (2)821-POV was "the mail must flow",
and now it should be "most mail traffic is in fact an attack".
- a clarification that continuation reply codes should be
consistent with the final reply code.
Yes, and replace that 123- example by another code. Bye, Frank