> [ On Mon, February 23, 1998 at 18:37:34 (-0500), Keith Moore wrote: ]
> > Subject: Re: bin/5039: change to vacation to support wider variety of mailers 
> >
> > > >Description:
> > > 
> > > 	Vacation doesn't find the user's address in mail that's sent
> > > 	without a 'To:' (or 'Cc:') header, and most importantly not in
> > > 	mail that's been 'Bcc:'ed to the user.  However most mailers
> > > 	do include the specific envelope address that resulted in the
> > > 	delivery.  Unfortunately the header used to show this address
> > > 	is not standard and several varieties exist.
> > 
> > 
> > That's beside the point.  Vacation wants to check the header recipient
> > addresses, (NOT the envelope recipient addresses), to determine
> > whether the mail was personally addressed to the recipient, instead of
> > just being list mail.  That way, it can respond to the personal mail
> > and not respond to the list mail.
> 
> Mail sent by way of Bcc should be no less important than mail that is
> Cc'ed or To'ed direclty to me.  It has absolutely *no* bearing
> whatsoever on whether or not the mail was sent through a mailing list.
> 
> Since Bcc'ed mail need not contain the recipient's address in any normal
> RFC header all that remains to be checked are the headers added by various

I have no problem with checking the Bcc header.
I do have a problem with modifying vacation so that it will 
send replies to mailing lists.

> I fully realize that if vacation(1) does recognize the headers normally
> used to represent the envelope-to address at final delivery then indeed
> it will recognize mail sent to the user via lists or group aliases which
> do not appear in the 'To' or 'Cc' headers.  However if list owners don't
> have enough sense to put the appropriate 'Precedence' header in the mail
> sent through their list then indeed they deserve every "vacation"
> response they get back to the list.  This is not rocket science.

There's no such thing as an appropriate Precedence field, and lists
certainly aren't expected to use it.

Precedence is not only non-standard, poorly conceived, and undefined, 
its use is so overloaded that it has been known to cause delivery failures.

(e.g. Some gateways won't forward messages that contain a Precedence
field unless the field contains one of a particular set of keywords.
(and neither 'junk' nor 'list' qualifies)  Some list exploders refuse
to forward messages with Precedence: bulk because they think it
will cause a mail loop.  etc.)

I have no problem with vacation using Precedence as a heuristic,
but vacation shouldn't depend on it being there.


> Personally I've always thought it terribly obnoxious and silly of
> vacation(1) to think that it should check if the mail was really sent to
> me or not.  Surely I'm smart enough only to invoke it via my own
> ~/.forward file!  If the mail arrives addressed to my mailbox then it is
> to me and there's no valid algorithm that can determine from the
> "destination" headers whether the mail was intended directly for me or
> not.

That's true, but the "check the to/cc/bcc" field heuristic is still 
valuable.  And you don't have to enable it.  Why defeat it?

> My patch was indeed a subversive attempt to alleviate the most obnoxious
> problem that results from its design without completely changing its
> user interface.  Ideally I would rip out (or purposefully ignore) the
> '-a alias' and 'login' arguments and have it pay attention *only* to the
> 'Precedence' header to determine if it needs to respond or not.  

This would be unfortnate, as it would unnecessarily cause bounces
to lists that don't happen to use Precedence.  If you manage to 
force people to adopt something that works poorly, you make it
more difficult to put in place something that works well.

Ideally, vacation would recognize the autosubmitted field;
it would not respond to messages with AutoSubmitted
headers with a keyword other than not-auto-submitted, 
and it would emit

AutoSubmitted: auto-replied

in every reply that it generated.

(autosubmitted is defined in RFC 2156, which is a standards-track
document; it's based on an X.400 field with a similar name.
there are drafts of additional documents that define its use 
for loop control.)

it has four keywords:
auto-generated 	(for things like cron jobs)
auto-replied 	(for auto replies such as those generated by vacation)
auto-forwarded 	(for list traffic)
not-auto-submitted	(for manually generated messages)

it also helps lists, in that they can refuse
to forward auto-generated and/or auto-replied messages.


> The only other possible rule I would consider is to ignore messages with
> 'Resent-*' headers.  This is also reasonably clearly defined by RFC-822,
> though not enough mailers follow this practice themselves....

Resent-* wasn't really intended for use by list exploders;
it's intended to indicate manual redirection.

(basically it's for when you want to redirect mail that arrived
at your mailbox by mistake - and you want to forward it to the
"right" address with the headers intact.)

> Vacation(1) should have been fixed a half dozen years or so ago.  That
> it still holds fast to the concepts of the 1980's is sad.
> 
> > (FWIW, automatic responses should indeed go to Return-Path and not
> > Reply-To.)
> 
> True, but vacation(1) is really a MUA facility, not an MTA facility and
> as such it should respond as an MUA (i.e. to the 'Reply-To'), not as an
> MTA.  

experience shows that it doesn't work well.  
(it's a really good way to cause mail loops)

receipt notifications are also an MUA function, but
if you look at the message disposition notification drafts 
(draft-ietf-receipt-mdn-*) you will see that the RECEIPT working 
group chose to make automatically generated message disposition 
notifications (think receipt notifications) go to the return-path 
address  - (they can be requested for other addresses but the recipient 
is supposed to manually confirm)

I believe X.400 does this the same way.

> The RFCs are very clear on this point and nothing they say

RFC 822 is anything but clear on the subject of replies.
(which is why reply-to is mis-implemented in almost every mailer
on the planet, but that's a different story.)

Keith