Mailing List Archive: exim: users

Sender verification, permanent vs. transient error codes

1 2

View All

Index | Next | Previous | View Threaded

nanosyzygy at gmail

Jan 24, 2007, 4:02 PM

Post #1 of 27 (2030 views)
Permalink

Sender verification, permanent vs. transient error codes

I'm having trouble sending email to a domain that uses exim 4.63. The
problem occurs with sender verification.

I snooped the packets on my outgoing smtp server and saw the following
exchange:

-------------------------
I (198.144.198.191) open a connection from port 4500 to their (209.51.152.98)
port 25.
They try to connect to my port 113 for auth.
I reply with an ICMP Destination Unreachable.
Then we do a normal SMTP exchange. When I send "RCPT TO:", they start the
sender verify:

They open a connection from port 40774 to my port 25, sending SYN.
I reply with SYN ACK.
They reply with ACK, completing the opening of the connection.
They send FIN ACK, immediately closing the connection.
I reply to the initial open with an ACK, followed by the text "220
syzygy.com ESMTP".
I then notice that they've closed the connection and send FIN ACK.
They reply to my last ACK and data packets with a pair of RST packets, since
they closed the connection without waiting for this data.

Back on the port 4500 connection, they reply with "451 Could not complete
sender verify callout".
-----------------------------

Well, I looked at :

http://www.exim.org/exim-html-3.00/doc/html/oview.html#SEC21

which says:

Unfortunately, several mailers believe that any error response after the
data for a message has been sent indicates a temporary error. Consequently,
such mailers will continue to try to send a message that has been rejected
as described above. To prevent this, whenever a message is rejected, Exim
records the time, bad address, and host in a DBM database. If the same host
sends the same bad address within 24 hours, it is rejected immediately at
the MAIL FROM command.

Sadly, even this doesn't stop some mailers from repeatedly trying to send
the message. As a last resort, if the same host sends the same bad address
for a third time in 24 hours, the MAIL FROM command is accepted, but all
subsequent RCPT TO commands are rejected. If this does not stop a remote
mailer then it is badly broken.

Since my MAIL FROM command is being accepted, and the RCPT TO is being
rejected, I'm guessing that I've landed in this DBM database. I know that
qmail is retrying these messages.

There are several curious things going on here. First, I have no idea why
sender verify would have ever failed, since I've never seen any error other
than the "451 Could not complete sender verify callout". There might be a
configuration problem on my end, but I can't get any info to debug it.

Second, the actual sender verify exchange doesn't seem to match what exim
claims to do. I gather that it's supposed to actually present an email
address and get back a yes/no reply from my side. Instead, it's just
opening the connection and closing it, without waiting for my initial 220
string. Perhaps it's finding me in the database and decides it doesn't need
to bother with the actual verification, so it just closes the connection.
That would be very bad, since I wouldn't have any chance of fixing a problem
once I got into that database. I'd have to flush my queue and not send any
email to that domain for 24 hours.

Most troubling, though, is that (according to the above link) exim expects
me to stop retrying, and tells me this by giving me a 451 TRANSIENT error.
Why would I stop trying when given a transient error?

Does exim record the error in this database, and resend it each time with
the same error code? That could explain the problem. Perhaps an actual
transient error occurred, and I retried enough to get stuck in the
database. Then, even though the error was fixed I still got an old copy of
the transient error message. It seems far fetched.

Can anyone tell from this what is going on?

What other info is needed to figure this out?

Thanks

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

holmgren at lysator

Jan 24, 2007, 5:24 PM

Post #2 of 27 (1997 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thursday 25 January 2007 01:02, Eric Messick wrote:
> I'm having trouble sending email to a domain that uses exim 4.63. The
> problem occurs with sender verification.
>
> I snooped the packets on my outgoing smtp server and saw the following
> exchange:
>
> -------------------------
> I (198.144.198.191) open a connection from port 4500 to their
> (209.51.152.98) port 25.
> They try to connect to my port 113 for auth.
> I reply with an ICMP Destination Unreachable.
> Then we do a normal SMTP exchange. When I send "RCPT TO:", they start the
> sender verify:
>
> They open a connection from port 40774 to my port 25, sending SYN.
> I reply with SYN ACK.
> They reply with ACK, completing the opening of the connection.
> They send FIN ACK, immediately closing the connection.
> I reply to the initial open with an ACK, followed by the text "220
> syzygy.com ESMTP".
> I then notice that they've closed the connection and send FIN ACK.
> They reply to my last ACK and data packets with a pair of RST packets,
> since they closed the connection without waiting for this data.
>
> Back on the port 4500 connection, they reply with "451 Could not complete
> sender verify callout".

