Re: [Exim] Pruning Forward Headers

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Robert Lister
Data:  
Para: exim-users
CC: Carolyn Longfoot
Asunto: Re: [Exim] Pruning Forward Headers
> You go around removing Received: headers, what you will get is a gigantic
> potential for mail loops.


Not if you remove the right headers going in the right direction rather
than blindly strip all received: headers.

i.e. leave it intact for internal messages and incoming messages, but just
strip the headers previously to the exim box. Or you could strip the
client headers (which probably won't have much bearing on server mail
loops)

Unfortunately you get exim's header left in there because it always adds
its own header, but then you can customize exim's header not to put the IP
address in the received: header.

If there is a loop involving your exim server, it will add its Received:
header again and it will count that as an incoming message as opposed to
an outgoing message. (With exim 3.x I only put the headers_remove bit in
the router that relays your outbound messages, not incoming messages.)

One possible solution to this is to change the format of the received:
headers (if possible) so that it doesn't put the IP addresses in there

One of my boxes used the sender address instead of the host/IP:
(So it gave me some sort of tracking internally.)

received_header_text = "Received: \
        ${if def:sender_address{from ${sender_address} }}\
        by ${primary_hostname}\n\t \
        id ${message_id}"


> In short, "not worth the effort".


Arguable. If you want to do it, do it, but beware you could strip out
useful information. Apply it only to outgoing messages.

I also used to strip other elements out such as X-Mailer: headers for
external mail, so that people couldn't tell what e-mail software versions
clients were using.

It is usually fairly easy to discover an organization's internal IP
address range though, using strategies such as bounce messages etc.
Which cause a nice failure message to go back and blab what the internal
IP addresses are.

Then there's other pants like failure messages that include the IP
address of the connection being attempted:

[192.168.1.20]: Unable to replicate; connection timed out.

(Usually if an exchange/domino type replication fails to happen.)

Rob