The user exists more than once things is annoying, but normal as far as I can tell, with my server running in good shape.
The delay has me troubled. If the DNS is setup properly, etc, it should be fairly quick. When you send an email to your server (the current slow way) does anything show up in the logs? If it doesnt show up right away, it might be a DNS resolving issue on MSN (your example)'s end. When you send msn an email, it technically knows the path back quicker without having to do a full lookup (cached).
But if it hits your log file right away and then doesnt show up...it will be something completely different.
Let me know..
Greylisting was a user-requested feature for the mail server to help reduce the spam which accounts for more than 80% of mail sent to the average mail server. Delivery delays are eliminated over time as valid source addresses are added to the whitelist. If I may ask, is the delay not worth blocking spam?
If you would like to tune your settings, full postfix configuration options can be found here:
@chris, svr mgr, 1 of 5:
Greylisting is certainly a good thing to have in ones anti-spam arsenal. However, it would be better to have it as a separate option in Server Admin. Users are under the impression they "simply" enable a spam or virus filter and thus do not realize this may cause delays. Furthermore, greylisting needs to be GUI configurable (think whitelists) as there are unfortunately many legit mail servers not retrying (I know they should, but they are not).
It is our experience that unfamiliar users are confused by the overwhelming choices offered by Server Admin's mail settings GUI, while advanced administrators often go directly to the configuration files. Adding another configurable GUI option will only exacerbate new user confusion will essentially be ignored by advanced users.
I have seen requests such as "provide better spam filtering!" not "please provide me with every possible option to tune my spam settings". Greylisting addresses the former, while the postfix documentation offers advanced users the latter's flexibility. So, I ask my question in a different way: given a significant percentage of X Server administrators with little mail service admin experience, how would you present greylisting to maximize the benefit to the customer base? (And no, I'm not being snarky, I'm trying to gather suggestions for improving the product.)
I agree that inexperienced users are overwhelmed and may have difficulties to decide which options they need to use. I also fully agree that greylisting will block significant amounts of spam and is well suited for a mail server maintained by non professionals. However, "stealthy" options confuse new users even more.
In Server Admin, they tick "Enable junk mail filtering" and as soon as they do so, several grayed out options become active. While they may not be familiar to the beginner, the options are written on that page and can be looked up.
Nowhere does it say that greylisting is going to be enabled and so a user doesn't even know what to look for if things do not work. All the user notices are delays.
The problem is further amplified by the fact that the warning logged in mail.log does not specify what is happening. The policy server logs:
"NOQUEUE: reject: RCPT from... 450 ... Recipient address rejected: Service is unavailable;"
while for example Postgrey will log something like:
"NOQUEUE: reject: RCPT from... 450 ... Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html;"
Having this extra bit of information would help the inexperienced user in asking for help.
Add to this that greylisting can cause the loss of legit mail if not provided with a whitelist and you get unhappy users.
If it was my call, I'd implement one or more of the following in order of priority:
-A seperate checkbox for Greylisting
-Replace "Refuse all messages from these hosts and networks" with a listbox for whitelisted domains (Refusing mail by IP has become pointless nowadays. Spam comes mostly from botnets).
-Log an explicit warning in mail.log
-If there is no separate checkbox, display a warning when users tick "Enable junk mail filtering", so they now about greylisting
And talking about keeping options down to the minimum: "Accepted languages and locales" is not a very effective measure in fighting spam and can be left to the admins willing to look under the hood.
Thanks for listening.
Thanks everyone for the help. It was grey listing that was causing the problem. Once we turned it off, email started coming in as expected. I wanted to give it a week or so of testing to make sure, but it worked!
Also, my thought, I do think that a GUI solution should be present and I like Alex's solution. It is simple and to the point, but still would allow a "nuts and bolts" admin the option to tinker via command line for more advanced options. But better logs are a must have in my book. /my 2¢
when I make the changes in main.cf to disable grey-listing and reload postfix, I get the following errors repeatedly in the mail.log:
Jun 2 12:50:05 mail postfix/smtpd: fatal: parameter "smtpdrecipientrestrictions": specify at least one working instance of: checkrelaydomains, rejectunauthdestination, reject, defer or deferifpermit
What else needs to be done after the changes in pterobyte's solution?