Cascade smtp delivery failure when one smtp fails

[Pedro David Marco]

Hello everybody!

it seems to me that when qmgr wants to deliver an email via smtp, qmgr 
"assigns" it to a smtp process. As long as there are no
concurrency needs, the same smtp process is used repeatedly even for 
diferent domain destinations.
Ok so far!

NOW, if one smtp process delivery takes long, long long... until it dies for 
the watchdog timeout, all smtp 
deliveries assigned to that smtp process fail! and qmgr send them back to 
deferred queue

Is there any way to force postfix to use one smtp process for each delivery so 
if one fail the others get delivered?

Thanks in advance!

David.

Re: Cascade smtp delivery failure when one smtp fails

[Viktor Dukhovni]

> On Mar 28, 2016, at 10:15 AM, Pedro David Marco  
> wrote:
> 
> It seems to me that when qmgr wants to deliver an email via smtp, qmgr
> "assigns" it to a smtp process. As long as there are no concurrency
> needs, the same smtp process is used repeatedly even for diferent
> domain destinations.

This impression is incorrect.  Deliveries are handled by the first
idle smtp(8) delivery agent, or if none are idle, a new one is spawned,
up to the process limit specified in master.cf or the default process
limit.

There is no prior "assignment".  Each smtp(8) delivery agent handles
one request at a time, and goes back for more when it is done.

The main complication is there are also per-nexthop destination
concurrency limits, so messages for a busy destination may need
to wait for delivery of other messages for the same destination
when the concurrency limit is reached.  Similarly, once the process
limit is reached, and all delivery agents are busy, new mail waits
for other deliveries to complete.


> NOW, if one smtp process delivery takes long, long long... until
> it dies for the watchdog timeout,

Watchdog timeouts are not normal Postfix behaviour.  They are a
last-resort safety measure in the face of kernel bugs or execution
on platforms that are not sufficiently compatible with Postfix.

If you're seeing watchdog timeouts, there's something wrong with
your system.

> all smtp deliveries assigned to that smtp process fail! and
> qmgr send them back to deferred queue

Exactly one delivery is "assigned" to a busy smtp(8) delivery
agent.  No other deliveries wait for that agent specifically.

However, if you restart the queue manager (via Postfix reload
or similar) it will not be able to obtain an exclusive lock
on a queue file that is open by a running delivery agent.
In that case, other recipients from the same queue file may
be blocked until the pending delivery completes.  This does
not affect the delivery of new mail.

DO NOT make a habit of restarting the queue manager.  In
particular, avoid routine use of "postfix reload" from cron.

> Is there any way to force postfix to use one smtp process
> for each delivery so if one fail the others get delivered?

The premise if flawed, so the question is moot.  Postfix
uses multiple processes in parallel by default.

-- 
Viktor.

Re: Webmin with Postfix: recommended or not.

[Ron Wheeler]

On 27/03/2016 2:08 PM, Steve Jenkins wrote:
On Sat, Mar 26, 2016 at 3:48 PM, Tom Browder > wrote:


I am considering using Webmin on my servers and see that it has a
Postfix module. Does anyone have any experience with it or have an
opinion to offer ref its ability to manage Postfix?


Hi, Tom. I use Webmin for a few different tasks, and like it, but find 
the Postfix config files straightforward and so I've always edited 
them directly.


Which is all the Webmin module is going to do, as well. I can't see 
any harm to using it. I just think that it's quicker to edit the 
main.cf  and master.cf  files directly.


SteveJ

I have used Webmin for years including for Postfix.
You have the option of direct editing of the cf files with Webmin.
To me this is the best of both worlds.

A lot of the instructions for adding things and fixing things come as 
direct mods to the .cf files so you do need to be able to both.


Webmin makes it easy to add aliases and manage the queue.
It is also easy to look at individual mailboxes if there is a question 
about a particular user where the problem may be on the client side.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Cascade smtp delivery failure when one smtp fails

