Re: RBL timing
On Thu, Nov 24, 2022 at 02:48:48PM -0800, Doug Hardie wrote: > Thanks to all for the assistance. It now works properly. I never > found reject_unlisted_recipient as it only exists on > https://www.postfix.com/SMTPD_ACCESS_README.html where it says it is > on by default. The description above should be included in the > documentation. Well, it is also briefly covered in: http://www.postfix.org/postconf.5.html#reject_unlisted_recipient (or as part of http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions) and http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient But, sadly the *timing* of the default action is not covered. So sure, it could be somewhat better documented. -- Viktor.
Re: RBL timing
On Nov 24, 2022, at 07:05, Matus UHLAR - fantomas wrote: > > >> >> Matus UHLAR - fantomas: > > Doug: > > There's implicit reject_unlisted_recipient at the end of rules when > smtpd_reject_unlisted_recipient=on (default). > > However when this one hits, DNS queries were already sent. > > the reject_unlisted_recipient makes sense when delivering mail to another > servers or processes/sockets where list of recipients can't be easily found > out Thanks to all for the assistance. It now works properly. I never found reject_unlisted_recipient as it only exists on https://www.postfix.com/SMTPD_ACCESS_README.html where it says it is on by default. The description above should be included in the documentation. — Doug
Re: RBL timing
Matus UHLAR - fantomas: reject_unlisted_recipient, of course: http://www.postfix.org/postconf.5.html#reject_unlisted_recipient reject_unlisted_recipient Reject the request when the RCPT TO address is not listed in the list of valid recipients for its domain class. See the smtpd_reject_unlisted_recipient parameter description for details. This feature is available in Postfix 2.1 and later. On 24.11.22 09:23, Wietse Venema wrote: To avoid DNSBL lookups for non-existent recipients, list reject_unlisted_recipient before reject_rbl_* and reject_rhsbl_*. yes, this is what I've meant. The OP currently has according to https://marc.info/?l=postfix-users=166927069321425=2 incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient ^^^ reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit where reject_unverified_recipient has to be replaced by reject_unlisted_recipient: incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unlisted_recipient, ^ reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit Doug: There's implicit reject_unlisted_recipient at the end of rules when smtpd_reject_unlisted_recipient=on (default). However when this one hits, DNS queries were already sent. the reject_unlisted_recipient makes sense when delivering mail to another servers or processes/sockets where list of recipients can't be easily found out. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK]
Re: RBL timing
Matus UHLAR - fantomas: > reject_unlisted_recipient, of course: > > http://www.postfix.org/postconf.5.html#reject_unlisted_recipient > > reject_unlisted_recipient >Reject the request when the RCPT TO address is not listed in the list of >valid recipients for its domain class. See the >smtpd_reject_unlisted_recipient parameter description for details. This >feature is available in Postfix 2.1 and later. To avoid DNSBL lookups for non-existent recipients, list reject_unlisted_recipient before reject_rbl_* and reject_rhsbl_*. Wietse
Re: RBL timing
Dnia 24.11.2022 o godz. 08:44:51 Matus UHLAR - fantomas pisze: you should use reject_unverified_recipient instead of reject_unverified_recipient, they have different use which is why you get DNS lookups prior recipient being rejected. On 24.11.22 11:34, Jaroslaw Rafa wrote: Hm... "reject_unverified_recipient instead of reject_unverified_recipient" ? You probably meant something else? Oh! reject_unlisted_recipient, of course: http://www.postfix.org/postconf.5.html#reject_unlisted_recipient reject_unlisted_recipient Reject the request when the RCPT TO address is not listed in the list of valid recipients for its domain class. See the smtpd_reject_unlisted_recipient parameter description for details. This feature is available in Postfix 2.1 and later. instead of: http://www.postfix.org/postconf.5.html#reject_unverified_recipient reject_unverified_recipient Reject the request when mail to the RCPT TO address is known to bounce, or when the recipient address destination is not reachable. Address verification information is managed by the verify(8) server; see the ADDRESS_VERIFICATION_README file for details. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: RBL timing
Dnia 24.11.2022 o godz. 08:44:51 Matus UHLAR - fantomas pisze: > > you should use reject_unverified_recipient instead of > reject_unverified_recipient, they have different use which is why > you get DNS lookups prior recipient being rejected. Hm... "reject_unverified_recipient instead of reject_unverified_recipient" ? You probably meant something else? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: RBL timing
Thursday, November 24, 2022, 7:22:09 PM, Doug Hardie wrote: >> On Nov 23, 2022, at 23:27, Phil Biggs wrote: >> >> Thursday, November 24, 2022, 5:24:12 PM, Doug Hardie wrote: >> >> >>> I am trying with the postscreen dns lookup disabled. Here is the main.cf >>> section: >> >>> # postscreen spam filtering >>> postscreen_greet_action = enforce >>> #postscreen_dnsbl_action = enforce >>> #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >>> b.barr >>> acudacentral.org >>> postscreen_access_list = permit_mynetworks, >>>cidr:/usr/local/etc/postfix/access.cidr >>> # >>> # Use long queue ids for uniqueness >>> enable_long_queue_ids = yes >>> # >>> # Incoming restrictions and Implement postfwd >>> incoming_smtpd_restrictions = >>>check_policy_service inet:127.0.0.1:10040, >>>reject_invalid_hostname, >>>reject_non_fqdn_sender, >>>reject_non_fqdn_recipient, >>>reject_unknown_sender_domain, >>>reject_unknown_recipient_domain, >>>reject_unauth_pipelining, >>>permit_mynetworks, >>>check_recipient_access hash:/usr/local/etc/postfix/tempfail, >>>reject_unauth_destination, >>>reject_unverified_recipient >>>reject_rbl_client bl.spamcop.net, >>>reject_rbl_client b.barracudacentral.org, >>>reject_rbl_client zen.spamhaus.org, >>>permit >>> # >> >> >>> Here is main.cf for smtpd: >> >>> smtpd pass - - n - 50 smtpd >>> -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions >> >> >>> However, I seem to be doing the dns for all received emails. I see the log >>> message for user User unknown in virtual alias table, and dns requests >>> with that same timestamp for spamcop, barracudacentral and spamhaus. I am >>> suspecting I am missing a reject statement that will reject the email when >>> the user is not in the virtual alias table that needs to be before the rbl >>> rejects. I thought that reject_unverified_recipient would do that, but >>> apparently not.' >> >>> -- Doug >> >> Never heard of the parameter "incoming_smtpd_restrictions" >> >> Is that really what you have in main.cf > Yes - that is a macro that is referenced in main.cf as shown above > — Doug Ah. Sorry, completely missed that. -- Best regards, Phil Biggs
Re: RBL timing
> On Nov 23, 2022, at 23:27, Phil Biggs wrote: > > Thursday, November 24, 2022, 5:24:12 PM, Doug Hardie wrote: > > >> I am trying with the postscreen dns lookup disabled. Here is the main.cf >> section: > >> # postscreen spam filtering >> postscreen_greet_action = enforce >> #postscreen_dnsbl_action = enforce >> #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >> b.barr >> acudacentral.org >> postscreen_access_list = permit_mynetworks, >>cidr:/usr/local/etc/postfix/access.cidr >> # >> # Use long queue ids for uniqueness >> enable_long_queue_ids = yes >> # >> # Incoming restrictions and Implement postfwd >> incoming_smtpd_restrictions = >>check_policy_service inet:127.0.0.1:10040, >>reject_invalid_hostname, >>reject_non_fqdn_sender, >>reject_non_fqdn_recipient, >>reject_unknown_sender_domain, >>reject_unknown_recipient_domain, >>reject_unauth_pipelining, >>permit_mynetworks, >>check_recipient_access hash:/usr/local/etc/postfix/tempfail, >>reject_unauth_destination, >>reject_unverified_recipient >>reject_rbl_client bl.spamcop.net, >>reject_rbl_client b.barracudacentral.org, >>reject_rbl_client zen.spamhaus.org, >>permit >> # > > >> Here is main.cf for smtpd: > >> smtpd pass - - n - 50 smtpd >> -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions > > >> However, I seem to be doing the dns for all received emails. I see the log >> message for user User unknown in virtual alias table, and dns requests with >> that same timestamp for spamcop, barracudacentral and spamhaus. I am >> suspecting I am missing a reject statement that will reject the email when >> the user is not in the virtual alias table that needs to be before the rbl >> rejects. I thought that reject_unverified_recipient would do that, but >> apparently not.' > >> -- Doug > > Never heard of the parameter "incoming_smtpd_restrictions" > > Is that really what you have in main.cf Yes - that is a macro that is referenced in main.cf as shown above — Doug
Re: RBL timing
On 23.11.22 22:24, Doug Hardie wrote: I am trying with the postscreen dns lookup disabled. Here is the main.cf section: # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions strange combination, but it should work. I personally recommend to use smtpd_recipient_restrictions in main.cf and if needed, override them for smtps/submission services. However, I seem to be doing the dns for all received emails. I see the log message for user User unknown in virtual alias table, and dns requests with that same timestamp for spamcop, barracudacentral and spamhaus. I am suspecting I am missing a reject statement that will reject the email when the user is not in the virtual alias table that needs to be before the rbl rejects. I thought that reject_unverified_recipient would do that, but apparently not.' you should use reject_unverified_recipient instead of reject_unverified_recipient, they have different use which is why you get DNS lookups prior recipient being rejected. Also, I want to repeat that it's better to reject DNSBLs at postscreen level, even if you see more DNSBL lookups - currently you are telling spambots which users do/don't exist -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
Re: RBL timing
Thursday, November 24, 2022, 5:24:12 PM, Doug Hardie wrote: > I am trying with the postscreen dns lookup disabled. Here is the main.cf > section: > # postscreen spam filtering > postscreen_greet_action = enforce > #postscreen_dnsbl_action = enforce > #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] > b.barr > acudacentral.org > postscreen_access_list = permit_mynetworks, > cidr:/usr/local/etc/postfix/access.cidr > # > # Use long queue ids for uniqueness > enable_long_queue_ids = yes > # > # Incoming restrictions and Implement postfwd > incoming_smtpd_restrictions = > check_policy_service inet:127.0.0.1:10040, > reject_invalid_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > permit_mynetworks, > check_recipient_access hash:/usr/local/etc/postfix/tempfail, > reject_unauth_destination, > reject_unverified_recipient > reject_rbl_client bl.spamcop.net, > reject_rbl_client b.barracudacentral.org, > reject_rbl_client zen.spamhaus.org, > permit > # > Here is main.cf for smtpd: > smtpd pass - - n - 50 smtpd > -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions > However, I seem to be doing the dns for all received emails. I see the log > message for user User unknown in virtual alias table, and dns requests with > that same timestamp for spamcop, barracudacentral and spamhaus. I am > suspecting I am missing a reject statement that will reject the email when > the user is not in the virtual alias table that needs to be before the rbl > rejects. I thought that reject_unverified_recipient would do that, but > apparently not.' > -- Doug Never heard of the parameter "incoming_smtpd_restrictions" Is that really what you have in main.cf -- Cheers, Phil
Re: RBL timing
> On Nov 23, 2022, at 4:49 AM, Matus UHLAR - fantomas wrote: > > On 23.11.22 01:58, Doug Hardie wrote: >> I originally had incoming_smtpd_restrictions set to: >> >> reject_unverified_recipient >> reject_rbl_client bl.spamcop.net, >> reject_rbl_client dnsbl.sorbs.net, >> reject_rbl_client zen.spamhaus.org, >> permit >> >> Later I added postscreen and commented out the reject_rbl_... entries. I >> included in main.cf: >> >> postscreen_dnsbl_action = enforce >> postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >> b.barracudacentral.org > >> This works as expected. However, I believe that postscreen is processed >> prior to smtpd. I am experiencing a lot of emails that are being sent to >> non-existent users. I don't have accurate counts, but the vast majority of >> email is that. Postscreen is doing a DNS lookup for every one of those. It >> seems it might be better to remove the dnsrbl from postscreen and reinstate >> the reject_rbl statements into incoming_smtpd_restrictions. I believe that >> way, only the mail that has a valid recipient will have the dns rbls >> checked. Am I understanding this correctly? Thanks, > > If you want to spare yourself from DNS lookups, you can do that. > > Note that you may be careful and not to reject mail unless it appears in more > than one DNSBL, or if it appears in e.g. DNSWL, in which case postcreen is > better. > > Also, postscreen is great at rejecting bots that talk prior to ESMTP banner > is sent to them. > > so I personally risk a few DNS lookups but benefit of weighing DNSBLs and use > lookups at postscreen level. > I am trying with the postscreen dns lookup disabled. Here is the main.cf section: # postscreen spam filtering postscreen_greet_action = enforce #postscreen_dnsbl_action = enforce #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barr acudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # # Use long queue ids for uniqueness enable_long_queue_ids = yes # # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit # Here is main.cf for smtpd: smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions However, I seem to be doing the dns for all received emails. I see the log message for user User unknown in virtual alias table, and dns requests with that same timestamp for spamcop, barracudacentral and spamhaus. I am suspecting I am missing a reject statement that will reject the email when the user is not in the virtual alias table that needs to be before the rbl rejects. I thought that reject_unverified_recipient would do that, but apparently not.' -- Doug
Re: RBL timing
On 2022-11-23 at 04:58:09 UTC-0500 (Wed, 23 Nov 2022 01:58:09 -0800) Doug Hardie is rumored to have said: I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Yes and no. If you use only postscreen for DNSBLs you do lookups on every IP, even if it is eventually going to send garbage recipients. If you use only smtpd_*_restrictions lists for DNSBLs and put reject_unverified_recipient aherad of them, you save the DNS queries at the cost of recipient queries to whatever verifies your recipients (probably trivial, maybe not) for recipients offered by clients that might have been shunned by postscreen. If you use *both* and have a proper local DNS cache, the second DNS query (in cases where you make it) will come from cache and be extremely fast and cheap. In some edge cases (e.g. SORBS) you may find some clients get through postscreen only because of slow DNS response and the answer is oin cached by the time the smtpd query is made. I use DNSBLs in both places because the second check is practically free and the useful lists for the two are not the same. For example, I know that I will probably not want to accept mail from machines on the Spamhaus PBL, but there are exceptions so a listing there alone is not adequate to block at the postscreen level without additional listings, but if I have not seen a positive reason to accept the mail by the end of smtpd_recipient_restrictions, a PBL listing will kill it. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: RBL timing
On 23.11.22 01:58, Doug Hardie wrote: I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Thanks, If you want to spare yourself from DNS lookups, you can do that. Note that you may be careful and not to reject mail unless it appears in more than one DNSBL, or if it appears in e.g. DNSWL, in which case postcreen is better. Also, postscreen is great at rejecting bots that talk prior to ESMTP banner is sent to them. so I personally risk a few DNS lookups but benefit of weighing DNSBLs and use lookups at postscreen level. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Eagles may soar, but weasels don't get sucked into jet engines.
RBL timing
I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Thanks, -- Doug
