On Tue, Mar 29, 2016 at 07:33:23AM -0700, jaso...@mail-central.com wrote:
> On Mon, Mar 28, 2016, at 08:03 PM, Viktor Dukhovni wrote:
> > Sorry, that's:
> >
> > http://www.postfix.org/postconf.5.html#check_client_ns_access
>
> Ugh. I should have just searched for 'ns_access'. Thanks.
>
> I'm not 100% sure why it's a "client" rule instead of a "sender"
> rule. Looking at examples, theses sets of checks end up in
> different mumble restriction. Is it because client is earliest in
> order?
Wrong (they can go in any mumble value of smtpd_mumble_restrictions)
and no.
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.
> As a last step, I'd like to understand how to eventually grow this
> correctly.
>
> If I wanted to add ns-related blocks that
>
> (1) block all messages from any/all domains NS-hosted on
> "example1.com" or ".example1.com"
"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.
(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.)
> and
> (2) block all messages from domains NS-hosted on "example2.com"
There's that "F" word again, what does "from" mean? :)
> and MTA RDNS matching, '^this-mta' (similar to what's already
> in there for synapp.io),
>
> would this be the best approach?
>
> main.cf
> ...
> smtpd_restriction_classes = no_ns_match
> no_ns_match =
> reject_unknown_client,
> check_client_access pcre:${config_directory}/ns_reject.pcre
>
> smtpd_client_restrictions =
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.
> permit_mynetworks
> reject_unauth_pipelining
> check_client_ns_access pcre:${config_directory}/ns_access.pcre
> ...
>
> cat ns_reject.pcre
> /^mta-wk-\d/ REJECT 554
I would not suggest specifying the SMTP code in general. Just use
"REJECT" and let Postfix handle the SMTP code and DSN.
> /^this-mta/ REJECT 554
>
> cat ns_access.pcre
> /\.synapp\.io$/ no_ns_match
> /\.example1\.com$/ REJECT 554
> /\.example2\.com$/ no_ns_match
>
> My specific concerns with that^ are
>
> (1) it could incorrectly match/reject on
> 'this-mta.somedomain.com' hosted on example1.com, not just
> example2.com, as intended
You are doing a check_client_ns_access lookup, so what you are
looking up here is the NS names for the client FCrDNS name. This is
NOT looking up the client's own hostname.
> (2) I'm not 100% sure I can mix "no_ns_match" & "REJECT 554"
> actions in the same file, 'ns_access.pcre'.
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
> Again this example was really helpful -- not just in solving this
> specific problem but giving an idea of how to add & layer
> restrictions, and how they 'flow'.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