[Noel Jones]

On 3/28/2016 9:15 AM, Pedro David Marco wrote:
> Hello everybody!
> 
> it seems to me that when qmgr wants to deliver an email via smtp, qmgr 
> "assigns" it to a smtp process. As long as there are no
> concurrency needs, the same smtp process is used repeatedly even for 
> diferent domain destinations.
> Ok so far!
> 
> NOW, if one smtp process delivery takes long, long long... until it dies for 
> the watchdog timeout, all smtp 
> deliveries assigned to that smtp process fail! and qmgr send them back to 
> deferred queue
> 
> Is there any way to force postfix to use one smtp process for each delivery 
> so if one fail the others get delivered?
> 
> Thanks in advance!
> 
> David.
> 


It seems you have a problem with postfix, but your diagnosis and
proposed solution are wrong.

If you show your config and logs demonstrating the problem, maybe
someone can help you find a suitable solution.

Please see:
http://www.postfix.org/DEBUG_README.html#mail


  -- Noel Jones

Re: Cascade smtp delivery failure when one smtp fails

[Wietse Venema]

Pedro David Marco:
> NOW, if one smtp process delivery takes long, long long... until
> it dies for the watchdog timeout,

That's 18000s, or 5 hours (setting: daemon_timeout in main.cf).

If you still have not fixed the watchdog problem, you should not
be asking performance-related questions. Find out what is wrong
with your system, whether is is a crippled VPS or some other
environment with restrictive resource policies.

Wietse

Re: Webmin with Postfix: recommended or not.

[Robert Schetterer]

Am 26.03.2016 um 23:48 schrieb Tom Browder:
> I am considering using Webmin on my servers and see that it has a
> Postfix module. Does anyone have any experience with it or have an
> opinion to offer ref its ability to manage Postfix?
> 
> Thanks.
> 
> Best regards,

i used it on relays , and limited the funkcions of the module
to do very small changes on a few tables for total postfix ignorant
users, you shouldnt use it as a general config tool

> 
> -Tom



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Hardware with non-FQDN EHLO

[Curtis Villamizar]

In message <56f6c728.2090...@megan.vbhcs.org>
Noel Jones writes:
> 
> On 3/26/2016 7:18 AM, Nicols wrote:
> > Thanks Wietse and Rob,
> > 
> > The client indeed uses SASL, but it gets rejected at HELO/EHLO time.
> > I will observe these days if I can fence in a reduced CIDR range and
> > use Wietse's approach, if not, I'll set up a Postfix local to the
> > broken client, which indeed is a cleaner way than my original approach.
> > 
> > Thanks!
> > 
> > Nicols
> > 
>  
>  
> If the client uses SASL, all you need to do is put
> permit_sasl_authenticated before your reject_non_fqdn_helo_hostname.
>  
> No need for a CIDR table or any other workarounds.
>  
> smtpd_helo_restrictions =
>permit_mynetworks
>permit_sasl_authenticated
>reject_non_fqdn_helo_hostname
>... any other stuff...


On http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
permit_sasl_authenticated is not listed.

Which makes some sense since the HELO occurs before AUTH.  HELO checks
seem to be all IP and hostname related.

>   -- Noel Jones

Am I missing something?

Curtis

> > 
> >  Mensaje original 
> > De: wie...@porcupine.org
> > Fecha:25/03/2016 17:56 (GMT+00:00)
> > Para: Postfix users
> > Asunto: Re: Hardware with non-FQDN EHLO
> > 
> > Nicols:
> >> Hi,
> >>
> >> I have some hardware which I've configured to send e-mails through
> >> my Postfix server. Unfortunately, this hardware's firmware has
> >> its' EHLO command hardcoded, not being it an FQDN.
> >>
> >> In Postfix, I've configured smtpd_helo_restrictions to
> >> have?reject_non_fqdn_helo_hostname and I'm pretty happy with it
> >> so I don't want to remove it, however it makes its' attempts to
> >> get rejected. Another issue is that it's connections are made from
> >> a dynamic IP address, so whitelisting its IP address is not an
> >> option. However, it has a dynamic hostname which updates each time
> >> it changes (a DynDNS-like host).
> > 
> > Wrap the reject_non_fqdn_helo_hostname inside an access table:
> > 
> > smtpd_mumble_restrictions =
> > ...other stuff...
> > check_client_access cidr:/etc/postfix/reject_non_fqdn_helo.cidr
> > ...more stuff...
> > 
> > /etc/postfix/reject_non_fqdn_helo.cidr:
> >  # Unlike hash files, cidr files are matched in the order of rules.
> >  # IPv4
> >  1.2.3.4 dunno
> >  0.0.0.0/0  reject_non_fqdn_helo_hostname
> >  # IPv6
> >  1:2::3:4 dunno
> >  ::0/0  reject_non_fqdn_helo_hostname
> > 
> > It's a bit clumsy with the CIDR patterns, but hash-based access
> > maps don't have a wild-card pattern.
> > 
> > Wietse

Re: Hardware with non-FQDN EHLO

[Viktor Dukhovni]

On Mon, Mar 28, 2016 at 05:32:24PM -0400, Curtis Villamizar wrote:

> > No need for a CIDR table or any other workarounds.
> >  
> > smtpd_helo_restrictions =
> >permit_mynetworks
> >permit_sasl_authenticated
> >reject_non_fqdn_helo_hostname
> >... any other stuff...
> 
> 
> On http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
> permit_sasl_authenticated is not listed.
> 
> Which makes some sense since the HELO occurs before AUTH.  HELO checks
> seem to be all IP and hostname related.
> 
> Am I missing something?

http://www.postfix.org/postconf.5.html#smtpd_delay_reject

-- 
Viktor.

block all mail from mta's with a FQDN match?

[jasonsu]

Hi,

How would I match/block access to mail sent from MTAs that have FQDNs that 
start with

mta-wk-*

it's not a header, it's not content, it's not an IP ...

but, it's clearly logged in my postfix logs

postfix.log:Mar 24 13:00:42 mail2 postfix/int01/smtpd[20932]: connect 
from mta-wk-1.mk1.ratineer.com[82.196.0.148]
postfix.log:Mar 24 13:00:43 mail2 postfix/int01/smtpd[20932]: NOQUEUE: 
client=mta-wk-1.mk1.ratineer.com[82.196.0.148]
postfix.log:Mar 24 13:00:58 mail2 postfix/int01/smtpd[20932]: lost 
connection after RCPT from mta-wk-1.mk1.ratineer.com[82.196.0.148]
postfix.log:Mar 24 13:00:58 mail2 postfix/int01/smtpd[20932]: 
disconnect from mta-wk-1.mk1.ratineer.com[82.196.0.148] ehlo=1 mail=1 rcpt=1 
commands=3

My goal is to block ALL mail from this list of MTAs


https://groups.google.com/d/msg/news.admin.net-abuse.email/_6DLJB8fF9k/ZGBwTTsFBQAJ

DNSBLs get many of them, but they apparently change IP addresses, and sneak 
through on occasion.

All seem to be hosted by/at SYNAPP.IO

Thanks.

Re: block all mail from mta's with a FQDN match?

[/dev/rob0]

On Mon, Mar 28, 2016 at 02:53:41PM -0700, jaso...@mail-central.com wrote:
> How would I match/block access to mail sent from MTAs that have 
> FQDNs that start with
> 
> mta-wk-*
>
> it's not a header, it's not content, it's not an IP ...

It's a bird!  It's a plane!  It's ... a FCrDNS hostname!

> but, it's clearly logged in my postfix logs
> 
>   postfix.log:Mar 24 13:00:42 mail2 postfix/int01/smtpd[20932]: 
>   connect from mta-wk-1.mk1.ratineer.com[82.196.0.148]

