[Cialug] Postini and Graylisting

Pixel // pinterface pix at kepibu.org
Wed Nov 23 00:16:38 CST 2011


Claus Niesen wrote:
> I'm running my own email server and have been running it with gray
> listing happily for many years.  Now I'm doing some beta testing for
> a company that decided to send their emails through Postini and I
> found out the hard way that I wasn't getting their emails.
>
> Postini (Google) apparently ignores the RFC 5321 Section 4.2.5 &
> 4.5.4.1 which states that failed emails must be queued and retried.
> All I found was one attempt to send the email in my logs.

We must be reading 4.5.4.1 differently.

    ... mail that cannot be transmitted immediately MUST be
    queued and periodically retried by the sender.

I would consider "cannot be transmitted immediately" to be a rather
different condition than "can be transmitted but was deferred by the
receiving server".  E.g., the first might be satisfied by the client
being offline, or having a network failure, whereas the second requires
an ability to connect to the receiving server.

At any rate, SMTP doesn't require any particular retry strategy.  If
Postini wants to give up immediately, that's their call.  It's not a
call I would necessarily agree with--there are plenty of reasons to
issue a 4xy response that have nothing whatsoever to do with
greylisting--, but c'est la vie.

> What are you guys doing?  Are you really adding an exception for the
> Postini SMTP servers?  If I do white list Postini's IPs how likely is
> it that I get bombarded with spam through them?

Greylisting isn't meant to be applied against real e-mail servers like
Postini, it's meant to combat your typical pump-n-dump zombieware.  You
know, the stuff you should be rejecting outright anyway because it
doesn't have a PTR record, or has rDNS that looks something like
1.0.0.127.residential.some-isp.example.com.

Greylisting is not terribly dangerous when the sending side only uses
one IP (small operation); but when dealing with a larger mail
sender--well, your first link to Postini explains probably the biggest
problem with (most implementations of) greylisting, and it'll cause
trouble for more than just Postini.  Many large mail systems attempt to
send mail via one set of IPs immediately (fast lane), and retry on a
separate set of IPs (slow lane).  That means even if you manage to
accept the mail before it times out on the sending side it will likely
be significantly delayed.

I use Exim, rather than Postfix, so I can't help with your config, but I
can tell you this: I don't use greylisting, /and/ I don't get much spam.

Much of what I /do/ do is listed at:
  http://postmaster.mbmacorp.com/

As a rough idea, for the week of 11-13 to 11-20, my stats were roughly:
  3000 mail attempts, 500 accepted, 100 deferred, 2500 rejected
  Of those rejected messages:
   44% rejected for lack of PTR
   20% rejected for being on multiple DNSBLs
    2% rejected for being on my local blacklist
    2% rejected by SpamAssassin
   <1% rejected by ClamAV
With most of the remaining rejections for an assorted mixture of
multiple failings.  Defers were almost entirely for transitory
DNS issues.

My acceptance rate for incoming mail was about 12%, which is a little
high--I generally try to err on the accepting side, but it's also been a
while since I've updated my local blacklist.

And now I've probably completely obscured my point.  Yes, you should be
exempting known mailservers from greylisting--especially large mail
operations like Google, but really anybody listed in dnswl is going to
be a sender with retries.  Greylisting won't prevent any spam from such
sources; best case it will delay it, worst case you won't get the mail
at all.

Aside:

You might also be interested in perusing the archives of the mailop
list.  Archive are private, which means you'll have to sign up to read
them (also means they aren't really searchable; sad!), but the list is
very low traffic, and populated by people who run mailservers.

There's also the SDLU list, which is higher traffic and oriented more at
combating spam.  May or may not be useful.

-- 



More information about the Cialug mailing list