Frank Ellermann wrote:
SM wrote:
We should also consider the legacy systems out there. A complete
reversal to reject, no bounces, makes the model unreliable.
+1 We're not going to copy the SpamCop FAQ wholesale into 2821bis.
( Nevertheless I've invited the SpamCop newsgroup readers to chime
in, some have rather radical ideas compared with what we say. :-)
450 I think we should avoid specifics of how mail is rejected.
IMO, at a minimum, SMTP compliance should be the only SMTP reason for
rejection. This is already implied as possible with strict SMTP site
considerations.
Outside of that, it is policy driven and I think, at least for me, why I
endorse the MUST for the delivery/failure notification behavior of SMTP
is a separate issue than the how a POLICY can alter that.
The same idea is found in POP3 operations and the specs specifically
says that SITE POLICY rules over user POP3 software mail retention
features and POP3 commands to keep/delete mail.
In other words, even though a MUA says
[X] Keep mail at server for _7__ days
[X] Delete mail after _30_ days
[X] Or until I delete it offline.
It has NO control over that the server site policy says about mail
storage, retention or deletion. Absolutely none, whatsoever, and the
POP3 specs make that very clear, and at least the Outlook MUA F1 Help
makes very clear.
The point?
The POP3 still defines the commands and defines what is the expected
technical behavior with the commands. Same with SMTP with what is
expected with 250/450/550.
But site policy can change all that so this is where the responsibility
lies - with the site.
I think CBV isn't specified in any RFC, and so we can't add a
reference to it. Similarly there's no RFC for grey-listing,
SRS, SES, CSV, or BATV. Referencing RFC 4409 chapter 6.1 should
be okay. For 4408 I'm not "neutral" (4409-1=4408 is nice :-)
Maybe one example 4409 6.1 is enough.
550- I don't think we should have any references to any validation
550 concept in 2821bis. Maybe for 3821, perhaps? :-)
I think, IMO, the best we can do is at this point is to convince John,
Tony, that "responsible" VALIDATION is important and since it is a
reality in practice, to help clarify the specifics for expected SMTP
behavior to help keep a high reliability of the framework.
I personally think most of that is done, maybe too spread out and not
consolidated enough as I would personally prefer, but I think we are
almost there - for this draft at least.
--
HLS