Il 02/10/12 13:44, Phil Pennock ha scritto:
> 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.
do you mean "route_data is simply a wrapper around "route_list", right?
[...]
>>
>> 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").
Ops, yes of course :)
>
>> 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.
>
I'm using this log setting:
log_selector = \
+delivery_size \
+sender_on_delivery \
+received_recipients \
+received_sender \
+smtp_confirmation \
+outgoing_port \
+subject \
+smtp_incomplete_transaction \
-dnslist_defer \
-host_lookup_failed \
-queue_run \
-rejected_header \
-retry_defer \
-skip_delivery
So I don't see any failed attempt (just now I enabled retry_defer) but
for every 'missed' mail, I see very long delivery times:
2012-10-01 12:35:45 1TIdLP-000KQL-JO [...]
2012-10-01 12:38:30 1TIdLP-000KQL-JO => xxx.yyy.zzz@???
F=<> R=internal T=remote_smtp S=1226 H=internal_host_ip
[internal_host_ip]* C="250 ok 1349087906 qp 49471"
So this could be the effective delivery after N retry.
I'll test you solution asap and I'll let you know.
Anyway, what's the '*' after the backend ip address in mainlog:
2012-10-01 12:38:30 1TIdLP-000KQL-JO => xxx.yyy.zzz@???
F=<> R=internal T=remote_smtp S=1226 H=internal_host_ip
[internal_host_ip]* C="250 ok 1349087906 qp 49471"
"[internal_host_ip]*"
?
I hope it helps.
Thanks,
d.
