John C Klensin wrote:
I thought we had closed that issue out
I thought you had just assigned issue 21 to 0b. I think it's
really important, it's THE issue, but...
I'd like to assign an issue number
...I don't see why it should get a third issue number.
My impression is that the general issue of prohibiting sending
out an NDN message when it cannot be definitively rejected at
SMTP envelope time has been ruled out of scope.
This is not THE issue. Nobody *here* supports to *prohibit* all
NDNs. If MTAs are confident that they know how to send an NDN
to the originator when necessary, or if they're confident that
they don't have to send a NDN, they can simply accept the mail.
THE issue is that they must be really confident, because they
MUST send an NDN to the *originator*. And no weasel words about
"as indicated in the reverse path" - in another article you just
proposed to move the old routing cruft into appendix F.2 with a
clear "DON'T DO THIS".
examples have been given in which it is impossible to make
the decisions while the server still has the connection
open from the client
It's always possible to decide "accept or reject", if nothing
helps they could use a random number generator. Or your "odd
IPs only on Tuesdays" recipe. But in a standard readers would
look for some better guidance, and the standard must not only
offer "as indicated in the reverse path" - this is would be an
"821bis" design. It also must not directly (or between the
lines) say that "accept" is always a good decision, because
sending an NDN later "as indicated by the reverse path" is no
problem. It is only no problem for a hypothetical "821bis" or
its SPF PASS reincarnation.
In other words it is a serious problem for most mails today,
and 2821bis cannot pretend that "reverse paths" still work as
designed in RFC 821, or hide THE issue behind smoke screens.
To take just one example
JFTR, I post such examples often on the spamcop list, I think
their FAQ is too simple. Of course most "misdirected bounces"
are still clearly avoidable, and then it's IMO okay to punish
such "bouncers" as hard as possible. The "bouncers" will then
(try to) quote RFC 2821, claiming that they MUST bounce, and
that RFC 2821 nowhere admits that its model is broken when the
reverse path has nothing to do with the originator. As it's
the case for most mails today.
Requiring that servers of either type have current knowledge
of deliverable addresses is technically burdensome
Yes, and ? Who should pay for such misdirected bounces, the
victims ? Just move the crap into some poor end user mailbox
where they can POP it with V.90 doesn't fly. Sooner or later
they'd be forced to reject or delete all bounces. So by NOT
trying to discourage this behaviour you'd get precisely what
you don't want, an SMTP with "de facto" prohibited bounces.
All participants have to share their part of this burden. Not
only the receivers, as the spamcop FAQ suggests, but certainly
they are a key. And for that 2821bis is important, because
receivers (like everybody else) are lazy and greedy, they will
say "MUST bounce" as long as RFC 2821 can be abused to justify
their misbehaviour.
The backup MX in question could temporarily block all mails
where the mail from + source IP is in any way suspicious. It
will cause some backscatter, but it can limit this damage to
some degree. Nobody *here* (as opposed to the spamcop list)
is expecting miracles. Just some minimum of common sense and
good will based on a realistic description that the originator
from the POV of this backup MX is in most cases NOT indicated
in the reverse path.
We have, historically, tried to encourage such intermediate
MX-associated servers as a means of making the Internet
accessible to more people and keeping the mail system as
robust as possible.
Historically the spam ratio wasn't 80%. And historically
forging reverse paths was a taboo, I recall a mail abuse FAQ
published in 2002 saying that this is a "social" problem, and
that such spammers are scam. At that time I couldn't nail it,
but I doubted that it's a _social_ problem, it was completely
against what I thought a reverse path is, _technically_
In 2003 I read an article about Hadmut Danisch's RMX draft,
and suddenly it was all clear (minus one bad day when Tony
told me that RFC 1123 is no nonsense, but a part of STD 3):
This is a BUG. "They" - likely some "they" including you -
screwed up royally when "they" wrote 1123, and somebody has
to fix it. IMHO 2821bis also has to share its part of this
collective burden.
And that is how I interpret issue 0b or 21 or 26, THE issue.
the consequences of going to a "never bounce" model are
fairly large
Absolutely nobody with an SPF PASS or FAIL policy could wish
that, bounces are essential for its 551 emulation (i.e. when
receivers forward their mail to a third party without noting
this fact in the reverse path, and when this third party
then rejects the unmodified reverse path resulting in FAIL)
I don't think it is in scope for the 2821bis effort.
It's completely out of scope of anything remotely related to
SMTP, "never bounce" is as bad as "accept on probation", or
maybe worse.
Frank