See:

postconf.5.html#check_client_access
access.5.html
pcre_table.5.html (regexp_table(5) is another possibility)
SMTPD_ACCESS_README.html

All of the above can be found at www.postfix.org or in your own 
$html_directory.

Example:

/etc/postfix/banned_hostname.pcre :
/^mta-wk/   REJECT ratineer role call!

main.cf :

[ ... ]
smtpd_recipient_restrictions = [ ... ] reject_unauth_destination,
check_client_access pcre:/etc/postfix/banned_hostname.pcre
[ ... ]
[ ... ]

> My goal is to block ALL mail from this list of MTAs
> 
> 
> https://groups.google.com/d/msg/news.admin.net-abuse.email/_6DLJB8fF9k/ZGBwTTsFBQAJ
> 
> DNSBLs get many of them, but they apparently change IP addresses, 
> and sneak through on occasion.

And this approach won't work very long.  Once they know they're being 
blocked by that hostname pattern, they will morph.

> All seem to be hosted by/at SYNAPP.IO

If you can get a list of IP addresses (CIDR blocks), you can use a 
cidr_table(5) lookup to block them more safely and surely (until they 
buy/steal different hosting, of course.)
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: block all mail from mta's with a FQDN match?

[Bill Cole]

On 28 Mar 2016, at 17:53, jaso...@mail-central.com wrote:


Hi,

How would I match/block access to mail sent from MTAs that have FQDNs 
that start with


mta-wk-*

it's not a header, it's not content, it's not an IP ...


From the magical command "man 5 postconf" you can find this and many 
other valuable facts about configuring Postfix:


   check_client_access type:table
  Search the specified access database for  the  client  hostname,
  parent  domains,  client  IP  address,  or  networks obtained by
  stripping least significant octets.  See  the  access(5)  manual
  page for details.


I expect you can deduce similar informative incantations for 
pcre_table(5) or regexp_table(5) which will aid you in figuring out a 
complete answer.

Re: block all mail from mta's with a FQDN match?

[Viktor Dukhovni]

> On Mar 28, 2016, at 5:53 PM, jaso...@mail-central.com wrote:
> 
> How would I match/block access to mail sent from MTAs that have FQDNs that 
> start with
> 
>mta-wk-*
> 
> it's not a header, it's not content, it's not an IP ...
> 
> but, it's clearly logged in my postfix logs
> 
>   postfix.log:Mar 24 13:00:42 mail2 postfix/int01/smtpd[20932]: connect 
> from mta-wk-1.mk1.ratineer.com[82.196.0.148]

mta-wk-1.mk1.ratineer.com has address 82.196.0.148
mta-wk-1.mk2.ratineer.com has address 198.199.127.53
mta-wk-1.mk3.ratineer.com has address 198.211.125.202
mta-wk-2.mk1.ratineer.com has address 82.196.2.106
mta-wk-2.mk2.ratineer.com has address 82.196.0.108
mta-wk-2.mk3.ratineer.com has address 198.211.126.47
mta-wk-3.mk1.ratineer.com has address 82.196.2.62
mta-wk-3.mk2.ratineer.com has address 37.139.10.126
mta-wk-3.mk3.ratineer.com has address 198.211.119.74
mta-wk-4.mk1.ratineer.com has address 82.196.7.244
mta-wk-4.mk2.ratineer.com has address 82.196.0.161
mta-wk-4.mk3.ratineer.com has address 82.196.1.172
mta-wk-5.mk1.ratineer.com has address 82.196.7.81
mta-wk-5.mk2.ratineer.com has address 37.139.12.112
mta-wk-5.mk3.ratineer.com has address 82.196.9.12
mta-wk-6.mk1.ratineer.com has address 37.139.2.211
mta-wk-6.mk2.ratineer.com has address 198.211.125.249
mta-wk-6.mk3.ratineer.com has address 82.196.0.113
mta-wk-7.mk1.ratineer.com has address 37.139.3.68
mta-wk-7.mk2.ratineer.com has address 198.211.126.201
mta-wk-7.mk3.ratineer.com has address 82.196.0.124

