3

I'm looking for a bit of advice on Postfix restrictions configuration. I'm looking for a balanced configuration which properly rejects spam and unauthorized access retries.

Lately, I've been reading some docs and trying to learn from other's experience, but I'm a bit confused when restrictions come about. Right now I'm being forced to set permit_sasl_authenticated as first restriction so authenticated users does not match against spam blocking lists while sending email from their desktop email client application. If I remove such restriction then people send email through desktop email client applications such as MS Outlook and which are connected to the net through ADSL or behind a dynamic IPs, usually is detected as spam.

I'm wondering if I have missed anything as when reading others configuration, tutorials and docs they look like not suffering from that issue. I feel like I'm the only one.

I'm also wondering if I'm checking against the right spam lists at each restriction statement.

mynetworks_style = host

smtpd_client_restrictions = 
permit_sasl_authenticated,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl
,reject_rbl_client zen.spamhaus.org
,reject_rbl_client bl.spamcop.net
,check_client_access regexp:/etc/postfix/client_restrictions

smtpd_data_restrictions = reject_unauth_pipelining

smtpd_end_of_data_restrictions =
smtpd_etrn_restrictions =

smtpd_helo_restrictions = 
permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,
permit_sasl_authenticated,
warn_if_reject reject_non_fqdn_hostname,
reject_invalid_hostname,
permit

smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_unauth_pipelining,
permit_mynetworks,
reject_non_fqdn_recipient,
warn_if_reject reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
warn_if_reject reject_unknown_helo_hostname,
check_policy_service inet:127.0.0.1:10023,
check_policy_service unix:private/policy-spf,
permit

smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
defer_unauth_destination

smtpd_restriction_classes =

smtpd_sender_restrictions = 
permit_sasl_authenticated, 
permit_mynetworks, 
warn_if_reject reject_non_fqdn_sender, 
reject_unknown_sender_domain, 
reject_unauth_pipelining, 
permit

One issue I faced was bl.sorbs.net detecting some Microsoft IPs as spam.

Any kind of tips and advice are welcome.

Gryu
  • 479
  • 1
  • 6
  • 14
peris
  • 488
  • 2
  • 9
  • 25

1 Answers1

2

Putting permit_sasl_authenticated users first or second is almost always the correct way of limiting who can relay through your server. Having a suitable mynetworks setting is also advisable, for those systems where doing proper authenticated smtp may not be simple or realistic. Usually this will be to allow your webserver to relay through your mailserver, and other similar situations. You could also look at placing your restrictions in smtpd_recipient_restrictions and just using smtpd_helo_restrictions to reject invalid hostnames, while also removing smtpd_client restrictions except maybe for your check_client_access regex table.

There's definitely no point in repeating the same restrictions in multiple smtpd_* stanzas. All of those options are part of the inital SMTP conversation, just different parts (client is the connection, HELO is the greeting, sender is the mail FROM:, relay and recipient are the RCPT TO:, data is the message, end of data is the end of the message) repeating them again afterwards is a waste of cycles.

As for Blacklists, you have 2 choices, first is to do as you are doing now, and let postfix decide to accept or reject messages based on BL replies, possibly removing ones which cause too many false positives. Second, you can set up something like greylisting, will will reject a lot of fire and forget bots (many don't retry), and let spamassassin make decisions as to whether the mail that does get through is spam or not (these rules can include blacklists). The nice thing about spamassassin is that you can tune it, and mail won't be rejected outright. It does take time and attention however. It also means your server will be working harder.

NickW
  • 10,183
  • 1
  • 18
  • 26
  • Ok thx so much. I'm already using Postgrey and amavis +spamassassin + clamav As your advising i'm going to review my rules to not repeat themself. – peris Mar 20 '14 at 12:03
  • There's also a third option, you can use a small subset of BLs with postfix, say the reliable ones, then allow spamassassin to do the deeper inspection. – NickW Mar 20 '14 at 12:07
  • Thx, do you have any advise on any RBL i should/could remove? Also today i noticed my Postfix implementation rejected an incoming email due to Spamcop blacklist while it shouldn't so i thought maybe could be a good idea to check multiple blacklist at once an then decide to reject or pass the email depending on how many positive were found. Do you know if that's a good practice? I haven't found information about that topic on the net? Also some hints on its implementation would be welcome. – peris Mar 20 '14 at 12:20
  • I would remove that blacklist from your postfix restrictions, you can balance blacklists with spamassassin, by dropping the assigned score to a level where being on a blacklist alone is not enough to make a message spam. – NickW Mar 20 '14 at 12:25
  • So if i understand, i can remove one or more blacklists from Postfix restrictions and then tell spamassassin to check against those blacklists so each positive can have a score and tell spamassassin to only reject emails above that score, right? Do you know where can i find some info about such behaviour? thx – peris Mar 20 '14 at 12:38
  • Yeah, many blacklist providers have instructions on how to do that: http://www.uribl.com/usage.shtml and of course, there is spamassassin documentation: http://wiki.apache.org/spamassassin/DnsBlocklists – NickW Mar 20 '14 at 12:43
  • Thank you so much, i really appreciate your advising. Just a last question, which restrictions do you use to remove blacklist from in order to let spamassassin manage it all? – peris Mar 20 '14 at 13:05
  • Just remove the line `reject_rbl_client ` – NickW Mar 20 '14 at 14:18
  • Well, i was really asking for your advice based on your experience. – peris Mar 20 '14 at 14:27
  • I actually tended to keep an eye on my logs, and also listened to my clients, and you can also get information from other admins about what they found to be too restrictive – NickW Mar 20 '14 at 14:46
  • Just to add my experience; I add spamhaus and spamcop to the Postfix configuration and that eliminates 90% of spam right away without further processing, if you add greylisting that should get you rid of basically 100% of spam. Spamassassin is a CPU hog and gives the spam message to the user to deal with, I used to use it but I don't anymore, not worth the headache in most cases imho. – LinuxDevOps Mar 20 '14 at 15:30
  • Spamassassin gives the message to your LDA to deal with, what your LDA does is decided by the admin (or local sieve/procmail rules), some people like the ability to look through their SPAM box, as sometimes blacklists can be aggressive (and overreaching). – NickW Mar 20 '14 at 15:33
  • Thank you both so much. What i would like right now is to be able to check positives against multiple blacklists before rejecting the email. I think that's the only thing i need to avoid issues like the one today. – peris Mar 20 '14 at 17:22
  • Alright then, best of luck with the monitoring. – NickW Mar 20 '14 at 17:27