Re: serious bug with check_client_access

[Покотиленко Костик]

В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:
> On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
> > On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
> >> ".domain.tld" only works if parent_domain_matches_subdomains does NOT
> >> include smtpd_access maps.
> >
> > The man page says nothing like that. So, the documentation should be
> > fixed.
> >
> 
> The vast majority of readers seem to interpret that section as 
> intended.  You're welcome to post a documentation patch in a 
> new thread, but I don't think the behavior or its 
> documentation has changed in ~10 years, so don't hold your breath.

Vast majority even believe in strange things...

Actually I read that section exactly like Vincent Lefevre.

I'll comment:

> The access(5) man page says:
>
>   domain.tld
>Matches domain.tld.
>
>The  pattern  domain.tld also matches subdomains, but only
>when the string smtpd_access_maps is listed in the Postfix
>parent_domain_matches_subdomains   configuration  setting.
>Otherwise, specify .domain.tld (note the initial  dot)  in
>order to match subdomains.

I read "Otherwise" as "If you don't like to depend on the value of
parent_domain_matches_subdomains"

"specify .domain.tld (note the initial  dot) in order to match
subdomains" means exactly that using ".domain.tld" form WILL match
subdomains with no other condition.

Also regarding to what you are telling there is no difference in those
two sentences, and it's completelly unclear in what those two notation
forms differ and why author has written one idea in two sentences.

Check your English ;)

> And next time behavior doesn't match your expectations, you 
> might get more sympathy if your message starts with "please 
> clarify this for me" rather than "serious bug".

If behavior doesn't match your expectations and also doesn't match docs
it's a bug, either in soft or in docs.

-- 
Покотиленко Костик 

Re: serious bug with check_client_access

[Emmanuel Fusté]

Le 04/11/2010 05:24, Noel Jones a écrit :

On 11/3/2010 11:07 PM, Vincent Lefevre wrote:

BTW, so, there is no way to match only subdomains (by that, I mean
all possible subdomains, but not the domain itself) without changing
parent_domain_matches_subdomains?


That's correct with indexed tables.  With regexp or pcre tables there
is no automatic subdomain search; you control the scope of the search
with your expression.

To answer your other question, when parent_domain_matches_subdomains
includes smtpd_access_maps (the default), the form ".domain.tld" is
never searched for. As a result, the entry is silently ignored.

  -- Noel Jones

Good to know, that is not what I expected too.
Hopefully, I generaly clear parent_domain_matches_subdomains in my 
configurations.


Emmanuel.

Re: serious bug with check_client_access

[lst_hoe02]

Zitat von Покотиленко Костик :


В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:

On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
> On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
>> ".domain.tld" only works if parent_domain_matches_subdomains does NOT
>> include smtpd_access maps.
>
> The man page says nothing like that. So, the documentation should be
> fixed.
>

The vast majority of readers seem to interpret that section as
intended.  You're welcome to post a documentation patch in a
new thread, but I don't think the behavior or its
documentation has changed in ~10 years, so don't hold your breath.


Vast majority even believe in strange things...

Actually I read that section exactly like Vincent Lefevre.

I'll comment:


The access(5) man page says:

  domain.tld
   Matches domain.tld.

   The  pattern  domain.tld also matches subdomains, but only
   when the string smtpd_access_maps is listed in the Postfix
   parent_domain_matches_subdomains   configuration  setting.
   Otherwise, specify .domain.tld (note the initial  dot)  in
   order to match subdomains.


I read "Otherwise" as "If you don't like to depend on the value of
parent_domain_matches_subdomains"


"Otherwise" is clearly related to the last part of the previous  
statement. If it is unclear, ask for clarification. Crying loud  
"serious bug" because your language interpretation is different from  
others is not helpful at all.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: serious bug with check_client_access

[Покотиленко Костик]

В Чтв, 04/11/2010 в 10:44 +0100, lst_ho...@kwsoft.de пишет:
> Zitat von Покотиленко Костик :
> 
> > В Срд, 03/11/2010 в 22:16 -0500, Noel Jones пишет:
> >> On 11/3/2010 10:00 PM, Vincent Lefevre wrote:
> >> > On 2010-11-03 21:40:54 -0500, Noel Jones wrote:
> >> >> ".domain.tld" only works if parent_domain_matches_subdomains does NOT
> >> >> include smtpd_access maps.
> >> >
> >> > The man page says nothing like that. So, the documentation should be
> >> > fixed.
> >> >
> >>
> >> The vast majority of readers seem to interpret that section as
> >> intended.  You're welcome to post a documentation patch in a
> >> new thread, but I don't think the behavior or its
> >> documentation has changed in ~10 years, so don't hold your breath.
> >
> > Vast majority even believe in strange things...
> >
> > Actually I read that section exactly like Vincent Lefevre.
> >
> > I'll comment:
> >
> >> The access(5) man page says:
> >>
> >>   domain.tld
> >>Matches domain.tld.
> >>
> >>The  pattern  domain.tld also matches subdomains, but only
> >>when the string smtpd_access_maps is listed in the Postfix
> >>parent_domain_matches_subdomains   configuration  setting.
> >>Otherwise, specify .domain.tld (note the initial  dot)  in
> >>order to match subdomains.
> >
> > I read "Otherwise" as "If you don't like to depend on the value of
> > parent_domain_matches_subdomains"
> 
> "Otherwise" is clearly related to the last part of the previous  
> statement. If it is unclear, ask for clarification.

Actually it's not clear to what condition the "Otherwise" is a conter
part. So it's being decided by a reader's logic wich differs sometimes.

I'm myself understood the actual meaning only after clarification on
this list. And, pleople would ask for clarification only if they can't
understand what is being ment, and not in case they think they
unsterstand.

Also, it's completelly unstated that ".domain.tld" notation doesn't work
if smtpd_access_maps is listed in parent_domain_matches_subdomains.

>  Crying loud  
> "serious bug" because your language interpretation is different from  
> others is not helpful at all.

List subscriber classified this situation as a "serious bug" from it's
point of view, and I think this is correct. If you don't agree, just
reclassify it.

BTW, clear docs save much time for both, the user, the list.

So, I suggest rewritiing this paragraph as following:

The  pattern  domain.tld also matches subdomains, but only
when the string smtpd_access_maps is listed in the Postfix
parent_domain_matches_subdomains   configuration  setting.
The  pattern .domain.tld (note the initial  dot) matches
only subdomains and only when the string
smtpd_access_maps is NOT listed in the Postfix
parent_domain_matches_subdomains configuration setting,
otherwise it's ignored.

Is this correct?

-- 
Покотиленко Костик 

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
> >>The access(5) man page says:
> >>
> >>  domain.tld
> >>   Matches domain.tld.
> >>
> >>   The  pattern  domain.tld also matches subdomains, but only
> >>   when the string smtpd_access_maps is listed in the Postfix
> >>   parent_domain_matches_subdomains   configuration  setting.
> >>   Otherwise, specify .domain.tld (note the initial  dot)  in
> >>   order to match subdomains.
> >
> >I read "Otherwise" as "If you don't like to depend on the value of
> >parent_domain_matches_subdomains"
> 
> "Otherwise" is clearly related to the last part of the previous statement.

Yes, but it adds information in the case where smtpd_access_maps IS NOT
listed in the Postfix parent_domain_matches_subdomains configuration
setting.

The problem occurs when smtpd_access_maps IS listed in the Postfix
parent_domain_matches_subdomains configuration setting. What the
man page says in THIS case is: "The pattern domain.tld also matches
subdomains" where the pattern domain.tld can be ".twitter.com" for
instance.

I don't think there is anything wrong with my reasoning.

> If it is unclear, ask for clarification. Crying loud "serious bug"
> because your language interpretation is different from others is not
> helpful at all.

As for me, the documentation was clear and didn't match the observed
behavior. So, I couldn't say that it was unclear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Well, everyone else using dnswl.org say bye bye to "opensource" usage.

[Stan Hoeppner]

Jerrale G put forth on 11/4/2010 4:54 AM:

> you know, they could have made a premium service or addition to offset
> overhead and generate revenue while having the white and blacklists as a
> free service. This means that spamassassin's accuracy, and opensource,
> will reduce as well. I guess Im going to have to consider dspam even
> more now.

You're spouting off half cocked.  from:  http://www.dnswl.org/


What does it cost?

Access for non-commercial use is free through the public nameservers.

Users with more than 100'000 queries per day on the public nameservers
must purchase a subscription for rsync download. The same applies to
companies selling anti-spam services. See the license for details.



I'm assuming you fall into the non-commercial free category.  The only
thing that has changed for free users is the access method.  You can no
longer use rsync, which does screw some Postfix users who aren't using a
third party daemon that can query the dnswl zone servers.

