Re: [exim] Sender verification, permanent vs. transient erro…

Top Page
Delete this message
Reply to this message
Author: Stephen Gran
Date:  
To: exim-users
Subject: Re: [exim] Sender verification, permanent vs. transient error codes
On Thu, Jan 25, 2007 at 09:34:06AM -0800, Eric Messick said:
> On 1/25/07, Stephen Gran <steve@???> wrote:
> No.   Time        Source                Destination           Protocol  Info
> 1   0.000000    198.144.198.191       209.51.152.98         TCP 4500 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=78345384 TSER=0  WS=0
> 2   0.092229    209.51.152.98         198.144.198.191       TCP smtp > 4500 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 
> 3   0.092342    198.144.198.191       209.51.152.98         TCP 4500 > smtp [ACK] Seq=1 Ack=1 Win=5840 Len=0
> 4   0.186294    209.51.152.98         198.144.198.191       TCP 40768 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460
> 5   0.186380    198.144.198.191       209.51.152.98         ICMP Destination unreachable
> 6   0.280798    209.51.152.98         198.144.198.191       SMTP Response: 220-river.securenet-server.net ESMTP Exim 4.63 #1 Wed, 24 Jan 2007 13:34:3 -0500
> 7   0.280882    198.144.198.191       209.51.152.98         TCP 4500 > smtp [ACK] Seq=1 Ack=185 Win=6432 Len=0
> 8   0.281210    198.144.198.191       209.51.152.98         SMTP Command: HELO syzygy.com
> 9   0.377053    209.51.152.98         198.144.198.191       TCP smtp > 4500 [ACK] Seq=185 Ack=18 Win=5840 Len=0
> 10  0.377683    209.51.152.98         198.144.198.191       SMTP Response: 250 river.securenet-server.net Hello syzygy.com [198.144.198.191]
> 11  0.377908    198.144.198.191       209.51.152.98         SMTP Command: MAIL FROM:<eric@???>
> 12  0.472850    209.51.152.98         198.144.198.191       SMTP Response: 250 OK
> 13  0.473057    198.144.198.191       209.51.152.98         SMTP Command: RCPT TO:<mark@???>
> 14  0.608652    209.51.152.98         198.144.198.191       TCP smtp > 4500 [ACK] Seq=260 Ack=86 Win=5840 Len=0
> 15  2.045787    209.51.152.98         198.144.198.191       TCP 40774 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460
> 16  2.045896    198.144.198.191       209.51.152.98         TCP smtp > 40774 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
> 17  2.138202    209.51.152.98         198.144.198.191       TCP 40774 > smtp [ACK] Seq=1 Ack=1 Win=5840 Len=0
> 18  2.258134    198.144.198.191       209.51.152.98         TCP 4501 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=78345610 TSER=0 WS=0
> 19  5.250159    198.144.198.191       209.51.152.98         TCP 4501 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=78345910 TSER=0 WS=0
> 20  11.250251   198.144.198.191       209.51.152.98         TCP 4501 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=78346510 TSER=0 WS=0
> 21  23.250406   198.144.198.191       209.51.152.98         TCP 4501 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=78347710 TSER=0 WS=0
> 22  32.138342   209.51.152.98         198.144.198.191       TCP 40774 > smtp [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
> 23  32.139131   209.51.152.98         198.144.198.191       SMTP Response: 451 Could not complete sender verify callout
> 24  32.139318   198.144.198.191       209.51.152.98         SMTP Command: QUIT


(reformatted slightly so I can read it).

> It looks like there's a 30 second delay between their ACK and their FIN
> ACK. I didn't think I'd configured a delay into my smtp server, but I'll go
> look.


The problem is apparently that, while you responsibly return icmp
unreachable for auth queries, they silently drop them, leaving you
reprobing them for auth before sending a greeting. This whole process
takes more than 30 seconds, so they tear down the conversation and
tempfail your mail.

I would suggest that if you can make auth queries _from_ your end take
less time, you do so. A firewall rule blocking outbound auth requests
would do it as a quick work around if your MTA can't limit the amount of
time it spends on auth queries natively. A conversation with their end
asking them to return an icmp unreachable rather than dropping it would
be good as well.
--
--------------------------------------------------------------------------
|  Stephen Gran                  | Things are not always what they seem.   |
|  steve@???             | -- Phaedrus                             |
|  http://www.lobefin.net/~steve |                                         |

--------------------------------------------------------------------------