Re: mail for mx2.youngguns.nl loops back to myself
On Thu, 21 Jan 2010 19:35:25 -0500 (EST), wie...@porcupine.org (Wietse Venema) wrote: Martijn de Munnik: Jan 21 17:02:30 marcus postfix/qmgr[16421]: 523FD1C11A: from=mart...@youngguns.nl, size=650750, nrcpt=1 (queue active) Jan 21 17:02:30 marcus postfix/smtp[16449]: 523FD1C11A: host mx-cluster1.one.com[91.198.169.10] said: 450 4.7.1 r...@musicscool.nl: Recipient address rejected: Greylisted for 5 minutes (in reply to RCPT TO command) Jan 21 17:02:30 marcus postfix/smtp[16449]: 523FD1C11A: to=r...@musicscool.nl, relay=mx-cluster2.one.com[91.198.169.11]:25, delay=32, delays=32/0.01/0.57/0.13, dsn=4.7.1, status=deferred (host mx-cluster2.one.com[91.198.169.11] said: 450 4.7.1 r...@musicscool.nl: Recipient address rejected: Greylisted for 5 minutes (in reply to RCPT TO command)) Above, musicscool.nl is delivered directly to its MX hosts: musicscool.nl mail is handled by 10 mx-cluster1.one.com. musicscool.nl mail is handled by 10 mx-cluster2.one.com. Jan 21 17:23:02 marcus postfix/qmgr[16900]: 523FD1C11A: from=mart...@youngguns.nl, size=650750, nrcpt=1 (queue active) Jan 21 17:23:02 marcus postfix/smtp[17064]: 523FD1C11A: to=r...@musicscool.nl, relay=none, delay=1264, delays=1264/0.01/0/0, dsn=5.4.6, status=bounced (mail for mx2.youngguns.nl loops back to myself) Jan 21 17:23:02 marcus postfix/bounce[17065]: 523FD1C11A: sender non-delivery notification: B15A81C76E Jan 21 17:23:02 marcus postfix/qmgr[16900]: 523FD1C11A: removed Above, the queue manager was restarted (pid changes from 16421 to 16900), presumably because some Postfix setting was changed. Ahh my mistake, the transport map is automatically copied between the hosts using a cron job. I forgot about that... I solved it using two separate transport maps. Now, musicscool.nl is NOT delivered directly to its MX hosts. Try undoing the change in Postfix setting. Wietse -- YoungGuns Kasteleinenkampweg 7b 5222 AX 's-Hertogenbosch T. 073 623 56 40 F. 073 623 56 39 www.youngguns.nl KvK 18076568
Re: Change behavior of return code
It works like a charm. Thanks a lot. On Thu, 2010-01-21 at 13:36 -0500, Wietse Venema wrote: Victor Duchovni: On Thu, Jan 21, 2010 at 02:57:17PM +0100, Mickael CANEVET wrote: Hi, I'd like postfix to treat EX_CANTCREAT (73) as temporary failure. I use this command to deliver my mails: mailbox_command = /usr/bin/formail -D 8192 ~/.msgid.cache -s /usr/libexec/dovecot/deliver The problem is that if the filesystem containing home directories is not mounted, formail returns an EX_CANTCREAT error, which is a permanent exception for postfix (by default). Is it possible to tell postfix to not reject permanently this kind of error ? /etc/postfix/main.cf: require_home_directory = yes Wietse signature.asc Description: This is a digitally signed message part
SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Stan Hoeppner put forth on 1/22/2010 1:28 AM: I've wondered for a couple of months why my rbl check is being skipped. I've not seen a spamhaus entry in my logs since Sept 25 '09. Interestingly, postgrey is being called now and then, and it is after the rbl check in main.cf. Any idea why my rbl check is being skipped? What have I screwed up to cause this? Bad form replying to my own post but... After a hint from Ralf, I started digging around and here is what I found: 1. Spamhaus has banned Google Public DNS resolver queries. I didn't know this until today. If Postfix is using Google Public DNS resolvers, rbl queries to zen.spamhaus.org fail but Postfix (Debian Lenny 2.5.5-1.1) logs NOTHING about it. Not the query attempt, not the failure, zilch, nut'n. This explains why I haven't seen any zen entries in my log since Sept 25 last year, apparently the day I switched to Google DNS resolvers. A total lack of log entries makes troubleshooting anything very difficult. Thanks to Ralf's off list suggestion, I was able to start troubleshooting down the correct path. 2. For other dns resolvers that Spamhaus doesn't like, such as a few under the CenturyLink umbrella (former Embarq/Sprint resolvers) an error is logged, such as: Jan 22 05:27:53 greer postfix/smtpd[19251]: warning: 50.211.118.82.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=50.211.118.82.zen.spamhaus.org type=A: Host not found, try again 3. Sometime between my switch to the Google resolvers and today, Spamhaus decided to ban my previous Embarq resolvers. So, when I switched back to the old ones, I got errors like that above, and my zen queries still failed. I dug around through some very old paperwork and found a set of old Sprint resolvers in Kansas City I'd never actually used which aren't banned by Spamhaus. Turns out this is probably a good thing since the resolvers I found that work are also closest physically and electrically, the primary being 4 hops and 35ms away, the secondary 7 hops and 40ms away. I'm glad I got this solved. I really wish that when I was using the Google resolvers that Postfix would have been logging some kind of errors. If it had, I'd have known I had a real problem much sooner. The total lack of log entries for ~3 months is what finally jolted me to look into this. This is a sad state of affairs. So the question at this point is, why didn't Postfix log any errors when NXDOMAIN domain was returned, but did log errors when SERVFAIL is returned? -- Stan
Email address with leading whitespace rejected
Messages containing leading whitespace in the recipient address are rejected. Example: Jan 22 08:32:41 vps10 postfix/smtpd[5937]: NOQUEUE: reject: RCPT from smtpout.eastlink.ca[24.222.0.30]: 550 5.1.1 soli...@example.com: Recipient address rejected: User unknown in virtual alias table; from=dba...@example2.com to= soli...@example.com proto=ESMTP helo=mta03.eastlink.ca soli...@example.com is a legitimate and functioning mail account. I'm guessing that the sender has a bad address book entry, like soli...@example.com -- a leading space before the address. Is there a good reason why Postfix doesn't simply ignore a leading space like this? Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? Thanks.
Re: Email address with leading whitespace rejected
* Doug Robbins drobb...@smartlabrador.ca: Messages containing leading whitespace in the recipient address are rejected. Example: Jan 22 08:32:41 vps10 postfix/smtpd[5937]: NOQUEUE: reject: RCPT from smtpout.eastlink.ca[24.222.0.30]: 550 5.1.1 soli...@example.com: Recipient address rejected: User unknown in virtual alias table; from=dba...@example2.com to= soli...@example.com proto=ESMTP helo=mta03.eastlink.ca soli...@example.com is a legitimate and functioning mail account. But soli...@example.com isn't. I'm guessing that the sender has a bad address book entry, like soli...@example.com -- a leading space before the address. Yes, probably. Is there a good reason why Postfix doesn't simply ignore a leading space like this? Garbage in, garbage out? Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? Hm, you could try and alias soli...@example.com to soli...@example.com But how??? -- 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: Email address with leading whitespace rejected
Doug Robbins: Messages containing leading whitespace in the recipient address are rejected. Only if the recipient does not exist. Example: Jan 22 08:32:41 vps10 postfix/smtpd[5937]: NOQUEUE: reject: RCPT from smtpout.eastlink.ca[24.222.0.30]: 550 5.1.1 soli...@example.com: Recipient address rejected: User unknown in virtual alias table; from=dba...@example2.com to= soli...@example.com proto=ESMTP helo=mta03.eastlink.ca soli...@example.com is a legitimate and functioning mail account. But the client sent soli...@example.com including the quotes. In SMTP, quotes are necessary when a string contains special characters. Postfix does not attempt to typo-correct quoted strings. Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? The most practical solution is to educate the user (it might take a long time to get the client software fixed so it better handles stupid data-entry errors like this one). You can use quoted strings in hash/btree/cdb/dbm aliases(5) maps soliver: soliver I don't think that Postfix supports quoted strings in any form of virtual aliases or in canonical maps, not even with *SQL or LDAP. Finally, Postfix 2.7 can compensate for almost all forms of SMTP client-side brain damage with the smtpd_command_filter feature. /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/braindead.pcre /etc/postfix/braindead.pcre /^(MAIL FROM:)\s+(.+)/$1$2 There's a similar feature for fixing remote SMTP server replies. Wietse
Timeout of SMTP servers
Hi List, RFC2821 section 4.5.3.2 Timeouts reads An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender. When I try to connect to an one.com mx (mx-cluster1.one.com or mx-cluster2.one.com) I notice they will close the connection after about 3 seconds. Why do they do this? Is anybody else using such short timeouts? Thanks, Martijn -- YoungGuns Kasteleinenkampweg 7b 5222 AX 's-Hertogenbosch T. 073 623 56 40 F. 073 623 56 39 www.youngguns.nl KvK 18076568
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Stan Hoeppner wrote: 1. Spamhaus has banned Google Public DNS resolver queries. Stan, Do you have a good enough reason to not run your own name resolver on your front MX machine? IMO relying on third parties for DNS on an MX is bad design. Mikael
Re: Email address with leading whitespace rejected
On 22-Jan-2010 10:11 AM, Wietse Venema wrote: Doug Robbins: Messages containing leading whitespace in the recipient address are rejected. Only if the recipient does not exist. Example: Jan 22 08:32:41 vps10 postfix/smtpd[5937]: NOQUEUE: reject: RCPT from smtpout.eastlink.ca[24.222.0.30]: 550 5.1.1 soli...@example.com: Recipient address rejected: User unknown in virtual alias table; from=dba...@example2.com to= soli...@example.com proto=ESMTP helo=mta03.eastlink.ca soli...@example.com is a legitimate and functioning mail account. But the client sent soli...@example.com including the quotes. In SMTP, quotes are necessary when a string contains special characters. Postfix does not attempt to typo-correct quoted strings. Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? The most practical solution is to educate the user (it might take a long time to get the client software fixed so it better handles stupid data-entry errors like this one). You can use quoted strings in hash/btree/cdb/dbm aliases(5) maps soliver: soliver I don't think that Postfix supports quoted strings in any form of virtual aliases or in canonical maps, not even with *SQL or LDAP. Finally, Postfix 2.7 can compensate for almost all forms of SMTP client-side brain damage with the smtpd_command_filter feature. /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/braindead.pcre /etc/postfix/braindead.pcre /^(MAIL FROM:)\s+(.+)/$1$2 There's a similar feature for fixing remote SMTP server replies. Wietse Thanks for that. As I'm using virtual aliases and a pre-2.7 Postfix it seems that education is the solution Doug
Re: Email address with leading whitespace rejected
On Fri, Jan 22, 2010 at 09:40:58AM -0330, Doug Robbins wrote: Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? A milter could remove recipients with spaces and add back ones without spaces. To do it completely cleanly, I think you'd also need to mess with message headers (so that all recipients saw corrected To and Cc headers, since smfi_addrcpt and smfi_delrcpt mess with the envelope, not the headers). Much, much better would be to get dbaron to fix his address book :) -- Noah Sheppard Assistant Computer Resource Manager Taylor University CSE Department nshep...@cse.taylor.edu
Re: Email address with leading whitespace rejected
On Fri, Jan 22, 2010 at 02:13:17PM +0100, Ralf Hildebrandt wrote: Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? Hm, you could try and alias soli...@example.com to soli...@example.com But how??? The lookup keys and RHS values for virtual(5) are in rfc822 format. A PCRE table can take care of this: /^ soliver@example\.com$/ soli...@example.com This said, far better to just reject this, and let the sender correct their address list. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Email address with leading whitespace rejected
* Victor Duchovni victor.ducho...@morganstanley.com: This said, far better to just reject this, and let the sender correct their address list. Yes. -- 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: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Stan Hoeppner: 1. Spamhaus has banned Google Public DNS resolver queries. I didn't know this until today. If Postfix is using Google Public DNS resolvers, rbl queries to zen.spamhaus.org fail but Postfix (Debian Lenny 2.5.5-1.1) logs NOTHING about it. Not the query attempt, not the failure, zilch, nut'n. This explains why I The query returns NXDOMAIN. No-one has asked me to log all the NXDOMAIN results for DNSBL queries. Wietse With query through Google DNS the host is not listed in zen.spamhaus.org: % dig @8.8.8.8 a 105.49.136.89.zen.spamhaus.org ; DiG 9.6.1-P1 @8.8.8.8 a 105.49.136.89.zen.spamhaus.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 50578 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;105.49.136.89.zen.spamhaus.org.IN A ;; AUTHORITY SECTION: zen.spamhaus.org. 150 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1001221345 3600 600 432000 150 ;; Query time: 169 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan 22 08:48:32 2010 ;; MSG SIZE rcvd: 112 With direct query, the host is listed as you can see for yourself.
Re: Email address with leading whitespace rejected
Victor Duchovni: On Fri, Jan 22, 2010 at 02:13:17PM +0100, Ralf Hildebrandt wrote: Is there something I can do to avoid these rejections (other than the obvious -- get dba...@example2.com to fix his address book)? Hm, you could try and alias soli...@example.com to soli...@example.com But how??? The lookup keys and RHS values for virtual(5) are in rfc822 format. A PCRE table can take care of this: /^ soliver@example\.com$/ soli...@example.com This said, far better to just reject this, and let the sender correct their address list. Virtual alias lookups are done in the unquoted form, while canonical map lookups are in quoted form. So, the above form is good for canonical mapping, but virtual alias mapping would require that the quotes be stripped: /^ soli...@example\.com$/ soli...@example.com (Normally, Postfix transforms addresses to unquoted form because the RFC supports multiple ways to quote the same string. Perhaps to make canonical mappings look more like local aliases, canonical mapping lookups use the external form; but that does not work. Unlike postalias, the postmap command can't blindly apply email quoting rules to its input). Wietse
Re: Best Suggestion For Blacklisting Senders
On Thu, Jan 21, 2010 at 2:43 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: This is a client IP not a sender, e. g. 'MAIL FROM: br...@example.com' The IP should go into a file referenced by a check_client_access restriction. I think I still don't have a understanding at how to properly read / understand message headers in order to create good filters in Postfix. I am very sorry for my confusion but can someone please tell me what the difference is between these two IP's I show in the headers. I am guessing one IP is the actual 'senders' IP address in which is initiating SMTP from using a client like Outlook / Thunderbird and the other IP I am guessing is the address of the senders SMTP server which establishes a connection with my Postfix MTA, right? Do I at least have this correct? I am looking at these headers: *** Return-path: b.148.1296207.0e628e696f0d1...@mail.wfmc.org X-original-to: car...@iamghost.com Delivered-to: car...@iamghost.com Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.iamghost.com (Postfix) with ESMTP id 8A54C77A8E9 for car...@iamghost.com; Fri, 22 Jan 2010 05:29:33 -0500 (EST) Received: from mail.iamghost.com ([127.0.0.1]) by localhost (iamghost.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eY2CHd1Jva+X for car...@iamghost.com; Fri, 22 Jan 2010 05:29:31 -0500 (EST) Received: from civismtp.uas.coop (civismtp.uas.coop [67.212.170.242]) by mail.iamghost.com (Postfix) with ESMTP id C00DB77A862 for car...@iamghost.com; Fri, 22 Jan 2010 05:29:30 -0500 (EST) Received: from wfmc.org (HELO www.wfmc.org) (192.220.23.216) (smtp-auth username editor, mechanism cram-md5) by civismtp.uas.coop (qpsmtpd/0.40) with ESMTPA; Fri, 22 Jan 2010 03:50:52 -0600 Mime-version: 1.0 Reply-to: r.148.1296207.0e628e696f0d1...@mail.wfmc.org From: BPM Times edi...@bpm.com Subject: BPM Times January 2010 List-unsubscribe: mailto:u.148.1296207.0e628e696f0d1...@mail.wfmc.org To: car...@iamghost.com car...@iamghost.com Content-type: multipart/alternative; boundary==_6f6883e747bd1842f9d8a495eff04b03 Date: 01/22/2010 05:29:29 AM Message-id: 20100122095052.183d3192c...@civismtp.uas.coop *** There are two (2) 'Received: from' lines which both have two completely different IP's. One has a HELO 'smtp-auth' username (editor) which I assume this line to be the client sending the message, not the MTA, is this correct? Any clarification is greatly appreciated.
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Mikael Bak put forth on 1/22/2010 7:50 AM: Stan Hoeppner wrote: 1. Spamhaus has banned Google Public DNS resolver queries. Stan, Do you have a good enough reason to not run your own name resolver on your front MX machine? IMO relying on third parties for DNS on an MX is bad design. Due to this fiasco I'm already looking into it. I'd never really considered it an issue until now since it's such a light duty box. Not sure if I have enough memory on the box right now to run a caching resolver. I may need to grab a stick or two. It wouldn't be an issue except for the fact I recently added a bunch of daemons to this box so I could decommission a _really old_ machine (dual P166) that housed the mail store and file shares. That increased the memory footprint quite a bit. Suggestions for a lightweight local resolver daemon on Debian Lenny are welcome. I've never actually used bind before and I've never been a dns admin. I have a vague hazy memory of reading grumblings that bind may be a bit too heavy for using as a local machine resolver. -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On Fri, Jan 22, 2010 at 08:34:35AM -0600, Stan Hoeppner wrote: Mikael Bak put forth on 1/22/2010 7:50 AM: Stan Hoeppner wrote: 1. Spamhaus has banned Google Public DNS resolver queries. Stan, Do you have a good enough reason to not run your own name resolver on your front MX machine? IMO relying on third parties for DNS on an MX is bad design. Due to this fiasco I'm already looking into it. I'd never really considered it an issue until now since it's such a light duty box. Not sure if I have enough memory on the box right now to run a caching resolver. I may need to grab a stick or two. It wouldn't be an issue except for the fact I recently added a bunch of daemons to this box so I could decommission a _really old_ machine (dual P166) that housed the mail store and file shares. That increased the memory footprint quite a bit. Suggestions for a lightweight local resolver daemon on Debian Lenny are welcome. I've never actually used bind before and I've never been a dns admin. I have a vague hazy memory of reading grumblings that bind may be a bit too heavy for using as a local machine resolver. -- Stan pdns-recursor 3.1.7.2 is easy to configure/use and has a tuneable resource footprint. Cheers, Ken
Re: Email address with leading whitespace rejected
On Fri, Jan 22, 2010 at 09:16:07AM -0500, Wietse Venema wrote:
The lookup keys and RHS values for virtual(5) are in rfc822 format.
A PCRE table can take care of this:
Virtual alias lookups are done in the unquoted form, while
canonical map lookups are in quoted form.
No, the cleanup(8) server virtual lookup key and value are in rfc822
quoted form, and will correctly process:
biza...@example.com
internal,comma@example.com,
internal whitespace@example.net,
...
So, the above form is good for canonical mapping, but virtual
alias mapping would require that the quotes be stripped:
See src/cleanup/cleanup_map1n.c around line 118:
quote_822_local(state-temp1, argv-argv[arg]);
if ((lookup = mail_addr_map(maps, STR(state-temp1), propagate)) != 0) {
...
}
Of course the address may not get that far, because the SMTP server
uses the internal form of the address when doing recipient validation:
static int check_rcpt_maps(SMTPD_STATE *state, const char *recipient,
const char *reply_class)
{
...
if (MATCH(rcpt_canon_maps, CONST_STR(reply-recipient))
|| MATCH(canonical_maps, CONST_STR(reply-recipient))
|| MATCH(virt_alias_maps, CONST_STR(reply-recipient)))
return (0);
One could argue that the SMTP server should use the external form of the
recipient for these lookup, to match downstream behaviour in cleanup(8)...
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users
If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.
Re: Email address with leading whitespace rejected
Victor Duchovni:
On Fri, Jan 22, 2010 at 09:16:07AM -0500, Wietse Venema wrote:
The lookup keys and RHS values for virtual(5) are in rfc822 format.
A PCRE table can take care of this:
Virtual alias lookups are done in the unquoted form, while
canonical map lookups are in quoted form.
No, the cleanup(8) server virtual lookup key and value are in rfc822
quoted form, and will correctly process:
biza...@example.com
internal,comma@example.com,
internal whitespace@example.net,
...
So, the above form is good for canonical mapping, but virtual
alias mapping would require that the quotes be stripped:
See src/cleanup/cleanup_map1n.c around line 118:
quote_822_local(state-temp1, argv-argv[arg]);
if ((lookup = mail_addr_map(maps, STR(state-temp1), propagate)) != 0) {
...
}
I stand corrected.
Of course the address may not get that far, because the SMTP server
uses the internal form of the address when doing recipient validation:
static int check_rcpt_maps(SMTPD_STATE *state, const char *recipient,
const char *reply_class)
{
...
if (MATCH(rcpt_canon_maps, CONST_STR(reply-recipient))
|| MATCH(canonical_maps, CONST_STR(reply-recipient))
|| MATCH(virt_alias_maps, CONST_STR(reply-recipient)))
return (0);
One could argue that the SMTP server should use the external form of the
recipient for these lookup, to match downstream behaviour in cleanup(8)...
Indeed. There was no address validation in the initial design and
implementation, so address validation support does not fit as nicely
as one would like. It suffers from code duplication which leads to
inconsistency. But I would rather fight the duplication than the
inconsistency that results from it.
Just like address verification probes reuse the Postfix delivery
mechanisms, address validation should reuse those mechanisms, too.
Otherwise we would just be moving code duplication around to other
places in Postfix, and that is no progress.
Wietse
Re: Email address with leading whitespace rejected
On Fri, Jan 22, 2010 at 10:33:58AM -0500, Wietse Venema wrote: One could argue that the SMTP server should use the external form of the recipient for these lookup, to match downstream behaviour in cleanup(8)... Indeed. There was no address validation in the initial design and implementation, so address validation support does not fit as nicely as one would like. It suffers from code duplication which leads to inconsistency. But I would rather fight the duplication than the inconsistency that results from it. Yes. The tricky part is that smtpd(8) is not always talking to a real cleanup service. When smtpd(8) is a proxy, and especially with delayed proxy filter connections, smtpd(8) has to perform recipient validation independently of any help from cleanup(8). It is tempting to create a rewriting library or service and move envelope recipient rewriting into smtpd(8), because that way we would also gain the ability to validate the output of canonical(5) rewriting and masquerading (masquerading is a form of wild-card rewriting that like wild-card mappings in canonical(5) is difficult to combine with recipient validation). Such a change would make it more difficult to present the original envelope to content filters (delay rewriting to the post-filter stage, as with recieve_override_options). So it would seem that we need a service or library that can answer two questions: - Is this recipient valid? - What addresses does this recipient rewrite to? A library is perhaps more natural, because with a service, it becomes more difficult to customize rewriting via -o name=value for mail that enters via distinct service end-points. (One could perhaps take the view that rewriting should be homogeneous within a given instance, but while multiple instances are a useful tool, I don't want to force people into that design pattern in all non-trivial use-cases). So, I would propose a library, used by at least cleanup(8) and smtpd(8), that, given a resolved recipient from trivial-rewrite, can answer each of the two questions. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On 1/22/2010 6:18 AM, Stan Hoeppner wrote: 1. Spamhaus has banned Google Public DNS resolver queries. I didn't know this until today. If Postfix is using Google Public DNS resolvers, rbl queries to zen.spamhaus.org fail but Postfix (Debian Lenny 2.5.5-1.1) logs NOTHING about it. Not the query attempt, not the failure, zilch, nut'n. Nothing is logged because the DNS server gives an authoritive does not exist answer. That's not an error, it is the expected response when a client is not listed in an RBL. It would be silly to log such events except under debug conditions. At any rate, the log for this would look completely normal; lookup performed, host not listed. The logs would be indistinguishable from any other successful RBL lookup of an unlisted client. 2. For other dns resolvers that Spamhaus doesn't like, such as a few under the CenturyLink umbrella (former Embarq/Sprint resolvers) an error is logged, such as: Jan 22 05:27:53 greer postfix/smtpd[19251]: warning: 50.211.118.82.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=50.211.118.82.zen.spamhaus.org type=A: Host not found, try again An error is logged because this DNS server returned an error. Obviously this DNS server is configured differently WRT spamhaus lookups. I'm glad I got this solved. I really wish that when I was using the Google resolvers that Postfix would have been logging some kind of errors. If it had, I'd have known I had a real problem much sooner. The total lack of log entries for ~3 months is what finally jolted me to look into this. This is a sad state of affairs. So the question at this point is, why didn't Postfix log any errors when NXDOMAIN domain was returned, but did log errors when SERVFAIL is returned? Test RBL lookups with the published test address. 127.0.0.1 should never be listed, 127.0.0.2 should always be listed. $ host 1.0.0.127.zen.spamhaus.org Host 1.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN) $ host 2.0.0.127.zen.spamhaus.org 2.0.0.127.zen.spamhaus.org has address 127.0.0.2 2.0.0.127.zen.spamhaus.org has address 127.0.0.4 2.0.0.127.zen.spamhaus.org has address 127.0.0.10 -- Noel Jones
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Kenneth Marshall put forth on 1/22/2010 8:39 AM: pdns-recursor 3.1.7.2 is easy to configure/use and has a tuneable resource footprint. Got her installed, configured, up and running. Let's see if this improves this spamhaus situation, and a handful a day of other dns related errors I've been getting during mail transactions. Those other errors may be normal, maybe not. This resolver should help me figure that out. I limited the cache to 65536 entries to start with to keep the ram footprint low. That should be plenty for mail, maybe enough to serve my workstation as well. With it nearly empty at this point pdns_recursor is only occupying 1628 Bytes RES and 4016 VIRT. So far so good in the low resource consumption department. Thanks for the suggestion Ken. -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On Fri, Jan 22, 2010 at 10:40:03AM -0600, Stan Hoeppner wrote: Kenneth Marshall put forth on 1/22/2010 8:39 AM: pdns-recursor 3.1.7.2 is easy to configure/use and has a tuneable resource footprint. Got her installed, configured, up and running. Let's see if this improves this spamhaus situation, and a handful a day of other dns related errors I've been getting during mail transactions. Those other errors may be normal, maybe not. This resolver should help me figure that out. I limited the cache to 65536 entries to start with to keep the ram footprint low. You can probably drop it even lower to ~8K entries, without significant impact on cache effectiveness, this is a single host cache for a low query volume host, not a recursive cache for a large network. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Noel Jones put forth on 1/22/2010 10:00 AM: Nothing is logged because the DNS server gives an authoritive does not exist answer. That's not an error, it is the expected response when a client is not listed in an RBL. Hi Noel, I was not venting at Postfix, or Wietse, or any of the devs for that matter, as much as I was venting at the situation. Vietse, Victor, my apologies if it seemed I was venting at you. I was not. My venting should be aimed at Spamhaus. What they've done here is the opposite of transparency. In the case of Google DNS, Spamhaus has pulled something a bit underhanded in my estimation. They don't want people using Google DNS to query Spamhaus zones. That's fine. I have no problem with that. But the way in which they have blocked access creates a silent discard on mail servers using Google DNS, or at least Postfix (I can't speak for other MTAs in this regard). What they should have done is reply with a code that actually generates a visible log error, so an admin, such as myself, can actually see that something is wrong. Instead, all I got from my logs was silence. Multiple months of that deafening silence finally prompted my action as I knew there had to be something wrong. My A/S special sauce is good, but it's not so darn good that I wouldn't at least get one zen lookup in a few months. Thankfully it's good enough that even without any dnsbls I've only been averaging about 1 spam/day in the inbox. Getting zen lookups working again may not help much, but at least I'll get one more shot at killing the junk before letting it through. Anyway, I've got my own resolver up now on my Postfix MX. It appears to be working: greer:/# host 2.0.0.127.zen.spamhaus.org 2.0.0.127.zen.spamhaus.org A 127.0.0.10 2.0.0.127.zen.spamhaus.org A 127.0.0.2 2.0.0.127.zen.spamhaus.org A 127.0.0.4 -- Stan
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On 22/01/2010 16:58, Stan Hoeppner wrote: My venting should be aimed at Spamhaus. What they've done here is the opposite of transparency. In the case of Google DNS, Spamhaus has pulled something a bit underhanded in my estimation. They don't want people using Google DNS to query Spamhaus zones. That's fine. I have no problem with that. But the way in which they have blocked access creates a silent discard on mail servers using Google DNS, or at least Postfix (I can't speak for other MTAs in this regard). They're not doing anything underhand. What they're doing to Google is exactly the same as they do to any other DNS server which exceeds the rate limit for the free lookup. This is documented on the Spamhaus website, along with a note explicitly warning users of free public DNS resolvers that they shouldn't use Spamhaus as it probably won't work. And, after all, why should it? if something is being provided for free, such as an open public DNS resolver, then the operators aren't going to want to pay for commercial access to something that they can't recoup money on by charging their own users. If you're going to use a PBL, such as those provided by Spamhaus, then you really ought to read the documentation first in order to avoid obvious bear traps like the one you fell into. It's not the fault of Spamhaus, Google or Postfix if people don't RTFM. Mark
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On Fri, 22 Jan 2010, Stan Hoeppner wrote: My venting should be aimed at Spamhaus. What they've done here is the opposite of transparency. In the case of Google DNS, Spamhaus has pulled something a bit underhanded in my estimation. They don't want people using Google DNS to query Spamhaus zones. That's fine. I have no problem with that. But the way in which they have blocked access creates a silent discard on mail servers using Google DNS, or at least Postfix (I can't speak for other MTAs in this regard). What they should have done is reply with a code that actually generates a visible log error, so an admin, such as myself, can actually see that something is wrong. Instead, all I got from my logs was silence. Multiple months of that deafening silence finally prompted my action as I knew there had to be something wrong. This is getting away from Postfix so I'll keep this part short but I'll take the opposite side. For Spamhaus to reply with anything other than NXDOMAIN risked some MTA rejecting the mail. For those resolvers they, for whatever reason, do not want to serve, a response that says accept the mail is the only logical response. Anything other than that or a specific reject reason (as encoded in a NXDOMAIN response) is undefined and could cause some MTA to incorrectly reject the mail. When I first set up asking RBL lists, I periodically checked the logs to make sure they were working. Even today, I have a weekly cron job that gives me a report of RBL effectiveness (it's real crude - a simple grep piped to wc -l) and mails it to me. I don't trust that I have anything setup correctly until I see proof in my logs. -- Larry Stone lston...@stonejongleux.com
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
Mark Goodge put forth on 1/22/2010 11:07 AM: It's not the fault of Spamhaus, Google or Postfix if people don't RTFM. I'll give you that. I'd been using zen for years, and sbl-xbl for years before that. When I changed my resolvers to Google from my current provider's (for performance reasons, and not just my MX), I didn't go to spamhaus.org to check and make sure it was ok to do so. It never dawned on me that there would be a problem. I guess because I'm not a dns monkey (not a racial slur, think training monkeys) it just didn't occur to me that there would be a problem. The most interesting part about this, actually, is that when I switched my resolvers back today, I found Google was apparently blocking them also, Centurylink's dsl customer resolvers. This happened within the past 3 months. I don't know what the reason is, but I doubt it's based on query volume given that these resolvers serve residential and small business dsl customers. They were working fine before I switched to Google resolvers. I think it's working again now, though I'll have to wait and see, given my mail flow and the fact that zen and postgrey only get table scraps, and not many at that. ;) -- Stan
Postfix Majordomo problem
Hello I have this puzzle that I can't figure out. I had my mailing list working on openSuSE 11.2 with postfix and majordomo. I've been using majordomo on sendmailf or years with no trouble. I moved to postfix with no trouble and now, suddenly I'm getting nothing through to my lists. I know this might be a majordomo problem but I'm not getting any useful debugging information. And I see that the list is using majordomo as well, so maybe someone can help me. I did test a change in the majordomo alias to a testing program I wrote in perl and tha alias seems to work. And I upped the debugging in postifx to -vv in the master.cf file. But I am completely puzzled. Everything says status=deferred(temporary failure). I have no idea what is happening. I've done a shake out with post fix and it seems to be relaying through the aliases fine. So, I think I might have somehow messed up my majordomo set up, but I can't find anything for the life of me. Aliases look like this majordomo: |/usr/lib/majordomo/wrapper majordomo #majordomo: |/tmp/tmp_mail owner-majordomo:root, majordomo-owner:root, # sample entry for a majordomo mailing-list called test # read /usr/doc/packages/majordomo/README.linux for more information # replace test with a new name and put the administrator into # the owner-test alias instead of root. # #test: |/usr/lib/majordomo/wrapper resend -l test test-outgoing hangout:|/usr/lib/majordomo/wrapper resend -l hangout hangout-outgoing #test-outgoing: :include:/var/lib/majordomo/lists/test hangout-outgoing: :include:/var/lib/majordomo/lists/hangout #test-request: |/usr/lib/majordomo/wrapper majordomo -l test hangout-request:|/usr/lib/majordomo/wrapper majordomo -l hangout #test-approval: owner-test, hangout-approval: owner-hangout, #owner-test-outgoing: owner-test, owner-hangout-outgoing: owner-hangout, #owner-test-request:owner-test, owner-hangout-request: owner-hangout, #owner-test:root, owner-hangout: ruben, The /etc/majordomo file show this # $log -- Where do I write my log? # $log = /var/lib/majordomo/Log; But there is no log and nothing under /var/lib/majordomo/tmp of use either I have the following file permisions www2:/usr/lib/majordomo # ls -al total 360 drwxr-xr-x 3 mdom mdom 472 Dec 19 17:02 . drwxr-xr-x 272 root root 109640 Jan 12 00:38 .. drwxr-xr-x 2 root root 264 Dec 19 17:02 Tools -rwxr-xr-x 1 root root 5267 Oct 19 11:24 archive2.pl -rwxr-xr-x 1 root root 2796 Oct 19 11:24 bounce-remind -rwxr-xr-x 1 root root10693 Oct 19 11:24 config-test -rwxr-xr-x 1 root root51130 Oct 19 11:24 config_parse.pl -rwxr-xr-x 1 root root14215 Oct 19 11:24 digest -rwxr-xr-x 1 root root62513 Oct 19 11:24 majordomo -rwxr-xr-x 1 root root24613 Oct 19 11:24 majordomo.pl -rwxr-xr-x 1 root root 137 Oct 19 11:24 majordomo_version.pl -rwxr-xr-x 1 root root 3793 Oct 19 11:24 request-answer -rwxr-xr-x 1 root root29949 Oct 19 11:24 resend -rw-r--r-- 1 root root10561 Oct 19 11:24 sample.cf -rwxr-xr-x 1 root root 8060 Oct 19 11:24 shlock.pl -rwsr-xr-x 1 root daemon 5896 Oct 19 11:24 wrapper config-test runs as a normal user ru...@www2:/usr/lib/majordomo ./wrapper config-test Config-test for Majordomo - Obvious things: - -- environment variables -- HOME=/usr/lib/majordomo LOGNAME=ruben MAJORDOMO_CF=/etc/majordomo.cf PATH=/bin:/usr/bin SHELL=/bin/sh USER=ruben - euid/egid checks - effective user = mdom (uid 28) effective group = mdom audio video games users gdm (gid 28 17 33 40 100 117 ) -- uid/gid checks -- real user = mdom (uid 28) real group = mdom audio video games users gdm (gid 28 17 33 40 100 117 ) Non obvious things that cause headaches: This is permisions for the list locations ru...@www2:/var/lib ls -al |grep maj drwxr-xr-x 6 mdom mdom 232 2010-01-22 00:59 majordomo ru...@www2:/var/lib/majordomo ls -al total 22 drwxr-xr-x 6 mdom mdom 232 2010-01-22 00:59 . drwxr-xr-x 60 root root 1560 2010-01-12 00:38 .. drwxr-xr-x 2 mdom mdom48 2009-10-19 11:24 archive drwxr-xr-x 2 mdom mdom48 2009-10-19 11:24 digest drwxr-xr-x 2 mdom mdom 704 2010-01-21 21:40 lists -rw-rw-r-- 1 mdom mdom 0 2010-01-22 00:59 Log -rw--- 1 mdom mdom 10504 2010-01-01 14:03 majordomo.cf -rwx-- 1 mdom mdom 8060 2005-05-19 03:52 shlock.pl
Re: SOLVED: rbl check being skipped - Postfix logs no error on NXDOMAIN, does on SERVFAIL
On 1/22/2010 10:58 AM, Stan Hoeppner wrote: Noel Jones put forth on 1/22/2010 10:00 AM: Nothing is logged because the DNS server gives an authoritive does not exist answer. That's not an error, it is the expected response when a client is not listed in an RBL. Hi Noel, I was not venting at Postfix, or Wietse, or any of the devs for that matter, as much as I was venting at the situation. Vietse, Victor, my apologies if it seemed I was venting at you. I was not. My venting should be aimed at Spamhaus. What they've done here is the opposite of transparency. In the case of Google DNS, Spamhaus has pulled something a bit underhanded in my estimation. They don't want people using Google DNS to query Spamhaus zones. That's fine. I have no problem with that. But the way in which they have blocked access creates a silent discard on mail servers using Google DNS, or at least Postfix (I can't speak for other MTAs in this regard). First remember how RBLs work. An authoritive NXDOMAIN means the site is not listed, any other answer means the site is listed. No answer (timeout) is an error that can only mean try again. That doesn't leave any option for an automatic you're blacklisted code. When spamhaus blacklists a site, they answer that every host is not listed via the normal NXDOMAIN. There are good reasons to do this, but it doesn't make the job any easier from this side of the fence. Since they return the normal not listed, no MTA or filter will log anything unusual -- you just won't see any hits. The up side is that it's unlikely that any MTA or filter will mistakenly reject or delay mail. If spamhaus just didn't answer, you would get timeouts in your log but high volume sites could experience a denial of service if every mail transaction suddenly took 30-60 seconds longer than normal. If they list everyone, that creates a worse problem. I suspect your other provider did something manually to return timeouts. While this logged the errors that finally brought this to your attention, this has the very real potential to cause problems, although it's unlikely that anyone with high enough volume to suffer from this uses an external DNS. So while it would be wrong for spamhaus to timeout on everyone, it's not so bad for an ISP's DNS to return timeouts. What they should have done is reply with a code that actually generates a visible log error, so an admin, such as myself, can actually see that something is wrong. As you see now, this is simply not possible with the current implementation of RBLs. This isn't a postfix (or any MTA specific) problem, but rather the way that *all* RBLs are implemented since their invention. For this to change, there would need to be an invention of an agreed-upon method to signal the client that their query succeeded, but is not honored for some reason. This is unlikely to happen anytime soon since there is no obvious technical solution, and it's not a problem the RBL operators are particularly concerned about. Instead, all I got from my logs was silence. Multiple months of that deafening silence finally prompted my action as I knew there had to be something wrong. If you're concerned, hack up a cron script to probe the test addresses and mail yourself the output. I think we've spent enough time on this. -- Noel Jones
Re: Postfix Majordomo problem
On Fri, Jan 22, 2010 at 01:10:51PM -0500, Ruben Safir wrote: Aliases look like this majordomo: |/usr/lib/majordomo/wrapper majordomo This script will run as nobody unless a non-root user owns the aliases.db file from which this alias is read. All tutorials on integrating list manager delivery scripts with Postfix via local aliases(5) describe how to add a secondary aliases file owned by the right user. Another alternative is a dedicated transport, with the user specified in the pipe(8) argument list. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Postfix Majordomo problem
On Fri, Jan 22, 2010 at 01:27:06PM -0500, Wietse Venema wrote: Victor Duchovni: On Fri, Jan 22, 2010 at 01:10:51PM -0500, Ruben Safir wrote: Aliases look like this majordomo: |/usr/lib/majordomo/wrapper majordomo That's how I run majordomo on my machine. If I recall correctly, the wrapper program needs to be installed set-uid, and it needs to be configured at compile time with the right uid/gid information. Wietse Thanks I made it SIUD and the wrapper config-test seems to believe everything is working. But it is still failing. Ruben -- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 Yeah - I write Free Software...so SUE ME The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society. I'm an engineer. I choose the best tool for the job, politics be damned. You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one. © Copyright for the Digital Millennium
Re: Postfix Majordomo problem
On Fri, Jan 22, 2010 at 01:18:10PM -0500, Victor Duchovni wrote: On Fri, Jan 22, 2010 at 01:10:51PM -0500, Ruben Safir wrote: Aliases look like this majordomo: |/usr/lib/majordomo/wrapper majordomo This script will run as nobody unless a non-root user owns the aliases.db file from which this alias is read. All tutorials on integrating list manager delivery scripts with Postfix via local aliases(5) describe how to add a secondary aliases file owned by the right user. Another alternative is a dedicated transport, with the user specified in the pipe(8) argument list. I think that is the current case. I think the wrapper file is suid to mdom.mdom Ruben -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly. -- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 Yeah - I write Free Software...so SUE ME The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society. I'm an engineer. I choose the best tool for the job, politics be damned. You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one. © Copyright for the Digital Millennium
Re: Postfix Majordomo problem
On Fri, Jan 22, 2010 at 01:27:06PM -0500, Wietse Venema wrote: If I recall correctly, the wrapper program needs to be installed set-uid, and it needs to be configured at compile time with the right uid/gid information. Ruben Safir: I made it SIUD and the wrapper config-test seems to believe everything is working. But it is still failing. Of course it is failing, because you are fixing it by hand. YOU have a majordomo configuration error. THIS is the Postfix mailing list. Wietse
Re: Changes in PCRE handling postfix etch vs lenny?
On 2010-01-21 8:23 PM, Stan Hoeppner wrote: Thanks for the heads up. Yes, I'm using IMAP and TB3. So I'm sure this is the same bug. Interestingly, like I said, the filter on Sender works fine for newly arriving messages. It just doesn't work on messages already in the inbox when running the filter manually. I don't have offline mode configured. Here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=184490 If you read the whole thing you'll find your exact problem - works on new mail, but not existing. The workaround is to set the folder for offline mode and let it download everything... not a pleasant thought when you have 16+ accounts, some with hundreds of folders and many GBs of email... -- Best regards, Charles
Re: Changes in PCRE handling postfix etch vs lenny?
On 2010-01-22 5:36 PM, Charles Marcus wrote: Here's the bug: Sorry, meant to send that direct to Stan...
Re: Postfix Majordomo problem
On 01/22/2010 05:22 PM, Wietse Venema wrote: On Fri, Jan 22, 2010 at 01:27:06PM -0500, Wietse Venema wrote: If I recall correctly, the wrapper program needs to be installed set-uid, and it needs to be configured at compile time with the right uid/gid information. Ruben Safir: I made it SIUD and the wrapper config-test seems to believe everything is working. But it is still failing. Of course it is failing, because you are fixing it by hand. YOU have a majordomo configuration error. THIS is the Postfix mailing list. Wietse . Thanks. It was initially installed by openSUSE11.2 ...I'm trying to fix what was working by hand. But my first problem is trying to understand what postfix is telling me or how I can get postfix to tell me more. Ruben
Re: Postfix Majordomo problem
On 01/22/2010 01:18 PM, Victor Duchovni wrote: On Fri, Jan 22, 2010 at 01:10:51PM -0500, Ruben Safir wrote: Aliases look like this majordomo: |/usr/lib/majordomo/wrapper majordomo This script will run as nobody unless a non-root user owns the aliases.db file from which this alias is read. All tutorials on integrating list manager delivery scripts with Postfix via local aliases(5) describe how to add a secondary aliases file owned by the right user. Another alternative is a dedicated transport, with the user specified in the pipe(8) argument list. Could you be kind enough to point me to the FAQs? Nothing I've read so far is helping me understand the problem. Ruben
Re: Postfix Majordomo problem
- Original Message From: Ruben Safir ru...@mrbrklyn.com To: Postfix users postfix-users@postfix.org Sent: Sat, January 23, 2010 12:33:53 AM Subject: Re: Postfix Majordomo problem On 01/22/2010 05:22 PM, Wietse Venema wrote: On Fri, Jan 22, 2010 at 01:27:06PM -0500, Wietse Venema wrote: If I recall correctly, the wrapper program needs to be installed set-uid, and it needs to be configured at compile time with the right uid/gid information. Ruben Safir: I made it SIUD and the wrapper config-test seems to believe everything is working. But it is still failing. Of course it is failing, because you are fixing it by hand. YOU have a majordomo configuration error. THIS is the Postfix mailing list. Wietse . Thanks. It was initially installed by openSUSE11.2 ...I'm trying to fix what was working by hand. But my first problem is trying to understand what postfix is telling me or how I can get postfix to tell me more. Ruben It would help if you posted the log messages you receive along with the information provided here: http://www.postfix.org/DEBUG_README.html. After you do that then we can try and help you. Thanks, Daniel
Re: Postfix Majordomo problem
Ruben Safir: [ Charset ISO-8859-1 unsupported, converting... ] On 01/22/2010 05:22 PM, Wietse Venema wrote: On Fri, Jan 22, 2010 at 01:27:06PM -0500, Wietse Venema wrote: If I recall correctly, the wrapper program needs to be installed set-uid, and it needs to be configured at compile time with the right uid/gid information. Ruben Safir: I made it SIUD and the wrapper config-test seems to believe everything is working. But it is still failing. Of course it is failing, because you are fixing it by hand. YOU have a majordomo configuration error. THIS is the Postfix mailing list. Thanks. It was initially installed by openSUSE11.2 ...I'm trying to fix what was working by hand. But my first problem is trying to understand what postfix is telling me or how I can get postfix to tell me more. You should to install the program from package, instead of trying to fix things by hand. However, if you insist on fixing things by hand, then you don't need Postfix to debug the program. Simply run the /some/where/wrapper majordomo... command by hand, with standard input connected to a file that contains an email message in UNIX mbox format. Majordomo is a Perl script, so you can debug it with all the standard Perl debugging features. This discussion is no longer appropriate for the Postfix mailing list, so this is my last post. Wietse
Re: Postfix Majordomo problem
It would help if you posted the log messages you receive along with the information provided here: http://www.postfix.org/DEBUG_README.html. After you do that then we can try and help you. Thanks, Daniel Thanks Daniel The relevant log area says this: an 22 17:49:47 www2 postfix/local[17734]: 0CD789C2B7: to=hang...@mrbrklyn.com, relay=local, delay=1049, delays=1048/0.05/0/0.71, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:47 www2 postfix/local[17739]: 043719C2BC: to=hang...@nylxs.com, relay=local, delay=376, delays=375/0.18/0/0.58, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:47 www2 postfix/local[17744]: 556449C284: to=majord...@nylxs.com, relay=local, delay=2284, delays=2283/0.01/0/0.57, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:47 www2 postfix/local[17742]: 129A09C25B: to=majord...@nylxs.com, relay=local, delay=4728, delays=4727/0.13/0/0.59, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:47 www2 postfix/cleanup[17556]: CB4A49629E: message-id=2010014947.cb4a496...@www2.mrbrklyn.com Jan 22 17:49:47 www2 postfix/bounce[17757]: 129A09C25B: sender delay notification: CB4A49629E Jan 22 17:49:47 www2 postfix/qmgr[2295]: CB4A49629E: from=, size=2396, nrcpt=1 (queue active) Jan 22 17:49:47 www2 postfix/trivial-rewrite[17733]: warning: do not list domain mrbrklyn.com in BOTH mydestination and virtual_alias_domains Jan 22 17:49:48 www2 postfix/local[17739]: 98A379C25D: to=hang...@mrbrklyn.com, relay=local, delay=4551, delays=4550/0.42/0/0.2, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/cleanup[17556]: 017C19C258: message-id=2010014948.017c19c...@www2.mrbrklyn.com Jan 22 17:49:48 www2 postfix/local[17744]: 7AFB89C25A: to=majord...@mrbrklyn.com, relay=local, delay=4690, delays=4689/0.6/0/0.27, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/cleanup[17783]: 1A3179C260: message-id=2010014948.1a3179c...@www2.mrbrklyn.com Jan 22 17:49:48 www2 postfix/local[17742]: 94E5D9C259: to=majord...@nylxs.com, relay=local, delay=4745, delays=4744/0.44/0/0.41, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/local[17734]: C1FCE56E8A: to=hang...@mrbrklyn.com, relay=local, delay=22800, delays=22800/0.35/0/0.41, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/cleanup[17787]: 3F9379C2AF: message-id=2010014948.3f9379c...@www2.mrbrklyn.com Jan 22 17:49:48 www2 postfix/bounce[17760]: 98A379C25D: sender delay notification: 017C19C258 Jan 22 17:49:48 www2 postfix/local[17767]: CB4A49629E: to=ru...@mrbrklyn.com, relay=local, delay=0.53, delays=0.09/0/0/0.44, dsn=2.0.0, status=sent (delivered to command: exec /usr/bin/procmail) Jan 22 17:49:48 www2 postfix/local[17739]: DEED79C25F: to=hang...@nylxs.com, relay=local, delay=4540, delays=4539/0.53/0/0.37, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/bounce[17759]: 7AFB89C25A: sender delay notification: 1A3179C260 Jan 22 17:49:48 www2 postfix/qmgr[2295]: 1A3179C260: from=, size=2806, nrcpt=1 (queue active) Jan 22 17:49:48 www2 postfix/qmgr[2295]: CB4A49629E: removed Jan 22 17:49:48 www2 postfix/local[17744]: BC32D56E6D: to=majord...@mrbrklyn.com, relay=local, delay=13182, delays=13181/0.65/0/0.35, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/cleanup[17556]: 6A8059629E: message-id=2010014948.6a80596...@www2.mrbrklyn.com Jan 22 17:49:48 www2 postfix/qmgr[2295]: 3F9379C2AF: from=, size=2396, nrcpt=1 (queue active) Jan 22 17:49:48 www2 postfix/trivial-rewrite[17733]: warning: do not list domain mrbrklyn.com in BOTH mydestination and virtual_alias_domains Jan 22 17:49:48 www2 postfix/bounce[17758]: 94E5D9C259: sender delay notification: 3F9379C2AF Jan 22 17:49:48 www2 postfix/qmgr[2295]: 017C19C258: from=, size=2742, nrcpt=1 (queue active) Jan 22 17:49:48 www2 postfix/local[17739]: 3F9379C2AF: to=ru...@mrbrklyn.com, relay=local, delay=0.27, delays=0.19/0.06/0/0.02, dsn=2.0.0, status=sent (delivered to command: exec /usr/bin/procmail) Jan 22 17:49:48 www2 postfix/local[17742]: D922A9C2BA: to=hang...@mrbrklyn.com, relay=local, delay=483, delays=482/0.77/0/0.29, dsn=4.3.0, status=deferred (temporary failure) Jan 22 17:49:48 www2 postfix/local[17734]: F12499C282: to=majord...@nylxs.com, relay=local, delay=2286, delays=2285/0.74/0/0.29, dsn=4.3.0, status=deferred (temporary failure) Not I just mucked with the majordomo.cf file and change the load allowance from 10 to 90: You can force Majordomo to delay any processing if the system load is too # high by uncommenting the following lines. THIS ONLY WORKS if your uptime # command (usually found in /usr/bin/uptime or /usr/bsd/uptime) # returns a string like: # 5:23pm up 5:51, 9 users, load average: 0.19, 0.25, 0.33 # $max_loadavg = 90; # Choose the maximum allowed load # $uptime = `/usr/bin/uptime` if -x '/usr/bin/uptime'; # Get system uptime #$uptime =
Re: Postfix Majordomo problem
On 01/22/2010 07:58 PM, Wietse Venema wrote: Majordomo is a Perl script, so you can debug it with all the standard Perl debugging features. This discussion is no longer appropriate for the Postfix mailing list, so this is my last post. Thanks for the help. What you've told me has been very helpful to getting this debugged. FWIW, I finally, even before this interact, just removed the mdomo packages and reinstalled them. Because, who knows? Maybe I'm overlooking something. It didn't help. I tried to run mail directly through majordomo, as you also pointed out, and it seems to function. That was weird. FWIW...my hard earned experience has taught me that packages aren't the be all of everything, like mana from heaven. There are a lot things I've had to install be hand to get rid of bugs in packages. This isn't intended to get into a flame war on packages, I'm just stating my experience. What do you do when packages don't work? You roll up your sleeves, do a lot of reading, comb though source code, and if your lucky, someone smarter than you, someone like yourself, can give you a moment of their free time and point you in the right direction. And for that, I'm grateful and thank you for your time! Ruben