Be glad it's still free and that you simply have to add some software to
your system to make it work again.  If I may say so, it seems you're
being a bit demanding, like they owe you something, given the fact
they're kind enough to have offered you a free service for so long, and
still do.

-- 
Stan

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[Larry Stone]

On 11/4/10 5:46 AM, Stan Hoeppner at s...@hardwarefreak.com wrote:

> Jerrale G put forth on 11/4/2010 4:54 AM:
> 
>> you know, they could have made a premium service or addition to offset
>> overhead and generate revenue while having the white and blacklists as a
>> free service. This means that spamassassin's accuracy, and opensource,
>> will reduce as well. I guess Im going to have to consider dspam even
>> more now.
> 
> You're spouting off half cocked.  from:  http://www.dnswl.org/
> 
> 
> What does it cost?
> 
> Access for non-commercial use is free through the public nameservers.
> 
> Users with more than 100'000 queries per day on the public nameservers
> must purchase a subscription for rsync download. The same applies to
> companies selling anti-spam services. See the license for details.
> 
> 
> 
> I'm assuming you fall into the non-commercial free category.  The only
> thing that has changed for free users is the access method.  You can no
> longer use rsync, which does screw some Postfix users who aren't using a
> third party daemon that can query the dnswl zone servers.

Exactly. Access of a DNS based whitelist is not natively supported by
Postfix. 
 
> Be glad it's still free and that you simply have to add some software to
> your system to make it work again.

Care to provide some pointers to such software? Or do you just assume we all
have the adequate level of expertise and time to do it ourselves.

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[Ronald MacDonald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 4 Nov 2010, at 11:54, Larry Stone wrote:

>> 
>> Be glad it's still free and that you simply have to add some software to
>> your system to make it work again.
> 
> Care to provide some pointers to such software? Or do you just assume we all
> have the adequate level of expertise and time to do it ourselves.


It's all on the web site. http://www.dnswl.org/



Ronald MacDonald : ron...@rmacd.com

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAkzSobUACgkQg+87crce7IM/DwCfQfC6y3lzaG1bmzy7rFU7fudP
skcAnjU2Z1Jbb3UFod0aSrtMRmm2wbo5
=w8oq
-END PGP SIGNATURE-

multiple instance question

[Ralf Hildebrandt]

I want to duplicate a existing postfix instance (master.cf / main.cf /
all maps), all I want to change is the queue_directory and no smtpd
should be listening.

What's the easiest way to do this?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[Larry Stone]

On 11/4/10 7:06 AM, Ronald MacDonald at ron...@rmacd.com wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> On 4 Nov 2010, at 11:54, Larry Stone wrote:
> 
>>> 
>>> Be glad it's still free and that you simply have to add some software to
>>> your system to make it work again.
>> 
>> Care to provide some pointers to such software? Or do you just assume we all
>> have the adequate level of expertise and time to do it ourselves.
> 
> 
> It's all on the web site. http://www.dnswl.org/

Care to provide more than just a link to the top level of their web site.
I've looked and all I've found is instructions on how to integrate the soon
to be no longer available for free rsync'd files into Postfix.

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Documentation (was: serious bug with check_client_access)

[Wietse Venema]

Vincent Lefevre:
> On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
> > >>The access(5) man page says:
> > >>
> > >>  domain.tld
> > >>   Matches domain.tld.
> > >>
> > >>   The  pattern  domain.tld also matches subdomains, but only
> > >>   when the string smtpd_access_maps is listed in the Postfix
> > >>   parent_domain_matches_subdomains   configuration  setting.
> > >>   Otherwise, specify .domain.tld (note the initial  dot)  in
> > >>   order to match subdomains.

I can replace that "Otherwise..." sentence by a separate list item.

   domain.tld
  Matches domain.tld.

  The pattern domain.tld also matches subdomains, but only
  when the string smtpd_access_maps is listed in the Postfix
  parent_domain_matches_subdomains configuration setting.

   .domain.tld
  Matches subdomains of domain.tld, but only when the
  string smtpd_access_maps is not listed in the Postfix
  parent_domain_matches_subdomains configuration setting.

We can afford the space used by the extra bits.

Wietse

Re: multiple instance question

[Victor Duchovni]

On Thu, Nov 04, 2010 at 01:47:59PM +0100, Ralf Hildebrandt wrote:

> I want to duplicate a existing postfix instance (master.cf / main.cf /
> all maps), all I want to change is the queue_directory and no smtpd
> should be listening.
> 
> What's the easiest way to do this?

# set -e
#
# newname=postfix-newname
# postmulti -I $newname -e create
# newcfdir=$(postmulti -i $newname -l | awk '{print $4}')
# newqdir=$(postmulti -i $newname -x postconf queue_directory)
# newddir=$(postmulti -i $newname -x postconf data_directory)
#
# cd $oldcfdir
# oldname=postfix-oldname
# oldcfdir=$(postmulti -i $oldname -l | awk '{print $4}')
# (cd $oldcfdir; find . ! -name 'main.cf' -print0 | cpio -0pd $newcfdir)
# mkdir -m 0755 $newcfdir/tmpcf; cp -p $oldcfdir/main.cf $newcfdir/tmpcf/.
# postconf -c $newcfdir/tmpcf -e \
"multi_instance_name = $newname" \
"queue_directory = $newqdir" \
"data_directory = $newddir" \
"master_service_disable = inet"
# mv $newcfdir/tmpcf/main.cf $newcfdir
#
# postmulti -i $newname -p start

-- 
Viktor.

Re: Documentation (was: serious bug with check_client_access)

[/dev/rob0]

On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote:
> Vincent Lefevre:
> > On 2010-11-04 10:44:34 +0100, lst_ho...@kwsoft.de wrote:
> > > >>The access(5) man page says:
> > > >>
> > > >>  domain.tld
> > > >>   Matches domain.tld.
> > > >>
> > > >>   The  pattern  domain.tld also matches subdomains, but only
> > > >>   when the string smtpd_access_maps is listed in the Postfix
> > > >>   parent_domain_matches_subdomains   configuration  setting.
> > > >>   Otherwise, specify .domain.tld (note the initial  dot)  in
> > > >>   order to match subdomains.
> 
> I can replace that "Otherwise..." sentence by a separate list item.
> 
>domain.tld
>   Matches domain.tld.
> 
> The pattern domain.tld also matches subdomains, but only
> when the string smtpd_access_maps is listed in the Postfix
> parent_domain_matches_subdomains configuration setting.
> 
>.domain.tld
> Matches subdomains of domain.tld, but only when the
> string smtpd_access_maps is not listed in the Postfix
> parent_domain_matches_subdomains configuration setting.

I like this. I think it's clearer. I, too, once misinterpreted this 
passage, and whilst it might not qualify as a postfix-users FAQ, it 
does come up regularly here.

Perhaps some more flesh could be added here as well:

parent_domain_matches_subdomains (default: see postconf -d output)
   What  Postfix  features match subdomains of "domain.tld" 
   automatically, instead of requiring an explicit ".domain.tld" 
   pattern.  This is planned backwards compatibility:  
   eventually, all Postfix features are expected to require 
   explicit ".domain.tld" style patterns when you really want to
   match subdomains.

Such as:
"
   Possible strings include debug_peer_list, fast_flush_domains, 
   mynetworks, permit_mx_backup_networks, qmqpd_authorized_clients,
   relay_domains, and smtpd_access_maps.

   Note: the leading dot ".domain.tld" pattern is ignored for
   features which are listed in parent_domain_matches_subdomains.
"

The string list is taken from my own postconf -d, are there others 
which might be used in some cases? I guess all of those except 
smtpd_access_maps would be hyperlinked; and maybe that could link to 
access.5.html.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[/dev/rob0]

On Thu, Nov 04, 2010 at 06:54:05AM -0500, Larry Stone wrote:
> On 11/4/10 5:46 AM, Stan Hoeppner at s...@hardwarefreak.com wrote:
> > Be glad it's still free and that you simply have to add some 
> > software to your system to make it work again.
> 
> Care to provide some pointers to such software? Or do you just 
> assume we all have the adequate level of expertise and time to
> do it ourselves.

That assumption, on the postfix-users mailing list, seems well- 
founded to me. I suggest, if you lack the time and expertise, that 
you reconsider your decision to host your own email. Running a mail 
server is not a trivial task.

Google is your friend. In recent months there has been discussion 
here regarding possible implementations of DNSWL for Postfix, and 
that discussion also mentioned alternatives (policy servers.)
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Documentation (was: serious bug with check_client_access)

[Vincent Lefevre]

On 2010-11-04 10:28:00 -0500, /dev/rob0 wrote:
> On Thu, Nov 04, 2010 at 10:56:57AM -0400, Wietse Venema wrote:
> > I can replace that "Otherwise..." sentence by a separate list item.
> > 
> >domain.tld
> >   Matches domain.tld.
> > 
> >   The pattern domain.tld also matches subdomains, but only
> >   when the string smtpd_access_maps is listed in the Postfix
> >   parent_domain_matches_subdomains configuration setting.
> > 
> >.domain.tld
> >   Matches subdomains of domain.tld, but only when the
> >   string smtpd_access_maps is not listed in the Postfix
> >   parent_domain_matches_subdomains configuration setting.
> 
> I like this. I think it's clearer. I, too, once misinterpreted this 
> passage, and whilst it might not qualify as a postfix-users FAQ, it 
> does come up regularly here.

I still think that it's a bit ambiguous, because I was seeing
".domain.tld" as a subcase of "domain.tld" ("domain" being a
sequence of allowed characters including dots). Correct me if
I'm wrong (I haven't tested and don't know what postfix does
internally), but would changing the beginning by

