Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 01:01 AM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> Ah! The problem seems to be the duplicate_filter_limit! >> >> I set it to 1 and now everything works fine! > > For the last time, you really should use the proper owner- alias > when delivering mail to a list. Then, one local(8) process will > never attempt to deliver more than 1000 recipients. > > As notes in previous reply, the owner- alias is needed for > the "last" alias when you have nested ones. As stated before, I *DID* set up an owner- alias for the alias that resolves to all of the list-members. And this owner- alias seems to work (partly). The envelope address is set to owner-rk: The receiver sees the following header: Return-Path: ... and the verbose log file says: 8< maps_find: aliases: hash:/etc/aliases(0,lock|no_regsub|no_proxy|no_unauth|fold_fix): owner-rk = edvadmin, cgroeschl send attr address = owner-rk input attribute value: owner...@example.com rewrite_clnt: local: owner-rk -> owner...@example.com deliver_alias[7]: set owner attr: owner...@example.com sender: owner...@example.com owner: owner...@example.com 8< However, I didn't notice any change such as separate processing of destination addresses. And I also cannot confirm that it uses a new queue id for each recipient. At which stage should the split happen? Maybe it cannot create a new queue file on error because the filehandle limit is already reached? The verbose log says that it cannot connect to the bounce and the defer service: 8< warning: cannot open file /home/lhock/.forward: Too many open files deliver_mailbox[4039]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock been_here: mailbox lhock: 0 deliver_mailbox[4039]: set user_attr: lhock deliver_mailbox_file[4040]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock spool_uid/gid 1725/12 chown_uid/gid -1/-1 set_eugid: euid 1725 egid 12 set_eugid: euid 89 egid 89 connect to subsystem private/bounce: Too many open files connect to subsystem private/defer: Too many open files warning: AB5663FE62: defer service failure AB5663FE62: to=, relay=local, delay=98, delays=0.06/5.2/0/93, dsn=4.3.0, status=deferred (bounce or trace service failure) flush_add: site example.com id AB5663FE62 match_hostname: example.com ~? samba.intern.example.com match_hostname: example.com ~? localhost.example.com match_hostname: example.com ~? example.com connect to subsystem public/flush: Too many open files flush_add: site example.com id AB5663FE62 status -1 warning: AB5663FE62: flush service failure been_here: forward-done /home/lhock/.forward: 0 been_here: forward-done /home/lhock/.forward: 0 been_here: forward-done /home/lhock/.forward: 0 8< 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: > However, I didn't notice any change such as separate processing of > destination addresses. > > And I also cannot confirm that it uses a new queue id for each > recipient. At which stage should the split happen? When the owner- alias is configured correctly, Postfix creates ONE NEW queue file for ALL recipients in the alias. When the owner- alias is NOT configured correctly, ONE local(8) PROCESS will attempt to deliver ALL recipients in the alias. You should be able to see the difference. Wietse
Re: thanks-- Re: metrics to show benefits of postfix
Jeroen Geilman put forth on 9/22/2010 5:06 PM: > > I don't know if anybody has run tests of this yet (it's still kinda > new), but it would be instructive to compare a "regular" postfix setup > (pre-postscreen) to a postscreen setup with fairly strict settings, with > respect to the load when a large spam dump hits. postfix with or without postscreen will go into stress-adaptive mode: shorten timeouts and hang up after one "error" until the surge passes. This is optional in Postfix 2.6 and default enabled in Postfix 2.7. postscreen blocks known and easy-to-detect zombies. Using built-in mechanisms and a mix of good DNSBLs I have recently not received any direct-from-zombie email. That will change as zombies (and postscreen) evolve. Wietse
Re: Return-path header
On Wed, Sep 22, 2010 at 07:09:44PM -0300, Alexandre Pires wrote: > Thanks Viktor, but how can I set envelop sender address in postfix ? With SMTP: EHLO MAIL FROM: RCPT TO: RCPT TO: DATA Message-Headers: Message Body . On the command-line: sendmail -f envelope-sen...@example.com -i -- \ recipie...@example.net recipie...@example.org < message-source-file -- Viktor.
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 01:11 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> However, I didn't notice any change such as separate processing of >> destination addresses. >> >> And I also cannot confirm that it uses a new queue id for each >> recipient. At which stage should the split happen? > > When the owner- alias is configured correctly, Postfix creates ONE > NEW queue file for ALL recipients in the alias. > > When the owner- alias is NOT configured correctly, ONE local(8) > PROCESS will attempt to deliver ALL recipients in the alias. When the owner- alias IS configured correctly, HOW is delivery distributed to multiple processes? Does it happen in deliver_switch() in recipient.c? 8< if (state.msg_attr.owner != 0 && strcasecmp(state.msg_attr.owner, state.msg_attr.user) != 0) return (deliver_indirect(state)); 8< If not - WHERE does it happen? --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/23/2010 01:11 PM, Wietse Venema wrote: > > Alexander 'Leo' Bergolth: > >> However, I didn't notice any change such as separate processing of > >> destination addresses. > >> > >> And I also cannot confirm that it uses a new queue id for each > >> recipient. At which stage should the split happen? > > > > When the owner- alias is configured correctly, Postfix creates ONE > > NEW queue file for ALL recipients in the alias. > > > > When the owner- alias is NOT configured correctly, ONE local(8) > > PROCESS will attempt to deliver ALL recipients in the alias. > > When the owner- alias IS configured correctly, HOW is delivery > distributed to multiple processes? When you implement owner- alias correctly, the logging will look as shown below. - Postfix creates ONE NEW queue file for ALL recipients in the alias. - Postfix delivers ONE recipient in ONE local(8) delivery process. Wietse Sep 22 12:52:19 hostname postfix/local[3210]: 47307924782: to=, orig_to=, relay=local, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (forwarded as 494B8924781) Sep 22 12:52:19 hostname postfix/qmgr[3182]: 494B8924781: from=, size=498, nrcpt=1 (queue active) Sep 22 12:52:19 hostname postfix/qmgr[3182]: 47307924782: removed Sep 22 12:52:19 hostname postfix/local[3212]: 494B8924781: to=, relay=local, delay=0, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 22 12:52:19 hostname postfix/local[3211]: 494B8924781: to=, relay=local, delay=0, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 22 12:52:19 hostname postfix/local[3215]: 494B8924781: to=, relay=local, delay=0, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Re: postfix/local: Too many open files when opening .forward
On Thu, Sep 23, 2010 at 03:36:27PM +0200, Alexander 'Leo' Bergolth wrote: > On 09/23/2010 01:11 PM, Wietse Venema wrote: > > Alexander 'Leo' Bergolth: > >> However, I didn't notice any change such as separate processing of > >> destination addresses. > >> > >> And I also cannot confirm that it uses a new queue id for each > >> recipient. At which stage should the split happen? > > > > When the owner- alias is configured correctly, Postfix creates ONE > > NEW queue file for ALL recipients in the alias. > > > > When the owner- alias is NOT configured correctly, ONE local(8) > > PROCESS will attempt to deliver ALL recipients in the alias. > > When the owner- alias IS configured correctly, HOW is delivery > distributed to multiple processes? See the deliver_indirect() code. A new message is put in the queue, via cleanup(8). The mail logs typically show: postfix/local[pid]: old-queue-id: to=, ... forwarded as The code is in indirect.c and forward.c. -- Viktor.
Re: Forwarding emails, quick question
O.k., I figured it out. I think. Problem wasn't with the MUA, or postfix (which I knew), or the configuration. It was with me (who would have thought?). Apparently what I am seeing is normal for MTA's and aliases. At least, it works the same for sendmail and postfix. I hadn't realized that. I assumed I had configured something wrong. Thanks for all your help! brian On Wed, Sep 22, 2010 at 6:00 PM, mouss wrote: > Le 22/09/2010 14:40, Brian Pribis a écrit : >> >> Victor, >> >> On Tue, Sep 21, 2010 at 10:39 AM, Victor Duchovni >> wrote: >>> >>> On Tue, Sep 21, 2010 at 08:36:49AM -0400, Brian Pribis wrote: >>> >>> complain to the provider of your MUA. >>> >>> In any case, this thread is closed, the issue has >>> NOTHING to do with Postfix. You can explore the semantics of your MUA >>> in another forum. >>> >> >> Seriously? You are suggesting I contact gmail, mozilla and the >> creators of the mail program on my freebsd machine? > > Brian, with all due respect, you're being too aggressive. let's try to start > again: > > - aliases and virtual aliases only change the _envelope_ recipient. This has > no influence on headers. if you believe it doesn't work that way for you, > please show evidence. > > - the reply button should use the Reply-To: header if present, and the From: > header if not. if you think it doesn't work that way for you, then please > show evidence. > > - your original post says "When the email arrives in my mail client it > arrives with t...@virtual_domain.com in the CC field. ..." if it's so, then > this has nothing to do with virtual aliases. once again, virtual aliases do > not change headers. > > - just in case you don't, you must understand the difference between the > envelope (which is used for routing) and headers (which are part of the > message). > >> [snip] > >
Postfix cluster fail-over
Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a cluster fail-over schema. When the "master" server goes down, the "slave" server goes up. I'm using Debian for my implementation. How can I do that ??? Thanks a lot. Alex
Re: Postfix cluster fail-over
Hello, Yes you can use heartbit with ip failover. With a ptr smtp.test.com A FAILOVER_IP Regards On Thu, 23 Sep 2010 11:36:16 -0700 (PDT), Alejandro Facultad wrote: Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a cluster fail-over schema. When the "master" server goes down, the "slave" server goes up. I'm using Debian for my implementation. How can I do that ??? Thanks a lot. Alex
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 03:48 PM, Victor Duchovni wrote: > On Thu, Sep 23, 2010 at 03:36:27PM +0200, Alexander 'Leo' Bergolth wrote: >> When the owner- alias IS configured correctly, HOW is delivery >> distributed to multiple processes? > > See the deliver_indirect() code. A new message is put in the queue, > via cleanup(8). The mail logs typically show: > > postfix/local[pid]: old-queue-id: to=, ... forwarded as > > > The code is in indirect.c and forward.c. OK, now I know why my messages are not requeued. First of all: The owner- alias IS REALLY set up correctly. :-) But if members of the list are aliases themselves, requeuing via cleanup won't work for them. Unfortunately, this is currently the case for my recipients. That's because deliver_switch() (with the correct owner- address set) first calls deliver_alias(), which resolves the alias (which in my case points to itself). But deliver_alias() also clears the owner attribute! Then control flow returns back to deliver_switch(), but the owner- address is still cleared. ... and the following condition won't match: 8< if (state.msg_attr.owner != 0 && strcasecmp(state.msg_attr.owner, state.msg_attr.user) != 0) return (deliver_indirect(state)); 8< Here is the control flow that leads to the problem: 8< deliver_recipient[9]: local rk recip lh...@example.com exten deliver an-a...@example.com exp_from rk been_here: recipient 9 lh...@example.com: 0 [...] owner: owner...@example.com ^^^ correctly set [...] deliver_switch[10]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from rk deliver_alias[11]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from rk -> finds lhock in ldap-aliases (lhock is an alias for itself) -> resets msg_attr.owner (calls RESET_OWNER_ATTR) deliver_resolve_tree[12]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock deliver_recipient[13]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock been_here: recipient 13 lh...@example.com: 0 [...] owner: null ^^^ owner is cleared now deliver_switch[14]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock deliver_alias[15]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock -> deliver_indirect() should be called here but owner is now null deliver_dotforward[15]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock 8< This means that requeuing via cleanup(8) doesn't work for destination addresses that are aliases. (Which is bad.) For those recipients, delivery is done by the same local(8) process, that's why I didn't see different queue ids. 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 cluster fail-over
On 09/23/2010 08:36 PM, Alejandro Facultad wrote: Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a cluster fail-over schema. Why do you want that ? SMTP has built-in redundancy - just run multiple MX machines. If you want instant IP-level failover, use a frontend loadbalancer with heartbeat detection, but that's really not postfix-related. -- J.
Re: Postfix cluster fail-over
I De: Jeroen Geilman Para: postfix-users@postfix.org Enviado: jueves, 23 de septiembre, 2010 16:12:19 Asunto: Re: Postfix cluster fail-over On 09/23/2010 08:36 PM, Alejandro Facultad wrote: Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a cluster fail-over schema. > Why do you want that ? SMTP has built-in redundancy - just run multiple MX machines. If you want instant IP-level failover, use a frontend loadbalancer with heartbeat detection, but that's really not postfix-related. -- J. Multiple MX machines doesn't suit to me because I need configurattion and accounts replication for high availability. I use a secondary MX in order to storage messages when the main MX goes down.
Re: Postfix cluster fail-over
On 09/23/2010 09:30 PM, Alejandro Facultad wrote: I *De:* Jeroen Geilman *Para:* postfix-users@postfix.org *Enviado:* jueves, 23 de septiembre, 2010 16:12:19 *Asunto:* Re: Postfix cluster fail-over On 09/23/2010 08:36 PM, Alejandro Facultad wrote: Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a cluster fail-over schema. Why do you want that ? SMTP has built-in redundancy - just run multiple MX machines. If you want instant IP-level failover, use a frontend loadbalancer with heartbeat detection, but that's really not postfix-related. -- J. Multiple MX machines doesn't suit to me because I need configurattion and accounts replication for high availability. Instead of replicating accounts, it would make more sense to use a central account database such as sql or ldap to hold that information. You can cluster those, too. I use a secondary MX in order to storage messages when the main MX goes down. Any MX can do that :) Seriously, do you have many issues with postfix not being available ? If this was for georedundancy, or in areas where your internet connection is not dependable, that makes more sense, but just postfix doesn't die that easily. -- J.
Re: Postfix cluster fail-over
A week ago my Postfix server goes down because of error disks...I have to review the disks and finally restore a backupI spent one dady and people from my company had not mail service and they were not happy :) I need a high availability system that let me have a second mail server online INMEDIATELY the first mail server fails. So, Linux HA Heartbeat is my solution, as Kevin told to me. De: Jeroen Geilman Para: postfix-users@postfix.org Enviado: jueves, 23 de septiembre, 2010 16:33:45 Asunto: Re: Postfix cluster fail-over On 09/23/2010 09:30 PM, Alejandro Facultad wrote: I > > > > De: Jeroen Geilman >Para: postfix-users@postfix.org >Enviado: jueves, 23 de septiembre, 2010 16:12:19 >Asunto: Re: Postfix cluster fail-over > >On 09/23/2010 08:36 PM, Alejandro Facultad wrote: >Dear, I want to have two Postfix SMTP servers, one active and one pasive, in a >cluster fail-over schema. >> Why do you want that ? SMTP has built-in redundancy - just run multiple MX machines. If you want instant IP-level failover, use a frontend loadbalancer with heartbeat detection, but that's really not postfix-related. -- J. Multiple MX machines doesn't suit to me because I need configurattion and accounts replication for high availability. Instead of replicating accounts, it would make more sense to use a central account database such as sql or ldap to hold that information. You can cluster those, too. I use a secondary MX in order to storage messages when the main MX goes down. > Any MX can do that :) Seriously, do you have many issues with postfix not being available ? If this was for georedundancy, or in areas where your internet connection is not dependable, that makes more sense, but just postfix doesn't die that easily. -- J.
Re: Postfix cluster fail-over
On 09/23/2010 09:58 PM, Alejandro Facultad wrote: A week ago my Postfix server goes down because of error disks...I have to review the disks and finally restore a backupI spent one dady and people from my company had not mail service and they were not happy :) I need a high availability system that let me have a second mail server online INMEDIATELY the first mail server fails. Or you could build it with better, redundant hardware. It all depends on your needs, I'm not saying your solution isn't valid, just explaining there are other options. -- J.
Re: Forwarding emails, quick question
Le 23/09/2010 16:11, Brian Pribis a écrit : O.k., I figured it out. I think. Problem wasn't with the MUA, or postfix (which I knew), or the configuration. It was with me (who would have thought?). Apparently what I am seeing is normal for MTA's and aliases. At least, it works the same for sendmail and postfix. I hadn't realized that. I assumed I had configured something wrong. happy to see you find out! and happy postfixikating
Re: postfix/local: Too many open files when opening .forward
Alexander 'Leo' Bergolth: > OK, now I know why my messages are not requeued. > > First of all: The owner- alias IS REALLY set up correctly. :-) > > But if members of the list are aliases themselves, requeuing via cleanup > won't work for them. Unfortunately, this is currently the case for my > recipients. I mentioned before that you need an owner- alias for the "final" alias when your aliases are nested. Thus, if one aliase expands into the names of N aliases, each of those N aliases needs an owner- alias. And I did test that it will forward mail to a new queue file, too. /etc/aliases: prealias: alias alias: wietse owner-alias: whatever Sending mail to "prealias" results in mail forwarding to a new queue file: Sep 22 12:54:22 hostname postfix/cleanup[3230]: B08A6924781: message-id=<20100922165422.ae80c924...@hostname.example.com> Sep 22 12:54:22 hostname postfix/local[3246]: AE80C924782: to=, orig_to=, relay=local, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (forwarded as B08A6924781) Sep 22 12:54:22 hostname postfix/qmgr[3224]: B08A6924781: from=, size=498, nrcpt=1 (queue active) Sep 22 12:54:22 hostname postfix/qmgr[3224]: AE80C924782: removed Sep 22 12:54:22 hostname postfix/local[3246]: B08A6924781: to=, relay=local, delay=0, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to file: /dev/null) Sep 22 12:54:22 hostname postfix/local[3246]: B08A6924781: to=, relay=local, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 22 12:54:22 hostname postfix/qmgr[3224]: B08A6924781: removed
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 11:03 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> OK, now I know why my messages are not requeued. >> >> First of all: The owner- alias IS REALLY set up correctly. :-) >> >> But if members of the list are aliases themselves, requeuing via cleanup >> won't work for them. Unfortunately, this is currently the case for my >> recipients. > > I mentioned before that you need an owner- alias for the "final" > alias when your aliases are nested. (Some of) the list _members_ are themselves represented as aliases. So the final alias that directly represents the list has the owner- alias. It isn't possible and it won't make any sense to add an owner- alias for every listmember. It's like the following aliases file: testlist: member1, member2 owner-testlist: root member1: leo member2: testleo You may argue that you already told me that in this case, the owner- alias isn't the final alias and thus it won't work. But that's bad. It should. The other misfeature that I'd like to point out again is the behavior of been_here() when the hash table is full. You praise postfix because "there is no such thing in Postfix as an overflow" but silently doing the wrong thing (simply not doing what the caller expects) will also cause very bad subsequent errors, namely a loop in this case. And this behavior has nothing to do with the reaction you intended: On 09/22/2010 07:06 PM, Wietse Venema wrote: > (there is no such thing in Postfix as an overflow; when memory runs > out, Postfix terminates the operation and tries later). 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: [ Charset ISO-8859-1 unsupported, converting... ] > On 09/23/2010 11:03 PM, Wietse Venema wrote: > > Alexander 'Leo' Bergolth: > >> OK, now I know why my messages are not requeued. > >> > >> First of all: The owner- alias IS REALLY set up correctly. :-) > >> > >> But if members of the list are aliases themselves, requeuing via cleanup > >> won't work for them. Unfortunately, this is currently the case for my > >> recipients. > > > > I mentioned before that you need an owner- alias for the "final" > > alias when your aliases are nested. > > (Some of) the list _members_ are themselves represented as aliases. So > the final alias that directly represents the list has the owner- alias. > It isn't possible and it won't make any sense to add an owner- alias for > every listmember. > > It's like the following aliases file: > testlist: member1, member2 > owner-testlist: root > member1: leo > member2: testleo A mailing list that expands into a bunch of single-member aliases. That would explain why this limitation hasn't been a problem in the past 12 years. > You may argue that you already told me that in this case, the owner- > alias isn't the final alias and thus it won't work. > > But that's bad. It should. > > 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. 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. Wietse
Re: postfix/local: Too many open files when opening .forward
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. I think this idea has been considered before. I (still) think this makes sense. A more interesting question is what to do with: toplist-owner: foo toplist: midlist1, midlist2 midlist1-owner: bar midlist1: a, b, c, d, e midlist2-owner: baz midlist2: x, y, z, w, t If mail delivery to "x" fails for a message addressed to "toplist", should the bounce notice go to "foo" or "baz". The latter potentially involvles forking off lots of copies of the message, one for each sub-list, so there is some incentive to leave the "owner" alone, if one is already set. -- Viktor.
Re: Forwarding emails, quick question
On Thu, Sep 23, 2010 at 10:13:30PM +0200, mouss wrote: > Le 23/09/2010 16:11, Brian Pribis a ?crit : >> O.k., I figured it out. I think. Problem wasn't with the MUA, or >> postfix (which I knew), or the configuration. It was with me (who >> would have thought?). Apparently what I am seeing is normal for >> MTA's and aliases. At least, it works the same for sendmail and >> postfix. I hadn't realized that. I assumed I had configured something >> wrong. > > happy to see you find out! > and happy postfixikating I missed the explanation of what the newly discovered problem was. For the record: - Did "Reply" in fact send mail to an address other than the "From:" address in the message? If so, why? From the headers provided, we see that Postfix added no headers to direct the MUA to Reply elsewhere. - If "Reply" did send a Reply to the "From:" address, what was the real problem? -- Viktor.
Re: postfix/local: Too many open files when opening .forward
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. > > I think this idea has been considered before. I (still) think this > makes sense. A more interesting question is what to do with: > > toplist-owner: foo > toplist: midlist1, midlist2 > midlist1-owner: bar > midlist1: a, b, c, d, e > midlist2-owner: baz > midlist2: x, y, z, w, t > > If mail delivery to "x" fails for a message addressed to "toplist", should > the bounce notice go to "foo" or "baz". The latter potentially involvles > forking off lots of copies of the message, one for each sub-list, so > there is some incentive to leave the "owner" alone, if one is already set. 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. Obviously this has escaped testing. Wietse
Re: postfix/local: Too many open files when opening .forward
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. > > > > I think this idea has been considered before. I (still) think this > > makes sense. A more interesting question is what to do with: > > > > toplist-owner: foo > > toplist: midlist1, midlist2 > > midlist1-owner: bar > > midlist1: a, b, c, d, e > > midlist2-owner: baz > > midlist2: x, y, z, w, t > > > > If mail delivery to "x" fails for a message addressed to "toplist", should > > the bounce notice go to "foo" or "baz". The latter potentially involvles > > forking off lots of copies of the message, one for each sub-list, so > > there is some incentive to leave the "owner" alone, if one is already set. > > 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. Wietse
Re: Postfix cluster fail-over
Alejandro Facultad put forth on 9/23/2010 2:58 PM: > A week ago my Postfix server goes down because of error disks...I have to > review > the disks and finally restore a backupI spent one dady and people from my > company had not mail service and they were not happy :) > > I need a high availability system that let me have a second mail server > online > INMEDIATELY the first mail server fails. > > So, Linux HA Heartbeat is my solution, as Kevin told to me. Sounds to me like (real) RAID is your solution. It would likely be easier to setup than a cluster with heartbeat. -- Stan
PCRE access map mistake
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.
Here's what I think is relevant (full postconf -n at the end). Some
paths were shortened to avoid line wrapping:
smtpd_restriction_classes = all_rbls, public_rbls
all_rbls =
reject_rbl_client jerks.viabit.com,
reject_rbl_client psbl.surriel.com,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client b.barracudacentral.org
public_rbls =
reject_rbl_client psbl.surriel.com,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client b.barracudacentral.org
smtpd_recipient_restrictions =
reject_unauth_destination,
reject_unlisted_recipient,
check_recipient_access hash://recipient_verify_domains,
check_recipient_access hash:/etc/postfix/maps/rfc_addresses,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
reject_non_fqdn_sender,
reject_unknown_reverse_client_hostname,
reject_unknown_sender_domain,
check_client_access pcre://generic_rbl_clients.pcre,
check_sender_access hash:/etc/postfix/maps/backscatter_senders,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
check_policy_service unix:private/policyd-spf,
check_policy_service unix:private/postgrey,
permit
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]
Sep 23 10:05:44 mx1 postfix/smtpd[12164]: NOQUEUE: reject: RCPT from
unknown[64.191.79.245]: 554 5.7.1 Service unavailable; Client host
[64.191.79.245] blocked using jerks.viabit.com; You've been sending
us spam. If you feel this is a mistake, please contact
ab...@viabit.com.; from=
to= proto=ESMTP
helo=<3dr.juicebox360.com>
Sep 23 10:05:54 mx1 postfix/smtpd[12164]: disconnect from
unknown[64.191.79.245]
I've restarted Postfix. What did I screw up?
# postconf -n
address_verify_positive_expire_time = 7d
address_verify_positive_refresh_time = 3h
address_verify_sender = postmas...@viabit.com
append_dot_mydomain = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisd-new:localhost:10024
disable_vrfy_command = yes
inet_interfaces = 127.0.0.1, 65.246.80.15
local_recipient_maps =
local_transport = error:local mail delivery is disabled.
message_size_limit = 1
multi_instance_directories = /etc/postfix-fax1
multi_instance_enable = yes
multi_instance_wrapper = ${command_directory}/postmulti -p --
mydestination =
mydomain = viabit.com
myhostname = mx1.viabit.com
mynetworks_style = host
relay_domains = hash:/etc/postfix/maps/relay_domains,
hash:/etc/postfix/maps/relay_domains-permanent,
proxy:pgsql:/etc/postfix/maps/relay_domains.pgsql
relay_recipient_maps = hash:/etc/postfix/maps/relay_recipient_maps,
hash:/etc/postfix/maps/relay_recipient_maps-permanent,
proxy:pgsql:/etc/postfix/maps/relay_recipient_maps.pgsql
relayhost = mail1.viabit.com
show_user_unknown_table_name = no
smtp_discard_ehlo_keywords = dsn
smtp_mx_session_limit = 3
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_discard_ehlo_keywords = dsn
smtpd_error_sleep_time = 10
smtpd_etrn_restrictions = reject
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_junk_command_limit = 3
smtpd_recipient_restrictions = reject_unauth_destination,
reject_unlisted_recipient, check_recipient_access
hash:/etc/postfix/maps/recipient_verify_domains,check_recipient_access
hash:/etc/postfix/maps/rfc_addresses,
reject_non_fqdn_helo_hostname,reject_invalid_helo_hostname,
reject_non_fqdn_sender, reject_unknown_reverse_client_hostname,
reject_unknown_sender_domain, check_client_access
pcre:/etc/postfix/maps/generic_rbl_clients.pcre,check_sender_access
hash:/etc/postfix/maps/backscatter_senders, reject_rhsbl_client
dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org, check_policy_service
unix:private/policyd-spf, check_policy_service unix:private/postgrey,
permit
smtpd_restriction_classes = all_rbls, public_rbls
smtpd_soft_error_limit = 2
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport_ma
Re: PCRE access map mistake
I don't see your master.cf here. In a setup like this I'd assume you
may be running more than one smtpd for submission. master.cf settings
can override main.cf settings. This might explain why you're seeing
behavior different than what main.cf says you should be seeing. Please
post master.cf.
--
Stan
Michael Orlitzky put forth on 9/23/2010 8: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.
>
> Here's what I think is relevant (full postconf -n at the end). Some
> paths were shortened to avoid line wrapping:
>
> smtpd_restriction_classes = all_rbls, public_rbls
>
> all_rbls =
> reject_rbl_client jerks.viabit.com,
> reject_rbl_client psbl.surriel.com,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client b.barracudacentral.org
>
> public_rbls =
> reject_rbl_client psbl.surriel.com,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
>reject_rbl_client b.barracudacentral.org
>
> smtpd_recipient_restrictions =
> reject_unauth_destination,
> reject_unlisted_recipient,
> check_recipient_access hash://recipient_verify_domains,
> check_recipient_access hash:/etc/postfix/maps/rfc_addresses,
> reject_non_fqdn_helo_hostname,
> reject_invalid_helo_hostname,
> reject_non_fqdn_sender,
> reject_unknown_reverse_client_hostname,
> reject_unknown_sender_domain,
> check_client_access pcre://generic_rbl_clients.pcre,
> check_sender_access hash:/etc/postfix/maps/backscatter_senders,
> reject_rhsbl_client dbl.spamhaus.org,
> reject_rhsbl_helo dbl.spamhaus.org,
> reject_rhsbl_sender dbl.spamhaus.org,
> check_policy_service unix:private/policyd-spf,
> check_policy_service unix:private/postgrey,
> permit
>
> 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]
>
> Sep 23 10:05:44 mx1 postfix/smtpd[12164]: NOQUEUE: reject: RCPT from
> unknown[64.191.79.245]: 554 5.7.1 Service unavailable; Client host
> [64.191.79.245] blocked using jerks.viabit.com; You've been sending
> us spam. If you feel this is a mistake, please contact
> ab...@viabit.com.; from=
> to= proto=ESMTP
> helo=<3dr.juicebox360.com>
>
> Sep 23 10:05:54 mx1 postfix/smtpd[12164]: disconnect from
> unknown[64.191.79.245]
>
> I've restarted Postfix. What did I screw up?
>
>
> # postconf -n
> address_verify_positive_expire_time = 7d
> address_verify_positive_refresh_time = 3h
> address_verify_sender = postmas...@viabit.com
> append_dot_mydomain = no
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = amavisd-new:localhost:10024
> disable_vrfy_command = yes
> inet_interfaces = 127.0.0.1, 65.246.80.15
> local_recipient_maps =
> local_transport = error:local mail delivery is disabled.
> message_size_limit = 1
> multi_instance_directories = /etc/postfix-fax1
> multi_instance_enable = yes
> multi_instance_wrapper = ${command_directory}/postmulti -p --
> mydestination =
> mydomain = viabit.com
> myhostname = mx1.viabit.com
> mynetworks_style = host
> relay_domains = hash:/etc/postfix/maps/relay_domains,
> hash:/etc/postfix/maps/relay_domains-permanent,
> proxy:pgsql:/etc/postfix/maps/relay_domains.pgsql
> relay_recipient_maps = hash:/etc/postfix/maps/relay_recipient_maps,
> hash:/etc/postfix/maps/relay_recipient_maps-permanent,
> proxy:pgsql:/etc/postfix/maps/relay_recipient_maps.pgsql
> relayhost = mail1.viabit.com
> show_user_unknown_table_name = no
> smtp_discard_ehlo_keywords = dsn
> smtp_mx_session_limit = 3
> smtpd_data_restrictions = reject_unauth_pipelining, permit
> smtpd_discard_ehlo_keywords = dsn
> smtpd_error_sleep_time = 10
> smtpd_etrn_restrictions = reject
> smtpd_hard_error_limit = 5
> smtpd_helo_required = yes
> smtpd_junk_command_limit = 3
> smtpd_recipient_restrictions = reject_unauth_destination,
> reject_unlisted_recipient,check_recipient_access
> hash:/etc/postfix/maps/recipient_verify_domains, check_recipient_access
> hash:/etc/postfix/maps/rfc_addresses,
> reject_non_fqdn_helo_hostname,reject_invalid_helo_hostname,
> reject_non_fqdn_sender, reject_un
Re: PCRE access map mistake
On 09/23/10 21:55, Stan Hoeppner wrote: > I don't see your master.cf here. In a setup like this I'd assume you > may be running more than one smtpd for submission. master.cf settings > can override main.cf settings. This might explain why you're seeing > behavior different than what main.cf says you should be seeing. Please > post master.cf. > == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == smtp inet n - n - - smtpd #submission inet n - n - - smtpd # -o smtpd_enforce_tls=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - - smtpd # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #628 inet n - n - - qmqpd # Don't filter locally-submitted mail through amavis. pickupfifo n - n 60 1 pickup -o content_filter= cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard # Disable local delivery #local unix - n n - - local # Disable virtual delivery too #virtual unix - n n - - virtual # And lmtp... #lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scacheunix - - n - 1 scache # AMAVISD-NEW CONTENT FILTER amavisd-new unix- - n - 3 smtp -o smtp_data_done_timeout=1200s -o smtp_send_xforward_command=yes -o max_use=20 # AMAVISD-NEW RE-INJECTION SMTPD INSTANCE 127.0.0.1:10025 inetn - n - - smtpd -o content_filter= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o local_header_rewrite_clients= # Policyd SPF checking. policyd-spf unix - n n - 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf proxywrite unix - - n - 1 proxymap
Re: PCRE access map mistake
I don't see anything in master.cf either. Hmmm Wait a second. My lack of regex foo may be showing. :) 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 If I'm not mistaken, that last expression is going to match pretty much anything and everything. So it looks like you're checking 64.191.79.245 against public_rbls an then with /./ checking it against all_rbls. Comment out the /./ catch all line and see what happens. I *think* that's what is happening anyway. Like I said, my regex foo is rather weak. -- Stan Michael Orlitzky put forth on 9/23/2010 8:59 PM: > On 09/23/10 21:55, Stan Hoeppner wrote: >> I don't see your master.cf here. In a setup like this I'd assume you >> may be running more than one smtpd for submission. master.cf settings >> can override main.cf settings. This might explain why you're seeing >> behavior different than what main.cf says you should be seeing. Please >> post master.cf. >> > > > == > # service type private unpriv chroot wakeup maxproc command + args > # (yes) (yes) (yes) (never) (100) > # == > smtp inet n - n - - smtpd > #submission inet n - n - - smtpd > # -o smtpd_enforce_tls=yes > # -o smtpd_sasl_auth_enable=yes > # -o smtpd_client_restrictions=permit_sasl_authenticated,reject > #smtps inet n - n - - smtpd > # -o smtpd_tls_wrappermode=yes > # -o smtpd_sasl_auth_enable=yes > # -o smtpd_client_restrictions=permit_sasl_authenticated,reject > #628 inet n - n - - qmqpd > > # Don't filter locally-submitted mail through amavis. > pickupfifo n - n 60 1 pickup > -o content_filter= > > cleanup unix n - n - 0 cleanup > qmgr fifo n - n 300 1 qmgr > #qmgr fifo n - n 300 1 oqmgr > tlsmgrunix - - n 1000? 1 tlsmgr > rewrite unix - - n - - trivial-rewrite > bounceunix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > verifyunix - - n - 1 verify > flush unix n - n 1000? 0 flush > proxymap unix - - n - - proxymap > smtp unix - - n - - smtp > # When relaying mail as backup MX, disable fallback_relay to avoid MX loops > relay unix - - n - - smtp > -o fallback_relay= > # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 > showq unix n - n - - showq > error unix - - n - - error > retry unix - - n - - error > discard unix - - n - - discard > > # Disable local delivery > #local unix - n n - - local > > # Disable virtual delivery too > #virtual unix - n n - - virtual > > # And lmtp... > #lmtp unix - - n - - lmtp > > anvil unix - - n - 1 anvil > scache unix - - n - 1 scache > > > # AMAVISD-NEW CONTENT FILTER > amavisd-new unix- - n - 3 smtp > -o smtp_data_done_timeout=1200s > -o smtp_send_xforward_command=yes > -o max_use=20 > > > # AMAVISD-NEW RE-INJECTION SMTPD INSTANCE > 127.0.0.1:10025 inetn - n - - smtpd > -o content_filter= > -o smtpd_delay_reject=no > -o smtpd_client_restrictions=permit_mynetworks,reject > -o smtpd_helo_restrictions= > -o smtpd_sender_restrictions= > -o smtpd_recipient_restrictions=permit_mynetworks,reject > -o smtpd_data_restrictions=reject_unauth_pipelining > -o smtpd_end_of_data_restrictions= > -o smtpd_restriction_classes= > -o mynetworks=127.0.0.0/8 > -o smtpd_error_sleep_time=0 > -o smtpd_soft_error_limit=1001 > -o smtpd_hard_error_limit=1000 > -o smtpd_client_connection_count_limit=0 > -o smtpd_client_connection_rate_limit=0 > -o > receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters > -o local_header_rewrite_clients= > >
Re: PCRE access map mistake
On 09/23/10 22:29, Stan Hoeppner wrote: > I don't see anything in master.cf either. Hmmm > > Wait a second. My lack of regex foo may be showing. :) > > 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 > > If I'm not mistaken, that last expression is going to match pretty much > anything and everything. So it looks like you're checking 64.191.79.245 > against public_rbls an then with /./ checking it against all_rbls. > > Comment out the /./ catch all line and see what happens. I *think* > that's what is happening anyway. Like I said, my regex foo is rather weak. > > You're right, but from pcre_table(5): DESCRIPTION The Postfix mail system uses optional tables for address rewriting, mail routing, or access control. These tables are usually in dbm or db format. Alternatively, lookup tables can be specified in Perl Compatible Regu- lar Expression form. In this case, each input is compared against a list of patterns. When a match is found, the corresponding result is returned and the search is terminated. ... SEARCH ORDER Patterns are applied in the order as specified in the table, until a pattern is found that matches the input string. I'm ever-so-slightly sure that the correct entry is matched first because, postmap -q 64.191.79.245 \ pcre:/etc/postfix/maps/generic_rbl_clients.pcre correctly returns "public_rbls".
Migrating Ver 2.1.5 to Ver 2.5.5
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. Mike -- Never trust a computer you can't lift. - Stan Masor 21:45:01 up 3 days, 20:57, 4 users, load average: 0.38, 0.41, 0.36 Linux Registered User #241685 http://counter.li.org
Re: PCRE access map mistake
Michael Orlitzky put forth on 9/23/2010 9:44 PM: > Alternatively, lookup tables can be specified in Perl Compatible Regu- > lar Expression form. In this case, each input is compared against a > list of patterns. When a match is found, the corresponding result is > returned and the search is terminated. If it is indeed matching on the first pattern, then the question is, why is the search not terminating? In the absence of one of the resident experts shining more light on this, you may need to turn on debug mode for smtpd and see what's really going on. -- Stan
Re: PCRE access map mistake
"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
Re: PCRE access map mistake
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. :) -- Sahil Tandon
Re: Migrating Ver 2.1.5 to Ver 2.5.5
* 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 > 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 :) -- 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: Migrating Ver 2.1.5 to Ver 2.5.5
> 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? I think you could use "postconf -n" on your new system with your old main.cf. It will show you differences between Default and your configuration. You can compare this output line by line with your main.cf to remove default lines. To get an overview of all options, you could use "postconf " to see all options and compare, if the remaining options from your old main.cf are still existing in the newer version. A last step might be to go through "man 5 postconf" and quickly zap over the parameter names taken from your main.cf to see what is deprecated. I am not sure, if this is an elegant way to "upgrade", but I would do it this way :-) Concerning your db-files. If they were created from hash, btree whatever files, I think you should not copy them, simply recreate it by running postmap (see the man page). But I do not give any guarantees ;-) Christian --- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com PGP.sig Description: Signierter Teil der Nachricht
