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.

1 Answer 1

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.

14
  • 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, 2014 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, 2014 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, 2014 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, 2014 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, 2014 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .