Mailing List Archive

On Tue, 25 Jun 2002, Pete Naylor wrote:

> I have a need to strip or not strip certain headers, depending on the IP
> address of the host which I'm transferring the message to via an SMTP
> transport. headers_remove is expanded, which is great, but unfortunately
> $host_address is not defined for remote transports.

Well, it should be. Please give more details of the configuration that
is failing.

Oh, wait. As you were. It's a timing problem. The headers_add and
headers_remove options are expanded at the start of the transport,
before it starts connecting to different hosts. So yes, at that time
$host_address won't be set.

The only way to do what you want is to use a transport filter. That's
expensive in resource terms.



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

Philip Hazel wrote...

> Oh, wait. As you were. It's a timing problem. The headers_add and
> headers_remove options are expanded at the start of the transport,
> before it starts connecting to different hosts. So yes, at that time
> $host_address won't be set.

Thanks for the reply Philip. In this case, the host (or list of hosts)
has been passed to the transport by a router (just as would happen for a
local transport, where $host_address _is_ defined). While the transport
has not yet connected, surely it knows or has access to a variable
defining where it will connect? It just seems to me that this could be
one of those expansion items that _might_ be defined in a transport
depending on whether it was provided by a director/router. If it wasn't
supplied, the value would be null.

> The only way to do what you want is to use a transport filter. That's
> expensive in resource terms.

I'm considering that, but the resource cost is troubling me. I'm also
considering using a local transport (pipe) to pipe the message back into
the queue via /usr/lib/sendmail.

--
Pete Naylor

On Wed, 26 Jun 2002, Pete Naylor wrote:

> Thanks for the reply Philip. In this case, the host (or list of hosts)
> has been passed to the transport by a router (just as would happen for a
> local transport, where $host_address _is_ defined). While the transport
> has not yet connected, surely it knows or has access to a variable
> defining where it will connect?

It has a _list_ of hosts (in general) to which it will connect. These are
not put in a variable - because Exim has no mechanism for vector
variables. (I didn't want to write a programming language. :-)

> It just seems to me that this could be
> one of those expansion items that _might_ be defined in a transport
> depending on whether it was provided by a director/router. If it wasn't
> supplied, the value would be null.

The problem is how to cope with multiple hosts.

And it wouldn't help you - because you want to make changes based on the
host to which the message is being sent. Until the connection is made
(or about to be made) you can't take that decision. A message may be
routed to two hosts - one of which should trigger your changes, and one
of which should not.

(OK, you'll tell me "that won't ever happen in practice", but I have to
think in general terms.)


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