On 2012-10-02 at 08:10 +0200, Davide D'Amico wrote:
> So changing route_data to route_list isn't a good idea to solve this
> problem?
No; route_list is simply a more powerful wrapper around route_list,
taking matching patterns and options. It doesn't affect this case.
> Is there really a problem with my setup?
I think this counts as a bug in Exim, which you need to work around for
now. I suspect that the fix is to change the retry system so that if
the remote port is not 25, then include the port in the retry key.
> As an (extreme) solution, I could use ((1 x service) x server) ip
> addresses and use standard port 25.
Not needed.
> Coming to your suggestion: if I understood, I shoud use (on my internal
> name server):
>
> internal_smtp1 IN A xxx.yyy.zzz.kkk
> internal_smtp2 IN A www.jjj.zzz.vvv
> int_service1_smtp1 IN CNAME internal_smtp1
> int_service2_smtp1 IN CNAME internal_smtp1
> int_service3_smtp1 IN CNAME internal_smtp1
> int_service1_smtp2 IN CNAME internal_smtp2
> int_service2_smtp2 IN CNAME internal_smtp2
> int_service3_smtp2 IN CNAME internal_smtp2
>
> and then in /usr/local/etc/exim/remote-servers:
>
> domain1.tld: int_service1_smtp1::1026:int_service1_smtp2::1026
> domain2.tld: int_service2_smtp1::1027:int_service2_smtp2::1027
> domain3.tld: int_service3_smtp1::1028:int_sergice3_smtp2::1028
Yes. (Aside from "sergice3" being "service3").
> and in /usr/local/etc/exim/configure:
>
> route_data =
> ${lookup{$domain}lsearch{/usr/local/etc/exim/remote-servers}}
> no_more
>
> ?
>
> I didn't understand the use of no_retry_include_ip_address, which seems
> related to retry control.
I believe that the reason that you sometimes get messages delivered to
the wrong remote port is that the message could not be immediately
delivered, so was deferred, with retry hints written into retry.db.
If you check the logs for some sample mis-delivered messages, I think
you'll an find earlier attempt to deliver the same message, which
deferred.
So what happens is a later connection succeeds, delivers its message,
and then before closing the connection Exim checks the retry.db to see
if there are any other messages which should go down this connection.
Because the port number is not used in the retry hints, the hints are
conflicting reality and the message is being mis-delivered.
I could be wrong about what's going on and it could be something else
entirely, but we're looking for something which (1) ignores the
configured port; (2) happens only sometimes, for a small percentage of
mails; (3) is explainable given what I know of Exim. So I _strongly_
suspect that the retry hints db is the source of your problems.
If you can confirm that, for any mail which is sent to the wrong port,
you can see a failed earlier attempt to send the message in the log,
that would help us confirm that this is a retry bug.
-Phil
