meant this:
outside mynetworks, known sender, known recipient (did fail as it should)
outside mynetworks, unknown sender, known recipient (did success as it
should)
outside mynetworks, known sender, unknown recipient (did fail as it should)
(successing this would make the server open relay)
outside mynetworks, unknown sender, unknown recipient (did fail as it
should) (successing this would make the server open relay)
inside mynetworks, known sender, known recipient (did success as it should)
inside mynetworks, unknown sender, known recipient (did success as it
should)
inside mynetworks, known sender, unknown recipient (did success as it
should)
inside mynetworks, unknown sender, unknown recipient (did fail as it should)
The reason I wanted this policy from the beginning, is that is makes it
harder for bots and zombies inside network, to send mail through the server.
Only way would be for a bot to actually use a valid sender adress belongning
to the server when relaying, the bot cannot spoof the sender, making the
email easly traced
and actions being taked (computers inside network being cleaned).
-----Ursprungligt meddelande-----
From: Viktor Dukhovni
Sent: Wednesday, May 07, 2014 8:51 PM
To: [email protected]
Subject: Re: Configure postfix to reject forged mail?
On Wed, May 07, 2014 at 08:33:18PM +0200, Sebastian Nielsen wrote:
I know. "check_sender_access" does always check MAIL_FROM, regardless of
in
which access context they are in. (else it would be check_recipient_access
or check_client_access)
When using "check_sender_access" use a separate lookup table whose
keys are sender addresses/domains, DO NOT use a single generic file
called "access" for everything. This just leads to trouble.
But a sender access policy cannot contain a recipient policy (like
reject_unauth_destination) because MAIL_FROM comes before RCPT_TO (unless
smtpd_delay_reject is set to yes)
You SHOULD have smtpd_delay_reject set to "yes".
Did test the policy carefully both using a external tool (that queries the
server externally) and internally, and all test cases did pass thorugh
with
the result I wanted.
Sure, it works now, but it is fragile, and will land you or your
successor in trouble some day.
This tool is GREAT to test complex relay restrictions:
http://smtper.nanogenesis.fr/
Tests only report things that are already broken. Only
design reviews report things that are fragile.
Of course, I will never put anything else than something I want to relay,
in
the "access" file, eg only "permit_mynetworks" and such.
Some day you will forget, or someone else won't know the constraints.
--
Viktor.
