I have recently opened a ticket with cpanel support and it was escalated to there dev team and this behavior was confirmed.
We have found the following to be true: When 2 or more domians/ips are setup to use /etc/mailhelo
/etc/mailips and one domain starts sending emails via smtp to the server and the remote isp (in this case aol) temporarily places a block/restriction on delivery for that IP and tells exim to queue the mail and then another configured domain starts sending off different configured IP on the server, exim will start to deliver the queued mail off the unblocked ip. This creates all types of problems as its totally different customers sending this mail and there spf/domain keys are mismatched. In addition they shouldnt be able to effect each others delivery. In theory, Exim should keep the queued mail there in the system till that ip is unblocked or return the mail as non deliverable after X attempts.
Below is what the cpanel support team has concluded.. We think this behavior by Exim is a bug.. can anyone confirm and if so what is next step..
reply from cpanel:
After logs of digging, Brian here in support and myself have found the cause of this behavior, and it's 100% by design of exim. However, it seems very wonky and bug like that it's happening exactly the way it is.
The reasoning is in the docs here:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch45.html#SECToutSMTPerr
Specifically this section:
When a message is successfully delivered over a TCP/IP SMTP connection, Exim looks in the hints database for the transport to see if there are any queued messages waiting for the host to which it is connected. If it finds one, it creates a new Exim process using the -MC option (which can only be used by a process running as root or the Exim user) and passes the TCP/IP socket to it so that it can deliver another message using the same socket. The new process does only those deliveries that are routed to the connected host, and may in turn pass the socket on to a third process, and so on.
The connection_max_messages option of the smtp transport can be used to limit the number of messages sent down a single TCP/IP connection.
The second and subsequent messages delivered down an existing connection are identified in the main log by the addition of an asterisk after the closing square bracket of the IP address.
If we look in the log we can see the message you provide in your header is needed denoted as being sent over a handed off tcp socket via the asterisk:
root@saw [~]# exigrep QqqXs-0000QW-Rj /var/log/exim_mainlog
2011-08-09 13:56:52 1QqqXs-0000QW-Rj <= kelly@??? H=([X.X.x.234]) [x.x.x.234] P=esmtpa A=dovecot_plain:kelly@<domain1.com>=2025 id=20110809175426.2512.92954@???
2011-08-09 13:56:52 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 14:20:15 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 15:15:30 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 16:31:14 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 17:06:41 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 18:01:27 1QqqXs-0000QW-Rj == robjauregui22@??? R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host
2011-08-09 18:14:19 1QqqXs-0000QW-Rj Message signed with DKIM: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
2011-08-09 18:14:19 1QqqXs-0000QW-Rj => robjauregui22@??? R=lookuphost T=remote_smtp H=mailin-02.mx.aol.com [205.188.103.1]* <-------- here's our marker
2011-08-09 18:14:19 1QqqXs-0000QW-Rj Completed
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.
On one hand I can see this being good default behavior for somebody that doesn't care about what ip the email is from, on the other hand I would say it's a bug that exim seems to be ignoring configurations.
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.
Matt Justin
This message is for the addressee's use only and may contain confidential, proprietary or legally privileged information. Unauthorized forwarding, copying, printing, distribution, or any other unauthorized use of the information in this message is prohibited. If you believe you are not the intended recipient of the message, please notify the sender and delete the message. No confidentiality or privilege is waived or lost by any mistransmission.
