Re: PCRE access map mistake

[Michael Orlitzky]

On 09/24/10 00:11, pf at alt-ctrl-del.org wrote:
> "Michael Orlitzky" September 23, 2010 9:37 PM
>> We run a private RBL, jerks.viabit.com, and check against it as well as
>> four other lists at SMTP time. Occasionally, I'll get a false positive
>> due to blocking an entire /24 and want to whitelist them from our
>> private RBL check but not against e.g. Spamhaus. I'm doing something
>> wrong w.r.t. restriction classes.
>>
>> The content of generic_rbl_clients.pcre:
>>
>>  # sutton-partners.com
>>  /^64\.191\.79\.245$/public_rbls
>>
>>  # mabel.ca
>>  /^70\.38\.108\.42$/ public_rbls
>>
>>  # dsnews.com
>>  /^209\.172\.40\.21[157]$/   public_rbls
>>
>>  # Default: check these lists.
>>  #
>>  /./ all_rbls
>>
>> However, 64.191.79.245 is still being subjected to the private RBL check:
>>
> 
> Test your various rules.
> postmap -q 64.191.79.245 pcre:/etc/postfix/maps/generic_rbl_clients.pcre
> 

This returns "public_rbls" as expected.

Re: PCRE access map mistake

[Michael Orlitzky]

On 09/24/10 01:10, Sahil Tandon wrote:
> On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote:
> 
>> check_client_access pcre://generic_rbl_clients.pcre,
>>
>> The content of generic_rbl_clients.pcre:
>>
>>   # sutton-partners.com
>>   /^64\.191\.79\.245$/public_rbls
>>
>>   # mabel.ca
>>   /^70\.38\.108\.42$/ public_rbls
>>
>>   # dsnews.com
>>   /^209\.172\.40\.21[157]$/   public_rbls
>>
>>   # Default: check these lists.
>>   #
>>   /./ all_rbls
>>
>> However, 64.191.79.245 is still being subjected to the private RBL check:
>>
>>   Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
>>   unknown[64.191.79.245]
> ^^^
> 
>  % host 64.191.79.245
>  245.79.191.64.in-addr.arpa domain name pointer sutton-partners.com.
>  % host sutton-partners.com
>  sutton-partners.com has address 64.202.189.170
> 
> /./ is greedy!  Explore check_reverse_client_hostname_access; and if
> it suits your needs, thank Noel Jones. :)
> 

Ok, I see what's going on. 'unknown' gets looked up first, and so /./
matches it before the client IP address gets looked up. Wouldn't
check_reverse_client_hostname_access suffer the same fate? I think
switching to a CIDR map probably avoids matching the 'unknown'; I'll
give that a try.

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 01:26 AM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> The other misfeature that I'd like to point out again is the behavior of
>> been_here() when the hash table is full.
> 
> The alternatives to a limited-size hash are a) run out of memory and
> try to deliver mail repeatedly until it is too old or b) bounce
> the excess recipients, neither of which wins a prize for beauty.

The most important action to take would be to print a big fat warning in
the maillog if the table gets full (the limit is reached).

Walking through a labyrinth of .forward files will in general end in a
loop if you loose track of where you have already been. So I think
bouncing the excess recipients and printing a big fat warning would
indeed be the best way to solve that problem.

If you continue, you will end up in subsequent errors like running out
of filehandles, which a) obfuscates the real problem and b) will cause
many other troubles. (If there are no filehandles available, not even
the socket to the bounce or defer daemons can be opened anymore!)

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

"pure" virtual and program delivery

[Toni Mueller]

Hi,

while setting up my first Postfix (2.7) server on a Debian/Lenny
system, along with Dovecot (1.2.x), with most tables maintained in a
PostgreSQL database, I've hit a problem in the mail delivery part (as
opposed to receiving mail) for which I can't see a good solution. Some
advice and/or pointers to "best practice" papers would be much
appreciated.


Except for 'root' and a short list of admins, there are no system users
on the box. When ready, it should handle email for several domains. So
I understood that I have to follow the "virtual domains, no system
users" part of the VIRTUAL_README. I've done that and can now create an
email address and get emails delivered to the right mailbox, only by
manipulating database entries.

Now I also want to deliver emails to programs ("pipe:" transport?),
and/or run programs on email delivery, possibly in addition to storing
the email in a mailbox. So far, because of other factors (quota support
etc), I've decided to use Dovecot's LDA as the virtual_transport, but I
can't see neither in Postfix nor in Dovecot, how to run additional
programs for this purpose. Some use cases would be to facilitate SMS
alerting, which users should be able to switch on and off at their
discreetion, eg. based on the contents and/or sender and/or recipient
address of an email, or to duplicate the email in such a case to
different email addresses, or to feed a trouble ticket system or other
software package (ML managers etc), or forwarding some (not all) emails
to a different mail server, or when their quota is up, or whatever.

I've already tried to use transport_map entries to specify "local:"
delivery for those special emails, which would give me a home to work
in, plus (I think) reduced privileges, but Postfix still insisted on
delivering the email by "virtual:", ie, to Dovecot. Restarting Postfix
did have no effect.



So far, I see the following options:

 * Add the affected domains to mydestination and switch them using the
   alias mechanism. Very unwieldy, plus there is no easy way to drop
   privileges while delivering email.

 * Use a sieve script to copy such emails to special addresses which
   are then handled according to the mechanism outlined above. Very
   ugly and error prone, too.

 * Use a different virtual_transport (which one?).




My basic postfix configuration (will be augmented to have policy
support etc), currently looks like this:


$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = yes
biff = no
bounce_queue_lifetime = 5d
canonical_classes = envelope_sender, header_sender
canonical_maps = pgsql:/etc/postfix/canonical_maps
config_directory = /etc/postfix
default_process_limit = 100
disable_dns_lookups = no
local_recipient_maps = $alias_maps
mailbox_size_limit = 0
maximal_queue_lifetime = 5d
message_size_limit = 107286400
mydestination = bugs.oeko.net, w3.oeko.net, localhost.oeko.net, localhost
myhostname = w3.oeko.net
mynetworks = 127.0.0.1/32
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = 
smtp_sasl_mechanism_filter = plain
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_auth_destination
permit_sasl_authenticated   reject_unauth_destination   
permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/*.oeko.net.crt
smtpd_tls_key_file = /etc/ssl/private/*.oeko.net.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
soft_bounce = yes
transport_maps = pgsql:/etc/postfix/transport_maps
virtual_alias_maps = pgsql:/etc/postfix/virtual_alias_maps
virtual_gid_maps = pgsql:/etc/postfix/virtual_gid_maps
virtual_mailbox_base = /srv/mailboxen/
virtual_mailbox_domains = pgsql:/etc/postfix/virtual_mailbox_domains
virtual_mailbox_limit = 107286400
virtual_mailbox_maps = pgsql:/etc/postfix/virtual_mailbox_maps
virtual_transport = dovecot
virtual_uid_maps = pgsql:/etc/postfix/virtual_uid_maps




Kind regards,
--Toni++

Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change a RCPT TO: from a milter?

[Fredrik Söderblom]

Hi,

Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change a RCPT TO: 
from a milter?

E.g. doing a delrcpt("old rcpt") and addrcpt("new rcpt"), forces NOTIFY=NEVER. 
Log snippet:

Sep 23 22:02:26 seafox postfix/smtp[29516]: > 
smtp.domain.cc[192.168.254.253]:25: RCPT TO: 
ORCPT=rfc822;new-u...@domain.cc NOTIFY=NEVER

I've searched the source for 2.6, but fails to spot why the originator wouldn't 
want to be notified on failures when
only the recipient have changed.

It seems like the following snippet from smtp_loop() (smtp/smtp_proto.c) adds 
it, however i can't find where
rcpt->dsn_notify get's set to 1 when doing a smfi_delrcpt/smfi_addrcpt() combo.

if (rcpt->dsn_notify)
vstring_sprintf_append(next_command, " NOTIFY=%s",
   dsn_notify_str(rcpt->dsn_notify));

Attached perl snippet will demonstrate my problem, tested on 2.6.1 and 2.7.0.

I would greatly appreciate any pointer in what i am doing wrong or missing.

/f

#!/usr/bin/perl

use Sendmail::Milter;
use strict;

sub eom_callback
{
my $ctx = shift;

$ctx->addrcpt("") or print("failed to add 
address.\n");
$ctx->chgheader("To", 1, "new-us...@domain.cc") or print ("failed to 
change header.\n");
$ctx->delrcpt("") or print("failed to delete 
address.\n");

return SMFIS_CONTINUE;
}

my %my_callbacks =
(
'eom' =>\&eom_callback,
);

BEGIN:
{
if (not Sendmail::Milter::setconn("inet:123...@localhost")) {
print("Failed to detect connection information.\n");
}

if (not Sendmail::Milter::register($ARGV[0], \%my_callbacks, 
SMFI_CURR_ACTS)) {
print("Failed to register callbacks for $ARGV[0].\n")
}

if (Sendmail::Milter::main()) {
print("Successful exit from the Sendmail::Milter engine.");
} else {
print("Unsuccessful exit from the Sendmail::Milter engine.");
}
}



PGP.sig
Description: This is a digitally signed message part

Re: PCRE access map mistake

[Stan Hoeppner]

Michael Orlitzky put forth on 9/24/2010 2:37 AM:

> Ok, I see what's going on. 'unknown' gets looked up first, and so /./
> matches it before the client IP address gets looked up. Wouldn't
> check_reverse_client_hostname_access suffer the same fate? I think
> switching to a CIDR map probably avoids matching the 'unknown'; I'll
> give that a try.

Why go to CIDR?  Just use this expression:

>>>   # Default: check these lists.
/\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/  all_rbls

It only matches on a dotted quad enclosed in [].  It won't match on the
rdns name, or lack thereof (unknown).


-- 
Stan

Re: PCRE access map mistake

[Stan Hoeppner]

Sahil Tandon put forth on 9/24/2010 12:10 AM:

>>   Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
>>   unknown[64.191.79.245]
> ^^^

Nice catch Sahil.  I'd momentarily forgotten the fact that
check_client_access goes after rdns host name as well as IP.

-- 
Stan

Re: PCRE access map mistake

[Stan Hoeppner]

Michael Orlitzky put forth on 9/23/2010 8:37 PM:

>   # sutton-partners.com
>   /^64\.191\.79\.245$/public_rbls
> 
>   # mabel.ca
>   /^70\.38\.108\.42$/ public_rbls
> 
>   # dsnews.com
>   /^209\.172\.40\.21[157]$/   public_rbls

Should the carat and dollar be there?  I just did some tests with

unknown[64.191.79.245]
sutton-partners.com[64.191.79.245]

as the input string to postmap -q using your expressions above, and it
doesn't match.  According to:
http://www.regular-expressions.info/reference.html

^ and $ tell the engine to match your expression at the first and last
position after a line break.  In this case, if what Sahil posted is
correct, then the first will be part of a host name and the last will be
a closing bracket.

I'm thinking you need to ditch ^ and $ because what you're attempting to
match with your regex isn't at the beginning or end of a line.

-- 
Stan

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> On 09/24/2010 01:26 AM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> The other misfeature that I'd like to point out again is the behavior of
> >> been_here() when the hash table is full.
> > 
> > The alternatives to a limited-size hash are a) run out of memory and
> > try to deliver mail repeatedly until it is too old or b) bounce
> > the excess recipients, neither of which wins a prize for beauty.

Have you already tried the "no RESET_OWNER_ATTR()" solution?

Wietse

Re: Virtual users pop3d suggestions

[Charles Marcus]

On 2010-09-22 6:01 PM, Nick Edwards wrote:
> The dovecot developer would not care that dovecots pop3 speed
> matches that of couriers pop3, he has stated publicly dovecot is
> developed primarily as imap server, read the dovecot lists archives
> if you are not subscribed there. Everyone knows that dovecots imap is
> faster, but we are not talking about imap here.

You previously were discussing *precisely* the problems Timo and the
list had been discussing with respect to NFS caching issues with
IMAP+Dovecot LDA and multiple delivery servers.

The fact that dovecot's pop3 performance may or may not be a little
slower than some other pop3 server is *irrelevant* to the question of
whether or not Timo (dovecots developer).

That said, you said yourself that courier's pop3 was no faster than
dovecots.

-- 

Best regards,

Charles

OT - Re: Virtual users pop3d suggestions

[Charles Marcus]

On 2010-09-22 6:03 PM, Nick Edwards wrote:
> By the way, I need to thank you, given your discussion with Timo was one
> that had set alarm bells off on this, and the thread with Eddie
> confirmed the risks, can't understand Timo's attitude towards it, but as
> he said maybe dovecot is not for anyone who needs reliable pop3 in NFS.

PLEASE stop with the FUD.

As has already been beaten to death, dovecot HAS NO RELIABILITY PROBLEMS
WITH POP3+NFS.

Timo's 'attitude' was *only* with respect to the issues with IMAP+NFS
(caching) and MULTIPLE delivery servers using dovecot's LDA, and Courier
and every other IMAP server, under the same circumstances, have the
exact same issues. His 'attitude' was only because the problem is
inherent to NFS, and there is really not much else he (or anyone else)
CAN do about it.

-- 

Best regards,

Charles

Re: Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change a RCPT TO: from a milter?

[Wietse Venema]

Fredrik S?derblom:
> Hi,
> 
> Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change
> a RCPT TO: from a milter?

I haven't seen any no documentation on what the recipient attributes
of addrcpt should be. In the absence of that, Postfix maintains
consistency with other Postfix features that add BCC recipients
(namely, always_bcc, sender_bcc_maps and recipient_bcc_maps).

Of course, any hard-coded policy should be made configurable,
but that does not help you now.

You can shut up Postfix about DSN attributes with:

/etc/postfix/main.cf:
smtp_discard_ehlo_keywords = dsn

or an equivalent smtp_discard_ehlo_keyword_address_maps setting.

This means that down-stream MTAs will send delivery status
notifications. The local Postfix instance will not send notifications
until NOTIFY is made configurable for addrcpt and other BCC features.

Wietse

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 12:42 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/24/2010 01:26 AM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
 The other misfeature that I'd like to point out again is the behavior of
 been_here() when the hash table is full.
>>>
>>> The alternatives to a limited-size hash are a) run out of memory and
>>> try to deliver mail repeatedly until it is too old or b) bounce
>>> the excess recipients, neither of which wins a prize for beauty.
> 
> Have you already tried the "no RESET_OWNER_ATTR()" solution?

I did a test run with the following aliases:

testlist: member1, member2, leo2
owner-testlist: root
member1: leo
member2: testleo
# leo2 is a real user

It requeues the mail now. (Which is new.) There is one new queue-id for all
the list-members and one local(8) process that delivers it:

Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, 
size=2011, nrcpt=1 (queue active)
Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: 
from=, size=2170, nrcpt=3 (queue active)
Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: 
to=, relay=local, delay=0.05, delays=0.02/0.02/0/0.02, 
dsn=2.0.0, status=sent (forwarded as 46761398CB)
Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed
Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, 
relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered 
to mailbox)
Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, 
relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent 
(delivered to mailbox)
Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
to=, relay=local, delay=0.03, delays=0.01/0.01/0/0, 
dsn=2.0.0, status=sent (delivered to mailbox)
Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: removed

Is this the intended behavior? (At least it looks the same if the list
members are real users instead of aliases.)

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at   
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: PCRE access map mistake

[Sahil Tandon]

On Fri, 2010-09-24 at 03:37:22 -0400, Michael Orlitzky wrote:

> >>   # sutton-partners.com
> >>   /^64\.191\.79\.245$/public_rbls
> >>
> >>   # Default: check these lists.
> >>   #
> >>   /./ all_rbls
> >>
> >> However, 64.191.79.245 is still being subjected to the private RBL check:
> >>
> >>   Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
> >>   unknown[64.191.79.245]
> > ^^^
> > 
> >  % host 64.191.79.245
> >  245.79.191.64.in-addr.arpa domain name pointer sutton-partners.com.
> >  % host sutton-partners.com
> >  sutton-partners.com has address 64.202.189.170
> > 
> > /./ is greedy!  Explore check_reverse_client_hostname_access; and if
> > it suits your needs, thank Noel Jones. :)
> 
> Ok, I see what's going on. 'unknown' gets looked up first, and so /./
> matches it before the client IP address gets looked up. 

Correct.

> Wouldn't check_reverse_client_hostname_access suffer the same fate? 

No, because then Postfix passes the unverified reverse client hostname
to the access(5) map, rather than 'unknown'.

> I think switching to a CIDR map probably avoids matching the
> 'unknown'; I'll give that a try.

Yes, that would circumvent this issue; you could also modify your final
pattern to match any IP, rather than anything and everything!

-- 
Sahil Tandon 

Re: PCRE access map mistake

[Sahil Tandon]

On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote:

> Michael Orlitzky put forth on 9/23/2010 8:37 PM:
> 
> >   # sutton-partners.com
> >   /^64\.191\.79\.245$/public_rbls
> > 
> >   # mabel.ca
> >   /^70\.38\.108\.42$/ public_rbls
> > 
> >   # dsnews.com
> >   /^209\.172\.40\.21[157]$/   public_rbls
> 
> Should the carat and dollar be there?  I just did some tests with
> 
> unknown[64.191.79.245]
> sutton-partners.com[64.191.79.245]

These aren't the input strings.  See access(5) ...

-- 
Sahil Tandon 

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Wietse Venema:
> Wietse Venema:
> > Victor Duchovni:
> > > On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
> > > 
> > > > More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> > > > That code is a remnant of a very early attempt to attribute bounces
> > > > very accurately, and may be creating more problems than it solves.
...
> > RESET_OWNER_ATTR() is more destructive - it will remove the owner
> > attribute when a sub-alias has no owner-alias. This is really old
> > code and I don't remember the fine details of what led me to this
> > some 12 years ago. 
> 
> Found it. Immediately before the code that decides to save recipients
> to a new queue file depending on the owner attribute value is this
> comment:
> 
>  * The code below must not trigger on mail sent to an alias that has no
>  * owner- companion, so that mail for an alias first.last->username is
>  * delivered directly, instead of going through username->first.last
>  * canonical mappings in the cleanup service. The downside of this
>  * approach is that recipients in the expansion of an alias without
>  * owner- won't have separate delivery queue file status records, because
>  * for them, the message won't be resubmitted as a new queue file.
> 
> The idea here is that we have the equivalent of:
> 
> /etc/aliases:
>   # Note: no owner- alias.
>   first.lastname: unixlogin
> 
> /etc/postfix/canonical:
>   unixlogin  first.lastname
> 
> Even then, when a mailing list does the equivalent of:
> 
> /etc/aliases:
>   listname: first.lastname, ...
>   owner-listname: whatever
> 
> what happens is that first.lastname is put into a new queue file,
> and when that queue file is delivered, the first.lastname->unixlogin
> alias expands without any mailing list owner attribute around, so
> this will not loop even when I remove the RESET_OWNER_ATTR()
> operation for an owner-less "first.lastname" alias.

As a follow-up, I ran a few checks with .forward files that contain
the recipient itself or a local alias for that recipient. This also
delivers properly without the the RESET_OWNER_ATTR() operation,
both with direct mail to the recipient, and with mail through an
alias with or without an owner- alias.

At this point I think I know why Postfix used RESET_OWNER_ATTR()
for an owner-less local alias (i.e. to avoid writing recipients to
a new queue file and going into a loop). There is also evidence
that this step is not needed even when the recipient was a member
of a mailing list alias with a proper owner- alias, because the
new queue file effectively stripped the mailing list owner attribute.

I will mull over this for a week and then add a compatibility switch
between the old behavior (off by default) and what appears to be
the more desirable behavior (on by default). This would be similar
to the Postfix 2.3 frozen_delivered_to option which should be safe
to remove five years after its introduction.

Wietse

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> > Have you already tried the "no RESET_OWNER_ATTR()" solution?
> 
> I did a test run with the following aliases:
> 
> testlist: member1, member2, leo2
> owner-testlist: root
> member1: leo
> member2: testleo
> # leo2 is a real user
> 
> It requeues the mail now. (Which is new.) There is one new queue-id for all
> the list-members and one local(8) process that delivers it:
> 
> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, 
> size=2011, nrcpt=1 (queue active)
> Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: 
> from=, size=2170, nrcpt=3 (queue active)
> Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: 
> to=, relay=local, delay=0.05, delays=0.02/0.02/0/0.02, 
> dsn=2.0.0, status=sent (forwarded as 46761398CB)
> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed
> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, 
> relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered 
> to mailbox)
> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, 
> relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent 
> (delivered to mailbox)

This is expected behavior when

- The local(8) process limit is set to 1 in master.cf,

- The default_process_limit is set to 1 in main.cf,

- Local deliveries are forced to be multi-recipient transactions
(_destination_recipient_limit > 1).

None of the above is the recommended default.

With the recommended default, the deliveries would be spread over
a small number of local(8) processes. Each process would deliver
one recipient per transaction, so that one recipient with an
expensive command in ~user/.forward would not slow down deliveries
for other users.

Wietse

Re: PCRE access map mistake

[Noel Jones]

On 9/24/2010 2:37 AM, Michael Orlitzky wrote:

On 09/24/10 01:10, Sahil Tandon wrote:

On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote:


check_client_access pcre://generic_rbl_clients.pcre,

The content of generic_rbl_clients.pcre:

   # sutton-partners.com
   /^64\.191\.79\.245$/public_rbls

   # mabel.ca
   /^70\.38\.108\.42$/ public_rbls

   # dsnews.com
   /^209\.172\.40\.21[157]$/   public_rbls

   # Default: check these lists.
   #
   /./ all_rbls

However, 64.191.79.245 is still being subjected to the private RBL check:

   Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
   unknown[64.191.79.245]

 ^^^

  % host 64.191.79.245
  245.79.191.64.in-addr.arpa domain name pointer sutton-partners.com.
  % host sutton-partners.com
  sutton-partners.com has address 64.202.189.170

/./ is greedy!  Explore check_reverse_client_hostname_access; and if
it suits your needs, thank Noel Jones. :)



Ok, I see what's going on. 'unknown' gets looked up first, and so /./
matches it before the client IP address gets looked up. Wouldn't
check_reverse_client_hostname_access suffer the same fate? I think
switching to a CIDR map probably avoids matching the 'unknown'; I'll
give that a try.



Yes, that's your problem and the correct solution.

I made this same mistake once upon a time...

With all the *access tests, the map is searched first for the 
hostname, then for the IP.  This is documented in the 
access(5) man page, but maybe could be improved.


Stan Hoeppner wrote:

/\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/  all_rbls

It only matches on a dotted quad enclosed in [].  It won't match on the
rdns name, or lack thereof (unknown).


No, the table is searched twice; first with the hostname (or 
unknown) and then with the bare IP -- no brackets.  Carefully 
read access(5) several times.


For a pcre IP catchall unlikely to match on a real hostname 
you could use

/^[0-9.]+$/  all_rbls

a cidr table -- which can never match a name -- is the cleaner 
solution.


Sahil Tandon wrote:

> Wouldn't check_reverse_client_hostname_access suffer the same fate?

No, because then Postfix passes the unverified reverse client hostname
to the access(5) map, rather than 'unknown'.


If the intent is to match on the IP, 
check_reverse_client_hostname_access would indeed behave in 
the same way; search once for the reverse hostname (or unknown 
if no rDNS), then a second time for the IP.  So that tool 
wouldn't solve this particular problem.






  -- Noel Jones

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 02:31 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>
>> I did a test run with the following aliases:
>>
>> testlist: member1, member2, leo2
>> owner-testlist: root
>> member1: leo
>> member2: testleo
>> # leo2 is a real user
>>
>> It requeues the mail now. (Which is new.) There is one new queue-id for all
>> the list-members and one local(8) process that delivers it:
>
> This is expected behavior when
> 
> - The local(8) process limit is set to 1 in master.cf,
> - The default_process_limit is set to 1 in main.cf,
> - Local deliveries are forced to be multi-recipient transactions
> (_destination_recipient_limit > 1).

Ah - that's the problem.

# postconf local_destination_recipient_limit
local_destination_recipient_limit = 1

> None of the above is the recommended default.

This IS the default:

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

> With the recommended default, the deliveries would be spread over
> a small number of local(8) processes. Each process would deliver
> one recipient per transaction, so that one recipient with an
> expensive command in ~user/.forward would not slow down deliveries
> for other users.

I see. I'll adjust that.

With one local(8) process, requeuing wouldn't make any difference, the
been_here table would fill just as much as without an owner- alias.

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 03:07 PM, Alexander 'Leo' Bergolth wrote:
> On 09/24/2010 02:31 PM, Wietse Venema wrote:
>> Alexander 'Leo' Bergolth:
 Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>>
>>> I did a test run with the following aliases:
>>>
>>> testlist: member1, member2, leo2
>>> owner-testlist: root
>>> member1: leo
>>> member2: testleo
>>> # leo2 is a real user
>>>
>>> It requeues the mail now. (Which is new.) There is one new queue-id for all
>>> the list-members and one local(8) process that delivers it:
>>
>> This is expected behavior when
>>
>> - The local(8) process limit is set to 1 in master.cf,
>> - The default_process_limit is set to 1 in main.cf,
>> - Local deliveries are forced to be multi-recipient transactions
>> (_destination_recipient_limit > 1).
> 
> Ah - that's the problem.
>
> # postconf local_destination_recipient_limit
> local_destination_recipient_limit = 1
> 
>> None of the above is the recommended default.
> 
> This IS the default:
> 
> http://www.postfix.org/postconf.5.html#local_destination_recipient_limit

Sorry. I mixed that up.
local_destination_recipient_limit = 1  is the default and that's what
you said.

--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: PCRE access map mistake

[Sahil Tandon]

On Sep 24, 2010, at 8:43 AM, Noel Jones  wrote:

> On 9/24/2010 2:37 AM, Michael Orlitzky wrote:
>> On 09/24/10 01:10, Sahil Tandon wrote:
>>> On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote:
>>> 
 check_client_access pcre://generic_rbl_clients.pcre,
 
 The content of generic_rbl_clients.pcre:
 
   # sutton-partners.com
   /^64\.191\.79\.245$/public_rbls
 
   # mabel.ca
   /^70\.38\.108\.42$/ public_rbls
 
   # dsnews.com
   /^209\.172\.40\.21[157]$/   public_rbls
 
   # Default: check these lists.
   #
   /./ all_rbls
 
 However, 64.191.79.245 is still being subjected to the private RBL check:
 
   Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
   unknown[64.191.79.245]
>>> ^^^
>>> 
>>>  % host 64.191.79.245
>>>  245.79.191.64.in-addr.arpa domain name pointer sutton-partners.com.
>>>  % host sutton-partners.com
>>>  sutton-partners.com has address 64.202.189.170
>>> 
>>> /./ is greedy!  Explore check_reverse_client_hostname_access; and if
>>> it suits your needs, thank Noel Jones. :)
>>> 
>> 
>> Ok, I see what's going on. 'unknown' gets looked up first, and so /./
>> matches it before the client IP address gets looked up. Wouldn't
>> check_reverse_client_hostname_access suffer the same fate? I think
>> switching to a CIDR map probably avoids matching the 'unknown'; I'll
>> give that a try.
> 
> 
> Yes, that's your problem and the correct solution.
> 
> I made this same mistake once upon a time...
> 
> With all the *access tests, the map is searched first for the hostname, then 
> for the IP.  This is documented in the access(5) man page, but maybe could be 
> improved.
> 
> Stan Hoeppner wrote:
>> /\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/  all_rbls
>> 
>> It only matches on a dotted quad enclosed in [].  It won't match on the
>> rdns name, or lack thereof (unknown).
> 
> No, the table is searched twice; first with the hostname (or unknown) and 
> then with the bare IP -- no brackets.  Carefully read access(5) several times.
> 
> For a pcre IP catchall unlikely to match on a real hostname you could use
> /^[0-9.]+$/  all_rbls
> 
> a cidr table -- which can never match a name -- is the cleaner solution.
> 
> Sahil Tandon wrote:
>>> > Wouldn't check_reverse_client_hostname_access suffer the same fate?
>> No, because then Postfix passes the unverified reverse client hostname
>> to the access(5) map, rather than 'unknown'.
> 
> If the intent is to match on the IP, check_reverse_client_hostname_access 
> would indeed behave in the same way; search once for the reverse hostname (or 
> unknown if no rDNS), then a second time for the IP.  So that tool wouldn't 
> solve this particular problem.

Woops, your are of course correct!  I'm allergic to catch-alls!  OP should 
stick to my first advice of explicitly matching an IP rather than anything and 
everything.

--
Sahil Tandon 

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> With one local(8) process, requeuing wouldn't make any difference, the
> been_here table would fill just as much as without an owner- alias.

That is incorrect.

With _destination_recipient_limit=1, there will be one recipient
per local(8) transaction. All local(8) state is reset between
transactions.

Wietse

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 02:31 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>
>> I did a test run with the following aliases:
>>
>> testlist: member1, member2, leo2
>> owner-testlist: root
>> member1: leo
>> member2: testleo
>> # leo2 is a real user
>>
>> It requeues the mail now. (Which is new.) There is one new queue-id for all
>> the list-members and one local(8) process that delivers it:
>>
>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, 
>> size=2011, nrcpt=1 (queue active)
>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: 
>> from=, size=2170, nrcpt=3 (queue active)
>> Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: 
>> to=, relay=local, delay=0.05, delays=0.02/0.02/0/0.02, 
>> dsn=2.0.0, status=sent (forwarded as 46761398CB)
>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed
>> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
>> to=, relay=local, delay=0.02, delays=0.01/0/0/0, 
>> dsn=2.0.0, status=sent (delivered to mailbox)
>> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
>> to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, 
>> dsn=2.0.0, status=sent (delivered to mailbox)
> 
> This is expected behavior when
> 
> - The local(8) process limit is set to 1 in master.cf,
> 
> - The default_process_limit is set to 1 in main.cf,
> 
> - Local deliveries are forced to be multi-recipient transactions
> (_destination_recipient_limit > 1).
> 
> None of the above is the recommended default.

Hmm - strange - all parameters are correctly set:

# grep ^local /etc/postfix/master.cf
local unix  -   n   n   -   -   local

# postconf default_process_limit \
local_destination_concurrency_limit \
local_destination_recipient_limit
default_process_limit = 100
local_destination_concurrency_limit = 2
local_destination_recipient_limit = 1

> With the recommended default, the deliveries would be spread over
> a small number of local(8) processes. Each process would deliver
> one recipient per transaction, so that one recipient with an
> expensive command in ~user/.forward would not slow down deliveries
> for other users.

With my parameters and yor explanation, I'd expect delivery to be
distributed over 2 concurrent local(8) processes by the queue manager,
each process delivering only to one local recipient.

Did I get that right?

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change a RCPT TO: from a milter?

[Claus Assmann]

On Fri, Sep 24, 2010, Wietse Venema wrote:
> Fredrik S?derblom:

> > Why does postfix (2.6.1, 2.7.0) force NOTIFY=NEVER when i change
> > a RCPT TO: from a milter?

> I haven't seen any no documentation on what the recipient attributes
> of addrcpt should be. In the absence of that, Postfix maintains

None. It doesn't say to add any ESMTP parameters.  That's what
smfi_addrcpt_par() is for.

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> On 09/24/2010 02:31 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
> >>
> >> I did a test run with the following aliases:
> >>
> >> testlist: member1, member2, leo2
> >> owner-testlist: root
> >> member1: leo
> >> member2: testleo
> >> # leo2 is a real user
> >>
> >> It requeues the mail now. (Which is new.) There is one new queue-id for all
> >> the list-members and one local(8) process that delivers it:
> >>
> >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, 
> >> size=2011, nrcpt=1 (queue active)
> >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: 
> >> from=, size=2170, nrcpt=3 (queue active)
> >> Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: 
> >> to=, relay=local, delay=0.05, 
> >> delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent (forwarded as 46761398CB)
> >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed
> >> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
> >> to=, relay=local, delay=0.02, delays=0.01/0/0/0, 
> >> dsn=2.0.0, status=sent (delivered to mailbox)
> >> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
> >> to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, 
> >> dsn=2.0.0, status=sent (delivered to mailbox)
> > 
> > This is expected behavior when
> > 
> > - The local(8) process limit is set to 1 in master.cf,
> > 
> > - The default_process_limit is set to 1 in main.cf,
> > 
> > - Local deliveries are forced to be multi-recipient transactions
> > (_destination_recipient_limit > 1).
> > 
> > None of the above is the recommended default.
> 
> Hmm - strange - all parameters are correctly set:
> 
> # grep ^local /etc/postfix/master.cf
> local unix  -   n   n   -   -   local
> 
> # postconf default_process_limit \
> local_destination_concurrency_limit \
> local_destination_recipient_limit
> default_process_limit = 100
> local_destination_concurrency_limit = 2
> local_destination_recipient_limit = 1
> 
> > With the recommended default, the deliveries would be spread over
> > a small number of local(8) processes. Each process would deliver
> > one recipient per transaction, so that one recipient with an
> > expensive command in ~user/.forward would not slow down deliveries
> > for other users.
> 
> With my parameters and yor explanation, I'd expect delivery to be
> distributed over 2 concurrent local(8) processes by the queue manager,
> each process delivering only to one local recipient.
> 
> Did I get that right?

Insufficient information.

I don't know what changes you have been making in the course of
trouble shooting. For example you could have added another local
transport to master.cf with a different name, in which case the
_destination_recipient_limit would be the default of 50 recipients
per transaction.

Even then, a 1000 recipient list should be spread across two local(8)
processes, each delivering transactions of 50 recipients side by side.
I don't see that happen, so I suspect the measurement is inconclusive.

By the way, having 50 recipients per transaction would not be enough
to bust the dupfilter limit and trigger anomalies, but deliveries
would suffer from unnecessary delays when one recipient has a slow
command in their .forward file. With the intended configuration,
faster recipients complete before slower recipients, instead of
having to wait for the slower one.

Wietse

relay_recipients_maps with LDAP lookup ?

[Frank Bonnet]

Hello

is it possible to use LDAP lookup in the relay_recipients_maps
statement ?

If yes ant infos links welcome !

Thanks

Re: relay_recipients_maps with LDAP lookup ?

[Noel Jones]

On 9/24/2010 8:46 AM, Frank Bonnet wrote:

Hello

is it possible to use LDAP lookup in the relay_recipients_maps
statement ?

If yes ant infos links welcome !

Thanks


Yes, you can use LDAP for relay_recipient_maps.  The result 
must be the same as with simple indexed files.

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


Postfix is map-type agnostic; you can use any supported map 
type for any *maps parameter.  This frees you to choose the 
map type based on the type of data you are looking up and 
where the data resides.




  -- Noel Jones

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 03:44 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/24/2010 02:31 PM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
> Have you already tried the "no RESET_OWNER_ATTR()" solution?

 I did a test run with the following aliases:

 testlist: member1, member2, leo2
 owner-testlist: root
 member1: leo
 member2: testleo
 # leo2 is a real user

 It requeues the mail now. (Which is new.) There is one new queue-id for all
 the list-members and one local(8) process that delivers it:

 Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, 
 size=2011, nrcpt=1 (queue active)
 Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: 
 from=, size=2170, nrcpt=3 (queue active)
 Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: 
 to=, relay=local, delay=0.05, 
 delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent (forwarded as 46761398CB)
 Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed
 Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
 to=, relay=local, delay=0.02, delays=0.01/0/0/0, 
 dsn=2.0.0, status=sent (delivered to mailbox)
 Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: 
 to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, 
 dsn=2.0.0, status=sent (delivered to mailbox)
>>>
>>> This is expected behavior when
>>>
>>> - The local(8) process limit is set to 1 in master.cf,
>>>
>>> - The default_process_limit is set to 1 in main.cf,
>>>
>>> - Local deliveries are forced to be multi-recipient transactions
>>> (_destination_recipient_limit > 1).
>>>
>>> None of the above is the recommended default.
>>
>> Hmm - strange - all parameters are correctly set:
>>
>> # grep ^local /etc/postfix/master.cf
>> local unix  -   n   n   -   -   local
>>
>> # postconf default_process_limit \
>> local_destination_concurrency_limit \
>> local_destination_recipient_limit
>> default_process_limit = 100
>> local_destination_concurrency_limit = 2
>> local_destination_recipient_limit = 1
>>
>>> With the recommended default, the deliveries would be spread over
>>> a small number of local(8) processes. Each process would deliver
>>> one recipient per transaction, so that one recipient with an
>>> expensive command in ~user/.forward would not slow down deliveries
>>> for other users.
>>
>> With my parameters and yor explanation, I'd expect delivery to be
>> distributed over 2 concurrent local(8) processes by the queue manager,
>> each process delivering only to one local recipient.
>>
>> Did I get that right?
> 
> Insufficient information.
> 
> I don't know what changes you have been making in the course of
> trouble shooting. For example you could have added another local
> transport to master.cf with a different name, in which case the
> _destination_recipient_limit would be the default of 50 recipients
> per transaction.

No. I didn't. There is only one local transport (the default).
I did a postconf -n. There are no local_ or qmgr_ related settings that
differ from the default.

> Even then, a 1000 recipient list should be spread across two local(8)
> processes, each delivering transactions of 50 recipients side by side.
> I don't see that happen, so I suspect the measurement is inconclusive.

Unfortunately it doesn't. :-(

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Matthias Leisi]

Hi all,

On Thu, Sep 23, 2010 at 12:15 AM, mouss  wrote:

>> postfix-dnswl-header
>> 222.255.237.6/32  PREPEND X-REPLACEME: low vinabook.com DNSWLId 17147
>>
>> postfix-dnswl-permit
>> 222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId 17147

> no, it was that way since a long time. and sigh, I noticed that a long long
> time ago but I focused on the header part...

Yes, this hasn't changed since... ages. Would it be OK to simple leave
out the verbose data after permit_auth_destination from a Postfix
point of view?

-- Matthias

PS: Thanks for pinging, I normally don't follow postfix-users very closely.

Re: PCRE access map mistake

[Stan Hoeppner]

Sahil Tandon put forth on 9/24/2010 7:12 AM:
> On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote:
> 
>> Michael Orlitzky put forth on 9/23/2010 8:37 PM:
>>
>>>   # sutton-partners.com
>>>   /^64\.191\.79\.245$/public_rbls
>>>
>>>   # mabel.ca
>>>   /^70\.38\.108\.42$/ public_rbls
>>>
>>>   # dsnews.com
>>>   /^209\.172\.40\.21[157]$/   public_rbls
>>
>> Should the carat and dollar be there?  I just did some tests with
>>
>> unknown[64.191.79.245]
>> sutton-partners.com[64.191.79.245]
> 
> These aren't the input strings.  See access(5) ...

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

The application check_client_access does both hostname and IP address
lookups.  So is the pcre table queried twice in this case, once for
hostname and once for IP address?

-- 
Stan

Re: PCRE access map mistake

[Stan Hoeppner]

Noel Jones put forth on 9/24/2010 7:43 AM:
> Stan Hoeppner wrote:
>> /\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/  all_rbls
>>
>> It only matches on a dotted quad enclosed in [].  It won't match on the
>> rdns name, or lack thereof (unknown).
> 
> No, the table is searched twice; first with the hostname (or unknown)
> and then with the bare IP -- no brackets.  Carefully read access(5)
> several times.

I read it at least 5 times.  And double search is the conclusion I came
to.  I needed confirmation though (as you'll see in the message I posted
before reading yours), which you graciously provide here.  Thanks for
the authoritative confirmation Noel.

> For a pcre IP catchall unlikely to match on a real hostname you could use
> /^[0-9.]+$/  all_rbls

Thanks for this expression as well.  Not sure if/when I'll use it, but
now I have it.

> a cidr table -- which can never match a name -- is the cleaner solution.

After the education, I definitely agree.

-- 
Stan

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> > Even then, a 1000 recipient list should be spread across two local(8)
> > processes, each delivering transactions of 50 recipients side by side.
> > I don't see that happen, so I suspect the measurement is inconclusive.
> 
> Unfortunately it doesn't. :-(

Actually, multiple local(8) processes are used only when delivery
is slow enough. 

When I send list mail to addresses that deliver to mailbox, I see
one local process(8) delivering each recipient like you do, with
10ms delay from queue file creation to mailbox update like you do:

Sep 24 10:20:17 hostname postfix/local[2732]: CE6E4924782: 
to=, orig_to=, relay=local, delay=0.02, 
delays=0.01/0/0/0, dsn=2.0.0, status=sent (forwarded as D14D4924781)
Sep 24 10:20:17 hostname postfix/qmgr[2721]: D14D4924781: 
from=, size=473, nrcpt=10 (queue active)
Sep 24 10:20:17 hostname postfix/qmgr[2721]: CE6E4924782: removed
Sep 24 10:20:17 hostname postfix/local[2732]: D14D4924781: 
to=, relay=local, delay=0.01, delays=0/0/0/0, dsn=2.0.0, 
status=sent (delivered to mailbox)
Sep 24 10:20:17 hostname postfix/local[2732]: D14D4924781: 
to=, relay=local, delay=0.01, delays=0/0/0/0, dsn=2.0.0, 
status=sent (delivered to mailbox)
... and so on ...

When I send list mail to addresses that are slow (the .forward file
has a command "|sleep 1") then there are two local(8) processes:

Sep 24 10:21:58 hostname postfix/local[2753]: 9C9F5924782: 
to=, orig_to=, relay=local, delay=0.02, 
delays=0.01/0/0/0, dsn=2.0.0, status=sent (forwarded as 9E904924781)
Sep 24 10:21:58 hostname postfix/qmgr[2721]: 9E904924781: 
from=, size=473, nrcpt=10 (queue active)
Sep 24 10:21:58 hostname postfix/qmgr[2721]: 9C9F5924782: removed
Sep 24 10:21:59 hostname postfix/local[2753]: 9E904924781: 
to=, relay=local, delay=1, delays=0/0/0/1, dsn=2.0.0, 
status=sent (delivered to command: sleep 1)
Sep 24 10:21:59 hostname postfix/local[2754]: 9E904924781: 
to=, relay=local, delay=1, delays=0/0/0/1, dsn=2.0.0, 
status=sent (delivered to command: sleep 1)
... and so on ...

Now this 10ms delay in my first example (and your example) is
suspicious. I strongly suspect that my laptop disk drive has write
caching enabled.  It is physically not possible to create a queue
file, fsync it, and then update a bunch of mailboxes and fsync them
when disk heads need to move.

With this caching going on, my laptop delivers mail (and syslogs
to the same disk) as fast as memory can be written, so there is no
room left to run multiple processes delivering mail.

On the other hand with my artificial 1000ms delays, there is plenty
of time for concurrency to pick up the slack. And that is what you
see happening in my second example.

Does your mail server disk have write caching enabled, and is the
cache persistent when power fails? I suppose it does not fail that
often where you live, compared to this third-world infrastructure
in the USA that I live on.

Wietse

Re: PCRE access map mistake

[Michael Orlitzky]

On 09/24/10 10:41, Stan Hoeppner wrote:
> Sahil Tandon put forth on 9/24/2010 7:12 AM:
>> On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote:
>>
>>> Michael Orlitzky put forth on 9/23/2010 8:37 PM:
>>>
   # sutton-partners.com
   /^64\.191\.79\.245$/public_rbls

   # mabel.ca
   /^70\.38\.108\.42$/ public_rbls

   # dsnews.com
   /^209\.172\.40\.21[157]$/   public_rbls
>>>
>>> Should the carat and dollar be there?  I just did some tests with
>>>
>>> unknown[64.191.79.245]
>>> sutton-partners.com[64.191.79.245]
>>
>> These aren't the input strings.  See access(5) ...
> 
> "REGULAR EXPRESSION TABLES
> ...Depending on the  application, that string is an entire client
> hostname, an entire client IP address, or an entire mail address."
> 
> The application check_client_access does both hostname and IP address
> lookups.  So is the pcre table queried twice in this case, once for
> hostname and once for IP address?
> 

It would be if the hostname 'unknown' doesn't match something. You can
actually see the order that the queries get sent to the map if you turn
on debug logging (it's not just for getting yelled at on the ML!).

The biggest problem I would have with keeping the regular expression map
is that, since the hostname is checked first, someone could switch his
hostname to 64.191.79.245.example.com and bypass my blacklist check. I
might be able to do it with a more complicated regex, but why?

Anyway -- thanks everyone for the help -- I switched to a CIDR map last
night and it's working correctly today.

Re: PCRE access map mistake

[Wietse Venema]

Stan Hoeppner:
> Noel Jones put forth on 9/24/2010 7:43 AM:
> > Stan Hoeppner wrote:
> >> /\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/  all_rbls
> >>
> >> It only matches on a dotted quad enclosed in [].  It won't match on the
> >> rdns name, or lack thereof (unknown).
> > 
> > No, the table is searched twice; first with the hostname (or unknown)
> > and then with the bare IP -- no brackets.  Carefully read access(5)
> > several times.
> 
> I read it at least 5 times.  And double search is the conclusion I came
> to.  I needed confirmation though (as you'll see in the message I posted
> before reading yours), which you graciously provide here.  Thanks for
> the authoritative confirmation Noel.

Postfix has table-DRIVEN mechanisms (access, aliases) and table
LOOKUP mechanisms (btree, mysql).

The access(5) manpage documents the table-DRIVEN mechanism and
extensively describes both hostname and network address lookups.

The details of table LOOKUP mechanisms are competely neutral
with respect to the table-DRIVEN mechanism that rides on top.

The table-DRIVEN mechanisms are mostly neutral with respect to the
table LOOKUP mechanisms underneath. With pattern-based lookup
mechanisms, regexp/pcr/cidr, parent domain and subnet address
lookups are not done.

Wietse

Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Stan Hoeppner]

Matthias Leisi put forth on 9/24/2010 9:12 AM:
> Hi all,
> 
> On Thu, Sep 23, 2010 at 12:15 AM, mouss  wrote:
> 
>>> postfix-dnswl-header
>>> 222.255.237.6/32  PREPEND X-REPLACEME: low vinabook.com DNSWLId 17147
>>>
>>> postfix-dnswl-permit
>>> 222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId 17147
> 
>> no, it was that way since a long time. and sigh, I noticed that a long long
>> time ago but I focused on the header part...
> 
> Yes, this hasn't changed since... ages. Would it be OK to simple leave
> out the verbose data after permit_auth_destination from a Postfix
> point of view?

AFAIK, ACCEPT/PERMIT actions don't allow optional text.  I believe
eliminating the verbose data would be preferable, yes.

-- 
Stan

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/24/2010 04:56 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Even then, a 1000 recipient list should be spread across two local(8)
>>> processes, each delivering transactions of 50 recipients side by side.
>>> I don't see that happen, so I suspect the measurement is inconclusive.
>>
>> Unfortunately it doesn't. :-(
> 
> Actually, multiple local(8) processes are used only when delivery
> is slow enough. 

Ah - OK.

> Now this 10ms delay in my first example (and your example) is
> suspicious. I strongly suspect that my laptop disk drive has write
> caching enabled.  It is physically not possible to create a queue
> file, fsync it, and then update a bunch of mailboxes and fsync them
> when disk heads need to move.
> 
> With this caching going on, my laptop delivers mail (and syslogs
> to the same disk) as fast as memory can be written, so there is no
> room left to run multiple processes delivering mail.
> 
> On the other hand with my artificial 1000ms delays, there is plenty
> of time for concurrency to pick up the slack. And that is what you
> see happening in my second example.
> 
> Does your mail server disk have write caching enabled, and is the
> cache persistent when power fails? I suppose it does not fail that
> often where you live, compared to this third-world infrastructure
> in the USA that I live on.

Yes, it has a battery backed write cache. But it's also connected to a
UPS even though we almost never have power outages. (This once was a
rescue coordination center. :-))

# hpacucli ctrl slot=0 show | grep -i -e "Write Cache" -e Battery
   Write Cache Size: 24 MB
   No-Battery Write Cache: Disabled
   Battery/Capacitor Count: 1
   Battery/Capacitor Status: OK

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: "pure" virtual and program delivery

[Jeroen Geilman]

On 09/24/2010 10:15 AM, Toni Mueller wrote:

So far, I see the following options:

  * Add the affected domains to mydestination and switch them using the
alias mechanism. Very unwieldy, plus there is no easy way to drop
privileges while delivering email.

  * Use a sieve script to copy such emails to special addresses which
are then handled according to the mechanism outlined above. Very
ugly and error prone, too.

  * Use a different virtual_transport (which one?).

   


You've neglected the simplest (and most commonly used) solution:

* configure a non-existent (or unused) local domain, add it to 
mydestination, and alias virtual users to addresses in that locally 
delivered domain:


mydestination = unused.local.domain, localhost

virtual(5):
some-virtual-u...@virtual-domainal...@unused.local.domain 
[,some-virtual-u...@virtual-domain] <-- to ensure delivery to the 
original recipient as well


/etc/aliases:
alias:f...@bar, pipe:somewhere, mailbox.file, etc, whatever

Any address in that local domain can take advantage of full local(8) 
alias and forward file processing, including delivery to commands or 
pipes as the mail recipient user account.


--
J.

RE: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Grobe, Tony]

Greetings,

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Stan Hoeppner
> Sent: Friday, September 24, 2010 11:08 AM
>
> Matthias Leisi put forth on 9/24/2010 9:12 AM:
> > Hi all,
> >
> > On Thu, Sep 23, 2010 at 12:15 AM, mouss  wrote:
> >
> >>> postfix-dnswl-header
> >>> 222.255.237.6/32  PREPEND X-REPLACEME: low vinabook.com DNSWLId
> 17147
> >>>
> >>> postfix-dnswl-permit
> >>> 222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId
> 17147
> >
> >> no, it was that way since a long time. and sigh, I noticed that a
> long long
> >> time ago but I focused on the header part...
> >
> > Yes, this hasn't changed since... ages. Would it be OK to simple
> leave
> > out the verbose data after permit_auth_destination from a Postfix
> > point of view?
>
> AFAIK, ACCEPT/PERMIT actions don't allow optional text.  I believe
> eliminating the verbose data would be preferable, yes.

For those who may need assistance in crafting the scripts to automate this, 
there is a Sourceforge project [1] that I use on our production server. It 
provides scripts for automatically updating dnswl data, as well as massaging 
the lookup results to your liking.


[1] http://sourceforge.net/projects/dnswl/

Regards,

--
Tony Grobe

Sorry for this --

This communication and any files or attachments transmitted with it may contain 
information that is part of a confidential communication or may otherwise be 
privileged and exempt from disclosure under applicable law. It is intended 
solely for the use of the individual or entity to which it was addressed. If 
you are not the intended recipient, you are hereby notified that any use, 
disclosure, dissemination, or copying of this communication is prohibited by 
law. If you have received this communication in error, please delete it from 
your email system and notify us immediately at (802) 257-5200 x5450 or via 
email at netad...@gsprecision.com.

Re: "pure" virtual and program delivery

[Wietse Venema]

Toni Mueller:
> I've already tried to use transport_map entries to specify "local:"
> delivery for those special emails, which would give me a home to work
> in, plus (I think) reduced privileges, but Postfix still insisted on
> delivering the email by "virtual:", ie, to Dovecot. Restarting Postfix
> did have no effect.

Then you made a mistake somewhere. The transport map is used late
in the mail routing machinery.

To debug:

$ postmap -q u...@example.com pgsql:/etc/postfix/transport_maps

The output should look like "local:" or "local:mumble".

Wietse

Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Matthias Leisi]

On Fri, Sep 24, 2010 at 5:08 PM, Stan Hoeppner  wrote:

 postfix-dnswl-permit
 222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId 17147

> AFAIK, ACCEPT/PERMIT actions don't allow optional text.  I believe
> eliminating the verbose data would be preferable, yes.

OK, fixed:

| j...@main:~/bin> grep "222.255.237.6" /opt/rsync/dnswl/postfix-dnswl-permit
| 222.255.237.6/32permit_auth_destination

-- Matthias

RE: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Grobe, Tony]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Matthias Leisi
> Sent: Friday, September 24, 2010 1:07 PM
> To: postfix-users@postfix.org
> Subject: Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to
> a specific domain -> ERROR mail to postmaster)
>
> On Fri, Sep 24, 2010 at 5:08 PM, Stan Hoeppner 
> wrote:
>
>  postfix-dnswl-permit
>  222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId
> 17147
>
> > AFAIK, ACCEPT/PERMIT actions don't allow optional text.  I believe
> > eliminating the verbose data would be preferable, yes.
>
> OK, fixed:
>
> | j...@main:~/bin> grep "222.255.237.6" /opt/rsync/dnswl/postfix-dnswl-
> permit
> | 222.255.237.6/32permit_auth_destination
>
> -- Matthias

That's fine, and solves the problem of using unmodified files from dnswl, but 
it complicates life for those who were already doing post processing on the 
downloaded data before putting it into production. Your excellent Sourceforge 
project makes it easy for local admins to decide what level of listing they're 
comfortable with subjecting to less stringent checks based on the extra 
information in postfix-dnswl-permit. Now it's all or nothing, or I'm forced to 
reconfigure to make a decision downstream based on header information alone.


-- Tony

This communication and any files or attachments transmitted with it may contain 
information that is part of a confidential communication or may otherwise be 
privileged and exempt from disclosure under applicable law. It is intended 
solely for the use of the individual or entity to which it was addressed. If 
you are not the intended recipient, you are hereby notified that any use, 
disclosure, dissemination, or copying of this communication is prohibited by 
law. If you have received this communication in error, please delete it from 
your email system and notify us immediately at (802) 257-5200 x5450 or via 
email at netad...@gsprecision.com.

Re: Migrating Ver 2.1.5 to Ver 2.5.5

[cajun]

On 09/24/2010 01:41 AM, Ralf Hildebrandt wrote:

* cajun:


I'm migrating a working Ver 2.1.5 server to Ver 2.5.5 (on a new box).

Two questions:

1) I assume it would not be a good thing just to copy main.cf&
master.cf along with the associated .db files to the new server as I
can see lots has changed. I'm assuming that a line-by-line
walk-through and comparison of the old&  new files is prudent copying
over only the portions that I'm sure are relevant.


It's usually safe to copy them and let postfix upgrade them


Thanks Ralf! There's at least 10,000 things I don't know about Postfix. 
This was certainly one of them.





2) I'm pretty sure there are variables in main.cf that are deprecated
from the older version to the newer version. Is there a way that I
can easily locate these changes to the variables?


That's hard :)



Yup, that's what I thought.

Thanks again

--

 Use free-form input where possible.
  14:50:01 up 4 days, 14:02,  4 users,  load average: 0.41, 0.53, 0.45

 Linux Registered User #241685  http://counter.li.org

Re: Migrating Ver 2.1.5 to Ver 2.5.5

[Jerry]

On Thu, 23 Sep 2010 21:53:02 -0500
cajun  articulated:

> 
> I'm migrating a working Ver 2.1.5 server to Ver 2.5.5 (on a new box).
> 
> Two questions:
> 
> 1) I assume it would not be a good thing just to copy main.cf & 
> master.cf along with the associated .db files to the new server as I
> can see lots has changed. I'm assuming that a line-by-line
> walk-through and comparison of the old & new files is prudent copying
> over only the portions that I'm sure are relevant.
> 
> 2) I'm pretty sure there are variables in main.cf that are deprecated 
> from the older version to the newer version. Is there a way that I
> can easily locate these changes to the variables?
> 
> Thanks for any pointers on how I can best accomplish this.

Just out of morbid curiosity, why not upgrade to the latest stable
version 
instead?

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

What I want is all of the power and none of the responsibility.

Re: Migrating Ver 2.1.5 to Ver 2.5.5

[Charles Marcus]

On 2010-09-24 3:51 PM, cajun wrote:
> On 09/24/2010 01:41 AM, Ralf Hildebrandt wrote:
>> It's usually safe to copy them and let postfix upgrade them

> Thanks Ralf! There's at least 10,000 things I don't know about Postfix.
> This was certainly one of them.

Ralf didn't exactly say, so just wanted to make sure you knew you did
actually have to run the upgrade command (as root):

postfix upgrade-configuration

-- 

Best regards,

Charles

Re: OT - Re: Virtual users pop3d suggestions

[Nick Edwards]

I have no idea how gmail allowed this post, since I labelled you as a
spammer (you're an outright troll, but sadly gmail has no function for
trolls, only spammers) after your first post to me.

But you are the one full of it, anyone is free to read the archives of
dovecot to see it affects pop3 DUE TO
dovecot-lda being used, I do not know what part of Timo confirmed this you
do not understand, perhaps english is not your native tongue and I don't
know how to make it clearer to you in your language, either way I don't
care, GPTFO

Now back in the spam bin where you belong marcus


On Fri, Sep 24, 2010 at 9:54 PM, Charles Marcus
wrote:

> On 2010-09-22 6:03 PM, Nick Edwards wrote:
> > By the way, I need to thank you, given your discussion with Timo was one
> > that had set alarm bells off on this, and the thread with Eddie
> > confirmed the risks, can't understand Timo's attitude towards it, but as
> > he said maybe dovecot is not for anyone who needs reliable pop3 in NFS.
>
> PLEASE stop with the FUD.
>
> As has already been beaten to death, dovecot HAS NO RELIABILITY PROBLEMS
> WITH POP3+NFS.
>
> Timo's 'attitude' was *only* with respect to the issues with IMAP+NFS
> (caching) and MULTIPLE delivery servers using dovecot's LDA, and Courier
> and every other IMAP server, under the same circumstances, have the
> exact same issues. His 'attitude' was only because the problem is
> inherent to NFS, and there is really not much else he (or anyone else)
> CAN do about it.
>
> --
>
> Best regards,
>
> Charles
>

Re: PCRE access map mistake

[Noel Jones]

"Michael Orlitzky"  wrote:

>On 09/24/10 10:41, Stan Hoeppner wrote:
>> Sahil Tandon put forth on 9/24/2010 7:12 AM:
>>> On Fri, 2010-09-24 at 05:31:15 -0500, Stan Hoeppner wrote:
>>>
 Michael Orlitzky put forth on 9/23/2010 8:37 PM:

>   # sutton-partners.com
>   /^64\.191\.79\.245$/public_rbls
>
>   # mabel.ca
>   /^70\.38\.108\.42$/ public_rbls
>
>   # dsnews.com
>   /^209\.172\.40\.21[157]$/   public_rbls

 Should the carat and dollar be there?  I just did some tests with

 unknown[64.191.79.245]
 sutton-partners.com[64.191.79.245]
>>>
>>> These aren't the input strings.  See access(5) ...
>>
>> "REGULAR EXPRESSION TABLES
>> ...Depending on the  application, that string is an entire client
>> hostname, an entire client IP address, or an entire mail address."
>>
>> The application check_client_access does both hostname and IP address
>> lookups.  So is the pcre table queried twice in this case, once for
>> hostname and once for IP address?
>>
>
>It would be if the hostname 'unknown' doesn't match something. You can
>actually see the order that the queries get sent to the map if you turn
>on debug logging (it's not just for getting yelled at on the ML!).
>
>The biggest problem I would have with keeping the regular expression map
>is that, since the hostname is checked first, someone could switch his
>hostname to 64.191.79.245.example.com and bypass my blacklist check. I
>might be able to do it with a more complicated regex, but why?

The catch-all I suggested earlier would still be safe.



  -- Noel Jones




>
>Anyway -- thanks everyone for the help -- I switched to a CIDR map last
>night and it's working correctly today.

Re: Migrating Ver 2.1.5 to Ver 2.5.5

[cajun]

On 09/24/2010 03:35 PM, Charles Marcus wrote:

On 2010-09-24 3:51 PM, cajun wrote:

On 09/24/2010 01:41 AM, Ralf Hildebrandt wrote:

It's usually safe to copy them and let postfix upgrade them



Thanks Ralf! There's at least 10,000 things I don't know about Postfix.
This was certainly one of them.


Ralf didn't exactly say, so just wanted to make sure you knew you did
actually have to run the upgrade command (as root):

postfix upgrade-configuration



Oh, that's another one of those 10,000 things I didn't know. Thank you 
Charles for bringing that to my attention!


--

 My sister opened a computer store in Hawaii. She sells C shells by the 
seashore.

  18:25:01 up  1:34,  2 users,  load average: 0.91, 0.88, 0.84

 Linux Registered User #241685  http://counter.li.org

Re: Migrating Ver 2.1.5 to Ver 2.5.5

[cajun]

On 09/24/2010 03:13 PM, Jerry wrote:

On Thu, 23 Sep 2010 21:53:02 -0500
cajun  articulated:



I'm migrating a working Ver 2.1.5 server to Ver 2.5.5 (on a new box).

Two questions:

1) I assume it would not be a good thing just to copy main.cf&
master.cf along with the associated .db files to the new server as I
can see lots has changed. I'm assuming that a line-by-line
walk-through and comparison of the old&  new files is prudent copying
over only the portions that I'm sure are relevant.

2) I'm pretty sure there are variables in main.cf that are deprecated
from the older version to the newer version. Is there a way that I
can easily locate these changes to the variables?

Thanks for any pointers on how I can best accomplish this.


Just out of morbid curiosity, why not upgrade to the latest stable
version
instead?



Only reason is it is a production machine and using Debian Lenny. Not 
that I would have any question at all about whether Postfix was stable 
at all.


--

 My sister opened a computer store in Hawaii. She sells C shells by the 
seashore.

  18:25:01 up  1:34,  2 users,  load average: 0.91, 0.88, 0.84

 Linux Registered User #241685  http://counter.li.org

mysql virtual alias table - want to log lookups with SQL

[Dan Farrell]

Hi All, 

This list has been super helpful in the past, so I am hoping that
you'll have an idea for me.  

Synopsis: does anybody know a way I can insert logging data into a
mysql table when aliases are looked up in a virtual_alias_maps
mysql lookup table?   

I recently set up a mysql lookup table for virtual_alias_maps to use in
addition to some file lookup tables I've been using.  It works great
with a little web interface for creating new aliases.  

But now I want to be able to log access to the lookup table.  Ideally
I'd like to know what server's connecting, what address it's trying to
deliver to, and what I said in return.   

Postfix is currently logging all this stuff through syslog, but i would
really like to integrate the logs into the website.  To do that, I
could parse the logs, but that seems rather tedious.  So I am trying to
figure out a way to add an update into the sql query itself.  

At first I thought mysql triggers would be perfect, failing utterly to
realize that mysql triggers can only be associated with statements that
change the table.  Darn, I thought that was very clever.

Now I'm thinking that maybe I can build something into the mysql SELECT
statement that could take care of this.  But how?  I haven't been able
to think of a way. 

This email constitutes a final effort to figure out how I could do such
a thing.  I hope that someone cleverer than I has thought of a really
slick solution to this.  A sub-query insert inside the select would be
just perfect if such a thing could be done, but my knowledge of mysql
doesn't cover any such option.  

So, anybody have any ideas, before I start filtering syslog logs?

Thanks in advance, 

-- Dan Farrell

Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[Stan Hoeppner]

Grobe, Tony put forth on 9/24/2010 12:36 PM:

>> | j...@main:~/bin> grep "222.255.237.6" /opt/rsync/dnswl/postfix-dnswl-
>> permit
>> | 222.255.237.6/32permit_auth_destination
>>
>> -- Matthias
> 
> That's fine, and solves the problem of using unmodified files from dnswl, but 
> it complicates life for those who were already doing post processing on the 
> downloaded data before putting it into production. Your excellent Sourceforge 
> project makes it easy for local admins to decide what level of listing 
> they're comfortable with subjecting to less stringent checks based on the 
> extra information in postfix-dnswl-permit. Now it's all or nothing, or I'm 
> forced to reconfigure to make a decision downstream based on header 
> information alone.

How does it complicate things for anyone?  Just use the -header file.
It's identical but for "permit_auth_destination" being replaced with
"PREPEND X-REPLACEME:".  SED takes care of your problems in a few
milliseconds.  This is pretty straight forward, especially for someone
already doing "post processing".  Am I missing something?

-- 
Stan