That's strange. I tested from sesame (the www.exim.org box) and got through
fine. I can see the sender verification in Exim's log.

> Well, I looked at :
>
> http://www.exim.org/exim-html-3.00/doc/html/oview.html#SEC21

That document is massively outdated. Some information may still be valid,
though.

> Unfortunately, several mailers believe that any error response after the
> data for a message has been sent indicates a temporary error. Consequently,
> such mailers will continue to try to send a message that has been rejected
> as described above. To prevent this, whenever a message is rejected, Exim
> records the time, bad address, and host in a DBM database. If the same host
> sends the same bad address within 24 hours, it is rejected immediately at
> the MAIL FROM command.
>
> Sadly, even this doesn't stop some mailers from repeatedly trying to send
> the message. As a last resort, if the same host sends the same bad address
> for a third time in 24 hours, the MAIL FROM command is accepted, but all
> subsequent RCPT TO commands are rejected. If this does not stop a remote
> mailer then it is badly broken.

This talks about sender verification and the subsequent possible rejection
after the DATA command. As you never got that far, it doesn't apply.

> Since my MAIL FROM command is being accepted, and the RCPT TO is being
> rejected, I'm guessing that I've landed in this DBM database. I know that
> qmail is retrying these messages.

This is something Exim 3.00 apparently was doing. Exim 4.63 has way more
flexibility; thus you can't draw any conclusions as to whether you've ended
up in any database. Usually callout verification is done after RCPT TO and
there is no such database at all.

So sorry, the rest of your mail is irrelevant as well.

I can't say for sure where the problem lies. Perhaps they had a temporary
problem. Maybe someone else on this list has a similar configuration so that
you can test against their server.

--
Magnus Holmgren holmgren[at]lysator.liu.se
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans

nanosyzygy at gmail

Jan 24, 2007, 7:14 PM

Post #3 of 27 (1991 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

First off, thanks for looking at this. It's getting to be quite frustrating
for me.

On 1/24/07, Magnus Holmgren <holmgren[at]lysator.liu.se> wrote:

> That's strange. I tested from sesame (the www.exim.org box) and got
> through
> fine. I can see the sender verification in Exim's log.

Did you do a sender verify callout to syzygy.com? Or just telnet? Or did
you send email TO exim.org and look in the log there? Sorry, I'm just not
sure what you did.

> Well, I looked at :
> >
> > http://www.exim.org/exim-html-3.00/doc/html/oview.html#SEC21
>
> That document is massively outdated. Some information may still be valid,
> though.

I *think* that's a good thing... Anyway, I'm glad to know it.

This talks about sender verification and the subsequent possible rejection
> after the DATA command. As you never got that far, it doesn't apply.

So, still there's no clue as to what the actual problem is. Perhaps they
have more info in their logs. I should ask them to check.

> Since my MAIL FROM command is being accepted, and the RCPT TO is being
> > rejected, I'm guessing that I've landed in this DBM database. I know
> that
> > qmail is retrying these messages.
>
> This is something Exim 3.00 apparently was doing. Exim 4.63 has way more
> flexibility; thus you can't draw any conclusions as to whether you've
> ended
> up in any database. Usually callout verification is done after RCPT TO and
> there is no such database at all.

Yes, the callout is being done right after the RCPT TO. Do you find it
strange that they're closing the connection without even waiting for my
first byte of data? Or is that the way sender verification is supposed to
work?

I could see value in it either way, so I'm not sure which exim does. My
impression is that it's supposed to submit an address and act based on my
response to that address. Since it's clearly not doing that, it looks to me
like something is broken on their end. But I don't know enough about this
to be sure.

