Mail receiving delay

It simply slows down mail delivery. Essentially, the idea is to give a spurious error when a new server tries to deliver a message to your server. If the sending server is a "real" (i.e. well-behaved) server, it'll retry the message after a delay (how long depends on the sending server's policy; I think the current version of postfix will retry after 5 minutes), and the receiving server will let it in. On the other hand, if the sending server is a spambot, it's likely to simply abandon the attempt and try some other target.

It's actually a bit more complicated than that, because the server keeps a database of what sending servers have tried to send messages from what source address to what destination address; if it sees the same server sending from the same source to the same destination again, it doesn't apply the delay. Also, after the same server has successfully delivered 10 messages past the greylist delay, it's exempted from the greylist even if it's using a new source and/or destination address. (Note: this is assuming I've read the policy script right...)

Net result: legitimate incoming mail is delayed for a while, but gets through after a bit; the delay tends to go away as the server learns which other servers to trust. Mail from lazy spammers, on the other hand, tends to get blocked. In all, it's a good feature to have, but I'll second pterobyte's suggestions for making it more apparent what's going on.

Gordon -- Thank you for that lucid explanation. I knew nothing about greylisting until I upgraded my server to SLS and found mails not being delivered. Log messages showed "Recipient address rejected: Service is unavailable". Panic ensued.

While I'm tempted to use pterobyte's fix to shut off greylisting, I'm now inclined to let it run for a while and see if it "learns."

I do think Apple could have done a better job of explaining this. I called Apple Care and they were frankly clueless.

BTW, I'm noticing that the server does "learn." Mail sent yesterday to my server from my mac.com account took an hour+ to arrive. Today it takes about two minutes from the same address.

I don't think that it is true to say that it simply slows down mail. It actually rejects the mail and I agree with other comments that the rejection message is too obscure. It then expects the mail server to re-send the same mail. If that is done soon enough and is from the same server then it lets it through and gradually learns which servers to accept. BUT not all servers re-send soon enough and not all re-send from the same server and so the mail continues to be rejected. The problem is that there is no workaround if you leave grey listing on as it is up to the servers to re-send and to stop it you have to turn junk filtering off. So, I also agree that this should be visible in Server Admin Filters pane. I ended up calling support to resolve the problem (thanks!) and so now know where to look. Had it listed Grey Listing as an option I would have been onto it way earlier - even putting some info about it onto the page with no controls would be helpful - eg "Junk Filtering also enables Grey Listing". Also, the junk filtering setting I assumed are for SpamAssassin only when in fact they also affect a Postfix setting so is again not intuitive.

The SMTP error that greylisting gives - 450 - explicitly indicates a temporary error receiving the message (the RFC gives the example that this could mean the mailbox is busy), implying that the sending server should try again later (by contrast, a 5xx error would indicate a permanent error and that the sending server should not retry delivering the message). While it's true that this could interact poorly in some cases (e.g. the message being retried from another server), I think this is generally rare. The only real objection I have is its opacity -- it's not visible in the UI and the error messages it logs on the receiving server don't give any indication what's going on (note: it also doesn't give the sending server any indication of what's going on, but that's actually good in this case). That, and it complicates debugging because its fake errors can be hard to tell from real errors; so my advice is to turn greylisting off while debugging other receiving errors, but on for normal operation.

To my mind, a better solution than disabling greylisting (which is an extremely effective anti-spam method) is to simply change the delay value. the default is 60 minutes, which is excessive.

sudo vi /usr/libexec/postfix/greylist.pl
/greylist_delay to get to the line:
$greylist_delay=60;

(line 77 on my machine)

change the 60 to, say 6.

I use greylisting on my mailserver. 85%of the connections to my server are dropped before I get to the SMTP transaction phase based on bogus server names, blacklisted IPs, or greylisting.

I was unpleasantly surprised that greylisting happened *without warning/documentation* as soon as I went online with my migrated (10.5.8 -> 10.6.3) server. Especially as I saw a lot of unexpected error messages for my users when I asked my backup mail service to etrn the queues. Not knowing what was going on I suspected an error on my side and killed everything asap.

As soon as I found out what was going on, I edited main.cf and removed the greylisting. But that implies I have also lost spamassasin tagging and my server side rule depend on those.

So, how do I drop greylisting with its delays (at least temporarily) but keep spamassasin filtering?

Greylisting is a feature, it has nothing to do with SpamAssasin, IMHO.

Disable it using Alex's (aka pterobyte) instuctions: http://osx.topicdesk.com/content/view/144/84/

Regards,

Kostas

@Syth: the default greylist_delay is 60 seconds, not 60 minutes; I would not recommend decreasing this.

If I disable greylisting according to those instructions I also lose spamassassin. I want spamassassin and not greylisting. But postfix config just says to use policy server or not.