[SLL] Greylisting downsides: Solutions?

johnbaxterlists at mac.com johnbaxterlists at mac.com
Tue Jun 12 14:49:32 PDT 2007


On Jun 12, 2007, at 11:38 AM, Glenn Stone wrote:

> So I was just doing something on a major car-rental company's  
> website, and I
> said to myself, "That's gonna generate an email."  So I went into  
> Postgrey's
> whitelist, added what I *thought* should be the appropriate domain,
> reloaded, hit SUBMIT, and.... nothing.  Checked /var/log/mail.log,  
> there's
> the attempt, but it HELOed as... who??  Turns out it was a host  
> owned by
> Postini, who is apparently handling Not Exactly's email for them.   
> (Hertz,
> for what it's worth, whoever is running their email servers  
> actually have
> them HELO'ing as hertz.com.  Win!)

The HELO (usually EHLO for the past 10 years or more) text MUST be  
either the sending server's FQDN or if it doesn't know its name its  
IP address inside [...].  (On the other hand receiving servers MUST  
NOT reject mail because they don't like the text.  IETF committee  
politics, I presume.

In the real world, using [IP-address] will get an attempt blocked  
many places, and many receiving servers do block mail because they  
don't like the EHLO text (some even block for saying HELO rather than  
EHLO, although that's still authorized if frowned upon).

In your case, don't try to sharpshoot the problem:  turn off  
greylisting, wait for the message to come in, turn it back on, and  
make a guess as to whether whitelisting the sending server will work  
for future mail (whose timeliness may not matter as much anyhow).

Here, we give each user the power to turn greylisting on or off for  
their account (default on).  (We don't use Postfix--I have no idea  
what Postgrey offers in the way of options.)

Oh...and you might as well whitelist--through greylisting--all the  
Postini servers you learn about--they are going to pass greylisting  
anyhow, so why delay the mail?

> ...SPF...

Enforcing can work for yourself (it can even work for enforcing ~all  
as if it were -all, for yourself).  It can work for a multiuser setup  
if the users don't need to forward email through a server that  
doesn't do SRS.  It won't work for a server working for a mixed  
audience.

We use SPF
   1.  as input in deciding on servers to whitelist through greylisting
   2.  to add some SpamAssassin points for failure in the case of  
"trusted" (by us) domains (SpamAssassin points lead here to messages  
going into Spam folders, not being rejected or dropped).

Note that MANY spammers (who may or may not adhere to CAN-SPAM)  
carefully publish SPF for their domains.  (Others carefully use DK or  
DKIM.)  Just passing isn't meaningful--passing and being a desired  
sending domain is meaningful.  Failing DKIM can be meaningful, but  
watch out for mailing lists (the current Mailman causes problems by  
stripping DKIM signatures, a reaction to the problems caused by not  
doing so--next version will switch back).

   --John



More information about the linux-list mailing list