Re: Postscreen Feature Request
On 03/09/17 00:43, Wietse Venema wrote: > On 02/09/17 22:03, Wietse Venema wrote: >> Surprise: I already solved that problem: postscreen would hand off >> the _decrypted_ session to the tarpitting daemon :-) > > Allen Coates: >> How would you optionally hand off to the tarpit daemon, instead of to >> postfix? > > That requires new code for a config parameter that specifies the > pathname of the tarpit service's UNIX-domain socket, and new code > for making the Postfix library call to send the SMTP session's file > descriptor to that socket. > > Wietse > Thanks for that. My spam defences are pretty well sorted - only eight since march - and I am itching to take the fight to them. Thanks for your time. Allen
Re: Postscreen Feature Request
On 02/09/17 22:03, Wietse Venema wrote: > Surprise: I already solved that problem: postscreen would hand off > the _decrypted_ session to the tarpitting daemon :-) Allen Coates: > How would you optionally hand off to the tarpit daemon, instead of to > postfix? That requires new code for a config parameter that specifies the pathname of the tarpit service's UNIX-domain socket, and new code for making the Postfix library call to send the SMTP session's file descriptor to that socket. Wietse
Re: Postscreen Feature Request
On 02/09/17 22:03, Wietse Venema wrote: > > Surprise: I already solved that problem: postscreen would hand off > the _decrypted_ session to the tarpitting daemon :-) > How would you optionally hand off to the tarpit daemon, instead of to postfix? Allen C
Re: Postscreen Feature Request
Viktor Dukhovni: > On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote: > > Allen Coates: > > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > > > decision to reject the message has already been made; > > > It seems to me that this is an opportunity to tar-pit the (bad) remote > > > host, diminishing spam throughput, and eroding the host's useful > > > life-span. > > > > postscreen could hand off a connection to some other daemon. > > > > Keeping connections open *inside* postscreen is definitely not an > > option. That would limit postcreen's scalability. With a tarpit-only > > daemon, failure in that daemon would not affect other connections. > > This is of course only possible if TLS is not in use. Since OpensSSL > TLS state is not serializable for migration across processes, tarpitting > TLS would cause congestion in tlsproxy. Surprise: I already solved that problem: postscreen would hand off the _decrypted_ session to the tarpitting daemon :-) With postscreen, the tlsproxy daemon maintains the per-session TLS state. Of course, tarpitting lots of TLS connections would be expensive, and it may cause some tlsproxy processes to fail. But that would not affect sessions that are already whitelisted. Wietse
Re: Postscreen Feature Request
On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote: > Allen Coates: > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > > decision to reject the message has already been made; > > It seems to me that this is an opportunity to tar-pit the (bad) remote > > host, diminishing spam throughput, and eroding the host's useful life-span. > > postscreen could hand off a connection to some other daemon. > > Keeping connections open *inside* postscreen is definitely not an > option. That would limit postcreen's scalability. With a tarpit-only > daemon, failure in that daemon would not affect other connections. This is of course only possible if TLS is not in use. Since OpensSSL TLS state is not serializable for migration across processes, tarpitting TLS would cause congestion in tlsproxy. -- Viktor
Re: Postscreen Feature Request
Allen Coates: > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the > decision to reject the message has already been made; > It seems to me that this is an opportunity to tar-pit the (bad) remote > host, diminishing spam throughput, and eroding the host's useful life-span. postscreen could hand off a connection to some other daemon. Keeping connections open *inside* postscreen is definitely not an option. That would limit postcreen's scalability. With a tarpit-only daemon, failure in that daemon would not affect other connections. Wietse
Postscreen Feature Request
GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the decision to reject the message has already been made; It seems to me that this is an opportunity to tar-pit the (bad) remote host, diminishing spam throughput, and eroding the host's useful life-span. I SUGGEST, therefore, that an additional "TAR-PIT" option be added to the list of available postscreen_mumble_action's. I envisage this as being the same as "ENFORCE", but with an added delay. It would be very nice if the tar-pit action could be invoked from within the Postscreen access control lists, but I appreciate that this could disrupt stable and well-tested code. I would be interested to hear what others make of this idea. Allen C
Re: postscreen feature request
Kov?cs Albert: On Tuesday, March 10, 2015 1:42 PM, Wietse Venema wie...@porcupine.org wrote: I'm not sure how one (type of) dns query is a performance concern, and another is not, see below. You see no performance difference between querying a small number of well-operated DNS servers that are chosen by the local sysadmin, versus random DNS servers all over the Internet that are determined by the sender's IP address? this isn't exactly what i wrote :-) Obviously querying PTR records may take some time. However, smtpd also needs the PTR record to perform some DNS tests, so sooner or later you need the query. If everything smtpd did was OK for postscreen, then we would not need postscreen. Wietse
Re: postscreen feature request
On Monday, March 9, 2015 4:21 PM, Noel Jones njo...@megan.vbhcs.org wrote: For performance reasons, postscreen does not do PTR lookups, nor will PTR lookups be added to postscreen in the foreseeable future. I'm not sure how one (type of) dns query is a performance concern, and another is not, see below. Either use one of the many RBLs that list dynamic clients, or put it's quite possible, however these RBLs are hardly complete, so the regex match still makes sense. your PTR check in one of the smtpd_*_restrictions. I'd rather avoid this since I don't want zombies to occupy smtpd processes. Albert
Re: postscreen feature request
Kov?cs Albert: On Monday, March 9, 2015 4:21 PM, Noel Jones njo...@megan.vbhcs.org wrote: For performance reasons, postscreen does not do PTR lookups, nor will PTR lookups be added to postscreen in the foreseeable future. I'm not sure how one (type of) dns query is a performance concern, and another is not, see below. You see no performance difference between querying a small number of well-operated DNS servers that are chosen by the local sysadmin, versus random DNS servers all over the Internet that are determined by the sender's IP address? I'd rather avoid this since I don't want zombies to occupy smtpd processes. With postscreen, zombies don't get to occupy smtpd processes, by using DNSBLs and pregreet tests. Wietse
Re: postscreen feature request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, If you want to block more DUL ip blocks, the easiest way is probably to use some upstream DUL DNSBL providers, and use rbldnsd to create your private DNSBL to provide your own additions. There also is a community-maintained pcre file for smtpd restrictions (located at: http://www.hardwarefreak.com/fqrdns.pcre), that will block many of your candidates at the smtpd level. You could probably get fail2ban or some homegrown logparser create additions to your rbldnsd input file based on the rejections (i.e. postscreen passes, smtpd blocks, ip(-block) is added to rbldnsd, postscreen blocks at next connect). Tom On 10-03-15 16:16, Kovács Albert wrote: On Tuesday, March 10, 2015 1:42 PM, Wietse Venema wie...@porcupine.org wrote: I'm not sure how one (type of) dns query is a performance concern, and another is not, see below. You see no performance difference between querying a small number of well-operated DNS servers that are chosen by the local sysadmin, versus random DNS servers all over the Internet that are determined by the sender's IP address? this isn't exactly what i wrote :-) Obviously querying PTR records may take some time. However, smtpd also needs the PTR record to perform some DNS tests, so sooner or later you need the query. OK, postscreen blocks many of the zombie hosts for sure, so you don't need to perform PTR queries for that many times, however (based on my experience) lots of hosts with names like ppp|dsl|cable|-xx-xx-xx-xx.some.provider.com pass postscreen ending up at smtpd. Anyway I started to use an RBL targeting dynamic IP blocks, and it makes postscreen dropping many such zombies, though no RBL is accurate, so I believe there's still some room for optimization. If there's some deeper guide or you could provide some hints on how postfix does dns resolution, I'd appreciate it, and perhaps I could make it for myself. With postscreen, zombies don't get to occupy smtpd processes, by using DNSBLs and pregreet tests. unfortunately not all of them, that's why I'd improve postscreen to have a better hit ratio. Albert -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU/yPbAAoJEJPfMZ19VO/16YwQAMCbKHTgIcbltHWd1btMZfcl E5BMs3ILcTK0+ABWJu9F4337SmWbZD/hOjO1F0JTi2UjfvmeyGGLGa+mjrRc2jSS 2I9UhqKF6wv/HI8O39P1NIYkoskav3Vlcimz5bRxtQAQPfhA8wcYiVM+Dun6R90G YgZgjK3YiJOPNtfAvf+iiGPbKst7k/RVgRvyLHq/lcbm8+ykLh5DRvw0Gf2ENlmL ImTClziBYFBvlJuLI9ECZu8RkSCl/5y3tNibjtUgktAUtRXO5jFg6oK0ht1E8hBK qMtRxhQ4Z1nJ8KBz/FR/SiX1qL/kg9TzL+ab5FspzfMxA03GhEVl/CNz7CtU8sUB dNfUayIMRq+5bwxJquixK+ux+8213AqOt5SGtX5sOGw5gLH2NGNk2wHQnZlyzN0n 6CvX0L1ESASRSJCpn2Ipc85EuuYoIE1njVNJiaaSZGE7TEadaCq9Xl9XTFjGOA+N /+mLXd4GgUB+Liuyjs/sxYZbc2KqlY8L4t8a0N0K0gLsTy1ZFnffiUqUJD2crrcm 3PilFNV2dv4Oxj93VbaXAsF4FndGXPfcjs862ct21FIzO+Sbf+SDEdQperxI6ep+ 6fEh0/mNQd+464zcMb0NtaVIrXJ+RhM/FHG+3kOhHuKwtxRslQNplH2lbWWxfquI Tkkf6BBb5sHKTT1W4q0M =7U0a -END PGP SIGNATURE-
Re: postscreen feature request
On Tuesday, March 10, 2015 1:42 PM, Wietse Venema wie...@porcupine.org wrote: I'm not sure how one (type of) dns query is a performance concern, and another is not, see below. You see no performance difference between querying a small number of well-operated DNS servers that are chosen by the local sysadmin, versus random DNS servers all over the Internet that are determined by the sender's IP address? this isn't exactly what i wrote :-) Obviously querying PTR records may take some time. However, smtpd also needs the PTR record to perform some DNS tests, so sooner or later you need the query. OK, postscreen blocks many of the zombie hosts for sure, so you don't need to perform PTR queries for that many times, however (based on my experience) lots of hosts with names like ppp|dsl|cable|-xx-xx-xx-xx.some.provider.com pass postscreen ending up at smtpd. Anyway I started to use an RBL targeting dynamic IP blocks, and it makes postscreen dropping many such zombies, though no RBL is accurate, so I believe there's still some room for optimization. If there's some deeper guide or you could provide some hints on how postfix does dns resolution, I'd appreciate it, and perhaps I could make it for myself. With postscreen, zombies don't get to occupy smtpd processes, by using DNSBLs and pregreet tests. unfortunately not all of them, that's why I'd improve postscreen to have a better hit ratio. Albert
postscreen feature request
Hello,
I'd like postscreen to have the ability to reject clients based on a regex
pattern based on their PTR records.
I use both the pregreet and the dns block feature of postfix. However it seems
that still too many spamming hostsmanage to pass postscreen and thus
overwhelming smtpd processes.
So I'd like to apply a list of regex patterns to the detected PTR record of the
smtp client host, and reject theconnection (at the postscreen level) in case of
a match. Then I may apply such patterns, eg.
/dialup-\d{1,3}-\d{1,3}-\d{1,3}\-\d{1,3}\-some.provider.net/ reject
Thanks in advance,
Albert
Re: postscreen feature request
On Mar 9, 2015, at 6:02 AM, Kovács Albert albiba...@yahoo.com wrote: I'd like postscreen to have the ability to reject clients based on a regex pattern based on their PTR records. If it has to be postscreen, you can setup a local RBL lookup and score it high enough to trigger a rejection. But based on your pattern, there are RBLs already out there that will block those sorts of patterns. You can also setup a file like rdns.pcre And check it via check_reverse_client_hostname_access pcre:/etc/postfix/rdns.pcre But that will not be postscreen. An RBL like zen would be better. -- On nights such as this, evil deeds are done. And good deeds, of course. But mostly evil deeds. --Wyrd Sisters
Re: postscreen feature request
On 3/9/2015 7:02 AM, Kovács Albert wrote:
Hello,
I'd like postscreen to have the ability to reject clients based on a
regex pattern based on their PTR records.
I use both the pregreet and the dns block feature of postfix.
However it seems that still too many spamming hosts
manage to pass postscreen and thus overwhelming smtpd processes.
So I'd like to apply a list of regex patterns to the detected PTR
record of the smtp client host, and reject the
connection (at the postscreen level) in case of a match. Then I may
apply such patterns, eg.
/dialup-\d{1,3}-\d{1,3}-\d{1,3}\-\d{1,3}\-some.provider.net/ reject
Thanks in advance,
Albert
For performance reasons, postscreen does not do PTR lookups, nor
will PTR lookups be added to postscreen in the foreseeable future.
Either use one of the many RBLs that list dynamic clients, or put
your PTR check in one of the smtpd_*_restrictions.
-- Noel Jones
