|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: .sub.domain matching problem in client_access
From: Michael Tokarev (mjt
tls.msk.ru)
Date: Tue Jul 13 2004 - 17:33:30 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
James Garrison wrote:
[]
> useful. One question: If I read the access(5) man page
> correctly, I only need parent_domain_matches_subdomains
> if I want a domain _without_ a leading period to match
> subdomains. Here's the relevant text from the postfix
> website:
>
>> The pattern domain.tld also matches subdomains, but
>> only when the string smtpd_access_maps is listed in
>> the Postfix parent_domain_matches_subdomains con-
>> figuration setting (note that this is the default
>> for some versions of Postfix). Otherwise, specify
>> .domain.tld (note the initial dot) in order to
>> match subdomains.
>
> This seems to indicate that, with the initial dot, it
> will automatically match subdomains but without the initial
> dot I must also specify parent_domain_matches_subdomains
> if I want subdomains to match. Thus by specifying the
> entry as .biz.rr.com I was expecting it to match
> subdomains without needin parent_domain_matches_subdomains
> Am I reading this incorrectly?
>
To make some sense of this whole awful thread, finally... ;)
In short, when parent_domain_matches_subdomains is ON in a
given scope (e.g. in smtpd access maps, when $p.d.m.s includes
smtpd_access_maps), postfix perform the following searches
for foo.example.com:
foo.example.com
example.com
com
if either of that is found, search will stop. But when
p.d.m.s is OFF, postfix performs the following lookups:
foo.example.com
.example.com
.com
Nothing more, nothing less.
In particular, specifying .example.com (with leading dot)
when p.d.m.s is ON is useless, as postfix will never look
at it. Whenever this is the right thing or not may be
questionable, but i think current behaviour is ok, as else
postfix will be doing too many lookups (two lookups for
every subdomain, one with and one w/o the leading dot --
think of e.g. LDAP maps). Also, when you turn the p.d.m.s
off, as it should be (NOT the default due to backwards
compatibility), you're free to specify exact domains or
subdomains you want to. Yes, with p.d.m.s off, you have
to list both example.com AND .example.com to match the
domain and it's subdomains, instead of one, but at least
it gives you more control.
The whole this mess is due to backwards compatibility.
When the problem has been pointed out (classical example
I had here: one ISP had their dialup pools named as
host-1-2-3-4.dialup.ptt.ru, and their outgoing mail
relay named dialup.ptt.ru - not a smart move but c'est
la vie), it was too late to change things, as many
users already relied on the p.d.m.s=ON behaviour. There
are several problems with default behaviour, one to
note is relay_domains, and especially (now obsoleted)
check_relay_domains (which accepted mails from HOSTS
who's rDNS is any subdomain of $relay_domains). Note
also transport_maps always worked with p.d.m.s=OFF,
so with p.d.m.s being empty string, all maps will
behave similarily.
Yes, the documentation IS (somewhat) confusing, even
for native English speaker (I'm not). Better wording
is welcome. But it is all due the p.d.m.s feature
itself: it IS confusing/misleading enouth by it's own,
and explaining a misleading feature is difficult
(one of tests for a feature: if it's difficult or
impossible to describe it cleanly, it is probably
wrong). Nothing can be changed (see above -- backward
compatibility), so we're stuck with it (for a while
at least).
/mjt
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]