ratineer.com.   600 IN  NS  kilmer-dns2.synapp.io

main.cf:
smtpd_client_restrictions =
check_ns_access pcre:${config_directory}/ns-access.pcre

smtpd_restriction_classes = no_mta_wk

no-mta-wk =
reject_unknown_client,
check_client_access pcre:${config_directory}/no-mta-wk.pcre

ns-access.pcre:
/\.synapp\.io$/ no_mta_wk

no-mta-wk.pcre:
/^mta-wk-\d/REJECT -Your reject message here-

-- 
Viktor.

Re: block all mail from mta's with a FQDN match?

[jasonsu]

On Mon, Mar 28, 2016, at 04:25 PM, Viktor Dukhovni wrote:
> ratineer.com.   600 IN  NS  kilmer-dns2.synapp.io
> 
> main.cf:
> smtpd_client_restrictions =
>   check_ns_access pcre:${config_directory}/ns-access.pcre
> 
> smtpd_restriction_classes = no_mta_wk
> 
> no-mta-wk =
>   reject_unknown_client,
>   check_client_access pcre:${config_directory}/no-mta-wk.pcre
> 
> ns-access.pcre:
> /\.synapp\.io$/   no_mta_wk
> 
> no-mta-wk.pcre:
> /^mta-wk-\d/  REJECT -Your reject message here-

well THAT'S pretty cool!

Thanks for the example -- learning something new about restriction classes!

Question about hyphen vs underscore --

In your example you use 

no-mta-wk =

IIUC, that's not referenced above.  Should that be

no_mta_wk =

?

Thanks.

Dot-prefixed subdomain behavior - possible bug

[Michael Fischer]

In Postfix 2.10, the default value of
$parent_domain_matches_subdomains changed from:

parent_domain_matches_subdomains =
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps

To:

parent_domain_matches_subdomains =
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,relay_domains,qmqpd_authorized_clients,smtpd_access_maps

(Note the addition of "relay_domains".)

Although this seemed like an innocuous change, it caused a temporary
outage for us after we upgraded from 2.9.1 to 2.10.

We have always used dot-prefix notation where necessary in our
$relay_domains list.  Specifically, we have listed ".example.com" in
our $relay_domains parameter in our inbound SMTP firewall for years.
But with the addition of "relay_domains" to this parameter upon
upgrade, Postfix suddenly began deferring email destined to
"sub.example.com" (denying relay) even though the dot-prefix was
already there!

The documentation for $parent_domain_matches_subdomains states:

> A list of Postfix features where the pattern "example.com" also matches 
> subdomains of example.com, instead of requiring an explicit ".example.com" 
> pattern. This is planned backwards compatibility: eventually, all Postfix 
> features are expected to require explicit ".example.com" style patterns when 
> you really want to match subdomains.

The documentation is vague about how Postfix behaves if the domain is
already dot-prefixed, but I think it's reasonable that doing so should
not change Postfix's behavior with respect to domain matching for
relaying purposes.

Does anyone disagree?  Otherwise this seems like a bug.  In the
meantime we've manually removed "relay_domains" from the list to
return to pre-2.10 behavior.

Best regards,

--Michael

Re: block all mail from mta's with a FQDN match?

[The Doctor]

