Re: [Sqlgrey-users] Dealing with pooled outgoing servers

[Lionel B. <lio...@bo...>]

Jeff Rice wrote the following on 22.07.2005 20:06 :

>Looking at my log today, I noticed a particular server (or set of
>servers, actually) that kept connecting to retry a single message.  The
>sender email, recipient email, and helo were the same but the sending
>servers were different (but on the same C net).  I believe that other
>ISPs use a similar technique -- AOL, for example?
>
>Can we think about a strategy to address this, without whitelisting
>these blocks?   If the C subnet is going to get whitelisted (assuming it
> has a reverse addy and is not dynamic) once it retries, is there a
>fundamental reason why the C net can't be used in the connect db rather
>than a full quad?
>
>  
>

 From sqlgrey.conf :

## Greylisting method:
# - full   : greylist by IP address
# - classc : greylist by class C network. eg:
#            2.3.4.6 connection accepted if 2.3.4.145 did connect earlier
# - smart  : greylist by class C network unless there is no reverse lookup
#            or it looks like a home-user address
# Default is smart
# greymethod = smart

If you use "full" the behaviour you witnessed is expected. If you use 
"smart" most of the time SQLgrey will find out that it's better to use 
the class C network when it is a real SMTP server from a pool but will 
occasionnaly fail to guess that class C is more suited so you can expect 
what you saw sometimes. If you use "classc" it will always use the class 
C network.

Note: "smart" relies on the fqdn Postfix hands over for the IP address, 
if the DNS is misconfigured on the other end of the communication, smart 
can't find out if the IP is more likely to be a SMTP server or a Windows 
zombie on a home connection. To be on the safe side it will use the 
whole IP.

I'm interested in the actual IP addresses you have problem with. 
Depending on the actual DNS entries I could modify the tests so that 
"smart" is more ... smart.

Lionel.