So sorry, the rest of your mail is irrelevant as well.
>
> I can't say for sure where the problem lies. Perhaps they had a temporary
> problem. Maybe someone else on this list has a similar configuration so
> that
> you can test against their server.

Unfortunately, I don't have access to their configuration data, so I don't
know how to tell if I'm talking to someone set up the same way.

I've tried to get them to look into this, but I think they're convinced
there's a problem on my end. I wouldn't be surprised if there is a problem
on my end as well, but it sure looks to me like they've got a problem.

I guess I'm wondering if anyone can confirm that for me based on what I've
posted so far, or anything else I could provide.

Again, I'm not running exim on my side, so I'm not very familiar with it.
I'm running qmail.

Thanks again,

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

dwmw2 at infradead

Jan 25, 2007, 1:39 AM

Post #4 of 27 (1991 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Wed, 2007-01-24 at 16:02 -0800, Eric Messick wrote:
> They open a connection from port 40774 to my port 25, sending SYN.
> I reply with SYN ACK.
> They reply with ACK, completing the opening of the connection.
> They send FIN ACK, immediately closing the connection.
> I reply to the initial open with an ACK, followed by the text "220
> syzygy.com ESMTP".
> I then notice that they've closed the connection and send FIN ACK.
> They reply to my last ACK and data packets with a pair of RST packets, since
> they closed the connection without waiting for this data.

I suspect a broken firewall. Since it doesn't seem to happen when I
connect to the mailhost for syzygy.com, I suspect a broken firewall at
_their_ side. Can you get them to show a tcpdump of their end of the
conversation?

--
dwmw2

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 8:48 AM

Post #5 of 27 (1989 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, David Woodhouse <dwmw2[at]infradead.org> wrote:
>
> On Wed, 2007-01-24 at 16:02 -0800, Eric Messick wrote:
> > They open a connection from port 40774 to my port 25, sending SYN.
> > I reply with SYN ACK.
> > They reply with ACK, completing the opening of the connection.
> > They send FIN ACK, immediately closing the connection.
> > I reply to the initial open with an ACK, followed by the text "220
> > syzygy.com ESMTP".
> > I then notice that they've closed the connection and send FIN ACK.
> > They reply to my last ACK and data packets with a pair of RST packets,
> since
> > they closed the connection without waiting for this data.
>
> I suspect a broken firewall. Since it doesn't seem to happen when I
> connect to the mailhost for syzygy.com, I suspect a broken firewall at
> _their_ side. Can you get them to show a tcpdump of their end of the
> conversation?

I'll see if I can get one.

I believe that mail from their server to mine works just fine. Their
firewall would have to be stopping their outgoing connection only when in
the middle of an incoming one from me. That doesn't seem plausible to me.

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

steve at lobefin

Jan 25, 2007, 8:56 AM

Post #6 of 27 (1987 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Wed, Jan 24, 2007 at 04:02:36PM -0800, Eric Messick said:
> I'm having trouble sending email to a domain that uses exim 4.63. The
> problem occurs with sender verification.
>
> I snooped the packets on my outgoing smtp server and saw the following
> exchange:

You don't show the timestamps on the packets, so I can't say for sure,
but how long between handshake and FIN? They may have a callout set up
with a timeout shorter than it takes your server to send the banner
(e.g., if you use delays before the banner is up, or you do rDNS checks,
or anything else). Knowing that the whole conversation happened roughly
immediately would rule that out, or provide another avenue for
investigation.

Take care,
--
--------------------------------------------------------------------------
| Stephen Gran | The first Rotarian was the first man to |
| steve[at]lobefin.net | call John the Baptist "Jack." -- H.L. |
| http://www.lobefin.net/~steve | Mencken |
--------------------------------------------------------------------------

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

holmgren at lysator

Jan 25, 2007, 9:05 AM

Post #7 of 27 (1992 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thursday 25 January 2007 04:14, Eric Messick wrote:
> On 1/24/07, Magnus Holmgren <holmgren[at]lysator.liu.se> wrote:
> > That's strange. I tested from sesame (the www.exim.org box) and got
> > through
> > fine. I can see the sender verification in Exim's log.
>
> Did you do a sender verify callout to syzygy.com? Or just telnet? Or did
> you send email TO exim.org and look in the log there? Sorry, I'm just not
> sure what you did.

