ietf-mta-filters
[Top] [All Lists]

Re: vacation and envelope-to: another try

2005-05-03 11:56:47


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

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