On Tue, Mar 29, 2016 at 08:53:48AM -0700, jaso...@mail-central.com wrote: > On Tue, Mar 29, 2016, at 08:29 AM, /dev/rob0 wrote: > > (However, in this thread you do seem to be focusing on spam from the > > quasi-legitimate marketers who might be in compliance with the USA > > "[You-]CAN-SPAM" law, and thus using real sender addresses.) > > Yeah, for now I'm trying to get to "mail sent from (a) hosts whose > (b) parent domains have (c) NS hosted by (d) vendor domain I don't > like". > > So, for example, from my logs I track down a bad-actor > > (a) mta host -> mta-wk-whatever.chumpineer.com > (b) parent -> chumpineer.com > (c) NS -> kilmer-dns1.synapp.io > (d) vendor -> synapp.io > > and my goal is to block that & all OTHER mta hosts that have their > NS on *.synapp.io or just synapp.io (just in case)
Hehe, this brings to mind an old spam war story. Sorry, but this might be of interest to this thread. In (I think) 2005 I was subcontracted for a small consultancy in Dallas. My boss (the contractor) had sold the customer (or the customer sold him?) on the idea of DNS filtering, and I was tasked to make it so. What I did (in pre-RPZ days, or at least, before I was aware of BIND response policy zones, which amounts to the same thing AFAIC) was to take a list of known malware domains, parse it into zone statements for our named.conf, include it. So our servers were giving authoritative answers for these zones, pointing wildcard records at an internal host. If any of our users tried those names for HTTP, our httpd there gave them a page saying that the domain was blocked by company policy, see your supervisor and/or I.T., blah blah. An unexpected side effect was a dramatic increase in unknown clients hitting the mail server! Why? Simple. Suppose 192.0.2.25 connects to us; we use our own nameserver to look up "25.2.0.192.in-addr.arpa/IN/PTR". Suppose further that the in-addr.arpa zone has NS names in one of our known malware domains, say, "ns1.malware.example". So "ns1.malware.example" resolves to our internal host, and no nameserver's running there, so wham, no PTR. Spammy clients are frequently shown as "unknown", even when they truly do have perfect FCrDNS set up. The area of NS-based blocking for spam control is fascinating and deserves research. (If I could get funding for such a project, I would be glad to do it.) Unfortunately it is VERY susceptible to the "human shield" defense. Rogue registrars & DNS providers need only pull in a few legitimate customers, which can make it painful for any site that wants to block them altogether. > Hah, "quasi-legitimate". That's being kind. All they're doing is I was thinking like the one whose name I can't recall which sued Spamhaus in US Federal court and almost took down the spamhaus.org domain name when UK-based Spamhaus opted not to respond to the suit. (Later Spamhaus did respond and solidly won.) > probing my server to see what addresses exist, etc so they can sell > services to their clients to be more efficient at sending unwanted > crap using MailChimp etc, who suggest 'verifying your emails > "externally"'. FWIW, if you get spammed by MailChimp, they do staff and empower an abuse desk. A report to them is not a waste of your time. > If anyone's interested, in digging around in my archived logs on http://spammers.dontlike.us/ ... a mailing list which I [sort of] co-manage ... this would be welcome there. > this issue, I've found a trail of these 'email verifier' probes & > spew from synapp.io, social123.com, datavalidation.com & > mailminion.com so far. It's tough to track down all the info since > their sending domains' whois info, but I'm pretty sure there's some > sort of relationships between them. For me, I'll be blocking them > all. > > > In many cases you can do all your restrictions in one place, and > > the usual choice for that would be smtpd_recipient_restrictions. > > See again the aforementioned SMTPD_ACCESS_README. > > I've seen that too. Don't have a great sense yet for when to break > it apart and when to do it all in one place. There's some > discussion I've found, but need to re-read a few times I think. The "Dangerous use" section describes it somewhat. Most times you can keep it all linear, with restrictions in only one place. But if you want certain restrictions only applied in certain cases, that's when you might want to use another restrictions list. You seem to be getting close to that situation. > > I would not suggest specifying the SMTP code in general. Just use > > "REJECT" and let Postfix handle the SMTP code and DSN. > > Somehow I got the impression that I had to specify to have a 'well > behaved' server. Thanks for clearing up. My assumption, which has often been validated, is that Wietse knows SMTP better than I do. :) > > Again refer to the access(5) manual, access.5.html -- yes, any > > valid action can be the result of any lookup. To use a custom > > restriction class name as a lookup result, that name must be: > > 1. listed in smtpd_restriction_classes, and > > 2. defined in main.cf > > Ok. For just a few entries, this should be fine. With a lot > (which I don't anticipate), it can get messy I think. BTDT, and I have lots of empty aspirin bottles to prove it. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