No, I connected (with telnet) to [209.51.152.98]:25, said (after EHLO) MAIL
FROM: magnus[at]exim.org and RCPT TO: postmaster@(the domain name in the
greeting). No error. Now I did the same, but with MAIL FROM:
postmaster[at]syzygy.com. Again no error.

--
Magnus Holmgren holmgren[at]lysator.liu.se
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans

nanosyzygy at gmail

Jan 25, 2007, 9:34 AM

Post #8 of 27 (1991 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, Stephen Gran <steve[at]lobefin.net> wrote:
>
>
> You don't show the timestamps on the packets, so I can't say for sure,
> but how long between handshake and FIN? They may have a callout set up
> with a timeout shorter than it takes your server to send the banner
> (e.g., if you use delays before the banner is up, or you do rDNS checks,
> or anything else). Knowing that the whole conversation happened roughly
> immediately would rule that out, or provide another avenue for
> investigation.

Ok, here's a dump of the whole log:

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
> 6 -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[at]xxxxxxxxxxx.syzygy.com>
> 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[at]xxxxxxxx.com>
> 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
> 25 32.139481 198.144.198.191 209.51.152.98 TCP
> 4500 > smtp [FIN, ACK] Seq=92 Ack=306 Win=6432 Len=0
> 26 32.140521 198.144.198.191 209.51.152.98 TCP
> smtp > 40774 [ACK] Seq=1 Ack=2 Win=5840 Len=0
> 27 32.233483 209.51.152.98 198.144.198.191 TCP
> smtp > 4500 [ACK] Seq=306 Ack=92 Win=5840 Len=0
> 28 32.233933 209.51.152.98 198.144.198.191 SMTP
> Response: 221 river.securenet-server.net closing connection
> 29 32.234026 198.144.198.191 209.51.152.98 TCP
> [TCP Keep-Alive] 4500 > smtp [RST] Seq=92 Ack=1150951851 Win=0 Len=0
> 30 32.235117 209.51.152.98 198.144.198.191 TCP
> smtp > 4500 [FIN, ACK] Seq=357 Ack=92 Win=5840 Len=0
> 31 32.235187 198.144.198.191 209.51.152.98 TCP
> [TCP Keep-Alive] 4500 > smtp [RST] Seq=92 Ack=1150951851 Win=0 Len=0
> 32 32.235199 209.51.152.98 198.144.198.191 TCP
> smtp > 4500 [ACK] Seq=358 Ack=93 Win=5840 Len=0
> 33 32.235235 198.144.198.191 209.51.152.98 TCP
> 4500 > smtp [RST] Seq=93 Ack=1150951851 Win=0 Len=0
> 34 32.251645 198.144.198.191 209.51.152.98 SMTP
> Response: 220 syzygy.com ESMTP
> 35 32.251772 198.144.198.191 209.51.152.98 TCP
> smtp > 40774 [FIN, ACK] Seq=23 Ack=2 Win=5840 Len=0
> 36 32.345273 209.51.152.98 198.144.198.191 TCP
> 40774 > smtp [RST] Seq=2 Ack=2978285068 Win=0 Len=0
> 37 32.345853 209.51.152.98 198.144.198.191 TCP
> 40774 > smtp [RST] Seq=2 Ack=2978285068 Win=0 Len=0

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.

I turned off reverse DNS lookups when I was having problems getting mail
from a misconfigured domain, so that shouldn't be it.

Is 30 seconds too short to wait on their part? If everyone waited until
near the end of the maximum allowable delay to answer, sender verification
could never work.

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 9:41 AM

Post #9 of 27 (1988 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, Magnus Holmgren <holmgren[at]lysator.liu.se> wrote:
>
>
> No, I connected (with telnet) to [209.51.152.98]:25, said (after EHLO)
> MAIL
> FROM: magnus[at]exim.org and RCPT TO: postmaster@(the domain name in the
> greeting). No error. Now I did the same, but with MAIL FROM:
> postmaster[at]syzygy.com. Again no error.