domain.tld
   Matches domain.tld, where "domain" may contain dots, but
   must not start with a dot.

be what is really intended?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[mouss]

Le 04/11/2010 13:53, Larry Stone a écrit :

On 11/4/10 7:06 AM, Ronald MacDonald at ron...@rmacd.com wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 4 Nov 2010, at 11:54, Larry Stone wrote:


Be glad it's still free and that you simply have to add some software to
your system to make it work again.

Care to provide some pointers to such software? Or do you just assume we all
have the adequate level of expertise and time to do it ourselves.


It's all on the web site. http://www.dnswl.org/

Care to provide more than just a link to the top level of their web site.
I've looked and all I've found is instructions on how to integrate the soon
to be no longer available for free rsync'd files into Postfix.



1- visit http://www.postfix.org/addon.html
2- scroll to http://www.postfix.org/addon.html#policy
3- read the description for the cited policy services
4- once you prune "specific" policy services (for example: greylisting 
servers), you'll have a short list

5- visit their page...
6- at some time, you'll end up reading about http://postfwd.org/
7- search for "dns whitelist" on that page. yo'ull find it is supported
8- go to the example link: http://postfwd.org/example-cfg.txt
9- search for "dnswl". ah, so it is supported!

is that detailed enough? :)



I don't see any such instructions on dnswl.org. however, 
http://postfwd.org/ supports dns whitelists. see the example on 
http://postfwd.org/example-cfg.txt.

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[Larry Stone]

On Thu, 4 Nov 2010, /dev/rob0 wrote:


On Thu, Nov 04, 2010 at 06:54:05AM -0500, Larry Stone wrote:

On 11/4/10 5:46 AM, Stan Hoeppner at s...@hardwarefreak.com wrote:

Be glad it's still free and that you simply have to add some
software to your system to make it work again.


Care to provide some pointers to such software? Or do you just
assume we all have the adequate level of expertise and time to
do it ourselves.


That assumption, on the postfix-users mailing list, seems well-
founded to me. I suggest, if you lack the time and expertise, that
you reconsider your decision to host your own email. Running a mail
server is not a trivial task.


Expertise to implement a policy server? I agree. Write one from scratch? I 
disagree. I do agree running a mail server is not trivial but disagree 
that hard-core programming skills should be a prequisite.



Google is your friend. In recent months there has been discussion
here regarding possible implementations of DNSWL for Postfix, and
that discussion also mentioned alternatives (policy servers.)


However, I do think one of the problems with this list (which I have been 
following for a couple of years) is a tendency for the cognescenti to 
reply with less than helpful things like "it's documented" or "Google is 
your friend" (I did and nothing useful came up - perhaps bad search 
terms). And, since I've been using DNSWL for awhile, I definitely would 
have been interested in a discussion related to alternatives for using 
their lists and recall nothing in the last few months (there was a 
discussion in September of their file format but I recall nothing there 
about implementing a policy-server).


While there are people who come to lists like this having done no research 
on their own, there are also many of us who try to find their own 
solutions first so when we post, responses that translate to "find it 
yourself" (which is what responses like "it's documented" or "Google is 
your friend mean) are entirely non-helpful.


And consider the other big discussion of today where there is piece of 
documentation that some people find entirely clear while others see it as 
entirely confusing (put me in the confused camp). What's obvious to you 
isn't obvious to everyone.


-- Larry Stone
   lston...@stonejongleux.com

Re: serious bug with check_client_access

[mouss]

Le 04/11/2010 05:07, Vincent Lefevre a écrit :

On 2010-11-03 22:55:59 -0500, Noel Jones wrote:

I'm so sorry you lost your twitter post.

Actually I might have lost other mail (though this is a bit unlikely)
since I was generally using an initial dot.


a good idea is to include both dotted and undotted entries:
example.comOK
.example.comOK
unless you have a reason not to do so.

if you search the archives for posts I've sent, you'll see that I always 
include both.


also, parent_domain_... is deprecated. See
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains

The recommendation is to empty it and use dots explicitely. here:
# postconf parent_domain_matches_subdomains
parent_domain_matches_subdomains =



The access map format you're looking for is
twitter.com  OK

Thanks for the information. I've corrected the whole access file.

BTW, so, there is no way to match only subdomains (by that, I mean
all possible subdomains, but not the domain itself) without changing
parent_domain_matches_subdomains?



see above: it is recommended not to rely on parent_domain_...

otherwise, you can do whatever you want with pcre:
/\.example\.com$/OK
or with sql or ldap.



I don't currently need such a feature, but I'm asking just in case...

THREAD KILLED: Documentation (was: serious bug with check_client_access)

[Victor Duchovni]

On Thu, Nov 04, 2010 at 05:02:25PM +0100, Vincent Lefevre wrote:

> I still think that it's a bit ambiguous, because I was seeing
> ".domain.tld" as a subcase of "domain.tld"

This objection is spurious, and constitutes trolling. Please do not feed
the trolls.

For the record, elementary logic:

If there are two cases:

domain.tld

and

.domain.tld

and the documentation is not deliberately obfuscated, then the two
cases are distinct. This is clear enough.

The current informal style is more readable. There is no need for
a BNF grammar.

However, there is no point in continuing this thread. The OP has consumed
all the bandwidth he deserves and more.

-- 
Viktor.

is there a way to tell postfix not to perform reverse lookup on the received header?

[Joe Wong]

Hello,


Postfix write the Received header like this:


Received: from HELO.HOSTNAME (*HOSTNAME_OF_CONNECTING_IP* [CONNECTING_IP])
 by HOSTNAME_OF_POSTFIX (Postfix) with SMTP id 0ABBCCDDEE
 for >; Wed,  1 Nov 2010
00:00:00 + (GMT)

is there a way to tell postfix not to write the HOSTNAME_OF_CONNECTING_IP,
or disable the reverse DNS lookup so that is always 'unknown' ?

Best regards,

- Joe

Re: is there a way to tell postfix not to perform reverse lookup on the received header?

[Victor Duchovni]

On Fri, Nov 05, 2010 at 12:25:21AM +0800, Joe Wong wrote:

> is there a way to tell postfix not to write the HOSTNAME_OF_CONNECTING_IP,
> or disable the reverse DNS lookup so that is always 'unknown' ?

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

-- 
Viktor.

Re: is there a way to tell postfix not to perform reverse lookup on the received header?

[Noel Jones]

On 11/4/2010 11:25 AM, Joe Wong wrote:

Hello,


Postfix write the Received header like this:


Received: from HELO.HOSTNAME (*HOSTNAME_OF_CONNECTING_IP*
[CONNECTING_IP])
  by HOSTNAME_OF_POSTFIX (Postfix) with SMTP id 0ABBCCDDEE
  for mailto:chant...@hk1.ibm.com>>; Wed,  1 Nov 2010 00:00:00
+ (GMT)

is there a way to tell postfix not to write the
HOSTNAME_OF_CONNECTING_IP, or disable the reverse DNS lookup
so that is always 'unknown' ?

Best regards,

- Joe




To disable the lookup, see:
http://www.postfix.org/postconf.5.html#smtpd_peername_lookup

Caution: setting this to "no" causes postfix to treat all 
clients as "unknown".  As a result, name-based 
check_client_access tables will not work, and if you use 
reject_unknown_client_hostname or 
reject_unknown_reverse_client_hostname they will reject every 
connection as "unknown".



If you only want to suppress the header, you can use a 
header_check that matches the offending header with an action 
of IGNORE or REPLACE.

http://www.postfix.org/header_checks.5.html


  -- Noel Jones

Re: is there a way to tell postfix not to perform reverse lookup on the received header?

[Joe Wong]

Thanks Viktor. I miss this one when reading the man page.. :)


On Fri, Nov 5, 2010 at 12:42 AM, Victor Duchovni <
victor.ducho...@morganstanley.com> wrote:

