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

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

Philip Guenther wrote:

>Alexandros Vellis <[email-masked]> 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
>  
>
Cyrus can be extended to have a compatibility option to accept "auth"
without a proper "require". I don't think this is a big deal.

>   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?
>  
>
I advocate B. I personally don't have a problem with defining "auth" as
an extension in the base document, but I wouldn't object to it being in
a separate document either.

I dislike C and A.

---

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

Alexey Melnikov wrote:

>> another is whether the spec should have an opinion on
>> whether the error should be detected at parse/compile time or at
>> execution time (I'd either go with either the latter or unspecified).
>
> IMHO, my general answer to this is "as soon as possible". But if Sieve 
> "variables" are also implemented, it might not be possible to check 
> this until runtime.

And this also suggests that if such errors are detected at runtime, they 
should not cause script execution error.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Jul 2005 17:08:42 +0100

Mark E. Mallett wrote:

>On Wed, Jun 29, 2005 at 02:01:31PM -0700, Philip Guenther wrote:
>  
>
>I'd go with this one.  I've silently ignored others up until this
>point but have had a long-standing private implementation note that
>it needs to be resolved, vis:
>
>TODO    /* Not really clear if this is an error- but for now we'll
>           just treat it as a non-match or a zero count.
>        */
>  
>
>There are other dimensions to the question, of course.  One is whether a
>prohibition under (B) will be a "SHOULD NOT" or a "MUST NOT" (MUST NOT
>seems better to me, but SHOULD NOT will work better as a retroactive
>recommendation);
>
As a user of Cyrus Sieve I would obviously prefer SHOULD NOT here.

IMHO, my general answer to this is "as soon as possible". But if Sieve 
"variables" are also implemented, it might not be possible to check this 
until runtime.

---

From: Alexandros Vellis <[email-masked]>
Date: Mon, 04 Jul 2005 21:23:02 +0300

On Wed, 2005-06-29 at 18:16 -0400, Mark E. Mallett wrote: 
> recommendation); another is whether the spec should have an opinion on

Based on the above comments, with which I wholeheartedly agree, I would
like to propose actually adding the envelope-auth capability in the base
spec. It is only a matter of one more paragraph clarifying the "auth"
value to the envelope argument.

I would like your comments on the following amendments:

5.4.
(......existing paragraphs:)
   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL
   command.

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is available, and only the one relevant
   to this user.

----------------------------
(....add this one:)

   If one of the envelope-part strings is (case insensitive) "auth",
then
   matching occurs against the value of the AUTH argument to the
   SMTP MAIL FROM command, as described in [SMTP-AUTH], section 5.
   Only implementations that advertise the capability "envelope-auth"
   should accept "auth" in the envelope-part string lists.

----------------------------
(....and this one probably?)

  Any other strings other than "from" or "to", as well as "auth" 
  envelope-auth is supported by the implementation, SHOULD
  result in an error.

(Probably someone can elaborate and describe better than me how this
error could be handled).

----------------------------
(...and this capability registration, but I'm not sure if a more formal
procedure for this is needed:)

   Capability name:        envelope-auth
   Capability keyword:     envelope-auth
   Capability arguments:  as in "envelope"
   Standards Track/IESG-approved experimental RFC number:
           This RFC (Sieve base spec, first revised edition)
   Person and email address to contact for further information:
           The Sieve discussion list <[email-masked]>

----------------------------
...and, LTBNL, probably add this informative reference as well:

[SMTP-AUTH]  J. Myers,  SMTP Service Extension for Authentication, March
1999

Alexandros

---

From: Philip Guenther <[email-masked]>
Date: Thu, 14 Jul 2005 20:00:11 -0700

....
>value to the envelope argument.

Unfortunately, it's a bit more than that: I'm fairly certain that the
SMTP-AUTH reference would need to be normative ("...must be read to
understand or implement...").  Rather than involving 3028bis in the
tangle that moving any sort of authentication protocol along the
standard track appears to be, I suggest the envelope-auth extension be
defined in a separate document.

Anyway, for now I've amended the first paragraph of section 5.4 to read:

   The "envelope" test is true if the specified part of the SMTP (or
   equivalent) envelope matches the specified key.  This specification
   defines the interpretation of the (case insensitive) "from" and "to"
   envelope-parts.  Additional envelope-parts may be defined by other
   extensions; implementations SHOULD consider unknown envelope parts an
   error.

Perhaps I'm misreading the work/pain implied by the SMTP-AUTH reference.
Do those with more experience think it'll be easy?

Philip Guenther

---

From: Michael Haardt <[email-masked]>
Date: Fri, 15 Jul 2005 10:51:11 +0200

>    extensions; implementations SHOULD consider unknown envelope parts an

Good, that closes this long-standing issue.

> Do those with more experience think it'll be easy?

I am not sure I understand what you are talking about.  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.

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.

Michael

---

From: Philip Guenther <[email-masked]>
Date: Fri, 15 Jul 2005 02:35:32 -0700

>On Thu, Jul 14, 2005 at 08:00:11PM -0700, Philip Guenther wrote:
...
>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

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.

>sender address is available, it is the empty string.  Feel free to correct

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Jul 2005 13:31:24 +0100

>Do those with more experience think it'll be easy?
I personally think that it would be quite difficult to move the whole 
chain of SMTP-AUTH references (SASL (2222bis), ...) to Draft. So a 
separate document would be better.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Jul 2005 13:39:10 +0100

>envelope-auth if it implements and is configured to support SMTP-AUTH.
I agree.