Hello,
This is <http://bugs.debian.org/261511>, there is nothing I can add
except for the fact that Ron has point, verifying foo@???
with callouts (exim -bhc) will indeed take a eternity, much longer
than is sane. - This is not fetchmail specific.
cu andreas
On 2004-07-26 Ron <ron@???> wrote:
> Package: exim4
> Version: 4.34-2
> Severity: normal
> Hi,
> exim4 allows you to configure a timeout for each single attempt at
> callout verification of receiver and sender addresses, but it places no
> absolute limit on the time taken to process a single address, or (put
> differently) on the number of mx's it will query before abandoning
> verification temporarily or permanently.
> I've been seeing spam with apparent senders from sites like mail333.com
> and newsabuse.net which have a large number of mx hosts listed in dns
> which are largely unresponsive. If exim attempts to do a callout
> verification on eg. foo@??? [1], then it will take
> sufficiently long to complete that a fetchmail process feeding it may
> lose its pop connection due to inactivity (which in the most common
> configuration will cause it to loop continually re-retrieving all the
> messages in the remote spool up to the problem one).
> Even with a callout time so short that usually responsive hosts may fail
> to answer in time, newsabuse.net was able to break my fetchmail feeder in
> this way until I disabled callout verification.
> If would be nice to have this defer if no answer is received in a (hard
> limited) configurable period, and perhaps to have a defer_fail option to
> complement defer_ok -- though the latter I can emulate using a acl_mX
> variable and two separate tests.
> See (the tail of) #186739 for similar comments with a fetchmail bias.
> callout verification is obviously more useful for a direct smtp
> connection than a fetchmail feed, but that may still be useful to
> people for mail filtering (it's too early for me to say how useful
> with much confidence ...)
> cheers,
> Ron
> [1] - exim -bt that one, then try to connect to a few to see what
> we're up against.
