Outgoing mail blocked by spamhaus

Please post the terminal output of postconf -n.
Makes it much easier to help.

This is a common problem if authenticated SMTP messages originate outside your subnet, and the IP block in which the originating address resides has been placed on one or more of the Spamhaus lists. By far the most common reason for block events—in my experience—is the inclusion by Spamhaus of major internet providers on their PBL, or Policy Block List.

Many providers in the US, including Comcast, Qwest and T-Mobile have had net blocks added by to the PBL because Spamhaus believes that these providers do not adequately protect tens of thousands of static IP addresses they control.

This policy is beyond annoying, because…

• only the party controlling the blocked range can seek to remove a record
• finding someone at a provider familiar with the issue and able to act is nearly impossible, and
• Spamhaus is unreachable and entirely uncooperative in any effort to resolve such issues undertaken by an affected third party

This obnoxious behavior had such a deleterious affect on our mobile workforce, that we simply severed our link to Spamhaus. That's regrettable, because they do a great job stopping SPAM traffic. This annoying listing behavior, however, eliminates any possibility that many users can take advantage of their services.

The problem stems from the fact that many private users have infected PCs which act as spambots, thus making this necessary. It would be unfeasible to list/delist dynamic IPs continously.

That said, the problem is easily circumvented by proper postfix configuration. As long as you make sure authentication is checked before the RBL, you will have no problems whatsoever.

I feel a little foolish for asking, but there is a dearth of documentation regarding such configuration steps. Can you provide an example of the necessary code strings to add to or modify in the postfix/master.cf or other applicable file to achieve this circumvention for authenticated clients?

We currently use port 25 with SSL enabled and MD5 Challenge-Response. Thanks for the tip!

If you look at/implement my tutorial Frontline spam defense for Mac OS X Server you will see the correct configuration for checking authentication before the RBLs. In addition you will reduce your spam intake significantly.

If you don't want to add anything to your default configuration, make sure that the following parameters in /etc/postfix/main.cf are in the right horizontal order:

smtpd clientrestrictions = permit_mynetworks, permit saslauthenticated, reject rblclient zen.spamhaus.org, permit

smtpd recipientrestrictions = permit_mynetworks, permit saslauthenticated, reject unauthdestination, reject rblclient zen.spamhaus.org, permit

This will make sure that once authenticated or coming from the internal network, the RBL won't be queried.

-

Furthermore, I would add a separate submission port (587) for your authenticated users only, bypassing the content filter as well. This can be done by adding the following to /etc/postfix/master.cf

submission inet n - n - - smtpd
-o content_filter=
-o smtpd recipient_restrictions=permit_saslauthenticated,reject

(3 spaces before -o )

Thank you so much for that information. I'll be studying the wide range of tutorials on your site, reconfiguring our servers and ultimately taking advantage of the server check option you offer!

Hi there,

Thanks for your valuable input - quick question: Whilst I am "the main administrator" of our machine, I can not rule out that another one or two admins "might" (it should not happen, but it could...) use Server Admin to add users/email addresses - if I follow your guides, and someone does the aforementioned changes through Apple's Server Admin interface, is there a risk something "breaks" completely?

I know it is a vague question, but please see it in the context of my 99.9% certainty that I can make sure I tell them off to touch anything but the "Add user", "Change User Password" and "add email address/alias" 🙂

Once I've got the basics set up, I will definitely consider going for your "test our server" services, sounds like a brilliant idea!

Thanks for all the tutorials, very interesting and useful!
Jonas

Jonas,

user setup is done in WGM and not Server Admin and as such poses no risk.

It is Server Admin that has a tendency to mangle configuration files. Makes sure you have a copy of all configuration files (if you use mailbfr for nightly backups, it will take care of this), just in case you need to revert. Most of the time Server Admin does fine, but it is unpredictable.

HTH,
Alex

Of course, you are absolutely right re Workgroup Manager and not Server Admin for this purpose!

I am not yet using mailfbr yet, is that something you'd get installed first, and then move on your other tutorial? At the risk of beginning to ask questions which are covered by your FAQ, I'll go straight there now! :-))

Best regards,
Jonas

mailbfr is a mail backup and maintenance utility and is available here:
http://osx.topicdesk.com/tools/