Subject: vacation and envelope-to: another try

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 3 May 2005 14:07:47 -0400

Hi-

I wanted to bring this one point up again since I failed so miserably at
it the last time.  So another try:

3.5  Address Parameter and Limiting Replies to Personal Messages

   > "Vacation" MUST NOT respond to a message unless the user's email
   > address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   > "Resent-Bcc" line of the original message.  Implementations are
   > assumed to know the user's email address, but users may have
   > additional addresses beyond the control of the local mail system.

I'd like to add that the envelope recipient address, if available,
qualifies as a known address.  In some other words:

   "Vacation" MUST NOT respond to a message unless a valid email address
   for the recipient appears in a "To", "Cc", "Bcc", "Resent-To",
   "Resent-Cc", or "Resent-Bcc" line of the original message.  An email
   address is valid for the recipient only if it is one of: an email
   address known by the implementation to belong to the recipient; the
   envelope recipient address if it's available to the implementation;
   any other address specified by the script writer via the ":addresses"
   tagged option.

The point being that the envelope recipient address is valid for the
recipient (since the receiving system obviously has delivered it to the
script), and (in the spirit of RFC3834) its presence in one of those
headers should validate the incoming message as an individually directed
message that can be autoresponded to.  A script writer shouldn't have to
list all possible valid envelope recipient addresses in :addresses when
they have, in effect, been listed algorithmically.

Perhaps this is assumed to be covered by "implementations are assumed to
know the user's email address" but I would not read that sentence that
way and I wouldn't expect other readers of the RFC to make that leap.

I'm not sure why this was controversial the last time, but I'm hoping
it was only the way I said it and not what I was saying.  If this
is still a bad suggestion for some reason, I'd like to hear why..

Yours,
mm

---

From: [email-masked]
Date: Tue, 03 May 2005 11:42:16 -0700 (PDT)

> is still a bad suggestion for some reason, I'd like to hear why..

It was controversial because you suggested replacing knowledge of the
recipient's address with simply using the current envelope recipient address. I
don't think encouraging implementations to rely solely on envelope recipient
address information is a good idea.

I have no problem calling out that the current envelope recipient address
as an additional source of information for this check. I'll add text to
this effect to the revision.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 3 May 2005 15:02:20 -0400

> address information is a good idea.

I haven't changed what I was suggesting at all, at least not in my mind.
Sorry if it was not clear the first time; if it's better this time, I'm
glad.

> this effect to the revision.

Cool.

Yours,
mm

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 4 May 2005 13:09:07 +0200

[email-masked] writes:
> I have no problem calling out that the current envelope recipient 
> address as an additional source of information for this check. I'll 
> add text to this effect to the revision.

Make sure to define "current envelope recipient address" as the address 
_after_ alias resolution at the final destination, ie. not the address 
seen in the SMTP conversation. Otherwise mail to [email-masked] would 
likely trigger vacation responses from all absent team members.

Arnt

---

From: Tony Finch <[email-masked]>
Date: Wed, 04 May 2005 12:10:14 +0100

>   any other address specified by the script writer via the ":addresses"

This fails if the envelope recipient address is an alias that expands to
more than one address before delivery to the user in question. The
intermediate results of expansion might not be available to the Sieve
implementation.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: NORTH 4 OR 5, LOCALLY 6
AT FIRST, DECREASING 3 OR 4. FAIR, RISK OF RAIN AT FIRST. MAINLY GOOD.
MODERATE TO ROUGH BECOMING SLIGHT TO MODERATE.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 4 May 2005 10:11:43 -0400

> intermediate results of expansion might not be available to the Sieve

Absolutely- what I had in mind was the final recipient address; the
personal email address that had been resolved and resulted in the
ultimate delivery to the user.  If it's available to the implementation,
of course.  This is what I attempted to describe in narrative, and
referring to it as "envelope recipient" is probably one place where I
confused things (see below too).  Using the "RCPT TO" address or any
unexpanded multi-recipient alias for this test would certainly be wrong.

-mm-

PS: my own implementation uses the final delivery address as the address
in the 'envelope "to"' sieve test, contrary to RFC3028 which says that
the SMTP RCPT TO address must be used.  You all can tell me how wrong
this choice of implementation is, and I would simply have to agree that
it's a violation, but I just don't find the RCPT TO address to be of
anywhere near as much interest to the script as the actual resolved
individual delivery address; not to mention the fact that the RCPT TO
address can't nececessarily be guaranteed to be consistent as
implementations evolve.  For example, an environment might at some point
expand aliases by re-injecting the individual addresses via SMTP or LMTP
where it didn't do so before.  The fact that I've implemented it this
way has colored the way I've talked about it in this thread, which is a
big error on my part.  Sorry about that.  I still stand by the actual
suggestion, though.