Hmmm.... I should try that while I'm watching packets.

That would tend to support the "got stuck in the bad guy DBM database"
theory. Why else would some addresses succeed and others fail?

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

steve at lobefin

Jan 25, 2007, 9:58 AM

Post #10 of 27 (1992 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thu, Jan 25, 2007 at 09:34:06AM -0800, Eric Messick said:
> On 1/25/07, Stephen Gran <steve[at]lobefin.net> 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[at]xxxxxxxxxxx.syzygy.com>
> 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[at]xxxxxxxx.com>
> 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[at]lobefin.net | -- Phaedrus |
| http://www.lobefin.net/~steve | |
--------------------------------------------------------------------------

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

wbh at conducive

Jan 25, 2007, 10:01 AM

Post #11 of 27 (1988 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

Eric Messick wrote:
> On 1/25/07, Magnus Holmgren <holmgren[at]lysator.liu.se> wrote:
>>
>> No, I connected (with telnet) to [209.51.152.98]:25, said (after EHLO)
>> MAIL
>> FROM: magnus[at]exim.org and RCPT TO: postmaster@(the domain name in the
>> greeting). No error. Now I did the same, but with MAIL FROM:
>> postmaster[at]syzygy.com. Again no error.
>
>
> Hmmm.... I should try that while I'm watching packets.
>
> That would tend to support the "got stuck in the bad guy DBM database"
> theory. Why else would some addresses succeed and others fail?
>
> -eric

JFWIW, 'Why else' when you are running Qmail can also include blocking of, for
example, the 'nth' and subsequent attempts at delivery to a destination over
multiple, parallel connections from the same sending server - a Qmail trait of
long-standing.

More smtp-compliant MTA use a single connection to send ONE copy of a message
with ONE set of handshakes and let the receiving server dupicate it locally.
Much more efficient of bandwidth, CPU, & other resources at both ends.

'n' can be as low as 2 for Exim's 'smtp_accept_max_per_host' allowing for a
simultaneous sender-verify, but blocking parallelizing spambots, and forcing
Qmail to 'come back later'. Often more than once.

This does not appear to be your specific situation, but you may encounter it
also, and it might initially look like an unpredictable form of blacklisting.

A side effect, BTW, is that Qmail is slower - *very much* slower - to complete
multiple-recipient-same-server delivery than 'proper' MTA - just the reverse of
their historical claim to fame, and dramatically so.

But if it acts like a spambot, walks like a spambot, and talks like a spambot -
it will have to take the heat.

HTH,

Bill Hacker

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 10:01 AM

Post #12 of 27 (1987 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, Eric Messick <nanosyzygy[at]gmail.com> wrote:
>
>
>
> On 1/25/07, Magnus Holmgren <holmgren[at]lysator.liu.se> wrote:
> >
> >
> > No, I connected (with telnet) to [209.51.152.98]:25, said (after EHLO)
> > MAIL
> > FROM: magnus[at]exim.org and RCPT TO: postmaster@(the domain name in the
> > greeting). No error. Now I did the same, but with MAIL FROM:
> > postmaster[at]syzygy.com. Again no error.
>
>
> Hmmm.... I should try that while I'm watching packets.
>
> That would tend to support the "got stuck in the bad guy DBM database"
> theory. Why else would some addresses succeed and others fail?
>

Ok, I tried it myself, and here's what I found.

RCPT TO: postmaster[at]x.y gets accepted immediately without doing a sender
verify at all.

All other combinations result in a sender verify which fails after a 30
second timeout.

When I telnet to my own address, I get the 220 greeting immediately. When
they try the sender verify, I give them at least a 30 second delay, and they
close and fail the verify.

Looks like I need to find out where that delay is coming from on my side.

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 10:06 AM

Post #13 of 27 (1989 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, Stephen Gran <steve[at]lobefin.net> wrote:
>
>
> 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.

That sounds like an excellent theory. The only question I have is: why
don't I see outgoing auth queries in the conversation?

I'll look into probing them on auth, and trying to stomp them on my end, and
see if that helps.

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

