On Tue, Mar 29, 2016, at 08:29 AM, /dev/rob0 wrote:
> A client lookup looks up the client hostname (if forward-confirmed
> reverse DNS) and IP address (in any case.)
>
> A helo lookup looks up the client's hostname as it gave in the
> HELO/EHLO command.
>
> A sender lookup looks up the sender address as given in the MAIL
> FROM: command.
>
> A recipient lookup looks up the recipient address as given in the
> RCPT TO: command.
>
> NS lookups look up the NS for one of those domains, as appropriate;
> check_sender_ns_access looks up the nameservers for the sender domain
> name.
That's a great summary!
> "From a domain" is inexact. See above. Domain names are seen in
> each category. Which one defines what domain it is "from"? You
> first need to understand this. Also, understand that if "from" means
> the sender address, 95%+ of spam uses forged sender addresses.
That summary helps a lot.
> (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)
Hah, "quasi-legitimate". That's being kind. All they're doing is 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"'.
If anyone's interested, in digging around in my archived logs on 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.
> 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.
> 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.
Thanks
Jason
