Re: [exim] problem confirmed with exim and mailing off wrong…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Dean Brooks
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] problem confirmed with exim and mailing off wrong IPs when mail is queued
On Mon, Aug 29, 2011 at 01:13:57PM +0000, Matt Justin wrote:
> Now, this is all fine well in good ,however as you have noticed,
> these messages being delivered over the exiting socket (initiated via
> a different outbound ip) seem to be totally ignoring the remote_smtp
> router once they are in the queue which leads to the interface= line
> in that router being ignored and the message sent over whatever
> connection is active rather than the one the domain is configured to use.
>
> The behavior can be worked around by setting
> connection_max_messages=1, however this would be a huge performance
> hit for any legitimate email deliveries since every single email will
> cause a new connection to happen, even if they are all from the same domain.


I meant to respond to this yesterday but never got a chance.

What you are seeing in Exim with regards to having to set
connection_max_messages=1 in order to ensure that the interface=
transport option is honored properly is indeed the case. Without it,
other messages waiting on the queue will get sent down the open
socket even if the interface= values dont match.

We ran into this several years ago (not on cpanel), investigated it
internally, and made the appropriate changes to our configuration.

The code in src/deliver.c appears to attempt to reuse an existing
socket if the transport name and hostnames match, but it probably
needs to also ensure that any interface= value also matches. I looked
at the code and I think it might be fairly straightforward to fix, but
it's been a long time since I've delved into Exim code and not sure
what negative ramifications it might have.

I'm not aware of another workaround other than setting
connection_max_messages=1 at this point. If someone else is familiar
with this code, it might be able to be fixed(?), or I could try and
take a stab at it in the near future since we have a configuration
that would benefit from it as well.

--
Dean Brooks
dean@???