At 8:06 +0100 2003/07/01, Andrew - Supernews wrote: > >>>>> "Giuliano" == Giuliano Gavazzi <eximlists@???> writes: [...] > >> fail to receive mail from us; if you make the callout attempts
> >> from an IP address which is listed on a dynamic-IPs list
> >> (currently dynablock.easynet.nl), or on one of a number of proxy
> >> and spam-sources blacklists, then the default timeouts will be too
> >> short to get the successful response from the verification, and
> >> you'll just defer the message forever unless you lengthen the
> >> timeout (to at least a couple of minutes) or set defer_ok.
>
> Giuliano> this is because, apart from the HELO phase, a server should
> Giuliano> offer a clean path to verification using a null sender.
>
>I think you missed my point completely.
>
>We do not currently reject any mail at the HELO or MAIL FROM stage,
>with the exception of Cacheflow proxies which are not permitted to
>connect at all. However, we do force substantial delays on certain
>hosts, and those delays _will_ cause sender callout verification to
>time out unless the timeout is increased from the default.
I also apply delays, but at the RCPT phase there are no delays for
sender verifications. With Clean I meant Clean! The problem is not
the sender callout, if you delayed for 6 minutes and the remote
server disconnected, would you say it is a problem with the SMTP
protocol? (well, maybe you could..)
