Hector Santos wrote:
We are not going to see another 2821bis for a long time. The window of
opportunity is now with 2821bis.
Hi Hector, I don't see it as window of opportunity for the introduction
of NEW features.
Otherwise I'd propose to move in a mandatory FAIL rejection at the MX,
considering an emulation of the RFC 821 reverse path as more important
than anything else, TLDs trying to be hosts, servers trying to convince
broken clients to stay online, or other less important features.
The window of opportunity is IMO limited to mitigating the worst effects
of killing the reverse path while keeping 1123 5.3.6(a). If the new
2821bis has it clear that border MTAs cannot accept mail if they've no
clue how to return it if forwarding it fails, I'm fine with it. And of
course 2821bis is an opportunity to fix known errors and ambiguities.
The 1yz and multiline stuff is a good example for this. Maybe you've
seen that I supported (2a), in the form of a "SHOULD NOT be different",
that's very close to the almost unanimous winner (3).
And that was before somebody posted the very plausible recipe "collect
all reply lines into a buffer and take the first three digits as result"
corresponding to (2b).
As John wrote your concept should actually get a new "000- ignore me"
class of error codes, not 1yz, and adding this 000- trick would be a
NEW feature.
IMO 2821bis should be a PS if it doesn't make every compatible effort to
explain drastically what "originator as indicated in the reverse path"
actually means for a border MTA. Certainly _not_ "accept and discard",
IIRC proposed as possible "receiver policy" in the same (2b) article.
But I also think that this is the ONLY issue justifying a "recycle at
PS" strategy, if it's not addressed adequatly in a language understood
by any postmaster.
For the 000- idea (or any variant of it you pick), that's really a job
for a separate RFC, like the I-Ds about "selective reject" (indirectly
related to the bogus bounce issue), a status code registry, UTF8SMTP,
Alexey's LANG proposal, the quickstart QHLO, etc.
When you propose to add 000- (or similar) to the core spec. without an
extension resulting in a mutual agreement about it, it would break all
clients doing something with different codes in a mutiline reply that
you don't expect. That would be no "opt-in", it would be brute force.
I'd have better ideas than 000- if brute force would be acceptable...
Frank