On Thu, Mar 31, 2005 at 10:37:12AM -0800,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
An implementation might know the address being delivered to (the
envelope recipient). UNIX "vacation" has a place to put additional
email addresses to look for, because the envelope recipient has
typically been been lost at this point. I would say that that's also
the value of the ":addresses" here too.
So I would think this would say that the envelope recipient, if known,
OR one of the addresses listed in the :addresses must appear in one of
the listed header fields.
I really don't think a change is in order here. Nothing in the present text
makes an implementation that has no knowledge of its own of the recipient's
address(es) incompliant. And OTOH I really don't think we should encourage
implementations that are ignorant of this. (It is one thing when circumstances
make it impossible, quite another where a standard in effect condones lazy
implementation practices.)
I humbly beg to differ about the lazy part. While I am probably lazier
than the next guy, I'm talking about completeness here in the absence of
knowable information. Remember (as I'm sure you do) that we're talking
about looking into the various destination headers (To, Cc, et al) to
make sure that one of them contains one of the addresses owned in some
sense by the recipient, as an indication that the message is specifically
addressed to the recipient.
There are a number of legitimate reasons why the implementation might
not know what all of the specific recipient addresses are.
It might be a foreign address, e.g. forwarded via some forwarding
service, or forwarded from another mailbox at the same site. This is
perfectly handled by the :addresses tag (and perhaps if you don't want
to encourage lazy implementations that don't know all of their
recipients' possible email addresses, you'd want to restrict :addresses
just to this case).
There may be a many-to-one mapping hardcoded at some site administrative
level, or at some group-administered level (for example, the site
administrator may assign some set of addresses {A} and some set of
mailboxes {B} to an organization, which that organization's admin can
map at will). The SIEVE script that's run on behalf of an individual
mailbox is unlikely to have access to any of mapping, and I don't think
laziness accounts for wanting it to remain that way.
There may be a many-to-one mapping expressed programmatically. The
owner may have a very large set of addresses {A} mapped to the mailbox,
and may use one or more SIEVE scripts to decide what to do with them.
(In fact I think it would be wonderful for an environment to support an
SMTP receiver which consulted, at RCPT-TO time, choices expressed in
this way.) The decision might have as part of its expression a list of
address *NOT* to accept, rather than a list of addresses to accept. In
any case, by the time you get to the 'vacation' statement, the mail
message has likely been accepted.
There may be environments that we haven't imagined. That's one of
the challenges: to allow new and different environments to be supported.
Now, there might be ways to arrange for a SIEVE implementation to check an
address in any scenario. Are there brownie points for having to find
hard ways to do things? (OK, I *am* lazy.)
So back to the specific recommendation: if you have the envelope
recipient address available, IMHO the spec should allow you to make use
of it in this test; it would likely be the prime address to find in one
of the recipient-address header lines. I can't see why this is any
less valid than using some other notion of the recipient's email
address: if the message has made it to the point where it's being
processed by the recipient's script, the envelope recipient address *is*
one of the recipient's email addresses. Are there downsides? What
are they?
mm