On Wed, May 04, 2005 at 12:10:14PM +0100, Tony Finch wrote:
"Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com> wrote:
"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.
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.
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.)