jh at plonk

Jan 25, 2007, 10:11 AM

Post #14 of 27 (1982 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

Quoting Eric Messick:

> When I telnet to my own address, I get the 220 greeting immediately. When
> they try the sender verify, I give them at least a 30 second delay, and they
> close and fail the verify.

I have seen such behaviour with broken firewalls (somewhere on the way,
could be on yours or their side) which erroneously tried to handle tcp
window scaling (rfc 1323). Are they/you using Linux with kernel >
2.6.17? Then try "echo 0 > /proc/sys/net/ipv4/tcp_window_scaling". See
e.g. http://kerneltrap.org/node/6723 for more information.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

steve at lobefin

Jan 25, 2007, 10:28 AM

Post #15 of 27 (1985 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thu, Jan 25, 2007 at 10:06:48AM -0800, Eric Messick said:
> On 1/25/07, Stephen Gran <steve[at]lobefin.net> wrote:
> >
> > 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.
>
> That sounds like an excellent theory. The only question I have is: why
> don't I see outgoing auth queries in the conversation?

You do:
> > 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

> I'll look into probing them on auth, and trying to stomp them on my end, and
> see if that helps.

That sounds like a good plan.
--
--------------------------------------------------------------------------
| Stephen Gran | <rcw> those apparently-bacteria-like |
| steve[at]lobefin.net | multicolor worms coming out of |
| http://www.lobefin.net/~steve | microsoft's backorifice <rcw> that's |
| | the backoffice logo |
--------------------------------------------------------------------------

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 10:39 AM

Post #16 of 27 (1982 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

Well, this appears to be the winner. If I REJECT outgoing auth connections
to their host, the sender verify completes with no problems.

Now I just need to convince them to fix it on their end...

Thanks, everyone!!!

-eric

On 1/25/07, Eric Messick <nanosyzygy[at]gmail.com> wrote:
>
>
>
> On 1/25/07, Stephen Gran <steve[at]lobefin.net> wrote:
> >
> >
> > 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.
>
>
> That sounds like an excellent theory. The only question I have is: why
> don't I see outgoing auth queries in the conversation?
>
> I'll look into probing them on auth, and trying to stomp them on my end,
> and see if that helps.
>
> -eric
>
>
>
>
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

joy at entuzijast

Jan 25, 2007, 1:01 PM

Post #17 of 27 (1980 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thu, Jan 25, 2007 at 10:39:38AM -0800, Eric Messick wrote:
> Well, this appears to be the winner. If I REJECT outgoing auth connections
> to their host, the sender verify completes with no problems.

Why do you do do ident checks, anyway? I thought they were pointless these
days... I've had rfc1413_query_timeout = 0s set for ages now.

--
2. That which causes joy or happiness.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

joy at entuzijast

Jan 25, 2007, 1:05 PM

Post #18 of 27 (1987 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thu, Jan 25, 2007 at 10:01:29AM -0800, Eric Messick wrote:
> RCPT TO: postmaster[at]x.y gets accepted immediately without doing a sender
> verify at all. All other combinations result in a sender verify which
> fails after a 30 second timeout.

BTW, that's normal - postmaster should have less stringent validity checks
in case someone is reporting a problem with the mail system. It's hard to
report a mail problem if the mail server prevents postmaster from getting
mail :)

--
2. That which causes joy or happiness.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

nanosyzygy at gmail

Jan 25, 2007, 1:15 PM

Post #19 of 27 (1984 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On 1/25/07, Josip Rodin <joy[at]entuzijast.net> wrote:

> Why do you do do ident checks, anyway? I thought they were pointless these
> days... I've had rfc1413_query_timeout = 0s set for ages now.

I agree that they're worthless.

I'm only doing them because they seem to be on by default. I'm not an ISP,
I just run a server on my own domain. I'll probably look into how to shut
them off, but right now I have to get back to my real job.

Thanks again to everyone for the help.

-eric
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

kjetilho at ifi

Jan 27, 2007, 10:42 AM

Post #20 of 27 (1988 views)
Permalink

Re: Sender verification, permanent vs. transient error codes [In reply to]

