Re: smtpd_relay_restrictions in Postfix 2.11.3 on openSUSE 13.2 causes mail to local domain to be rejected

[Sebastian Nielsen]

I would instead suggest setting the relay access to:

check_sender_access hash:/etc/postfix/relay_auth, reject_unauth_destination

where /etc/postfix/relay_auth is:
<YOUR_DOMAIN> permit_mynetworks, reject
[<EXTERNAL_IP_OF_SMTP_SERVER>] permit_mynetworks, reject

This protects agains most malicious relaying:

client inside "mynetworks":




client outside "mynetworks":







Sent: Monday, March 09, 2015 4:54 PM
To: postfix-users@postfix.org


On 3/9/2015 10:46 AM, Earl Killian wrote:

Bot infected computer attempt to relay from "rolexreplicawatc...@rolexwatches.com" to "someinnocentu...@example.org": Mail is rejected, because no "permit_mynetworks" exist in the rules path for any domain not ending in "<YOUR_DOMAIN>" or IP literal of your SMTP. While legit mail (having a FROM ending in your domain) is passed without problems. Someone is trying to send spoofed mail from "postmaster@<YOUR_DOMAIN>" to "some_innocent_user@<YOUR_DOMAIN>". Even tough this mail is local, the spoofing attempt is rejected, because of the bare "reject" word after permit_mynetworks, causing the evaluator to never reach reject_unauth_destination and pass the mail as local mail. However, mail destined to a local mailbox, NOT having a FROM of any of your domains, will pass without problems. I would also suggest not allowing relaying at all (not even after authentication) if your client is outside mynetworks. Even spammers have access to dictionaly lists and password cracking software. Better to be strict and only allow relay from the inside, so dropping permit_sasl_authenticated is a good idea too. If theres no authentication at all, theres no password to probe or crack at all :-) -----Ursprungligt meddelande----- From: Noel Jones Subject: Re: smtpd_relay_restrictions in Postfix 2.11.3 on openSUSE 13.2 causes mail to local domain to be rejected

On 2015/3/9 08:12, Noel Jones wrote:

You have misunderstood the purpose of smtpd_relay_restrictions.
Your mail is rejected by the final "reject" you placed.

*ALL* mail is evaluated by smtpd_relay_restrictions, and unless you
have very unusual relay requirements, you should either set it
empty, or use the suggested safety net:
smtpd_relay_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination



   -- Noel Jones

Thank you for correcting my misunderstanding; I understand it now. I
gather then, since they are both used, that the only purpose of the
new one is to have a default value that protects someone from
leaving things out of smtpd_recipient_restrictions.

You suggested it would very unusual to set it, but it seems like
permit_tls_clientcerts would be one reason. I am thinking of setting
it to
smtpd_relay_restrictions =
        reject_non_fqdn_recipient
        reject_unknown_recipient_domain
        reject_unknown_sender_domain
        permit_mynetworks
        permit_tls_clientcerts
        reject_rbl_client bl.blocklist.de
        permit_sasl_authenticated
        reject_unauth_destination
where the RBL is used to prevent password probing before the
permit_sasl_authenticated. I would then remove those same lines from
smtpd_recipient_restrictions to avoid redundancy. Does this sound
reasonable?

Put only restrictions related to relaying in
smtpd_relay_restrictions.  It is not intended for spam or access
control, only as a relay safety net.

It's certainly OK to add permit_tls_certclients, but the other
restrictions belong elsewhere.

-- Noel Jones

smime.p7s
Description: S/MIME Cryptographic Signature