Subject: Re: 3028bis open issue #2: unknown envelope-part names

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Jul 2005 11:30:53 +0100

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.
>  
>

---

From: Michael Haardt <[email-masked]>
Date: Fri, 15 Jul 2005 12:19:32 +0200

> 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
base extension?

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
good.

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.

Michael