On Mon, Mar 28, 2016 at 07:25:43PM -0400, Viktor Dukhovni wrote:
> 
> > On Mar 28, 2016, at 5:53 PM, jaso...@mail-central.com wrote:
> > 
> > How would I match/block access to mail sent from MTAs that have FQDNs that 
> > start with
> > 
> >mta-wk-*
> > 
> > it's not a header, it's not content, it's not an IP ...
> > 
> > but, it's clearly logged in my postfix logs
> > 
> > postfix.log:Mar 24 13:00:42 mail2 postfix/int01/smtpd[20932]: connect 
> > from mta-wk-1.mk1.ratineer.com[82.196.0.148]
> 
> mta-wk-1.mk1.ratineer.com has address 82.196.0.148
> mta-wk-1.mk2.ratineer.com has address 198.199.127.53
> mta-wk-1.mk3.ratineer.com has address 198.211.125.202
> mta-wk-2.mk1.ratineer.com has address 82.196.2.106
> mta-wk-2.mk2.ratineer.com has address 82.196.0.108
> mta-wk-2.mk3.ratineer.com has address 198.211.126.47
> mta-wk-3.mk1.ratineer.com has address 82.196.2.62
> mta-wk-3.mk2.ratineer.com has address 37.139.10.126
> mta-wk-3.mk3.ratineer.com has address 198.211.119.74
> mta-wk-4.mk1.ratineer.com has address 82.196.7.244
> mta-wk-4.mk2.ratineer.com has address 82.196.0.161
> mta-wk-4.mk3.ratineer.com has address 82.196.1.172
> mta-wk-5.mk1.ratineer.com has address 82.196.7.81
> mta-wk-5.mk2.ratineer.com has address 37.139.12.112
> mta-wk-5.mk3.ratineer.com has address 82.196.9.12
> mta-wk-6.mk1.ratineer.com has address 37.139.2.211
> mta-wk-6.mk2.ratineer.com has address 198.211.125.249
> mta-wk-6.mk3.ratineer.com has address 82.196.0.113
> mta-wk-7.mk1.ratineer.com has address 37.139.3.68
> mta-wk-7.mk2.ratineer.com has address 198.211.126.201
> mta-wk-7.mk3.ratineer.com has address 82.196.0.124
> 
> ratineer.com.   600 IN  NS  kilmer-dns2.synapp.io
> 
> main.cf:
> smtpd_client_restrictions =
>   check_ns_access pcre:${config_directory}/ns-access.pcre
> 
> smtpd_restriction_classes = no_mta_wk
> 
> no-mta-wk =
>   reject_unknown_client,
>   check_client_access pcre:${config_directory}/no-mta-wk.pcre
> 
> ns-access.pcre:
> /\.synapp\.io$/   no_mta_wk
> 
> no-mta-wk.pcre:
> /^mta-wk-\d/  REJECT -Your reject message here-
> 
> -- 
>   Viktor.


Then block on the following

82.196.0.0/16

37.139.0.0/16

198.211.0.0/16

198.199.127.0/24

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Manitoba and Saskatchewan! Save your provinces in April! Vote Liberal!!

Re: block all mail from mta's with a FQDN match?

[jasonsu]

> Then block on the following
> 
> 82.196.0.0/16
> 37.139.0.0/16
> 198.211.0.0/16
> 198.199.127.0/24

At this stage, that's harsh -- those are DigitalOcean blocks.  Not that I'm a 
fan of the 'flow' of email I see from them, but right now -- servers with NS @ 
synapp.io seems a good enough solution.

Re: block all mail from mta's with a FQDN match?

[Bill Cole]

On 28 Mar 2016, at 20:19, jaso...@mail-central.com wrote:


Then block on the following

82.196.0.0/16
37.139.0.0/16
198.211.0.0/16
198.199.127.0/24


At this stage, that's harsh -- those are DigitalOcean blocks.


No, they are not. The /16's are all PARTLY Digital Ocean, but each of 
them is split between many entirely different entities in /18-/22 pieces 
by RIPE and ARIN. None are in the traditional Class B range, so there's 
not even an obsolete reason to see them as /16 networks. The last is a 
single /24 out of a /18 allocated to DO, so thee's no rational pattern 
in that list...


Not that I'm a fan of the 'flow' of email I see from them, but right 
now -- servers with NS @ synapp.io seems a good enough solution.