> On Fri, Nov 05, 2010 at 12:25:21AM +0800, Joe Wong wrote:
>
> > is there a way to tell postfix not to write the
> HOSTNAME_OF_CONNECTING_IP,
> > or disable the reverse DNS lookup so that is always 'unknown' ?
>
> http://www.postfix.org/postconf.5.html#smtpd_peername_lookup
>
> --
>Viktor.
>

Re: is there a way to tell postfix not to perform reverse lookup on the received header?

[mouss]

Le 04/11/2010 17:45, Joe Wong a écrit :

Thanks Viktor. I miss this one when reading the man page.. :)


note that if your goal is to hide private information, then you should 
use header_checks instead of disabling reverse DNS lookup.


header_checks = pcre:/etc/postfix/header_checks.pcre

== header_checks.pcre:

/^(Received: from myhelo\.example\.com) \(\S+\.private\.local( 
\[10\..*)/REPLACE $1 (unknown $2


the above will replace "*.private.local" by "unknown".






On Fri, Nov 5, 2010 at 12:42 AM, Victor Duchovni 
> wrote:


On Fri, Nov 05, 2010 at 12:25:21AM +0800, Joe Wong wrote:

> is there a way to tell postfix not to write the
HOSTNAME_OF_CONNECTING_IP,
> or disable the reverse DNS lookup so that is always 'unknown' ?

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

--
   Viktor.

SPF enforcement opinions?

[Robert Fitzpatrick]

I have SPF setup and Postfix is rejecting mail from explicitly 
unauthorized servers. If a customer wants me to customize the 
configuration so that they can receive mail from that server, is that 
wrong? Their current SPF TXT record contains a hard fail as ...


"v=spf1 a mx ptr -all"

--Robert

Re: SPF enforcement opinions?

[Randy Ramsdell]

Robert Fitzpatrick wrote:
I have SPF setup and Postfix is rejecting mail from explicitly 
unauthorized servers. If a customer wants me to customize the 
configuration so that they can receive mail from that server, is that 
wrong? Their current SPF TXT record contains a hard fail as ...


"v=spf1 a mx ptr -all"

--Robert


I say, the customer gets what they want.

Re: SPF enforcement opinions?

[Will Fong]

On Nov 4, 2010, at 2:12 PM, Robert Fitzpatrick wrote:

> I have SPF setup and Postfix is rejecting mail from explicitly unauthorized 
> servers. If a customer wants me to customize the configuration so that they 
> can receive mail from that server, is that wrong? Their current SPF TXT 
> record contains a hard fail as ...
> 
> "v=spf1 a mx ptr -all"
> 
> --Robert

I wouldn't reject messages that fail SPF or any other authentication 
technologies, like DK/DKIM. They aren't perfect and could be totally 
legitimate. You can Google to find the specific cases where they fail. 

What you might want to consider is do extra spam checks for those messages that 
fail.

HTH,

-will

cidr table performance

[Stan Hoeppner]

What's the CIDR lookup table performance difference between say 256 /32
entries and a single /24 entry?  Is it 256:1?  Or, how about 90,000 /32
entries vs 60,000 entries that consolidate many of those 90,000 /32s
into larger CIDRs such as /24s and /21s etc?  I have no idea what the
total processing time would be on such size CIDRs.  Is it small enough
to be irrelevant, or are we looking at something like multiple seconds
per lookup (obviously dependent on hardware)?

Thanks.

-- 
Stan

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-04 17:18:17 +0100, mouss wrote:
> otherwise, you can do whatever you want with pcre:
> /\.example\.com$/OK
> or with sql or ldap.

For pcre, the man page is not clear. It says:

  Each  pattern  is  a  regular  expression that is applied to the entire
  string being looked up. Depending on the application, that string is an
  entire  client hostname, an entire client IP address, or an entire mail
  address.

But where is it described whether the string is an entire client
hostname, an entire client IP address, or an entire mail address?

According to your example, the string is an entire client hostname.
But then, this means that one cannot match IP addresses.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

[Stan Hoeppner]

Vincent Lefevre put forth on 11/4/2010 6:04 PM:
> On 2010-11-04 17:18:17 +0100, mouss wrote:
>> otherwise, you can do whatever you want with pcre:
>> /\.example\.com$/OK
>> or with sql or ldap.
> 
> For pcre, the man page is not clear. It says:
> 
>   Each  pattern  is  a  regular  expression that is applied to the entire
>   string being looked up. Depending on the application, that string is an
>   entire  client hostname, an entire client IP address, or an entire mail
>   address.
> 
> But where is it described whether the string is an entire client
> hostname, an entire client IP address, or an entire mail address?

check_client_access pcre:/etc/postfix/filter.pcre
check_sender_access pcre:/etc/postfix/filter.pcre
check_recipient_access  pcre:/etc/postfix/filter.pcre

As you can see, this is defined by the smtpd_foo_restriction you target
the PCRE table with.  What is checked against the table is dependent on
the restriction used.  Read the documentation for each check_*_access
restriction above at:  http://www.postfix.org/postconf.5.html

-- 
Stan

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
> check_client_access   pcre:/etc/postfix/filter.pcre
> check_sender_access   pcre:/etc/postfix/filter.pcre
> check_recipient_accesspcre:/etc/postfix/filter.pcre
> 
> As you can see, this is defined by the smtpd_foo_restriction you target
> the PCRE table with.  What is checked against the table is dependent on
> the restriction used.  Read the documentation for each check_*_access
> restriction above at:  http://www.postfix.org/postconf.5.html

On this page, it is said:

  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.

And in the access(5) manual page:

 Depending on the application, that string is an entire client
 hostname, an entire client IP address, or an entire mail address.

So, which string is checked when a pcre table is used with
check_client_access? The client hostname or the client IP address?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: cidr table performance

[Jeroen Geilman]

On 11/04/2010 11:55 PM, Stan Hoeppner wrote:

What's the CIDR lookup table performance difference between say 256 /32
entries and a single /24 entry?  Is it 256:1?  Or, how about 90,000 /32
entries vs 60,000 entries that consolidate many of those 90,000 /32s
into larger CIDRs such as /24s and /21s etc?  I have no idea what the
total processing time would be on such size CIDRs.  Is it small enough
to be irrelevant, or are we looking at something like multiple seconds
per lookup (obviously dependent on hardware)?

Thanks.

   


From util/cidr_match.c:

/* cidr_match_execute - match address against compiled CIDR pattern list */

CIDR_MATCH *cidr_match_execute(CIDR_MATCH *list, const char *addr)
{


for (entry = list; entry; entry = entry->next) {

Each map is a linked list of CIDR patterns, so consolidate as much as 
possible - 10 single IPs will cause noticable delays when the last 
entry matches!


I would also consider using multiple CIDR maps in an alternating fashion 
- whitelist large ranges, then examine smaller ranges that must be 
excluded individually, with a different list.


And always, definitely, list the largest ranges first.


--
J.

Re: cidr table performance

[Wietse Venema]

Stan Hoeppner:
> What's the CIDR lookup table performance difference between say 256 /32
> entries and a single /24 entry?  Is it 256:1? 

One /32 match is a probably a little faster than one /24 match.
The difference depends on compiler and hardware used.

The CIDR implementation could be sped up by using IF/ELSE/ENDIF as
in pcre and regexp tables. Adding that is much more work than it
was with pcre or regexp.

> Or, how about 90,000 /32
> entries vs 60,000 entries that consolidate many of those 90,000 /32s
> into larger CIDRs such as /24s and /21s etc?  I have no idea what the
> total processing time would be on such size CIDRs.  Is it small enough
> to be irrelevant, or are we looking at something like multiple seconds
> per lookup (obviously dependent on hardware)?

Try measuring it on a few systems.

Wietse

Re: serious bug with check_client_access

[Wietse Venema]

Vincent Lefevre:
> On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
> > check_client_access pcre:/etc/postfix/filter.pcre
> > check_sender_access pcre:/etc/postfix/filter.pcre
> > check_recipient_access  pcre:/etc/postfix/filter.pcre
> > 
> > As you can see, this is defined by the smtpd_foo_restriction you target
> > the PCRE table with.  What is checked against the table is dependent on
> > the restriction used.  Read the documentation for each check_*_access
> > restriction above at:  http://www.postfix.org/postconf.5.html
> 
> On this page, it is said:
> 
>   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.
> 
> And in the access(5) manual page:
> 
>  Depending on the application, that string is an entire client
>  hostname, an entire client IP address, or an entire mail address.
> 
> So, which string is checked when a pcre table is used with
> check_client_access? The client hostname or the client IP address?

check_client_access searches the address and domain with ALL lookup
table types. It just doesn't do the substring lookups with PCRE,
REGEXP and CIDR.

Wietse

Re: serious bug with check_client_access

[Jeroen Geilman]

On 11/05/2010 01:26 AM, Vincent Lefevre wrote:

On 2010-11-04 19:06:57 -0500, Stan Hoeppner wrote:
   

check_client_access pcre:/etc/postfix/filter.pcre
check_sender_access pcre:/etc/postfix/filter.pcre
check_recipient_access  pcre:/etc/postfix/filter.pcre

As you can see, this is defined by the smtpd_foo_restriction you target
the PCRE table with.  What is checked against the table is dependent on
the restriction used.  Read the documentation for each check_*_access
restriction above at:  http://www.postfix.org/postconf.5.html
 

On this page, it is said:

   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.

And in the access(5) manual page:

  Depending on the application, that string is an entire client
  hostname, an entire client IP address, or an entire mail address.

So, which string is checked when a pcre table is used with
check_client_access? The client hostname or the client IP address?
   


*REGULAR EXPRESSION TABLES*
   This section describes how the table lookups  change  when
   the table is given in the form of regular expressions. For
   a description of regular expression lookup  table  syntax,
   see*regexp_table*(5)    
or*pcre_table*(5)  .

   Each  pattern  is  a regular expression that is applied to
   the entire string being looked up. Depending on the appli-
   cation,  that  string  is  an  entire  client hostname, an
   entire client IP address, or an entire mail address. Thus,
   no  parent  domain  or  parent  network  search  is  done,
   /u...@domain/  mail addresses are not broken  up  into  their
   /user@/  and/domain/  constituent parts, nor is/user+foo/  broken
   up into/user/  and/foo/.

   Patterns are applied in the order as specified in the  ta-
   ble,  until  a  pattern  is  found that matches the search
   string.

   Actions are the same as with indexed  file  lookups,  with
   the  additional feature that parenthesized substrings from
   the pattern can be interpolated as*$1*,*$2*  and so on.


I copied the entire section detailing PCRE access matches for you, since 
you seem unable to find it.


How many domain names look like IP addresses to you ?

If check_client_access matches against both IPs and hostnames, then your 
regex table will match against both IPs and hostnames.


Also read http://www.postfix.org/pcre_table.5.html for more detail on 
PCRE maps.


--
J.

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-04 20:33:11 -0400, Wietse Venema wrote:
> check_client_access searches the address and domain with ALL lookup
> table types. It just doesn't do the substring lookups with PCRE,
> REGEXP and CIDR.

If I understand correctly, there's another difference: in the default
table format, the string to be checked depends on the pattern form
(e.g. hostname for domain.tld, IP address for net.work.addr.ess), but
for pcre, both strings are checked against all patterns?

So, with pcre, if I want to check whether the IP address starts with
1.2.3, I need something like:

  /^1\.2\.3\.[0-9]+$/

because /^1\.2\.3\./ could also match hostnames (I've noticed in my
mail archives that hostnames of this form occur in practice).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-05 01:38:37 +0100, Jeroen Geilman wrote:
> *REGULAR EXPRESSION TABLES*
>This section describes how the table lookups  change  when
>the table is given in the form of regular expressions. For
>a description of regular expression lookup  table  syntax,
>see*regexp_table*(5)    
> or*pcre_table*(5)  .
> 
>Each  pattern  is  a regular expression that is applied to
>the entire string being looked up. Depending on the appli-
>cation,  that  string  is  an  entire  client hostname, an
>entire client IP address, or an entire mail address. Thus,
>no  parent  domain  or  parent  network  search  is  done,
>/u...@domain/  mail addresses are not broken  up  into  their
>/user@/  and/domain/  constituent parts, nor is/user+foo/  broken
>up into/user/  and/foo/.
> 
>Patterns are applied in the order as specified in the  ta-
>ble,  until  a  pattern  is  found that matches the search
>string.
> 
>Actions are the same as with indexed  file  lookups,  with
>the  additional feature that parenthesized substrings from
>the pattern can be interpolated as*$1*,*$2*  and so on.
> 
> 
> I copied the entire section detailing PCRE access matches for you,
> since you seem unable to find it.

Useless answer. If you had read my message, you would have seen that
I quoted from it.

> How many domain names look like IP addresses to you ?
> 
> If check_client_access matches against both IPs and hostnames, then your
> regex table will match against both IPs and hostnames.

This is not what the documentation says:

  Depending on the application, that string is an entire client
  hostname, an entire client IP address, or an entire mail address.
 ^^

It is said "or", and "or" doesn't mean "both". Quite the opposite.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

too many recipients does not log

[Richard Stockton]

I have a client trying to send to more than the allowed number of
recipients (smtpd_recipient_limit = 100).  On the server side the
only indication I see in the maillog is a "sender non-delivery
notification" with no explanation.  This makes debugging the
client's problem more difficult when you are handling 20-30 million
SMTP requests per day.

Is there a way to tell postfix to log a more informational message
when smtpd_recipient_limit is exceeded?  If it just logged the
same message it is sending to the client ("452 4.5.3 Error: too
many recipients") that would be helpful.

TIA for any useful suggestions.

 - Richard 

Re: RBL Spam question

[Michael Orlitzky]

On 11/04/2010 12:39 AM, Stan Hoeppner wrote:
> Ned Slider put forth on 11/3/2010 6:33 PM:
> 
>> My other thought was to simply comment (or document) ranges known to
>> contain FPs and then the user can make a judgement call whether they
>> want to comment out that particular regex based on their circumstances.
>> Not a very elegant solution.
> 
> I'm starting to wonder, considering your thoughts on FPs, if this might
> be better implemented, for OPs concerned with potential FPs, via a
> policy daemon, or integrated into SA somehow and used for scoring
> instead of outright blocking.  I don't have the programmatic skill to
> implement such a thing.


http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC

too many recipients does not log

[Richard Stockton]

I think I sent this to the wrong address, so I'm trying again...

I have a client trying to send to more than the allowed number of
recipients (smtpd_recipient_limit = 100).  On the server side the
only indication I see in the maillog is a "sender non-delivery
notification" with no explanation.  This makes debugging the
client's problem more difficult when you are handling 20-30 million
SMTP requests per day.

Is there a way to tell postfix to log a more informational message
when smtpd_recipient_limit is exceeded?  If it just logged the
same message it is sending to the client ("452 4.5.3 Error: too
many recipients") that would be helpful.

TIA for any useful suggestions.

 - Richard  

Re: too many recipients does not log

[Will Fong]

On Nov 4, 2010, at 6:09 PM, Richard Stockton wrote:

> I think I sent this to the wrong address, so I'm trying again...
> 
> I have a client trying to send to more than the allowed number of
> recipients (smtpd_recipient_limit = 100).  On the server side the
> only indication I see in the maillog is a "sender non-delivery
> notification" with no explanation.  This makes debugging the
> client's problem more difficult when you are handling 20-30 million
> SMTP requests per day.
> 
> Is there a way to tell postfix to log a more informational message
> when smtpd_recipient_limit is exceeded?  If it just logged the
> same message it is sending to the client ("452 4.5.3 Error: too
> many recipients") that would be helpful.
> 
> TIA for any useful suggestions.
> 
> - Richard  

Hi Richard,

What are you trying to, debug? I thought the problem was obvious?

Also, if someone was sending to that many recipients, it may be worth while to 
use some sort of mailing list software.  Would be able to track bounces and 
such a bit better. It's a bit of a concern for you as it may harm your IP 
reputation for delivery.

HTH,
-will

Re: serious bug with check_client_access

[Jeroen Geilman]

On 11/05/2010 01:57 AM, Vincent Lefevre wrote:

On 2010-11-05 01:38:37 +0100, Jeroen Geilman wrote:
   

*REGULAR EXPRESSION TABLES*
This section describes how the table lookups  change  when
the table is given in the form of regular expressions. For
a description of regular expression lookup  table  syntax,
see*regexp_table*(5)   
or*pcre_table*(5).

Each  pattern  is  a regular expression that is applied to
the entire string being looked up. Depending on the appli-
cation,  that  string  is  an  entire  client hostname, an
entire client IP address, or an entire mail address. Thus,
no  parent  domain  or  parent  network  search  is  done,
/u...@domain/  mail addresses are not broken  up  into  their
/user@/  and/domain/  constituent parts, nor is/user+foo/  broken
up into/user/  and/foo/.

Patterns are applied in the order as specified in the  ta-
ble,  until  a  pattern  is  found that matches the search
string.

Actions are the same as with indexed  file  lookups,  with
the  additional feature that parenthesized substrings from
the pattern can be interpolated as*$1*,*$2*  and so on.


I copied the entire section detailing PCRE access matches for you,
since you seem unable to find it.
 

Useless answer. If you had read my message, you would have seen that
I quoted from it.
   


And yet you didn't understand what it says.
It bears repeating.


How many domain names look like IP addresses to you ?

If check_client_access matches against both IPs and hostnames, then your
regex table will match against both IPs and hostnames.
 

This is not what the documentation says:

   Depending on the application, that string is an entire client
   hostname, an entire client IP address, or an entire mail address.
  ^^

It is said "or", and "or" doesn't mean "both". Quite the opposite.
   



If you combine

Each  pattern  is  a regular expression that is applied to the entire string 
being looked up.


with
*
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.

the result is as explained.

Nowhere in the entire documentation is it mentioned that a regex table 
will ONLY match a domain OR an IP address.


If it's not in the manual, then it's not supported.

--
J.

Re: serious bug with check_client_access

[Reinaldo de Carvalho]

On Thu, Nov 4, 2010 at 8:04 PM, Vincent Lefevre  wrote:
> On 2010-11-04 17:18:17 +0100, mouss wrote:
>> otherwise, you can do whatever you want with pcre:
>> /\.example\.com$/        OK
>> or with sql or ldap.
>
> For pcre, the man page is not clear. It says:
>

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.

This means that not import the table type, each check_client_access
entry in restriction, will generate some lookups.

I'll change my tombstone words for you: "While not fully understand a
documentation, don't try to adapt this documentation to the way you
work, but rather yourself to the way the documentation works".

-- 
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"While not fully understand a software, don't try to adapt this
software to the way you work, but rather yourself to the way the
software works" (myself)

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-05 02:29:53 +0100, Jeroen Geilman wrote:
> If you combine
> 
> Each  pattern  is  a regular expression that is applied to the entire string 
> being looked up.
> 
> 
> with
> *
> 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.
> 
> the result is as explained.

It is said "or", not "and".

> Nowhere in the entire documentation is it mentioned that a regex table will
> ONLY match a domain OR an IP address.

Read again what you quoted above.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: serious bug with check_client_access

[Reinaldo de Carvalho]

On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
 wrote:
>
> 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.
>
> This means that not import the table type, each check_client_access
> entry in restriction, will generate some lookups.
>

This means that not matter the table type.

> I'll change my tombstone words for you: "While not fully understand a
> documentation, don't try to adapt this documentation to the way you
> work, but rather yourself to the way the documentation works".
>

-- 
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"While not fully understand a software, don't try to adapt this
software to the way you work, but rather yourself to the way the
software works" (myself)

Re: serious bug with check_client_access

[Stan Hoeppner]

Vincent Lefevre put forth on 11/4/2010 7:49 PM:
> On 2010-11-04 20:33:11 -0400, Wietse Venema wrote:
>> check_client_access searches the address and domain with ALL lookup
>> table types. It just doesn't do the substring lookups with PCRE,
>> REGEXP and CIDR.
> 
> If I understand correctly, there's another difference: in the default
> table format, the string to be checked depends on the pattern form
> (e.g. hostname for domain.tld, IP address for net.work.addr.ess), but
> for pcre, both strings are checked against all patterns?
> 
> So, with pcre, if I want to check whether the IP address starts with
> 1.2.3, I need something like:
> 
>   /^1\.2\.3\.[0-9]+$/
> 
> because /^1\.2\.3\./ could also match hostnames (I've noticed in my
> mail archives that hostnames of this form occur in practice).

This is why you need to use "fully qualified" patterns when matching
forward/reverse hostnames.  For example:

/^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.dyn\.isp\.net$/ REJECT

In practice, most ISPs don't have a /8 worth of dynamically assigned
addresses, usually a /16 or less.  So for a specific ISP dynamic range
it would look my like this:

/^201\.33\.[0-9]{1,3}\.[0-9]{1,3}\.dyn\.isp\.net$/ REJECT

That will match a /16 of rDNS patterns only at the ISP "isp.net"

-- 
Stan

Re: serious bug with check_client_access

[Vincent Lefevre]

On 2010-11-04 23:06:17 -0300, Reinaldo de Carvalho wrote:
> On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
>  wrote:
> >
> > 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.
> >
> > This means that not import the table type, each check_client_access
> > entry in restriction, will generate some lookups.
> 
> This means that not matter the table type.

Yes, it will generate *some* lookups, but it doesn't say exactly
*which* lookups. That was precisely my question.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: cidr table performance

[Stan Hoeppner]

Wietse Venema put forth on 11/4/2010 7:30 PM:
> Stan Hoeppner:
>> What's the CIDR lookup table performance difference between say 256 /32
>> entries and a single /24 entry?  Is it 256:1? 
> 
> One /32 match is a probably a little faster than one /24 match.
> The difference depends on compiler and hardware used.
> 
> The CIDR implementation could be sped up by using IF/ELSE/ENDIF as
> in pcre and regexp tables. Adding that is much more work than it
> was with pcre or regexp.
> 
>> Or, how about 90,000 /32
>> entries vs 60,000 entries that consolidate many of those 90,000 /32s
>> into larger CIDRs such as /24s and /21s etc?  I have no idea what the
>> total processing time would be on such size CIDRs.  Is it small enough
>> to be irrelevant, or are we looking at something like multiple seconds
>> per lookup (obviously dependent on hardware)?
> 
> Try measuring it on a few systems.

Is using "time postmap -q 1.1.1.1 cidr:./map.pcre" a realistic test method?

-- 
Stan

Re: Well, everyone else using dnswl.org say bye bye to "opensource"usage.

[Sahil Tandon]

On Thu, 2010-11-04 at 06:54:05 -0500, Larry Stone wrote:

> On 11/4/10 5:46 AM, Stan Hoeppner at s...@hardwarefreak.com wrote:
> > Be glad it's still free and that you simply have to add some
> > software to your system to make it work again.
> 
> Care to provide some pointers to such software? Or do you just assume
> we all have the adequate level of expertise and time to do it
> ourselves.

I use postfwd to query dnswl.org.

-- 
Sahil Tandon 

Re: serious bug with check_client_access

[Reinaldo de Carvalho]

On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre  wrote:
> On 2010-11-04 23:06:17 -0300, Reinaldo de Carvalho wrote:
>> On Thu, Nov 4, 2010 at 10:42 PM, Reinaldo de Carvalho
>>  wrote:
>> >
>> > 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.
>> >
>> > This means that not import the table type, each check_client_access
>> > entry in restriction, will generate some lookups.
>>
>> This means that not matter the table type.
>
> Yes, it will generate *some* lookups, but it doesn't say exactly
> *which* lookups. That was precisely my question.
>

- client hostname (reverse dns hostname)
- client IP address.

if smtpd_access_maps in parent_domain_matches_subdomains.
- compare client hostname without the first part at left by dot
- compare client hostname without the first and the second part at
left by dot (and recursively at the TDL)

-- 
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"While not fully understand a software, don't try to adapt this
software to the way you work, but rather yourself to the way the
software works" (myself)

Re: too many recipients does not log

[Victor Duchovni]

On Thu, Nov 04, 2010 at 06:04:37PM -0700, Richard Stockton wrote:

> I have a client trying to send to more than the allowed number of
> recipients (smtpd_recipient_limit = 100).  On the server side the
> only indication I see in the maillog is a "sender non-delivery
> notification" with no explanation.  This makes debugging the
> client's problem more difficult when you are handling 20-30 million
> SMTP requests per day.

The error is a 4XX error, there is no connection between too many
recipients and any "sender non-delivery notification" (which would
be sent on the client-side in any case).

> Is there a way to tell postfix to log a more informational message
> when smtpd_recipient_limit is exceeded?  If it just logged the
> same message it is sending to the client ("452 4.5.3 Error: too
> many recipients") that would be helpful.

Given ESMTP pipelining, this is not a good idea. The client will deliver
the accepted recipients, and make a second connection (or more) connection
to send the rest.

-- 
Viktor.

Re: cidr table performance

[Stan Hoeppner]

Stan Hoeppner put forth on 11/4/2010 9:20 PM:
> Wietse Venema put forth on 11/4/2010 7:30 PM:
>> Stan Hoeppner:
>>> What's the CIDR lookup table performance difference between say 256 /32
>>> entries and a single /24 entry?  Is it 256:1? 
>>
>> One /32 match is a probably a little faster than one /24 match.
>> The difference depends on compiler and hardware used.
>>
>> The CIDR implementation could be sped up by using IF/ELSE/ENDIF as
>> in pcre and regexp tables. Adding that is much more work than it
>> was with pcre or regexp.
>>
>>> Or, how about 90,000 /32
>>> entries vs 60,000 entries that consolidate many of those 90,000 /32s
>>> into larger CIDRs such as /24s and /21s etc?  I have no idea what the
>>> total processing time would be on such size CIDRs.  Is it small enough
>>> to be irrelevant, or are we looking at something like multiple seconds
>>> per lookup (obviously dependent on hardware)?
>>
>> Try measuring it on a few systems.
> 
> Is using "time postmap -q 1.1.1.1 cidr:./map.pcre" a realistic test method?

In my informal testing with postmap -q I'm seeing something I wouldn't
have expected.  The results seem to show that the total size of the map
file has more of an impact on search time than the number or order of
entries.

-rw-r--r-- 1 root root 1.4M Nov  4 03:58 dnswl
-rw-r--r-- 1 root root 2.9M Nov  4 21:37 dnswl.tst

$ cat dnswl|wc -l
63120
$ cat dnswl.tst|wc -l
63120

$ time postmap -q "192.220.88.224" cidr:./dnswl
OK

real0m0.383s
user0m0.352s
sys 0m0.028s

$ time postmap -q "192.220.88.224" cidr:./dnswl.tst
permit_auth_destination

real0m0.483s
user0m0.420s
sys 0m0.060s

$ time postmap -q "65.41.216.221" cidr:./dnswl
OK

real0m0.372s
user0m0.328s
sys 0m0.040s

$ time postmap -q "65.41.216.221" cidr:./dnswl.tst
permit_auth_destination

real0m0.478s
user0m0.424s
sys 0m0.052s


The original postfix-dnswl-permit file:

-rw-r--r-- 1 root root 3.5M Nov  4 03:21 postfix-dnswl-permit

$ cat postfix-dnswl-permit|wc -l
88506

x$ time postmap -q "192.220.88.224" cidr:./postfix-dnswl-permit
permit_auth_destination

real0m0.673s
user0m0.604s
sys 0m0.068s

$ time postmap -q "65.41.216.221" cidr:./postfix-dnswl-permit
permit_auth_destination

real0m0.679s
user0m0.624s
sys 0m0.056s


The two test files are the output of running postfix-dnswl-permit
through a CIDR consolidating perl script which merges multiple CIDRs
into a larger CIDR when possible.  This cut the number of entries in the
table from 88506 to 63120.  The only difference between the two test
files is the action.  The number of bytes in "permit_auth_destination"
is sufficient to double the file size vs the byte count of "OK".

Interestingly, there seems to be no difference in elapsed time when
searching for the first entry, the last entry, or something in the
middle.  This seems to contradict Jeroen's recommendation

"And always, definitely, list the largest ranges first."

>From my rudimentary testing, ordering within the file seems to make
little difference WRT search time.  What seems to make the most
difference is the action itself, or more likely, the number of bytes of
the action changing the total file size.

My testing was performed on a very low performance system so others may
see much lower times.  The timed results above show a direct
correlation, almost a linear slope, between table file size and lookup
time, independent of the number of table entries.

Is indicative of Postfix behavior, possibly the way my Linux system and
libraries are setup, or the nature of the hardware in my test system?
This CPU only has 512KB of L2 cache.  The Postfix binaries I am running
are version 2.5.5 Debian Lenny.  I don't know what GCC optimizations
were used when compiling.  This is a 32 bit i686 system with kernel.org
kernel 2.6.34.1 rolled by yours truly.

Based on the above testing, even having gargantuan CIDR files shouldn't
be much of a performance impact on smtpd processes for low to mid volume
servers.  Adding a fraction of a second to extremely high volume servers
may have an impact, given all the other smptd checks we have our systems
perform.

Given the difference is lookup performance between using an "OK" action
and a "permit_auth_destination" action, is using "OK" in such a
whitelist manner suitable?  If not, could another action of shorter word
length be used in order to cut down on file size thus increasing lookup
performance?

I gotta say this is pretty interesting stuff.  I didn't expect these
results, and am surprised the code performs in this manner, if indeed
it's the code, and not my platform, showing these results.

-- 
Stan

Re: serious bug with check_client_access

[Stan Hoeppner]

Vincent Lefevre put forth on 11/4/2010 7:57 PM:

> This is not what the documentation says:
> 
>   Depending on the application, that string is an entire client
>   hostname, an entire client IP address, or an entire mail address.

_Application_ in this sentence refers to things like
smtpd_foo_restrictions.

For instance, check_client_access is going to pass both a hostname and
an IP address to your pcre table, but not an email address.
check_sender_access is going to pass only an email address to your pcre.

Please don't get frustrated.  I had difficulty with some of the
documentation myself not all that long ago, and I still have problems
digesting some of the docs now and then.  The Postfix documentation is
some of the most comprehensive and complete for any piece of software
I've ever worked with.  However, as you've noticed, sometimes it tends
to be written in a manner that seems geared more toward a college
computer science graduate than the average Joe sysadmin, and that may be
true.

Postfix is a very powerful MTA.  As a result the documentation is very
technical.  Postfix isn't for everyone.  I'm guessing some folks might
read two Postfix man pages and burn holes in their shoes running out to
pay $2000 for MS Exchange and a handful of CALs.

Be patient, be polite (even when it seems others aren't), and we'll help
you get where you want to go.  Learning Postfix literally is a journey.
 I've been using it for 5 years and I've probably only touched on 1% of
it's capabilities, probably less than that now that I think of the
length of the parameters page. :)

-- 
Stan

Re: RBL Spam question

[Stan Hoeppner]

Michael Orlitzky put forth on 11/4/2010 8:06 PM:
> On 11/04/2010 12:39 AM, Stan Hoeppner wrote:
>> Ned Slider put forth on 11/3/2010 6:33 PM:
>>
>>> My other thought was to simply comment (or document) ranges known to
>>> contain FPs and then the user can make a judgement call whether they
>>> want to comment out that particular regex based on their circumstances.
>>> Not a very elegant solution.
>>
>> I'm starting to wonder, considering your thoughts on FPs, if this might
>> be better implemented, for OPs concerned with potential FPs, via a
>> policy daemon, or integrated into SA somehow and used for scoring
>> instead of outright blocking.  I don't have the programmatic skill to
>> implement such a thing.
> 
> 
> http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC

Any idea where I can get a look that the regexes they use in this rule?

-- 
Stan

Relaying denied during 2 hours, driving me crazy

[Pablo Chamorro]

Today we had a 'relaying denied' issue between 15:08-17:02 p.m.  Here it is the 
output of pflogsumm:

Per-Hour Traffic Summary
time  received  delivered   deferredbounced rejected

-0100   0  0  0  0  0
0100-0200   0  0  0  0  0
0200-0300   0  0  0  0  0
0300-0400   0  0  0  0  0
0400-0500 897958 51  9 10
0500-0600 835873 62  1 19
0600-0700 938   1019 53  1 16
0700-08001257   1455 73  0 10
0800-09001833   2413 38  1 26
0900-10001926   2574 70  8 25
1000-11001859   3029 72  9 29
1100-12001998   2529 31  3 13
1200-13001553   1845 52  7 27
1300-14001349   1593 47  5 20
1400-15001758   2166 62  4 23
1500-16001941   2473 31143 33
1600-17002072   5745 17283 31
1700-18002008   2821 18  2 15
1800-19001468   1769 10  0 32
1900-20001213   2391 45 71 22
2000-21001013   1119 32  0  8
2100-2200 988   1082 32  1  8
2200-23001100   3458 30  3 19
2300-2400 523550  9  2  2

The problem wasn't specific for one domain. It happened the same for Yahoo, 
Hotmail, GMail and others. But, according to the above table,  it seems, just 
some of them were bounced, weren't they?

I wonder what happened. Could somebody please give me an answer about what 
could have happened? Below a log of a sent and bounced message, as far as I 
understand:

-- sent message, start --
Nov  4 16:02:44 correo postfix/pickup[20590]: 9198E2D6A7A: uid=101 
from=
Nov  4 16:02:44 correo postfix/cleanup[14980]: 9198E2D6A7A: 
message-id=<20101104210235.m95...@correo.ingeominas.gov.co>
Nov  4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: 
from=, size=2113, nrcpt=1 (queue active)
Nov  4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, 
delays=0.07/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20341-15, from 
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as AC18C2D6A1F)
Nov  4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: removed
-- end --


-- bounced message, start --
Nov  4 16:02:44 correo postfix/smtpd[7447]: AC18C2D6A1F: 
client=localhost.localdomain[127.0.0.1]

Nov  4 16:02:44 correo postfix/cleanup[17693]: AC18C2D6A1F: 
message-id=<20101104210235.m95...@correo.xxx.gov.co>

Nov  4 16:02:44 correo postfix/qmgr[14629]: AC18C2D6A1F: 
from=, size=2590, nrcpt=1 (queue active)

Nov  4 16:02:44 correo amavis[20341]: (20341-15) Passed CLEAN, [127.0.0.1] 
 -> , Message-ID: 
<20101104210235.m95...@correo.xxx.gov.co>, mail_id: 4-lL-jKSP5zp, Hits: -, 
size: 2113, queued_as: AC18C2D6A1F, 154 ms

Nov  4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, delays=0.07/0/0/0.15, dsn=2.0.0, 
status=sent (250 2.0.0 Ok, id=20341-15, from MTA([127.0.0.1]:10025): 250 2.0.0 
Ok: queued as AC18C2D6A1F)

Nov  4 16:02:45 correo postfix/smtp[20466]: AC18C2D6A1F: to=, 
relay=gmail-smtp-in.l.google.com[74.125.45.27]:25, delay=0.91, 
delays=0.07/0.01/0.71/0.12, dsn=5.0.0, status=bounced (host 
gmail-smtp-in.l.google.com[74.125.45.27] said: 550 Relaying denied. (in reply 
to RCPT TO command))

Nov  4 16:02:45 correo postfix/bounce[8853]: AC18C2D6A1F: sender non-delivery 
notification: AA01E2D6A76

Nov  4 16:02:45 correo postfix/qmgr[14629]: AC18C2D6A1F: removed
-- end --

Thank you very much,

Pablo Chamorro
IT Group


  

Re: serious bug with check_client_access

[mouss]

Le 05/11/2010 00:04, Vincent Lefevre a écrit :

On 2010-11-04 17:18:17 +0100, mouss wrote:

otherwise, you can do whatever you want with pcre:
/\.example\.com$/OK
or with sql or ldap.

For pcre, the man page is not clear. It says:

   Each  pattern  is  a  regular  expression that is applied to the entire
   string being looked up. Depending on the application, that string is an
   entire  client hostname, an entire client IP address, or an entire mail
   address.

But where is it described whether the string is an entire client
hostname, an entire client IP address, or an entire mail address?

According to your example, the string is an entire client hostname.
But then, this means that one cannot match IP addresses.



You need to read BOTH the doc of the map type AND the doc of what it is 
used for (access in this case).


in short, for each map, you have multiple parameters:
- the map type
- the search context (check_client_access, check_sender_acces, ... 
transport, virtual_alias_maps, ... etc)

- the list of search keys

for each combination, a "search list" is derived: for each key, sub-keys 
are derived (whether this occurs and how depends on the map type & 
context).

and it is this search list that you need to grasp. so here is an example.


for check_client_access, the search keys are: the hostname and the IP 
(in that order).

the sub-keys depend on the map type, so let's look at a few.
we assume the hostname is lab1.lab2.lab3.example.com and the IP is 1.2.3.4

[hash/cdb/...]

- if parent_domain_matches_subdomains contains smtpd_access: here, the 
search list is
S = ( lab1.lab2.lab3.example.com, lab2.lab3.example.com, 
lab3.example.com ..., com, 1.2.3.4, 1.2.3, 1.2, 1 )
so postfix will search for each element of this set and stops as soon as 
a match is found.


-  if parent_domain_matches_subdomains does not contains smtpd_access, 
then the search list becomes
S = ( lab1.lab2.lab3.example.com, .lab2.lab3.example.com, 
.lab3.example.com ..., .com, 1.2.3.4, 1.2.3, 1.2, 1 )

note the leading dot before lab2, lab3, ...


[pcre/regexp]
with such maps, no subkeys are used. this means the search list is
S = { lab1.lab2.lab3.example.com, 1.2.3.4 }

[cidr]
with cidr, only the IP is meaningful, so the set becomes
S = { 1.2.3.4}


now if we were using check_helo_access, then it's as above except that 
there is no IP.
and if we were about check_sender_access, then we only have one key (the 
email address) but may have many sub-keys.

Re: Relaying denied during 2 hours, driving me crazy

[mouss]

Le 05/11/2010 05:54, Pablo Chamorro a écrit :

Today we had a 'relaying denied' issue between 15:08-17:02 p.m.  Here it is the 
output of pflogsumm:

Per-Hour Traffic Summary
 time  received  delivered   deferredbounced rejected
 
 -0100   0  0  0  0  0
 0100-0200   0  0  0  0  0
 0200-0300   0  0  0  0  0
 0300-0400   0  0  0  0  0
 0400-0500 897958 51  9 10
 0500-0600 835873 62  1 19
 0600-0700 938   1019 53  1 16
 0700-08001257   1455 73  0 10
 0800-09001833   2413 38  1 26
 0900-10001926   2574 70  8 25
 1000-11001859   3029 72  9 29
 1100-12001998   2529 31  3 13
 1200-13001553   1845 52  7 27
 1300-14001349   1593 47  5 20
 1400-15001758   2166 62  4 23
 1500-16001941   2473 31143 33
 1600-17002072   5745 17283 31
 1700-18002008   2821 18  2 15
 1800-19001468   1769 10  0 32
 1900-20001213   2391 45 71 22
 2000-21001013   1119 32  0  8
 2100-2200 988   1082 32  1  8
 2200-23001100   3458 30  3 19
 2300-2400 523550  9  2  2

The problem wasn't specific for one domain. It happened the same for Yahoo, 
Hotmail, GMail and others. But, according to the above table,  it seems, just 
some of them were bounced, weren't they?

I wonder what happened. Could somebody please give me an answer about what 
could have happened? Below a log of a sent and bounced message, as far as I 
understand:

-- sent message, start --
Nov  4 16:02:44 correo postfix/pickup[20590]: 9198E2D6A7A: uid=101 
from=
Nov  4 16:02:44 correo postfix/cleanup[14980]: 9198E2D6A7A: 
message-id=<20101104210235.m95...@correo.ingeominas.gov.co>
Nov  4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: 
from=, size=2113, nrcpt=1 (queue active)
Nov  4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, 
delays=0.07/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20341-15, from 
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as AC18C2D6A1F)
Nov  4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: removed
-- end --


-- bounced message, start --
Nov  4 16:02:44 correo postfix/smtpd[7447]: AC18C2D6A1F: 
client=localhost.localdomain[127.0.0.1]

Nov  4 16:02:44 correo postfix/cleanup[17693]: AC18C2D6A1F: 
message-id=<20101104210235.m95...@correo.xxx.gov.co>

Nov  4 16:02:44 correo postfix/qmgr[14629]: AC18C2D6A1F: 
from=, size=2590, nrcpt=1 (queue active)

Nov  4 16:02:44 correo amavis[20341]: (20341-15) Passed CLEAN, 
[127.0.0.1]  ->  , 
Message-ID:<20101104210235.m95...@correo.xxx.gov.co>, mail_id: 4-lL-jKSP5zp, Hits: -, 
size: 2113, queued_as: AC18C2D6A1F, 154 ms

Nov  4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, delays=0.07/0/0/0.15, dsn=2.0.0, 
status=sent (250 2.0.0 Ok, id=20341-15, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: 
queued as AC18C2D6A1F)

Nov  4 16:02:45 correo postfix/smtp[20466]: AC18C2D6A1F: to=, 
relay=gmail-smtp-in.l.google.com[74.125.45.27]:25, delay=0.91, 
delays=0.07/0.01/0.71/0.12, dsn=5.0.0, status=bounced (host 
gmail-smtp-in.l.google.com[74.125.45.27] said: 550 Relaying denied. (in reply to RCPT 
TO command))


hmmm. here:
$ host 74.125.45.27
27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net.
$ host gmail-smtp-in.l.google.com
gmail-smtp-in.l.google.com has address 209.85.227.27

74.125.45.27  is a google IP, but I don't see it listed as the IP of one 
of the MX's.







Nov  4 16:02:45 correo postfix/bounce[8853]: AC18C2D6A1F: sender non-delivery 
notification: AA01E2D6A76

Nov  4 16:02:45 correo postfix/qmgr[14629]: AC18C2D6A1F: removed
-- end --

Thank you very much,

Pablo Chamorro
IT Group

Re: RBL Spam question

[Michael Orlitzky]

On 11/05/10 00:11, Stan Hoeppner wrote:
> Michael Orlitzky put forth on 11/4/2010 8:06 PM:
>> On 11/04/2010 12:39 AM, Stan Hoeppner wrote:
>>> Ned Slider put forth on 11/3/2010 6:33 PM:
>>>
 My other thought was to simply comment (or document) ranges known to
 contain FPs and then the user can make a judgement call whether they
 want to comment out that particular regex based on their circumstances.
 Not a very elegant solution.
>>>
>>> I'm starting to wonder, considering your thoughts on FPs, if this might
>>> be better implemented, for OPs concerned with potential FPs, via a
>>> policy daemon, or integrated into SA somehow and used for scoring
>>> instead of outright blocking.  I don't have the programmatic skill to
>>> implement such a thing.
>>
>>
>> http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC
> 
> Any idea where I can get a look that the regexes they use in this rule?
> 

I think this is the latest:

http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf