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

From: Philip Guenther <[email-masked]>
Date: Wed, 29 Jun 2005 01:06:36 -0700

The behavior of the 'envelope' test does not appear to be defined
for envelope-parts other than 'from' and 'to', ala:
	envelope "cc" "[email-masked]"

Should that be a required error, required to be silently ignored,
or implementation defined?

(The only opinion other than my own that I've heard on this felt
that it should be a required error, so if no one speaks up, that's
the way it'll go.)

Philip Guenther

---

From: Alexandros Vellis <[email-masked]>
Date: Wed, 29 Jun 2005 15:53:25 +0300

> that it should be a required error, so if no one speaks up, that's

I would actually vote for 'implementation defined' (first choice) or
'silently ignored' (2nd). :-)

Why? I was thinking of the LMTP AUTH that can appear in an {S|L}MTP
transaction:

MAIL FROM=<> AUTH=<user>

this could be mostly useful it it could be referenced to inside the
Sieve scripts.

Since it can be considered part of the envelope, one could use something
like :envelope "auth" "is" "avel" , and in the end use in the Sieve
script the information that a user was authenticated when sending a
message.

So in the end, "auth" should be allowed to be there, apart from 'from'
and 'to'.

OK, you could allow just that one through too, but what if more such
envelope "extensions" appear in the future? A bit difficult but
still. :)

Alexandros

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jun 2005 14:18:03 +0100

>So in the end, "auth" should be allowed to be there, apart from 'from'
I agree. In fact this is what Cyrus Sieve does already.

>envelope "extensions" appear in the future? A bit difficult but
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.

Alexey

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Jun 2005 09:30:07 -0400

> envelope "extensions" appear in the future? A bit difficult but

FWIW, CMU Sieve already supports "auth" as an envelope test.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Alexandros Vellis <[email-masked]>
Date: Wed, 29 Jun 2005 19:27:47 +0300

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

Alexandros

---

From: Tim Showalter <[email-masked]>
Date: Wed, 29 Jun 2005 10:41:32 -0700

> a proper require statement.

I agree wholeheartedly.

Tim

---

From: Philip Guenther <[email-masked]>
Date: Wed, 29 Jun 2005 14:01:31 -0700

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

Philip Guenther

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 29 Jun 2005 18:16:42 -0400

>    unless declared via some new extension

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

>          haven't been updated to require the new extension

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

mm

---

From: Alexandros Vellis <[email-masked]>
Date: Thu, 30 Jun 2005 10:29:22 +0300

>    PROS: <standard "declare before use" argument>, scripts using "auth"

I believe portability is not so much of an issue, as much as what
decisions a GUI program can make when building Sieve scripts.

As a Sieve client, I would very much like an extra capability being
returned, 'envelope-auth', and use the LMTP auth. If it's not there, I
can fall back to other means of verification, such as RFC822 headers.

The question whether the same capability MUST be require'd in the script
itself is something that you know better than me if it should be
enforced. I don't have any strong opinions on the <standard "declare
before use" argument>. And since I haven't implemented 'envelope' yet at
all, I don't worry about backward compatibility and thus shouldn't have
a say on this particular issue. :)

Alexandros Vellis