(Maybe a better way to provide this rfc-violating envelope test would be
to use a different "envelope-part" keyword.)

---

From: [email-masked]
Date: Wed, 04 May 2005 07:24:32 -0700 (PDT)

> likely trigger vacation responses from all absent team members.

By definition sieve operates at or around the time of final delivery. Aliases
necessarily have to be expanded prior to this point. I suppose an
implementation could have squirreled away original address information
somewhere/somehow, but how someone could mistakenly see it as appropriate to
use this material as a "current envelope address" escapes me.

Nevertheless, if it makes people feel better, I'll change the phrase to
read "final recipient address".

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 04 May 2005 17:48:22 +0200

On Wed, 2005-05-04 at 10:11 -0400, Mark E. Mallett wrote:
> implementations evolve.

_which_ SMTP RCPT TO?

in many environments, the expansion happens at one server and delivery
at another.  it's simply impossible to pass information about the
"original" RCPT TO on to the next server when the alias is an actual
expansion (ie. more than one recipient address).  3028 even says as
much:

   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.

what's a "final delivery address"?

in our case with Cyrus as the server, the delivery address isn't
necessarily a routable e-mail address(!), as it's rewritten from
f.m.lastname+detail@domain to username+detail@domain.  in other words,
our system is contrary to RFC 3028, too.  (I should point out that Cyrus
can be used in a strictly compliant manner, but not at our site.)

IMO it is a reasonable interpretation to use the _latest_ ("final" if
you will) recipient address.  never mind the fact that the latest RCPT
TO happened across LMTP rather than SMTP.  I think the base spec should
be changed to reflect this more clearly.  I would prefer wording which
allowed Cyrus to work like today, leaving alias knowledge to the MTA.
changing "SMTP" to "SMTP or LMTP" is sufficient for that, but it
probably won't do for Mark.  suggestions?
-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 04 May 2005 18:39:46 +0200

> probably won't do for Mark.  suggestions?

I'm embarrassed to admit that my reading skills are extremely lacking.
RFC 3028 says, just two paragraphs down from my earlier quote:

   If a protocol other than SMTP is used for message transport,
   implementations are expected to adapt this command appropriately.

so the spec is fine already, IMHO.
-- 
Kjetil T.

---

From: [email-masked]
Date: Wed, 04 May 2005 09:27:44 -0700 (PDT)

> _which_ SMTP RCPT TO?

Exactly what I was thinking.

> expansion (ie. more than one recipient address).

And more to the point, the fact that a given recipient address hasn't actually
appeared in an SMTP dialogue in a RCPT TO field is 100% irrelevant. The message
envelope and its associated list of recipients is an abstraction that manifests
in a variety of ways, including but not limited to SMTP commands.

Another way to look at it is that when we talk about RCPT TO addresses we're
referring to the addresses in the envelope recipient list, not to those
addresses in the specific case where they happen to appear in SMTP. The
terminology choie is unfortunate, but after over 20 years changing it is simply
not realistic.

> 3028 even says as much:

> what's a "final delivery address"?

FWIW it's defined, more or less, as part of the NOTARY specifications.

> can be used in a strictly compliant manner, but not at our site.)

There are really two issues here that overlap to some extent. One is the issue
that arises when a recipient address gets turned into something that isn't
globally meaningful or usable. properly. The other is what address to expose to
sieve for the purposes of performing envelope recipient tests.

THe overlap is only partial since there can be multiple global addresses
involved in addition to local addresses, so the choice of address to
expose isn't simply local/global.

Quite a few systems, ours included, use oddball local address forms at the
point of final delivery. I personally don't like this much, but in our case the
design was a fait accompli long before I was even involved. Even so, when this
is done the goal needs to be to minimize exposure of these local address forms,
for one simple reason: They don't work when someone enters then into their
email client.

As far as selecting the right address to use in envelope tests goes, I like to
apply the least astonishment principle: Use the address the user expects.

> TO happened across LMTP rather than SMTP. 

Or even if there was no protocol involved at all.

> I think the base spec should

I tend to use the term "envelope recipient" or "final envelope recipient" or
something similar if I'm trying to avoid tying things to SMTP specifically. But
the reality is that the term "RCPT TO" is now used all the time for this even
when SMTP isn't necessarily part of the picture.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 4 May 2005 17:40:10 -0400

>    implementations are expected to adapt this command appropriately.

On the other hand, "transport" != "delivery" when we talk about email
architecture.  And when an RFC talks about RCPT TO, and transport
commands, well... it reads the way it reads.  Sounds like there's at
least some support for interpreting this as a (possibly munged) final
recipient address, so maybe that's something to think about clarifying
for 3028bis.

People are agreeing; I'm not arguing, honest...

mm