Absolutely.

Re: block all mail from mta's with a FQDN match?

[jasonsu]

Viktor

On Mon, Mar 28, 2016, at 04:25 PM, Viktor Dukhovni wrote:
> main.cf:
> smtpd_client_restrictions =
>   check_ns_access pcre:${config_directory}/ns-access.pcre

I'm working on setting this up.

When I use your example, in my logs I see

  warning: unknown smtpd restriction: "check_ns_access"

In my main.cf I added

  smtpd_client_restrictions =
sleep 1,
permit_mynetworks
reject_unauth_pipelining
+   check_ns_access pcre:${config_directory}/ns_access.pcre

Checking

  postconf | grep ns_acc
smtpd_client_restrictions = sleep 1, permit_mynetworks 
reject_unauth_pipelining check_ns_access   
pcre:${config_directory}/ns_access.pcre

The config sees it.

So back to the docs.  But when I google on

  check_ns_access site:postfix.org

It just returns

  Your search - check_ns_access site:postfix.org - did not match any documents.

Sorry if I'm missing something obvious, but - where is this documented?

Re: block all mail from mta's with a FQDN match?

[Viktor Dukhovni]

On Mon, Mar 28, 2016 at 06:03:53PM -0700, jaso...@mail-central.com wrote:

> Viktor
> 
> On Mon, Mar 28, 2016, at 04:25 PM, Viktor Dukhovni wrote:
> > main.cf:
> > smtpd_client_restrictions =
> > check_ns_access pcre:${config_directory}/ns-access.pcre
> 
> I'm working on setting this up.
> 
> When I use your example, in my logs I see
> 
>   warning: unknown smtpd restriction: "check_ns_access"

Sorry, that's:

http://www.postfix.org/postconf.5.html#check_client_ns_access

And yes, the restriction class needs to be exactly the same when
defined as when it is used.  Go with "_" throughout.

-- 
Viktor.

Re: Dot-prefixed subdomain behavior - possible bug

[Viktor Dukhovni]

On Mon, Mar 28, 2016 at 04:52:04PM -0700, Michael Fischer wrote:

> In Postfix 2.10, the default value of
> $parent_domain_matches_subdomains changed from:
> 
> parent_domain_matches_subdomains =
> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps
> 
> To:
> 
> parent_domain_matches_subdomains =
> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,relay_domains,qmqpd_authorized_clients,smtpd_access_maps

No such change took place.

2009

   Feature: configurable parent domain matching strategy for
   transport map lookups. File:  trivial-rewrite/transport.c.

   New parent_domain_matches_subdomains parameter. This lists
   all the Postfix features where a domain name matches itself
   and all its subdomains (instead of requiring ".domain.name"
   for subdomain matches).  Planning for future backwards
   compatibility :-)  File:  global/match_parent_style.c.

Since 2001, the default has been:

 /*
  * Backwards compatibility: foo.com matches itself and names below foo.com.
  */
#define VAR_PAR_DOM_MATCH  "parent_domain_matches_subdomains"
#define DEF_PAR_DOM_MATCH  VAR_DEBUG_PEER_LIST "," \
   VAR_FFLUSH_DOMAINS "," \
   VAR_MYNETWORKS "," \
   VAR_PERM_MX_NETWORKS "," \
   VAR_QMQPD_CLIENTS "," \
   VAR_RELAY_DOMAINS "," \
   SMTPD_ACCESS_MAPS

> (Note the addition of "relay_domains".)

Sorry, that's simply not the case.

> Although this seemed like an innocuous change, it caused a temporary
> outage for us after we upgraded from 2.9.1 to 2.10.

Any change in your configuration is not the result of upstream
changes in Postfix.  The "relay_domains" element is still there
even in 3.2 snapshots.

$ postconf -d mail_version parent_domain_matches_subdomains
mail_version = 3.2-20160314
parent_domain_matches_subdomains = 
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps

-- 
Viktor.