Alexandros Vellis <avel(_at_)noc(_dot_)uoa(_dot_)gr> writes:
Alexey Melnikov wrote:
I still think that an implementation should treat an unrecognized
envelope part as an error. Scripts should not be using a feature without
a proper require statement.
I don't feel strongly about my vote, and I'm not a guru of SMTP
protocols either, so as long as the 'auth' is added in the
clarification, that's fine with me too. 8-)
I think we have to choose among the following:
A) leave the behavior undefined if a script uses envelope-parts other
than "from" and "to"
CONS: such parts (ala "auth") effectively become undeclared, unnamed
extensions; scripts can't depend on support; no way to test for
support (e.g., in managesieve)
PROS: breaks neither existing implementations nor existing scripts
B) require implementations to reject parts other than "from" and "to"
unless declared via some new extension
CONS: makes Cyrus implementation non-conforming; breaks scripts that
haven't been updated to require the new extension
PROS: <standard "declare before use" argument>, scripts using "auth"
aren't portable anyway
C) require implementations to ignore all unknown parts, or maybe just
"auth"
CONS: breaks lots of implementations; script behavior could change if
an implementation started recognizing new parts
PROS: doesn't break existing scripts using "auth"
D) roll "auth" into the base-spec
CONS: breaks lots of implementations; have to define what it means in
implementations that don't have access to SMTP/LMTP AUTH info;
why have an extension mechanism if we're not going to use it?
PROS: doesn't break Cyrus implementation or scripts using "auth"
It sounds like you're suggesting (C), yes? Do yo have any comments on
the pros and cons in the above list or the tradeoffs among them?
Philip Guenther