Re: check_sender_access and pattern matching
On 12/21/2015 11:38 AM, Alex wrote: > Hi, > I have a postfix-2.10 fedora22 system and having trouble with my > sender checks. I have a domain that is sending mail with an invalid > hostname. The temporary solution is to add a check_sender_access > entry, but I must be doing something wrong. > > Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from > mailout.example.com[64.123.123.200]: 450 4.1.8 > : Sender address rejected: Domain not found; > from= to= > proto=ESMTP helo= > First, sending mail with an invalid envelope sender is a very bad idea. Much better to either fix the domain name or fix the sender. > I had previously had the following: > > *@invalid.example.com OK For hash: access tables, the correct line is (assuming the default value of parent_domain_matches_subdomains): invalid.example.com OK See the access table documentation, pattern search order section for details. http://www.postfix.org/access.5.html -- Noel Jones
Re: check_sender_access and pattern matching
Hi, On Mon, Dec 21, 2015 at 12:48 PM, Noel Jones wrote: > On 12/21/2015 11:38 AM, Alex wrote: >> Hi, >> I have a postfix-2.10 fedora22 system and having trouble with my >> sender checks. I have a domain that is sending mail with an invalid >> hostname. The temporary solution is to add a check_sender_access >> entry, but I must be doing something wrong. >> >> Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from >> mailout.example.com[64.123.123.200]: 450 4.1.8 >> : Sender address rejected: Domain not found; >> from= to= >> proto=ESMTP helo= >> > > First, sending mail with an invalid envelope sender is a very bad idea. > > Much better to either fix the domain name or fix the sender. Yes, absolutely. Understood. I've reiterated that to them. >> I had previously had the following: >> >> *@invalid.example.com OK > > For hash: access tables, the correct line is (assuming the default > value of parent_domain_matches_subdomains): > > invalid.example.com OK > > See the access table documentation, pattern search order section for > details. > http://www.postfix.org/access.5.html I've been confused by that man page in the past, but I'm not sure that's the problem here. I actually had that in the file already, and it just stopped working about a week ago. I just added the sender_access file to smtpd_recipient_access and now it's working: smtpd_recipient_restrictions = reject_non_fqdn_recipient, check_sender_access hash:/etc/postfix/sender_checks, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_unknown_sender_domain, I can't imagine that's the right way to do it, but don't understand why recipient_restrictions is consulted and generally why it's now working with the same pattern. Thanks, Alex
Re: check_sender_access and pattern matching
On 12/21/2015 12:13 PM, Alex wrote: >> For hash: access tables, the correct line is (assuming the default >> value of parent_domain_matches_subdomains): >> >> invalid.example.com OK >> >> See the access table documentation, pattern search order section for >> details. >> http://www.postfix.org/access.5.html > > I've been confused by that man page in the past, but I'm not sure > that's the problem here. I actually had that in the file already, and > it just stopped working about a week ago. I just added the > sender_access file to smtpd_recipient_access and now it's working: > > smtpd_recipient_restrictions = > reject_non_fqdn_recipient, > check_sender_access hash:/etc/postfix/sender_checks, > reject_non_fqdn_sender, > reject_unlisted_recipient, > reject_unknown_recipient_domain, > permit_mynetworks, > reject_unauth_destination, > reject_unknown_sender_domain, > > I can't imagine that's the right way to do it, but don't understand > why recipient_restrictions is consulted and generally why it's now > working with the same pattern. > > Thanks, > Alex > It's perfectly valid to do sender checks in smtpd_recipient_restrictions. Many people put all their restrictions in smtpd_recipient_restrictions to make whitelisting easier and to have all the rules in one place. http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions see the part near the bottom about "other restrictions valid in this context". Is this client listed in $mynetworks? If so, that's why it didn't work before, and works now. -- Noel Jones
Re: check_sender_access and pattern matching
Hi, On Mon, Dec 21, 2015 at 2:18 PM, Noel Jones wrote: > On 12/21/2015 12:13 PM, Alex wrote: >>> For hash: access tables, the correct line is (assuming the default >>> value of parent_domain_matches_subdomains): >>> >>> invalid.example.com OK >>> >>> See the access table documentation, pattern search order section for >>> details. >>> http://www.postfix.org/access.5.html >> >> I've been confused by that man page in the past, but I'm not sure >> that's the problem here. I actually had that in the file already, and >> it just stopped working about a week ago. I just added the >> sender_access file to smtpd_recipient_access and now it's working: >> >> smtpd_recipient_restrictions = >> reject_non_fqdn_recipient, >> check_sender_access hash:/etc/postfix/sender_checks, >> reject_non_fqdn_sender, >> reject_unlisted_recipient, >> reject_unknown_recipient_domain, >> permit_mynetworks, >> reject_unauth_destination, >> reject_unknown_sender_domain, >> >> I can't imagine that's the right way to do it, but don't understand >> why recipient_restrictions is consulted and generally why it's now >> working with the same pattern. >> >> Thanks, >> Alex >> > > > It's perfectly valid to do sender checks in > smtpd_recipient_restrictions. Many people put all their > restrictions in smtpd_recipient_restrictions to make whitelisting > easier and to have all the rules in one place. > http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions > see the part near the bottom about "other restrictions valid in this > context". I initially had all the restrictions in smtpd_recipient_restrictions, but thought it made it more clear to separate them, and was also following someone's guidelines from this list. I thought it would be easier just for the way my thought process worked, but it sounds like there's much more overlap between restrictions than I thought. I don't think I realized that sender and helo restrictions could also be included with recipient restrictions. I still don't understand why the sender exclusion wasn't processed when it was listed in the smtpd_sender_restrictions, however. > Is this client listed in $mynetworks? If so, that's why it didn't > work before, and works now. No, it's not in $mynetworks. Besides, isn't it reject_non_fqdn_sender which blocked it, and comes before permit_mynetworks?
Re: check_sender_access and pattern matching
On 21 Dec 2015, at 12:38, Alex wrote: Perhaps the ordering of restrictions is not correct? 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_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 smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_checks, check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf reject_unknown_sender_domain It does not matter what order the various lists of restrictions have in main.cf, they are always evaluated in the same order: http://www.postfix.org/SMTPD_ACCESS_README.html#timing Each restriction list is evaluated independently but a REJECT or DEFER result from any list causes later lists to be skipped. Note that http://www.postfix.org/SMTPD_ACCESS_README.html#lists does not say OK/PERMIT from one list is carried forward to whitelist against restrictions in later lists *because it is not.* Individual restriction rules inside a list are evaluated in order, so the above applies your check_sender_access whitelist inside smtpd_sender_restrictions, protecting it from the reject_unknown_sender_domain in that list. This allows the message to proceed and be evaluated by the smtpd_recipient_restrictions list, which has its own reject_unknown_sender_domain. You can tell that this is what rejected your message by noting the log entry wording: Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from mailout.example.com[64.123.123.200]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= Strictly speaking, the domain is not "invalid" (containing characters not allowed in hostnames or otherwise technically malformed) but simply "unknown" (not found in DNS). Presumably it has a dot in it so it's nominally fully-qualified.
Re: check_sender_access and pattern matching
Hi, On Wed, Dec 23, 2015 at 12:53 PM, Bill Cole wrote: > On 21 Dec 2015, at 12:38, Alex wrote: > >> Perhaps the ordering of restrictions is not correct? >> >> 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_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 >> >> smtpd_sender_restrictions = permit_mynetworks, >> check_sender_access hash:/etc/postfix/sender_checks, >> check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf >> reject_unknown_sender_domain > > > It does not matter what order the various lists of restrictions have in > main.cf, they are always evaluated in the same order: > http://www.postfix.org/SMTPD_ACCESS_README.html#timing > > Each restriction list is evaluated independently but a REJECT or DEFER > result from any list causes later lists to be skipped. Note that > http://www.postfix.org/SMTPD_ACCESS_README.html#lists does not say OK/PERMIT > from one list is carried forward to whitelist against restrictions in later > lists *because it is not.* > > Individual restriction rules inside a list are evaluated in order, so the > above applies your check_sender_access whitelist inside > smtpd_sender_restrictions, protecting it from the > reject_unknown_sender_domain in that list. This allows the message to > proceed and be evaluated by the smtpd_recipient_restrictions list, which has > its own reject_unknown_sender_domain. You can tell that this is what > rejected your message by noting the log entry wording: > >> Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from >> mailout.example.com[64.123.123.200]: 450 4.1.8 >> : Sender address rejected: Domain not found; >> from= to= >> proto=ESMTP helo= 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? How can I get around the duplication? One of the reasons I separated the restrictions was to avoid the problem of too permissive access. Should I just expect to duplicate the check_*_access using the same lists to solve this? If it would be best to combine the restrictions, can you suggest how I might do that? Thanks again, Alex
Re: check_sender_access and pattern matching
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. If it would be best to combine the restrictions, can you suggest how I might do that? Don't try to use a single unified restriction list in smtpd_recipient_restrictions if you use maps based on client, helo, or sender values to exempt specific violators only from reject_* rules that apply to the same values. You need to be very careful about using any maps that act as whitelists in smtpd_recipient_restrictions; you can order rules there to get complexity that can't be set up elsewhere, but it is risky.
Re: check_sender_access and pattern matching
Hi, On Wed, Dec 23, 2015 at 3:34 PM, Bill Cole 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? 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 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.com554 Spammer 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 someu...@example3.tld OK I just wanted to make sure this was the proper way to do this. 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. Thanks so much. Alex
Re: check_sender_access and pattern matching
On 27 Dec 2015, at 13:24, Alex wrote: Hi, On Wed, Dec 23, 2015 at 3:34 PM, Bill Cole 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.com554 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 lis
Re: check_sender_access and pattern matching
Hi, >> 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" Okay, that's more clear. I think I understood that, but not sure why I didn't apply it also to smtpd_recipient_restrictions. Since there aren't really any restrictions in smtpd_sender_restrictions other than a bad NS, I now believe it's not necessary to have any check_sender_access maps there to OK a sender, correct? As I mentioned, I'm trying to make sure that the IPs of a handful of mail servers, and a handful of domains which they host, are not rejected. I don't believe any of them will have a problem with DNS, but it's possible some could be blacklisted on an RBL. Now it sounds like I should add a check_client_access and check_sender_access map to my smtpd_recipient_restrictions after permit_mynetworks: smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unknown_recipient_domain, reject_unauth_destination, reject_unknown_sender_domain, permit_mynetworks, check_client_access hash:/etc/postfix/client_checks, check_sender_access hash:/etc/postfix/sender_checks, 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 I've also reordered reject_unauth_destination and reject_unknown_sender_domain to above permit_mynetworks, as no one should be routing mail to unauthorized destinations or domains. >> 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 I should have been more clear. I was hoping to somehow log an entry each time one of those IPs is received, in a similar way as the INFO or PREPEND directive can be used so w
Re: check_sender_access and pattern matching
On 27 Dec 2015, at 20:22, Alex wrote: [...] 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" Okay, that's more clear. I think I understood that, but not sure why I didn't apply it also to smtpd_recipient_restrictions. I'm unclear on what you're referring too as "it"... Let me try again. As I understand your problem, there is mail which you must accept that uses a sender domain name which does not resolve. However, you generally want to use reject_unknown_sender_domain, which is a good thing. The ideal way to address that problem is a check_sender_access map with your exception in the smtpd_sender_restrictions list, before reject_unknown_sender_domain ALSO in the smtpd_sender_restrictions list. You currently have reject_unknown_sender_domain in smtpd_recipient_restrictions, so the bogus-domain mail is being rejected. If you were to put your permissive check_sender_access map in the smtpd_recipient_restrictions list before reject_unknown_sender_domain, all of the exceptions in the map would bypass all restrictions following it in smtpd_recipient_restrictions. Because a sender address is trivial to forge, that would open up a relay and/or local delivery hole as described in http://www.postfix.org/SMTPD_ACCESS_README.html Since there aren't really any restrictions in smtpd_sender_restrictions other than a bad NS, I now believe it's not necessary to have any check_sender_access maps there to OK a sender, correct? Correct as stated. HOWEVER, if you have sender-based blanket restrictions like reject_unknown_sender_domain in smtpd_recipient_restrictions and need to make exceptions to them, ordering of rules in smtpd_recipient_restrictions becomes tricky if you want to avoid the exceptions turning into an obscure way to get around what should be unrelated restrictions. Sender addresses can be set to anything by anyone from anywhere, so using them as a basis to get past any restriction other than ones purely about sender addresses is unsafe. As I mentioned, I'm trying to make sure that the IPs of a handful of mail servers, and a handful of domains which they host, are not rejected. I don't believe any of them will have a problem with DNS, That belief seems to be in error. Your first message in this thread quoted a munged log line that showed a failure due to a domain not being in DNS. but it's possible some could be blacklisted on an RBL. The easiest fix for that is to add the trusted IPs to mynetworks. If you trust those mail servers to send you mail with a bogus sender domain, you trust those mail servers entirely. Now it sounds like I should add a check_client_access and check_sender_access map to my smtpd_recipient_restrictions after permit_mynetworks: smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unknown_recipient_domain, reject_unauth_destination, reject_unknown_sender_domain, permit_mynetworks, check_client_access hash:/etc/postfix/client_checks, check_sender_access hash:/etc/postfix/sender_checks, 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 I've also reordered reject_unauth_destination and reject_unknown_sender_domain to above permit_mynetworks, as no one should be routing mail to unauthorized destinations or domains. This is a bit exasperating Do you not see reject_unknown_sender_domain in that list? Are you refusing to accept that "Sender address rejected: Domain not found" in your log meant what it said? This is the 3rd (& last) message where I've pointed at reject_unknown_sender_domain in smtpd_sender_restrictions being key to your originally described problem. Putting reject_unknown_sender_domain in smtpd_sender_restrictions is more absolute
Re: check_sender_access and pattern matching
Hi, > As I understand your problem, there is mail which you must accept that uses > a sender domain name which does not resolve. However, you generally want to > use reject_unknown_sender_domain, which is a good thing. > > The ideal way to address that problem is a check_sender_access map with your > exception in the smtpd_sender_restrictions list, before > reject_unknown_sender_domain ALSO in the smtpd_sender_restrictions list. Okay, I've adjusted my smtpd_sender_restrictions to the following: smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf, check_sender_access hash:/etc/postfix/sender_checks, reject_unknown_sender_domain > You currently have reject_unknown_sender_domain in > smtpd_recipient_restrictions, so the bogus-domain mail is being rejected. If > you were to put your permissive check_sender_access map in the > smtpd_recipient_restrictions list before reject_unknown_sender_domain, all > of the exceptions in the map would bypass all restrictions following it in > smtpd_recipient_restrictions. Because a sender address is trivial to forge, > that would open up a relay and/or local delivery hole as described in > http://www.postfix.org/SMTPD_ACCESS_README.html I don't know how I missed that previously. I'm not new to postfix, but perhaps I was a bit confused. >> Now it sounds like I should add a check_client_access and >> check_sender_access map to my smtpd_recipient_restrictions after >> permit_mynetworks: >> >> smtpd_recipient_restrictions = >> reject_non_fqdn_recipient, >> reject_non_fqdn_sender, >> reject_unlisted_recipient, >> reject_unknown_recipient_domain, >> reject_unauth_destination, >> reject_unknown_sender_domain, >> permit_mynetworks, >> check_client_access hash:/etc/postfix/client_checks, >> check_sender_access hash:/etc/postfix/sender_checks, >> 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 >> >> I've also reordered reject_unauth_destination and >> reject_unknown_sender_domain to above permit_mynetworks, as no one >> should be routing mail to unauthorized destinations or domains. > > This is a bit exasperating > > Do you not see reject_unknown_sender_domain in that list? Are you refusing > to accept that "Sender address rejected: Domain not found" in your log meant > what it said? This is the 3rd (& last) message where I've pointed at > reject_unknown_sender_domain in smtpd_sender_restrictions being key to your > originally described problem. Yes, I sincerely appreciate your patience with me as I try to learn how to do this. I got confused with placement, but certainly understand that reject_unknown_sender_domain in smtpd_recipient_restrictions would have rejected my unknown domains. > Putting reject_unknown_sender_domain in smtpd_sender_restrictions is more > absolutely effective than burying it 1/3 of the way into > smtpd_recipient_restrictions, with the added benefit that you can put your > exceptions to reject_unknown_sender_domain in a check_sender_access map > right before it in smtpd_sender_restrictions and have no concern about your > special snowflake sender domains becoming a free pass for spammers to hit > local users or to relay through you. Hopefully the smtpd_sender_restrictions I posted above is correct, but I will also have to either add the IPs to mynetworks or duplicate the check_sender_access map in smtpd_recipient_restrictions to avoid being rejected in the RBLs there, correct? smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unknown_recipient_domain, permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_destination, 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, Thanks again, Alex
Re: check_sender_access and pattern matching
On 27 Dec 2015, at 22:48, Alex wrote: Hopefully the smtpd_sender_restrictions I posted above is correct, but I will also have to either add the IPs to mynetworks or duplicate the check_sender_access map in smtpd_recipient_restrictions to avoid being rejected in the RBLs there, correct? If you are not willing to put the IPs in mynetworks, I would still urge you to NOT use check_sender_access to whitelist sources that you can identify purely by IP or reliably resolvable domain name (i.e. "client" identities). It's trivial to forge a sender address and you should avoid extending trust based on such a weak identification. On the other hand, it is a complex trick to hijack an IP address for a TCP-based protocol like SMTP or hijack/spoof DNS for a client hostname that Postfix would deem valid. So a check_client_access map dedicated solely to protecting those servers from DNSBLs would be a better choice in smtpd_recipient_restrictions. smtpd_recipient_restrictions = [...] check_sender_access hash:/etc/postfix/sender_access, reject_unauth_destination, In any case, those two should never be in that order if the check_sender_access map has any OK actions.
Re: check_sender_access and pattern matching
Hi, On Mon, Dec 28, 2015 at 12:17 AM, Bill Cole wrote: > On 27 Dec 2015, at 22:48, Alex wrote: > >> Hopefully the smtpd_sender_restrictions I posted above is correct, but >> I will also have to either add the IPs to mynetworks or duplicate the >> check_sender_access map in smtpd_recipient_restrictions to avoid being >> rejected in the RBLs there, correct? > > If you are not willing to put the IPs in mynetworks, I would still urge you > to NOT use check_sender_access to whitelist sources that you can identify > purely by IP or reliably resolvable domain name (i.e. "client" identities). > It's trivial to forge a sender address and you should avoid extending trust > based on such a weak identification. On the other hand, it is a complex > trick to hijack an IP address for a TCP-based protocol like SMTP or > hijack/spoof DNS for a client hostname that Postfix would deem valid. So a > check_client_access map dedicated solely to protecting those servers from > DNSBLs would be a better choice in smtpd_recipient_restrictions. I didn't previously explain that there is one host that I know for sure doesn't resolve. It wasn't so much that I didn't want to add the IPs to mynetworks. I also really wanted to learn how it sender maps worked. I thought of the mynetworks solution as an "all access pass", but now I understand why it's more secure than the sender maps. >> smtpd_recipient_restrictions = > > [...] >> >> check_sender_access hash:/etc/postfix/sender_access, >> reject_unauth_destination, > > In any case, those two should never be in that order if the > check_sender_access map has any OK actions. Thanks so much for your help. Alex
Re: check_sender_access and pattern matching
Hi, I hoped I could ask another question. Below is my smtpd_recipient_restrictions as we were discussing earlier this week: On Sun, Dec 27, 2015 at 9:37 PM, Bill Cole wrote: > On 27 Dec 2015, at 20:22, Alex wrote: > [...] > 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 The docs say reject_unlisted_recipient rejects mail when the recipient is not listed in the list of valid recipients for its domain class. I assume this means an IP listed in mynetworks or an entry from the check_recipient_access list? The part I don't understand is, the reject_unlisted_recipient is before the users/IPs are listed. How does it know which users/IPs are permissible when it comes so far up in the processing list? Thanks, Alex
Re: check_sender_access and pattern matching
On 12/30/2015 7:45 PM, Alex wrote: > > The docs say reject_unlisted_recipient rejects mail when the recipient > is not listed in the list of valid recipients for its domain class. I > assume this means an IP listed in mynetworks or an entry from the > check_recipient_access list? > > The part I don't understand is, the reject_unlisted_recipient is > before the users/IPs are listed. How does it know which users/IPs are > permissible when it comes so far up in the processing list? reject_unlisted_recipient is not related to the sender or client IP. When you specify reject_unlisted_recipient, postfix checks to see if postfix controls that domain, and if it does, if the recipient address exists. Nonexistent recipients are rejected. More details in http://www.postfix.org/ADDRESS_CLASS_README.html Other restrictions control what senders or client IPs are acceptable. -- Noel Jones
Re: check_sender_access and pattern matching
On 30 Dec 2015, at 20:45, Alex wrote: Hi, I hoped I could ask another question. Well, you can ask... Below is my smtpd_recipient_restrictions as we were discussing earlier this week: On Sun, Dec 27, 2015 at 9:37 PM, Bill Cole wrote: On 27 Dec 2015, at 20:22, Alex wrote: [...] smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, [...] The docs say reject_unlisted_recipient rejects mail when the recipient is not listed in the list of valid recipients for its domain class. I think you need to read the docs more carefully. Start at http://www.postfix.org/postconf.5.html#reject_unlisted_recipient, follow the reference in that section and follow the references from there as well. It may also help to read http://www.postfix.org/ADDRESS_CLASS_README.html. Maybe skim over them less swiftly? I'm having a hard time responding to the specifics in the rest of your message because it seems that you've missed some critical concepts, so the ensuing queries don't really make much sense.
