Michael Haardt <michael(_dot_)haardt(_at_)freenet-ag(_dot_)de> writes:
On Thu, Jul 14, 2005 at 08:00:11PM -0700, Philip Guenther wrote:
...
Perhaps I'm misreading the work/pain implied by the SMTP-AUTH reference.
Do those with more experience think it'll be easy?
I am not sure I understand what you are talking about. <...>
I was referring to the procedural issues it creates. A protocol cannot
advance any further on the standard track (proposed->draft->full) than
the protocols/documents for which it has normative references.
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.
In case you ask
how easy it would be to upgrade existing Sieve implementations to support
"auth", if nothing else to return an empty string: I will implement that
in Exim these days. Cyrus already has it and one other implementation,
too.
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.
I don't think there are disagreements on its specification. I understood
it that way: For SMTP, it is the AUTH parameter to MAIL FROM, in case
the mail system trusts that information (RFC 2554, section 5). For other
protocols, it is the authenticated sender address. If no authenticated
sender address is available, it is the empty string. Feel free to correct
me, if I am wrong.
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?
Philip Guenther