ietf-smtp
[Top] [All Lists]

Re: vacation programs, was BATV breaks rfc2821bis?

2008-05-21 09:51:41


On Tue, 20 May 2008, John R Levine wrote:
>> If you're going to cast doubt on the choice of the envelope sender
>> address, perhaps you could describe what you think the right choice is.
>
> For a vacation program, Reply-To: or lacking that From:.  You know, like
> replying to a message in a MUA.  This is not an innovative design.

Sure sounds innovative (in the "newly introduced" sense) to me: the
'vacation' program shipped with BSD has been using the envelope sender
originally from the "From " separator line) for the entire 27 years of its
existence.  The 'formail' program has been generating autoreplies for
vacation message that go to the envelope sender since at least 1999 (and
before then it only misrouted messages with Resent-* fields).

Interesting. Back in the early 80s the sample "trip" script for VMS MAIL used
the From: field, but since VMS MAIL only has one originator address field
there wasn't much choice. And no, it didn't work very well.

More to the point... Of course there can be problems no matter what address you
choose. Reply-to: should work pretty well as long as your list detection is
really good - there are still plenty of lists that put the list address in the
Reply-to: field.

From: is another matter. One case where it fails rather badly is when messages
are resent. Resending leaves From: intact but changes envelope from and add
Resent- fields. And since the new recipient is listed in the header the message
will pass those sorts of checks. But if the vacation reply goes to the From:
field it ends up going to the original sender, which is almost always wrong.

Another case where this can get tetchy is some "send on behalf of" scenarios.
In such cases the envelope from is best thing to use - the originator is free
to set the envelope from to match the Sender: if they want to see automatic
responses, or it can be set to agree with the From: if they want the person the
message is being sent on behalf of to get them. There is simply no way for the
recipient to determine which of the From: or Sender: field is right to use.
(This one, incidentially, was the main problem report generator for us back
when we used to use From:.)

                                Ned

<Prev in Thread] Current Thread [Next in Thread>