Michael Haardt wrote:
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"
Authenticated SMTP is common these days and being able to use it in the
envelope test makes sense to me. The Exim implementation currently
rejects anything but "to" and "from", but I had no problem to add
"auth", thus having one broken implementation less. Although I don't
like how Cyrus silently introduced it, it _is_ useful and having to use
"envelope-auth" besides "envelope" looks awkward to me. Opinions from
other implementations? Would the change be a problem?
But: What does "auth" actually do? Does it contain the authenticating ID
or the authenticated sender?
It uses value of the "AUTH" MAIL FROM parameter, which is authentication ID.
Neither is a problem for me, I just have
to know. Implementations that can not access this information could
behave as with comparing header fields not present in the message.
That is why the option B is better: implementation that can't access it
will not support "auth".
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
If we decide that D is not an option, this is my second choice. Silently
ignoring mistakes never pays off in the long run, so let's stay safe
and clean. Cyrus should not have introduced a new feature that way,
but indeed RFC 3028 was not clear how keys other than "from" and "to"
MUST be processed.
I don't like A and C at all.