Bug#261511: marked as forwarded (exim4: possible very long delay with callout verification)

[Debian Bug Tracking System]

Your message dated Mon, 9 Aug 2004 12:19:58 +0200
with message-id <20040809101958.GD6238@downhill.at.eu.org>
has caused the Debian Bug report #261511,
regarding exim4: possible very long delay with callout verification
to be marked as having been forwarded to the upstream software
author(s) exim-users@exim.org.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

---------------------------------------
Received: (at 261511-forwarded) by bugs.debian.org; 9 Aug 2004 10:20:03 +0000
>From eximusers@downhill.at.eu.org Mon Aug 09 03:20:03 2004
Return-path: <eximusers@downhill.at.eu.org>
Received: from server.logic.univie.ac.at [131.130.190.41] ([UAwGafeBWYDHDAPmFgTN8htq3V9nrDyS])
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1Bu7G7-0003ou-00; Mon, 09 Aug 2004 03:20:03 -0700
Received: from m-134-246.adsl.univie.ac.at ([131.130.134.246])
	by server.logic.univie.ac.at with asmtp (Exim 4.34)
	id 1Bu7G2-0004LK-4m; Mon, 09 Aug 2004 12:20:00 +0200
Received: from ametzler by downhill.univie.ac.at with local (Exim 4.34)
	id 1Bu7G2-0001tf-MK; Mon, 09 Aug 2004 12:19:58 +0200
Date: Mon, 9 Aug 2004 12:19:58 +0200
From: Andreas Metzler <eximusers@downhill.at.eu.org>
To: exim-users@exim.org
Cc: Ron <ron@debian.org>, 261511-forwarded@bugs.debian.org
Subject: Re: Bug#261511: exim4: possible very long delay with callout verification
Message-ID: <20040809101958.GD6238@downhill.at.eu.org>
Mail-Followup-To: Andreas Metzler <eximusers@downhill.at.eu.org>,
	exim-users@exim.org, Ron <ron@debian.org>,
	261511-forwarded@bugs.debian.org
References: <E1Bp564-0004ME-AK@hank.shelbyville.oz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1Bp564-0004ME-AK@hank.shelbyville.oz>
X-GPG-Fingerprint: BCF7 1345 BE42 B5B8 1A57  EE09 1D33 9C65 8B8D 7663
User-Agent: Mutt/1.5.6+20040722i
Sender: Andreas Metzler <ametzler@downhill.at.eu.org>
Delivered-To: 261511-forwarded@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-4.5 required=4.0 tests=BAYES_10,HAS_BUG_NUMBER 
	autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 

Hello,
This is <http://bugs.debian.org/261511>, there is nothing I can add
except for the fact that Ron has point, verifying foo@newsabuse.net
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@debian.org> 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@newsabuse.net [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.