SMTP-AUTH is currently at proposed; while Rob Siemborski has started the
ball rolling on revising it (draft-siemborski-rfc2554bis-04.txt), its
normative references form a pretty hefty dependency tree. I personally
believe we'll be able to advance the sieve base spec to draft before
SMTP-AUTH gets there.
I see. So basically it's the decision of getting the Sieve base
specification out the door soon and have an envelope-auth extension,
or possibly wait a long time just due to dependencies, plus being unable
to advance any of the Sieve extensions, because they reference the Sieve
Sounds like Usenet hierarchy modification decisions. :-/
Umm, what's the point in implementing it to always return the empty
string? IMHO, an implementation should only advertise and support
envelope-auth if it implements and is configured to support SMTP-AUTH.
Right now, we appear to have three kinds of implementations:
o Anything but "to" and "from" returns an error.
o Anything but "to" and "from" is being ignored.
o Anything but "to", "from" and "auth" is being ignored.
RFC 3028 appears to allow all three, because it simply does not specify
what happens if anything but "to" and "from" is used, and that is not
Your suggestion puts a SHOULD on the first option, which does not cause
the other options to violate the spec. It just specifies previously
unspecified behaviour. It may as well define what "auth" does (apart
from the formal reasons above).
If the AUTH= parameter wasn't used, shouldn't the envelope "auth" part
never match and _not_ be the empty string, like an absent header used
with the "address" test?
Correct me, if I am wrong, but as I see it
MAIL FROM: <addr-spec> AUTH=<>
means the same as
MAIL FROM: <addr-spec>
although the first example formally specifies the authenticated sender.
MTAs are in fact free not to trust AUTH=, acting as if AUTH=<> or no
AUTH parameter was being passed. Treating all three ways as setting
the authenticated sender to the empty string makes sense to me.
If an implementation always returns the empty string, it means it never
trusts the authenticated sender information. That is perfectly legal,
so implementing "auth", should the base specification require to do so,
is very easy. I don't think anybody would in fact do that, but it is
an easy upgrade path for existing implementations for being compliant
with the new spec.