Re: [exim] Ordering of random vs. real sender verification c…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: David Woodhouse
Dátum:  
Címzett: W B Hacker
CC: exim users
Tárgy: Re: [exim] Ordering of random vs. real sender verification callout
On Sat, 2009-05-16 at 13:55 +0800, W B Hacker wrote:
> David Woodhouse wrote:
> > I've just encountered a host which seems to temporarily firewall me for
> > a minute or two after I give it a bogus RCPT TO:.
> >
> > So what happens is this:
> >
> > Exim connects and does a random callout, which is correctly rejected.
> > On sending RSET, it just gets a TCP FIN back. Exim attempts to make
> > another connection, and its SYN packets are just ignored.
> >
> > Five minutes later, the sender tries again. This time, the random
> > callout result is cached, so Exim goes straight to verifying the _real_
> > address. The verification passes, and the mail is accepted.
> >
> > Perhaps we should be doing our callouts in the opposite order -- the
> > real address (which we expect to succeed) before the random address
> > (which we expect to fail)?
> >
> > Yes, that means that in the case where the random address _does_
> > succeed, we're pointlessly checking the real address too. But only once,
> > and we're still doing it all in only a single connection.
> >
>
> Try it both ways against wbh@???, then again against wbh@???
>
> I'll check the logs and let you know what we are seeing here.


The former just gives me this on connection (to 203.194.153.81):

    451 Temporary local problem - please try later


The latter works fine; gives this in the callback exchange:

    220 ESMTP Sat, 16 May 2009 14:30:13 +0800
    HELO twosheds.infradead.org
    250 triligon.to Hello twosheds.infradead.org [90.155.92.209]
    MAIL FROM:<>
    250 OK
    RCPT TO:<twosheds.infradead.org-1242455382-testing@???>
    550-
    550 Mis-typed or Invalid address or wrong address format.
    RSET
    250 Reset OK
    MAIL FROM:<>
    250 OK
    RCPT TO:<wbh@???>
    250 Accepted
    QUIT
    221 triligon.to closing connection


--
dwmw2