Ken Murchison wrote:
Barry Leiba wrote:
* Consensus -- as I recall it -- was to use two actions:
1. Leave the current action alone, but add text that says that
implementations MAY use protocol-level reject if and only if the
response text is US-ASCII.
Agreed.
That is my recollection as well.
2. Add a new action that ONLY accepts US-ASCII response text, and
that MUST use protocol-level reject.
Did we actually have consensus on disallowing UTF-8
No, this wasn't discussed in San Diego.
I think we've discussed this before and decided that ereject will
replace non-US-ASCII with an implementation defined US-ASCII string. I
would rather not revisit this decision.
for ereject and that it can't issue MDNs?
I think we hummed for "ereject can use protocol level refusal or
generate MDN". It sounds like we don't have a consensus on the "or
generate MDN" part yet.
The former seems too strict given that a future SMTP extension might
allow non-US-ASCII text in responses.
Agreed.
The latter prevents scripts from being portable.
I thought we were going to leave how best to do the reject/ereject up
to the implementation (based on environment, etc), but weighted by the
fact that by using ereject the user is placing a priority on protocol
level refusal, and by using 'old' reject the user is placing a
priority on sending the exact reason string.
Indeed, this is how I was thinking about the two actions.