Is Mavericks Server swallowing Mail? I fear, YES

Other people will have more technical detail to offer, I expect, but my experience may help.

Greylisting - I have seen anumber of concerns about Server greylisting, and frequent recommendations to turn it off. I have it on and, although I'm not aware of having permanently lost any significant mail, I have seen quite long delays (more than a day) in receiving mail from 'new' senders. I surmise (but this needs testing) that Server greylisting in your new setup started be seeing *all* senders as 'new', which would generate a high percentage of delayed inbound mail. It may be that some sending servers stop retrying before Server finally permits receipt.

I switched to Server from MDaemon on Windows, and found greylisting to be much more 'aggressive' on Server

Anti-spam - I'd suggest lowering the aggressiveness of the filter - I would recommend setting it off completely to start with (that would enable you to separate filter issues from greylisting issues), then increasing it one notch at a time to get to a satisfactory balance.

Hope that helps

Read the logs. Check the Postfix settings. See what's going on within your mail server.

Also confirm that your public DNS is correct — that is, fetch your MX record and confirm that the name to address translation works, and that the address then returns the domain name (the mail server host name) you started with. (Related reading)

Other mechanisms simply deny access to sites that have bogus DNS settings — this is the other side of the public DNS tests mentioned above. Using these settings and using RBLs can reduce the volume of spam.

Greylisting avoids spam because a substantial part of the spam around isn't sent from mail servers, it's sent from spam engines. The typical spam engines don't retry — they just blast messages, and move on when the message isn't delivered. Mail servers do retry. If you don't retry the send, you don't get through the greylisting.

Greylisting does not have an aggressiveness selecting. It's a rejection. SMTP 450. Not now I'm busy. It's then all up to the remote mail server to retry the message later. That might happen within minutes or hours, or the remote mail server might (rarely) be configured to drop the message — different mail providers have different settings.

Greylisting also offers explicit mail server whitelisting features, which can be helpful around Google GMail and related services that are operating with a gazillion mail servers — particularly if there's some form of failover or clustering in play, and the inbound mail messages aren't all sent from the same originating mail server. Until your greylisting software "learns" the pool of servers, some messages will be slow to arrive.

If you want the folks here to check your Postfix settings and/or your external DNS settings, post the output from:

postconf -n -c /Library/Server/Mail/Config/postfix

FWIW, given that it now takes around three minutes to scan the whole of the active IPv4 address space from one box (with a big enough network pipe), and given that the spammers can scan even faster than that given how many hosts the average botnet has, and given the spammers are already looking for DNS MX records and related, you're not going to be disclosing anything that the spammers don't already know about and aren't already testing.

Now there can be personal preferences and various other reasons to obfuscate a domain — so if you do choose to post the output and do obfuscate, please do perform the obfuscation consistently.

There's nothing in that postconf that would block traffic, so — beyond checking the logs and preferably beyond moving to a static IP address — there don't seem to be any particular issues here.

ruggiero wrote:

Thanks for the tips. Nothing has changed DNS wise during the last couple years. It is just the NAT that is internally pointing to a different IP.

That will effect DNS. Did you then verify internal DNS is still correct? Harmless diagnostic command to do that:

sudo changeip -checkhostname

The public DNS for this server is misconfigured, and — if you were not already using that mail relay, and were sending email directly — this server will be seen as a spam engine by various other mail servers, and messages arriving from this server will be dropped by a number of those receiving servers:

$ dig +short MX rucotec.ch

10 rucotec.ch.

$ dig +short rucotec.ch

213.189.151.242

$ dig +short -x 213.189.151.242

ip-213-189-151-243.fix.magnet.ch.

$

Were you not using a relay via your ISP, that last translation would be the host name rucotec.ch, and your current configuration would be indistinguishable from a spam engine by other mail servers. Some mail servers will not send messages to a configuration such as this; I've used a few that detect and drop such messages without sending them. If you already have or can get static IP from your ISP (as implied by that fix in the domain), then check with your ISP for that address-to-name translation. That'll entirely avoid the need for the mail relay.

You're fairly wide open in terms of what mail you'll accept with the following, too — yes, you do have greylisting running (that's the policy entry shown below), but that'll just defer the messages while also greatly reducing the spam:

smtpd_helo_restrictions = reject_non_fqdn_helo_hostname reject_invalid_helo_hostname

smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/policy permit

As for your concerns around the command line usage and entirely unfortunately with OS X Server, there's not all that much documentation of or guidance around what's stable and what's not and what's allowed at the command line and what's not — muy frustrante — though I've empirically found that direct changes to Postfix via postconf -e -c /Library/Server/Mail/Config/postfix "value = settings" commands do (currently) stick.