SpamAssassin & DNSBLs (was Re: PostFix as a "/dev/null" MTA?)
On 13 Oct 2016, at 1:06, li...@lazygranch.com wrote: On the surface, SA hitting multiple RBLs sounds inefficient. SpamAssassin is inherently inefficient. That's why in a production environment with heavily loaded systems, it is important to have layers ahead of it to deal with the bulk of spam. Fortunately, recent versions (since 3.3, I think) are more parallelized so that high-latency tests (i.e. 'net' rules) don't block each other or faster scans, so it is not a huge problem. Essentially all the DNSBL, DNSWL, and URIBL checks are done in the time it takes to do the slowest one. However does each hit add to the SA rating? Yes, although it's variable and subject to local adjustments. There are some complications involving multiplexed DNSBLs and a few meta rules that combine DNSBL rules with each other or with other rules, but essentially DNSBL rules get summed up just like any other SA rules. The default ruleset has 65 scored rules calling the check_rbl_sub or check_rbl methods. Each rule's score is either determined by the SA project's RuleQA/massscan service or is set to a fixed value that can be changed in local config but isn't subject to nightly automated tuning. Few (if any) are ever individually scored above 3.6, so no single DNSBL can cause a message to be tagged as spam if you use the default threshold (5.) Of those 65 rules, 25 are disabled by having fixed scores of 0, 15 are effectively informational with fixed or tuned scores between -0.1 and 0.1, 11 are whitelists with scores < -0.1, and 14 are blacklists with scores > 0.1. If so, that sounds like a plan. That is if a message is rejected by N RBLs, it is more significant than just one RBL. That's the principle both in SA and in postscreen. SA does a much more complex aggregation of DNSBL results than I'd want to make postscreen do, but it is useful to have a simpler aggregation in postscreen to handle the clearest cases without needing to do any more work.
Re: PostFix as a "/dev/null" MTA?
On the surface, SA hitting multiple RBLs sounds inefficient. However does each hit add to the SA rating? If so, that sounds like a plan. That is if a message is rejected by N RBLs, it is more significant than just one RBL. Original Message From: Bill Cole Sent: Wednesday, October 12, 2016 9:11 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: PostFix as a "/dev/null" MTA? On 12 Oct 2016, at 18:59, li...@lazygranch.com wrote: > You really can't rate RBLs in a normal setup since if one rejects the > email, the others don't get a try. That's not the case if you use DNSBLs in postscreen or SpamAssassin. In those cases the lookups get done asynchronously and all the answers are (or at least can be) logged. e.g: Oct 11 18:45:14 bigsky postfix/dnsblog[94896]: addr 41.138.199.26 listed by domain blackholes.scconsult.com as 127.0.0.2 Oct 11 18:45:14 bigsky postfix/dnsblog[94893]: addr 41.138.199.26 listed by domain zen.spamhaus.org as 127.0.0.4 Oct 11 18:45:14 bigsky postfix/dnsblog[94889]: addr 41.138.199.26 listed by domain ix.dnsbl.manitu.net as 127.0.0.2 Either one of the last 2 on their own would be adequate for postscreen to reject the connection. You will note that the PIDs are in reverse order, indicating that the last dnsblog process spawned was the first to complete. This makes sense, as that DNS lookup never left the system's motherboard, while the others had to cross a WAN link and multiple routers. My recent logs have no examples of multi-DNSBL messages making it to SA, because my config is designed to avoid the need to have SA look at mail, but when it does get a message that hits multiple DNSBLs, I see them all in the log of rule hits for ones that get rejected an also a header for the very rare case of them getting through (which is effectively impossible unless they are targeting postmaster@ or abuse@).
Re: PostFix as a "/dev/null" MTA?
On 12 Oct 2016, at 18:59, li...@lazygranch.com wrote: You really can't rate RBLs in a normal setup since if one rejects the email, the others don't get a try. That's not the case if you use DNSBLs in postscreen or SpamAssassin. In those cases the lookups get done asynchronously and all the answers are (or at least can be) logged. e.g: Oct 11 18:45:14 bigsky postfix/dnsblog[94896]: addr 41.138.199.26 listed by domain blackholes.scconsult.com as 127.0.0.2 Oct 11 18:45:14 bigsky postfix/dnsblog[94893]: addr 41.138.199.26 listed by domain zen.spamhaus.org as 127.0.0.4 Oct 11 18:45:14 bigsky postfix/dnsblog[94889]: addr 41.138.199.26 listed by domain ix.dnsbl.manitu.net as 127.0.0.2 Either one of the last 2 on their own would be adequate for postscreen to reject the connection. You will note that the PIDs are in reverse order, indicating that the last dnsblog process spawned was the first to complete. This makes sense, as that DNS lookup never left the system's motherboard, while the others had to cross a WAN link and multiple routers. My recent logs have no examples of multi-DNSBL messages making it to SA, because my config is designed to avoid the need to have SA look at mail, but when it does get a message that hits multiple DNSBLs, I see them all in the log of rule hits for ones that get rejected an also a header for the very rare case of them getting through (which is effectively impossible unless they are targeting postmaster@ or abuse@).
Re: PostFix as a "/dev/null" MTA?
There are tips out there on how to set up a catch all account to accept mail that wasn't addressed to any known user. That is a (very) small part of your project. When you have a catch all, nothing bounces IF the email at least when to your FQDN. In your project, it would be a service to rate the RBLs, though in your setup you couldn't detect false positives. Maybe you should have one authorized user? Perhaps have two setups with at least on having a legitimate user plus catch-all and no open relay. That is, something close to a normal setup in addition to your accept anything server. You really can't rate RBLs in a normal setup since if one rejects the email, the others don't get a try. I have been changing the order that the RBLs appear in the configuration file with the assumption that the are used sequentially. I am working on a log filtering script to determine which catches the most spammers, though as I said, the approach is flawed since not all RBLs get a fair shot. I put the better known RBLs like Baracuda at the bottom in the configuration file. Original Message From: Glenn Forbes Fleming Larratt Sent: Wednesday, October 12, 2016 12:26 PM To: postfix-users@postfix.org Subject: PostFix as a "/dev/null" MTA? Folks, I've done some searching of the list archives and the web, but I can't lay hands on an answer to this question: - is there a way, ideally documented in a HOWTO or guide, to configure PostFix such that: - it will accept any mail (think "open relay", but...); - it will *never* attempt to forward that mail; - it will *never* generate e-mail: no sent mail, no return receipts, no bounces, nothing? The application we have in mind is a "Phish Phillet" engine, that would accept any mail sent to it, save the message locally, and process it using a home-grown set of analysis tools - DNS and whois queries, reputational databases, etc. - to rate messages and accumulate statistics about bad-actor mail senders and phishing sites. Thanks! -- Glenn Forbes Fleming Larratt Cornell University IT Security Office
Re: PostFix as a "/dev/null" MTA?
On Wed, Oct 12, 2016 at 03:25:25PM -0400, Glenn Forbes Fleming Larratt wrote: > I've done some searching of the list archives and the web, but I can't lay > hands on an answer to this question: > > - is there a way, ideally documented in a HOWTO or guide, to configure > PostFix such that: > > - it will accept any mail (think "open relay", but...); > - it will *never* attempt to forward that mail; > - it will *never* generate e-mail: no sent mail, no return receipts, no > bounces, nothing? main.cf: # Adjust as desired, this accepts 50MB messages: # message_size_limit = 52428800 mailbox_size_limit = 104857600 virtual_mailbox_limit = 104857600 queue_min_free = 104857600 # All domains are virtual mailbox domains # virtual_mailbox_domains = static:all virtual_transport = virtual # Splay out the mail into a pile of maildirs, # one per virtual(8) process id. # virtual_mailbox_base = /var/spool/junkmail/ virtual_mailbox_maps = static:$process_id/ # Reserve an otherwise unused uid/gid, and create a group # and account so it does not get later doubly allocated # virtual_uidgid = 10001 virtual_mailbox_uid_maps = static:$virtual_uidgid virtual_mailbox_gid_maps = static:$virtual_uidgid # With all domains final, no need for trusted clients # All mail will accepted and delivered to local maildirs. # mynetworks = smtpd_relay_restrictions = reject_unauth_destination smtpd_recipient_restrictions = reject_unauth_destination smtpd_client_restrictions = smtpd_sender_restrictions = smtpd_data_restrictions = smtpd_end_of_data_restrictions = header_checks = nested_header_checks = mime_header_checks = # All the other address classes are now empty, but just # in case bounce mail if this assumption fails. # content_filter = transport_maps = default_transport = error:5.1.2 Restricted destination mydestination = local_transport = $default_transport alias_maps = alias_database = local_recipient_maps = relay_domains = relay_transport = $default_transport relay_recipient_maps = virtual_alias_domains = virtual_alias_maps = -- Viktor.
Re: PostFix as a "/dev/null" MTA?
Glenn Forbes Fleming Larratt: > Folks, > > I've done some searching of the list archives and the web, but I can't lay > hands on an answer to this question: > > - is there a way, ideally documented in a HOWTO or guide, to configure > PostFix such that: > > - it will accept any mail (think "open relay", but...); > - it will *never* attempt to forward that mail; > - it will *never* generate e-mail: no sent mail, no return receipts, > no bounces, nothing? You could use the Postfix smtp-sink program. It's been used as an email trap in the past. http://www.postfix.org/smtp-sink.1.html Wietse
