Mailing List Archive: PATH oddity in pipe transport

PATH oddity in pipe transport

Jul 19, 2002, 7:09 AM

Post #1 of 4 (412 views)

I'm getting some odd behaviour in a pipe transport which I've found whilst setting up spamassassin (although this is nothing to do with SA).

The problem appears to be that the transport_filter program I specify always wants an absolute path. If I make it relative and use the 'path = /usr/bin' then the router fails. It's quite possible that I've set something up wrong but if I have it's a little obscure.

In more detail, I have a router set as below which I was using to test SA.

spamcheck:
driver = pipe
command = /usr/exim/bin/exim -oMr spam-scanned -bS
use_bsmtp = true
path = /usr/bin
transport_filter = tee -a /tmp/spamcheck.log
home_directory = "/tmp"
current_directory = "/tmp"
# must use a privileged user to set $received_protocol on the way back in!
user = exim
group = exim
log_output = true
return_fail_output = true
return_path_add = false
message_prefix =
message_suffix =

However, this fails. The exim log shows:

14:56:10 17VYEs-0001Ea-00 <= Glenn.Carver@atm.ch.cam.ac.uk H=sheridan.atm.ch.cam.ac.uk (sheridan) [131.111.112.194] P=esmtp S=2128 id=20020719145610.Q28443@sheridan.atm.ch.cam.ac.uk
14:56:11 SMTP connection from exim lost while reading message data (header)
14:56:11 17VYEs-0001Ea-00 <glenn@atm.ch.cam.ac.uk>: spamcheck transport output: An error was detected while processing a file of BSMTP input.
14:56:11 17VYEs-0001Ea-00 ** glenn@atm.ch.cam.ac.uk R=spamcheck_router T=spamcheck: Child process of spamcheck transport returned 2 from command: /usr/exim/bin/exim

.. which I take to mean that it couldn't find or run the 'tee' command. Certainly the file /tmp/spamcheck.log is empty. It doesn't seem to matter where I put the path line.

Now if I change the transport_filter line to read:
transport_filter = /usr/bin/tee -a /tmp/spamcheck.log

..it works! The log file shows a clean delivery and as expected I get a copy of the message in /tmp/spamcheck.log.

The spec clearly says that the path option specifies the string setup in the PATH env. variable of the subprocess. If the 'command' path is not absolute then it should look for the tee command in path. So I think my first attempt should work.

Either this is something subtle I don't understand or it's a bug.

Glenn

--

Dr. Glenn Carver, Centre for Atmospheric Science, Univ. of Cambridge,
Chemistry Dept., Lensfield Road, Cambridge, CB2 1EW, UK.

mailto:Glenn.Carver@atm.ch.cam.ac.uk http://www.atm.ch.cam.ac.uk/~glenn/
Phone: +44 (1223) 763827 ** please note new numbers **
Fax: +44 (1223) 763823

Re: PATH oddity in pipe transport [ In reply to ]

ph10 at cus

Jul 22, 2002, 2:35 AM

Post #2 of 4 (396 views)

Permalink

On Fri, 19 Jul 2002, Glenn Carver wrote:

> The problem appears to be that the transport_filter program I specify
> always wants an absolute path.

Yes, I'm afraid that's the way transport filters work.

> If I make it relative and use the 'path =
> /usr/bin' then the router fails. It's quite possible that I've set
> something up wrong but if I have it's a little obscure.

Transport filters can be applied to any transport. "path=" is an option
of the pipe tranport (and no others). It applies only to the command
that is being run by the pipe. That's basically why it works the way it
does.

> Now if I change the transport_filter line to read:
> transport_filter = /usr/bin/tee -a /tmp/spamcheck.log
>
> ..it works! The log file shows a clean delivery and as expected I get a copy of the message in /tmp/spamcheck.log.

But note that you'll get interleaved messages if two arrive at once...

> The spec clearly says that the path option specifies the string setup
in the PATH env. variable of the subprocess. If the 'command' path is
not absolute then it should look for the tee command in path. So I think
my first attempt should work.

This is the documentation for the pipe transport. It's talking
exclusively about the subprocess that is run by the pipe, and the
"command" argument of the pipe transport. It is not talking about the
transport filter subprocess, which is something that happens up at a
higher level (because it can apply to all transports, not just pipes).

I'll make this clearer in the next edition (which won't be for a while,
because I've just released a new edition this morning).

Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

Re: PATH oddity in pipe transport [ In reply to ]

Glenn.Carver at atm

Jul 22, 2002, 8:51 AM

Post #3 of 4 (394 views)

Permalink

On 2002.07.22 10:35 Philip Hazel wrote:
>
> > Now if I change the transport_filter line to read:
> > transport_filter = /usr/bin/tee -a /tmp/spamcheck.log
> >
> > ..it works! The log file shows a clean delivery and as expected I get a copy of the message in /tmp/spamcheck.log.
>
> But note that you'll get interleaved messages if two arrive at once...

Which got me wondering.. how would one approach writing a transport_filter in general then. How can the filter distinguish between separate messages arriving at once? This is a general question from the point of view of writing transport filters. (presumably spamc has a way of doing it).

Glenn

--

Dr. Glenn Carver, Centre for Atmospheric Science, Univ. of Cambridge,
Chemistry Dept., Lensfield Road, Cambridge, CB2 1EW, UK.

mailto:Glenn.Carver@atm.ch.cam.ac.uk http://www.atm.ch.cam.ac.uk/~glenn/
Phone: +44 (1223) 763827 ** please note new numbers **
Fax: +44 (1223) 763823

Re: PATH oddity in pipe transport [ In reply to ]

ph10 at cus

Jul 22, 2002, 9:00 AM

Post #4 of 4 (395 views)

Permalink

On Mon, 22 Jul 2002, Glenn Carver wrote:

> > But note that you'll get interleaved messages if two arrive at once...
>
> Which got me wondering.. how would one approach writing a
transport_filter in general then. How can the filter distinguish between
separate messages arriving at once? This is a general question from the
point of view of writing transport filters. (presumably spamc has a way
of doing it).

There's no problem with the filter. Two messages at once will run two
different delivery processes, and therefore two filter processes.

The problem is that in your filter you are taking a copy of the message
and writing it to a file without any kind of interlock.

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.