On 27 Dec 2015, at 13:24, Alex wrote:
Hi,
On Wed, Dec 23, 2015 at 3:34 PM, Bill Cole
<[email protected]> wrote:
On 23 Dec 2015, at 13:53, Alex wrote:
[...]
Okay, I understand. So if the list wasn't also included in
smtpd_sender_restrictions, would it have been rejected there, due to
the reject_unknown_sender_domain at the end?
Yes.
How can I get around the duplication?
If you don't duplicate rejection rules then you don't need to
duplicate map
rules to exempt special cases from them.
One of the reasons I separated
the restrictions was to avoid the problem of too permissive access.
I can see why: if your check_sender_access whitelist is in
smtpd_recipient_restrictions, it whitelists against every rule
following it
in smtpd_recipient_restrictions, based on an arbitrarily forgeable
sender
domain. Using a magically bogus sender domain would become a free
relay
pass.
Should I just expect to duplicate the check_*_access using the same
lists to solve this?
No. You only need to duplicate whitelisting if you duplicate
rejection, and
there is a risk of opening loopholes if you put whitelisting maps for
client/helo/sender rejections into smtpd_recipient_restrictions. So:
remove
reject_unknown_sender_domain from smtpd_recipient_restrictions, leave
smtpd_sender_restrictions intact as-is.
General rule: If you want to use a reject_* rule but also need a
whitelist
exempting special cases from that rule, put the rejection rule
immediately
after its whitelist map in the earliest legal rejection list for that
rejection rule, as far down as possible.
It's taken me a few days to process what you've written, but I think
I'm now on the right track. Just to be sure I understand, I'd like to
list my smtpd_*_restrictions and ask if someone could review them.
I have a list of domain names and IPs that I need to ensure are not
rejected. Given the restrictions below, if I add the IPs to a
check_client_access map in smtpd_client_restrictions, and the
hosts/domains to a check_sender_access map in
smtpd_sender_restrictions, can I expect them to bypass any further
checks?
No.
You cannot bypass restrictions in smtpd_recipient_restrictions by
permitting a client hostname or IP in a smtpd_client_restrictions rule
or by permitting a sender address or domain in
smtpd_sender_restrictions.
You cannot bypass restrictions in smtpd_sender_restrictions by
permitting a client hostname or IP in a smtpd_client_restrictions
The 7 Postfix restriction lists that apply to normal message transport
are run in this order:
At RCPT: (unless smtpd_delay_reject is set to "no")
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_relay_restrictions (Postfix 2.10 and later)
smtpd_recipient_restrictions
At DATA:
smtpd_data_restrictions
At End-of-DATA:
smtpd_end_of_data_restrictions
REJECT and DEFER results from any restriction in a list cause Postfix to
skip all later restrictions in that restriction list AND all later
restriction lists.
PERMIT or OK results only cause Postfix to skip restrictions that occur
later in the same restriction list.
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
permit
No "OK" results from your other restriction lists affect how the
reject_* rules in this list operate. Specifically, the only exemption
from "reject_unknown_sender_domain" at RCPT time will be
"permit_mynetworks"
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/postfix/client_checks,
check_reverse_client_hostname_access
pcre:/etc/postfix/fqrdns-042715a.pcre,
check_reverse_client_hostname_access
pcre:/etc/postfix/reverse_client_hostname_access.pcre,
check_client_access cidr:/etc/postfix/client_access_blocklist
smtpd_sender_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/sender_checks,
check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf
In my current client_checks file, I have entries such as the following
to control connections from the mail servers:
66.224.87.178 OK
172.16 554 Bugger off!
ymlpsrvr.com 554 Spammer
That "OK" result applies to a client connecting from 66.224.87.178 ONLY
in the context of smtpd_client_restrictions. The later restriction lists
(in your case, just smtpd_sender_restrictions and
smtpd_recipient_restrictions) don't see that result.
In my current sender_checks file, I have entries such as the following
to control MAIL FROM:
example.tld 554 Spam not tolerated here
63.87.29.0/25 OK
[email protected] OK
I just wanted to make sure this was the proper way to do this.
No, it is not. sender_checks only applies to the sender address, i.e.
the argument given in the SMTP MAIL FROM command. Unless you really want
to accept mail from "[email protected]/25" and other addresses in
the invalid domain "63.87.29.0/25" this cannot be correct. Also, it
doesn't exempt [email protected] from anything other than your
blacklist_ns.cf map.
Is it
possible to append text after the "OK" the way it's okay to do it with
the 554? If not, is there another way to do this? I didn't see a way
in the access(5) man page.
No. How would want Postfix to use such text?
The text after a "554" action (or other non-OK action) in a Postfix
access map is used in the SMTP reply to the client which constitutes the
message rejection. That reply ultimately should be sent back to the
original sender in some form of DSN so the optional text can be an
explanation of the rejection. Since any "OK" is provisional until the
end of DATA and it is relatively rare to generate DSNs for successful
message transport, it isn't clear what such text would be for. The text
Postfix sends in the end-of-DATA "250" reply is as useful, informative,
and non-committal as an MTA should be.
