Subject: Re: bin/5039: change to vacation to support wider variety of mailers
To: None <netbsd-bugs@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
Date: 02/25/1998 01:01:34
[ On Tue, February 24, 1998 at 07:05:39 (-0500), der Mouse wrote: ]
> Subject: Re: bin/5039: change to vacation to support wider variety of mailers
> > 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.
> Whatever gives you the idea there is such a thing as "the appropriate
> Precedence: header"? What RFC specifies it and describes how the list
> owner should select a value? (I looked at RFCs 822, 1122, and 1123, to
> no avail; perhaps I missed one.)
I should have qualified that statement with "*and* they set the reply
address to be the list distribution address."
Indeed there are no RFCs that I'm aware of defining the use of
'Precedence'. None the less the vacation(1) manual page itself suggests
this by way of inference and in the example shown (though not nearly
strongly enough IMHO), and given that many list exploders also use it I
assume it's documented with them too (I think I've seen mention of it in
the LISTPROC docs, though I don't have immediate access to them to
search just now).
> > [...] and have it pay attention *only* to the 'Precedence' header to
> > determine if it needs to respond or not.
> What on *earth* could a Precedence: header have to do with whether
> vacation should respond? This is a leap of (il)logic I completely fail
> to follow.
Since vacation(1) has long defined 'Precedence' as the de facto standard
way to determine if mail needs a response or not (ignoring the other
so-called heuristics we're debating), and given that this same header is
in effect the de facto standard used by many mailing lists, and given
that those list exploders which don't set 'Precedence' seem to always
set the reply address (as defined by RFC 822) to something other than
the list distribution address, and since there is no other way to
determine if the message was relayed via a list or if it was simply
Bcc'ed, I can only conclude that 'precedence' is the only useful header
from which any decision can be made by vacation(1) as to whether or not
it should reply.
Well it should also pay attention to a list of "well known" originators
(i.e. in RFC-822 originator fields, not the envelope sender). that need
not receive responses, though I've trimmed my list down to just
"mailer-daemon" as I can't think of any others that should be mandatory
(in fact this list should probably be user extensible, perhaps by a
simple script which feeds faked messages to vacation in such a way that
it will build up the database iwth "permanent" entires and not send
replies during this time). Since the database can indeed be faked up in
this manner there's really no need to include this test in the internal
hard-wired logic -- leave it externally table driven as it should be.
Greg A. Woods
+1 416 443-1734 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>