When I cut over my existing email system from sendmail to exim, I left the
forward files created for users in place, as is. Instead of relying on the
call to a vacation program from a pipe in a .forward file, I now call
vacation when a .vacation.msg file exists.
A typical forward file currently looks like:
\<user>, "|/usr/bin/vacation <user>"
Sending email to a user with such a forward apparently has caused the
sender to eventually receive back an email messages similar to this:
> Subject: Warning: message 1BrdPN-0003Pf-5b delayed 24 hours
>
> This message was created automatically by mail delivery software.
> A message that you sent has not yet been delivered to one or more of
> its
> recipients after more than 24 hours on the queue on nodename.domain.
>
> The message identifier is: 1BrdPN-0003Pf-5b
> The subject of the message is: <the subject>
> The date of the message is: Mon, 2 Aug 2004 10:03:06 -0400
>
> The address to which the message has not yet been delivered is:
>
> pipe to |/usr/bin/vacation <user>
> generated by <vacation user>@<domain>
> Delay reason: pipe_transport unset in userforward router
A matching entry is made in my logs which I was aware of, but I didn't
find out about the message to the original sender until just the end of
last week. (Swore I tested for that, but guess not...)
The .forward file is created through a SquirrelMail plugin. I realise
could quickly rewrite the plugin to not put a forward in place to solve
the problem, but I was hoping there's a way to ignore pipes in forward
files so I wouldn't have to edit all the forward files currently in place.
(And additionally if for some crazy reason my site ever decided to revert
back from exim, it would be one less thing to worry about.)
I'd also like to stay away from changing the forward router to allow
pipes.
I've been habitually deleting them for the last week, but I've also
noticed that I receive a copy of the output from any vacation message to
my postmaster or MAILER-DAEMON address. Of course since I've deleted them
I can't remember which address they were being sent to. Is this a result
of the problem above?
-Mark
--
Mark T. Valites
Unix Systems Analyst
Computing & Information Technology
SUNY Geneseo
>--))> >--))>
