Is there any way to make the NetBSD vacation program reply to the
person identified by the "From:" header in the actual message, rather
than the sender identified by the envelope "From" line, or the "Return
Path" header ?

I'm trying to use my a/c on a NetBSD box to make up for deficiencies
in the "Out Of Office" feature of a Certain Other OS, by setting up a
"Rules Wizard" rule in Lookout which simply redirects incoming mail to
my NetBSD a/c, and then have Un*x vacation use its better intelligence
to refrain from replying to senders who don't want to know where I am.

[NB: "Redirect" is a feature introduced in Lookout 2000, and is not
the same as the "Forward" feature present in Lookout 98 and earlier]

Unfortunately I discover that the message that arrives at NetBSD from
Lookout/Exchange has headers something like this :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
< cut =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
 From nick.boyce@myemployers.exchange.server Mon Mar 29 19:34:07 2004
 Return-Path: <nick.boyce@myemployers.exchange.server>

 Received: from myemployers.internal.mail.relay
         by mynetbsd.box (8.11.6p2/8.11.6) with ESMTP id i2TIY6a02798
         for <nickboyce@mynetbsd.box>; Mon, 29 Mar 2004 19:34:06 +0100

 Received: from myemployers.exchangehub
         by myemployers.internal.mail.relay
         for <nickboyce@mynetbsd.box>; Mon, 29 Mar 2004 19:33:07 +0100

  [more "Received" headers showing message travelling from=20
   third party, across our internal network to my employer's=20
   Exchange server, and then, after redirection, back across=20
   our internal network to the mail relay, where it gets=20
   transferred to the Un*x side of things]

 Received: from jsoap by somethirdparty.business.contact with local
         for <nick.boyce@myemployers.exchange.server>;=20
         Mon, 29 Mar 2004=20

 From: Joe Soap <jsoap@somethirdparty.business.contact>
 To: "My OoO Assistant (E-mail)" <nickboyce@mynetbsd.box>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
< cut =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

So the message arrives in my NetBSD mailbox with all the info required
to deal with it intelligently, and then gets handled _stupidly_ IMHO.
The NetBSD vacation auto-reply gets sent back to
nick.boyce@myemployers.exchange.server - and _that_ only happens for
the first message of the day, since I have the repeat interval for any
one sender set to 1 day, and all the messages appear to come from the
same sender ... me :-(

Yes .. I've Googled ... and I see that this is a thorny subject (to
put it mildly).  There are disputes as to what should be used as
vacation's _sender_ address (so nondelivery bounces get handled
sensibly), whether vacation auto-replies should be categorised as
"errors" or "messages" (ditto), whether vacation should reply to the
envelope sender, or to the message sender (my problem) or to the
return path, whether the "-z" option should exist to allow people to
specify an arbitrary auto-reply sender address ... etc., etc.

I actually found someone complaining that (circa 1997) Linux vacation
*used* to do what I want, but Solaris vacation didn't.
http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&threa=
dm=3D876021010.31683%40dejanews.com&rnum=3D7&prev=3D/groups%3Fq%3Dunix%25=
20vacation%2520program%2520reply%2520address%26hl%3Den%26lr%3D%26ie%3DUTF=
-8%26oe%3DUTF-8%26sa%3DN%26tab%3Dwg

But it seems that can't be the case now :

Debian Linux 3.0 vacation man page :

     vacation reads the incoming message from standard input,=20
     checking the message headers for either the UNIX ``From''=20
     line or a ``Return-Path'' header to determine the sender. =20
     If both are present the sender from the ``Return-Path''=20
     header is used.  Sendmail(8) includes this ``From'' line
     automatically.

=46WIW, NetBSD 1.6.1 vacation man page :

     vacation reads the first line from the standard input for=20
     a UNIX ``From'' line to determine the sender.  sendmail(8)
     includes this ``From'' line automatically.

It's plainly a fairly religious thing ... (where "religious" =3D "RFC
interpretation", for some value of "=3D").

The net effect seems to be that lots of people have written their own
vacation, so as to get the behaviour they need :

Greg Woods' version 2 :
  http://www.weird.com/~woods/projects/BSD-vacation-v2.html
Marco d'Itri's version :
  http://www.gnu.org/directory/vacation.html  =20
A "linux" version :
  http://www.gnu.org/directory/linuxvacation.html
  http://vacation.sourceforge.net/
etc., etc.

(I guess the NetBSD version is an earlier Greg Woods' version ?)

Some people even say don't bother with vacation - use procmail to get
intelligent auto-replies  - but this seems overkill.

It's starting to look as if I may have to hack somebody else's version
to get the behaviour _I_ need ...

How silly.  Wouldn't it be sensible to have a single true vacation
program, with configuration options to allow different behaviours as
necessary ?

Side Notes:

1)  The Linux version has more useful options than the NetBSD one
(e.g. -l to list the senders currently in the received-from database)

2)  There have been several posts, over the aeons of this saga, from
people who want the vacation auto-reply to have a subject line that
references the subject line of the original message, so active
emailers can tell which of their posts generated the auto-reply ...
the Linux vacation program does that, and so does Greg Woods' (cf
$SUBJECT), (_and_ so does the Other OS OoO facility), yet the NetBSD
vacation doesn't have this feature - any reason for that ?

In fact, the Linux version seems to be considerably more useful than
the *BSD one - does nobody really use vacation on *BSD ?

Anyway - pointers on how to get vacation to reply to "From:"
gratefully received ... likewise flames about me missing something.
Otherwise .. thanks for listening :)   Have a nice day.

Nick Boyce
Bristol, UK
--=20
I tried to patent patent barratry as a business model,=20
but there was too much prior art.