[Greylist-users] Greylisting via Exim 4 local_scan harmful?

William Blunn bill--greylist at blunn.org
Tue Mar 2 08:12:10 PST 2004

> From: "William Blunn" <bill--greylist at tao-group.com>
> >I had a user complain of a message appearing to have been lost during
> >the period when it was using local_scan.  I check the logs and indeed
> >it appears that a message from a large corporation (who shall remain
> >nameless) has been temporarily rejected, and then appears not to have
> >been re-tried.
> >
> >I am suspecting that the problem is that the message has been
> >temporarily rejected at the end of the DATA section, but the remote
> >mailer has ignored the reply and assumed successful delivery.
> This is plausible, but I'm reluctant to change my mailer in response
> to uncorroborated rumors about suspicions about misbehavior from
> anonymous large corporations.

It's not just this.  The Exim documentation also makes mention of
various other MTAs not properly interpreting errors other than at RCPT

Also, that would not be the only reason to change.  If you reject at
RCPT time rather than after DATA, then you get to save incoming
bandwidth to the tune of the size of the message.  It's looking like
95% of mail is Spam, so on a large site this can add up to a
significant incoming bandwidth saving.

I understand that existing admins may need more convincing before
expending resource on changing an existing installation over.

But for new installions I think it should be reason enough?

> Are you willing to make your hypothesis
> testable by naming the corporation?

I can give you the "Received" record immediately prior to the one
where the message entered our server, which ought to identify the MTA
software under suspicion.

I have removed the bits which identify the large corporation.

  Received: from <mailhost1>.<largecorp>.com (<mailhost1>.<largecorp>.com [<ipaddr>])
          by <mailhost2>.<largecorp>.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i21Eua7W004036
          for <<myuser>@tao-group.com>; Mon, 1 Mar 2004 06:56:36 -0800 (PST)

This probably identifies the MTA under suspicion as
"(Switch-3.1.4/Switch-3.1.0)".  I don't know what that is.

> I have observed that groups.yahoo.com doesn't retry when relaydelay
> TEMPFAIL's them at the end of the DATA section, and I cope with this
> by whitelisting them.  If I had correctly incorporated the whitelist
> from relaydelay the first time around, I wouldn't have seen this
> problem.  Is that the large corporation you had in mind?

No it's not Yahoo :-)

Although I did notice a problem with Yahoo.  They seem to always use a
different sender address, so I put in a whitelist entry for them on my


More information about the Greylist-users mailing list