On Thu, 2007-01-25 at 22:01 +0100, Josip Rodin wrote:
> Why do you do do ident checks, anyway? I thought they were pointless these
> days... I've had rfc1413_query_timeout = 0s set for ages now.

they are not pointless if you want us to accurately handle complaints
about abuse coming from our multi-user servers. a timeout of 5s should
be plenty, though.

--
Kjetil T.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

wbh at conducive

Jan 27, 2007, 10:50 AM

Post #21 of 27 (1980 views)
Permalink

Re: OFF LSIT - ident check [In reply to]

Kjetil Torgrim Homme wrote:
> On Thu, 2007-01-25 at 22:01 +0100, Josip Rodin wrote:
>> Why do you do do ident checks, anyway? I thought they were pointless these
>> days... I've had rfc1413_query_timeout = 0s set for ages now.
>
> they are not pointless if you want us to accurately handle complaints
> about abuse coming from our multi-user servers. a timeout of 5s should
> be plenty, though.
>

Kjetil.

*Last thing* I want is to start a bonfire... but I am not too old to learn..

We've given up in ident checks, and do not run a daemon ourselves.

The benefit you gain shows up how? And is it unique, or something that can be
adequately served by other means?

i.e - big win? little win?

Curious, not confrontational... (too tired...)

Bill Hacker

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

kjetilho at ifi

Jan 27, 2007, 11:45 AM

Post #22 of 27 (1980 views)
Permalink

Re: OFF LSIT - ident check [In reply to]

On Sun, 2007-01-28 at 02:50 +0800, W B Hacker wrote:
> We've given up in ident checks, and do not run a daemon ourselves.
>
> The benefit you gain shows up how? And is it unique, or something that can be
> adequately served by other means?
>
> i.e - big win? little win?

if someone sends e-mail from login.uio.no and we get a complaint about
it, there will be a dozen or two possible users. if they include
ident-information with the complaint, we can pinpoint the culprit
exactly.

there is no reason for _you_ to run ident, since there won't be users
logged on to your server.

--
Kjetil T.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

ph10 at hermes

Jan 30, 2007, 2:39 AM

Post #23 of 27 (1960 views)
Permalink

Re: OFF LSIT - ident check [In reply to]

On Sat, 27 Jan 2007, Kjetil Torgrim Homme wrote:

> if someone sends e-mail from login.uio.no and we get a complaint about
> it, there will be a dozen or two possible users. if they include
> ident-information with the complaint, we can pinpoint the culprit
> exactly.

Same for several hosts in .cam.ac.uk - some with thousands of accounts.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

anfi at xl

Jan 30, 2007, 10:28 AM

Post #24 of 27 (1948 views)
Permalink

Re: OFF LSIT - ident check [In reply to]

Philip Hazel <ph10[at]hermes.cam.ac.uk> writes:

> On Sat, 27 Jan 2007, Kjetil Torgrim Homme wrote:
>
>> if someone sends e-mail from login.uio.no and we get a complaint about
>> it, there will be a dozen or two possible users. if they include
>> ident-information with the complaint, we can pinpoint the culprit
>> exactly.
>
> Same for several hosts in .cam.ac.uk - some with thousands of accounts.

Do you think it would be worthwhile to create some kind of in DNS hint
recommending to check ident info provided by given host?

--
[pl>en: Andrew] Andrzej Adam Filip : anfi[at]priv.onet.pl : anfi[at]xl.wp.pl
Home site: http://anfi.homeunix.net/

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

kjetilho at ifi

Jan 30, 2007, 12:05 PM

Post #25 of 27 (1952 views)
Permalink

Re: OFF LSIT - ident check [In reply to]

On Tue, 2007-01-30 at 19:28 +0100, Andrzej Adam Filip wrote:
> Do you think it would be worthwhile to create some kind of in DNS hint
> recommending to check ident info provided by given host?

a single TCP SYN to port 1413 with a response of RST is much less
expensive than a DNS roundtrip to get a "no data" response.

those who set up their firewalls to drop packets silently will get
slower e-mail from some hosts, but that's their own doing.
--
Kjetil T.

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com