Are you guys saying that current implementations do not conform to the spec or
are you saying that the spec should be changed to tell people to do things
And given that this all pertains to "SHOULD" labels rather than "MUST" I would
expect that the delta between spec and reality would need to be quite high, to
warrant changing the directive.
On Mon, 22 Jan 2007 22:24:27 +0100, Frank Ellermann said:
However there's no way that this rest can be a "draft standard"
without fixing another major problem in RFC 2821, the design
flaw to favour "accept and bounce" instead of "reject".
Unfortunately, I have to agree with Frank here - today's Internet isn't
the Internet of RFC821, and we really *should* take a very close look at
fixing that language even if it *does* mean another iteration at Proposed,
beecause if we don't fix it this time around, we'll be saddled with it
for years - RFC6821 is a long way aray.
Would tagging "accept and bounce" as a SHOULD NOT (with appropriate text
attached) be doable without resetting back to Proposed? I know "MUST NOT"
would cause such a reset, and even I'm not ready to stick *that* label on
"accept and bounce" - mostly because I've spent too much time working with
large-scale mail systems where the mailbox *was* valid when we sent the
far end the '250 OK', but had been race-conditioned into oblivion by the
time actual final delivery was attempted.