Re: Mail sits in queue
Just to not leave this open-ended. I decided to just switch to Pear::Mail and use that to send directly to our production mail server. I appreciate all of the help provided, but for the small scope of what Postfix was doing and the number of unknown possible issues, it was easier to port my current mail script over to using Pear than to spend who knows how much longer troubleshooting this issue. -Doug On Thu, Feb 5, 2009 at 1:15 PM, Wietse Venema wie...@porcupine.org wrote: Victor Duchovni: On Thu, Feb 05, 2009 at 10:02:47AM -0500, Doug Jaquays wrote: Does: # postkick public pickup W move mail out of the queue in a more timely fashion? It does not seem to be anymore effective than mailq -q. Is there any more verbose logging that I can enable for this situation? PHP just cares that the message gets dumped into the queue and only returns yes it worked or no it didn't, which of course it works. It really seems like the timer to wakeup pickup isn't working properly, though I can't find any reason why it wouldn't be and nothing solid to say it isn't. Search your logs for error/warning/panic/fatal messges from pickup. Add (temporarily) a -v flag to the pickup service in master.cf. Read your logs carefully. It's frustrating to see that other systems set up exactly Well, not *exactly* the same, but you have not yet found out how this one is different. The pickup daemon needs to be able read and write the maildrop queue, and the permissions of the public/pickup socket need to be correct. The maildrop queue should not contain any files that cause pickup severe indigestion (fatal error on processing the queue file in question). My first recommendation is to strace the pickup daemon. Simply strace -o filename -p pickup-process-id and let it run for a few minutes then control-c and share the file with the mailing list. The other recommendation is to FSCK their file systems. The effects of file system corruption are not included in the Postfix guarantee. Wietse This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: Mail sits in queue
On Wed, Feb 4, 2009 at 11:03 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Feb 04, 2009 at 08:58:17AM -0500, Doug Jaquays wrote: - The pickup fifo has been deleted from /var/spool/postfix/public Make sure $queue_directory contains a private/pickup fifo. This is a /var/spool/postfix/public/pickup fifo, there is not a /var/spool/postfix/private/pickup fifo As you can tell from the first of the two lines, it is indeed public not private. That's what I figured but wanted to make sure that you were not talking about two separate things - The O/S is buggy Disable SELinux, App-armor, ... This is entirely possible, though we have other SLES servers running the same environment without issue. I did just turn off AppArmor on the server with this problem, so we'll see what happens. Is the Postfix queue stored on an NFS server? Is the system clock correct? Otherwise, report your findings post AppArmor, ... It is not stored via nfs, everything is stored locally. It's actually stored on a FC lun on our san, but the VM doesn't know that and it doesn't affect file times. Our system times are correct, everything in our organization time syncs. With AppArmor turned off, it is still holding mail. Does: # postkick public pickup W move mail out of the queue in a more timely fashion? It does not seem to be anymore effective than mailq -q. Is there any more verbose logging that I can enable for this situation? PHP just cares that the message gets dumped into the queue and only returns yes it worked or no it didn't, which of course it works. It really seems like the timer to wakeup pickup isn't working properly, though I can't find any reason why it wouldn't be and nothing solid to say it isn't. It's frustrating to see that other systems set up exactly the same as far as I can tell work perfectly fine and this one doesn't. I suppose I could just install the Pear::Mail class and send directly to our main mail server. -Doug This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: Understanding Message Headers
Carlos, The important piece of the headers when you're trying to figure out if the headers are spoofed or your smtp config is broken isthe Received from/by lines. See below On Wed, Feb 4, 2009 at 10:55 AM, Carlos Williams carlosw...@gmail.com wrote: I received an email this morning that I was confused / concerned by. I am looking at the headers however I am not sure exactly how to make this out. This is obviously spam and I did not send myself spam. The sender shows my email address as well as the recipient address however when I view the full message headers, I can see the 'Return Path' is to a different address. Does that mean that the headers were spoofed to look like I was the sender? Just trying to understand how to read this and also make sure I don't have a serious problem here. Return-Path: carlosw...@pten.org X-Original-To: carlosw...@example.com Delivered-To: carlosw...@example.com Received: from localhost (localhost [127.0.0.1]) by $my_mail_server (Postfix) with ESMTP id 9D1FD1FA4BBF for carlosw...@example.com; Wed, 4 Feb 2009 07:59:01 -0500 (EST) Received: from $my_mail_server ([127.0.0.1]) by localhost ($my_mail_server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id These two lines show your mail routing through amavisd tax+kKxS6xrS for carlosw...@example.com;Wed, 4 Feb 2009 07:58:59 -0500 (EST) Received: from amerblind.outbound.ed10.com (pfz2203.tam.ne.jp [210.133.173.203])by $my_mail_server (Postfix) with SMTP id These lines show the originating server, which I'm guessing you are not associated with at all. 935711FA4B51 for carlosw...@example.com; Wed, 4 Feb 2009 07:58:58 -0500 (EST) -Doug This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: Mail sits in queue
On Tue, Feb 3, 2009 at 1:49 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Tue, Feb 03, 2009 at 01:34:10PM -0500, Brian Evans - Postfix List wrote: The php mail() command (on *nix) defaults to come in through the pickup daemon (using the sendmail(1) command). It can also be sent in via the smtpd daemon. Intentionally send a message through your app and immediately check your log. Read and understand entry to delivery(or relay). If you need assistance with the logs, please post a transaction here. No log messages are generated when mail is deposited in the maildrop queue. If pickup is not finding the mail in a timely fashion it is because: - The pickup master.cf entry is busted (no wakeup timer) pickupfifo n - n 60 1 pickup This line appears correct. There is no difference between it and the pickup lines in the other postfix installations we have that work properly. - The pickup fifo has been deleted from /var/spool/postfix/public Make sure $queue_directory contains a private/pickup fifo. This is a /var/spool/postfix/public/pickup fifo, there is not a /var/spool/postfix/private/pickup fifo - File permissions are wrong postfix set-permissions I didn't see anything wrong, and it would seem that permissions would completely stop delivery not just stop it until something jolts it back into action. - The O/S is buggy Disable SELinux, App-armor, ... This is entirely possible, though we have other SLES servers running the same environment without issue. I did just turn off AppArmor on the server with this problem, so we'll see what happens. or http://tomayko.com/writings/that-dilbert-cartoon I'm guessing this won't help :) -Doug This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Mail sits in queue
Hello, We recently moved our anti-virus server to Linux, eTrust ITM and SLES10sp1 with all available updates without going to sp2. When our clients have notifications that match our policy, they are forwarded to the server, which then sends the notification to a php script that parses the information and emails it using the mail() command. Everything appears to work as intended to this point. The problem is that once the mail gets in queue, it seems to almost never be picked up until some form of human interaction wakes up master/pickup/qmgr/whichever-piece-it-is-that's-not-working. The human interaction part seems to be flakey as well. Sometimes flushing the queue works immediately, sometimes it doesn't. I had a message sit in the queue for almost 24 hours and when I tried to run strace on master as some website suggested, it suddenly sent the message through. It does appear to somehow be related to how long it sits idle without sending a message. eTrust screwed up one of their definition releases that tagged javascripts inappropriately about a week ago and it was sending messages very frequently which all made it through. I've searched all of what I would believe to be the obvious causes of my problem and for any errors that explain the issue. I'm sure I'll be asked, so here are the potentially relevant pieces of data: http://pastebin.com/m6bc0ebe8 Doug Jaquays MSU-KCMS Information Technology 1000 Oakland Dr. Kalamazoo, MI 49008 (269) 337-4409 This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: Mail sits in queue
On Tue, Feb 3, 2009 at 12:33 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: Doug Jaquays wrote: Hello, We recently moved our anti-virus server to Linux, eTrust ITM and SLES10sp1 with all available updates without going to sp2. When our clients have notifications that match our policy, they are forwarded to the server, which then sends the notification to a php script that parses the information and emails it using the mail() command. Everything appears to work as intended to this point. The problem is that once the mail gets in queue, it seems to almost never be picked up until some form of human interaction wakes up master/pickup/qmgr/whichever-piece-it-is-that's-not-working. The human interaction part seems to be flakey as well. Sometimes flushing the queue works immediately, sometimes it doesn't. I had a message sit in the queue for almost 24 hours and when I tried to run strace on master as some website suggested, it suddenly sent the message through. It does appear to somehow be related to how long it sits idle without sending a message. eTrust screwed up one of their definition releases that tagged javascripts inappropriately about a week ago and it was sending messages very frequently which all made it through. I've searched all of what I would believe to be the obvious causes of my problem and for any errors that explain the issue. I'm sure I'll be asked, so here are the potentially relevant pieces of data: /_http://pastebin.com/m6bc0ebe8_/ I hope you have more in your master.cf than listed in that pastebin. It is severely lacking some entries. Logs for a transaction entering to delivery would help as well. So I do, I'm not sure how I missed the rest. fixed pastepin: http://pastebin.com/m5b61c858 As for the transaction log. I'm not sure how one can get that when using php's mail() function to send a message. I don't see any obvious answers through google. postconf -n: alias_maps = hash:/etc/aliases defer_transports = That's good. Postfix will not hold things on purpose smtpd_sender_restrictions = hash:/etc/postfix/access Depreciated, suggested to use 'check_sender_access I believe that's something that SLES/YaST put in there. I may have forgot to mention that this is Postfix That file only has the default comments, which looks like the man page, in it. hash:/etc/postfix/access' to avoid future confusion/breakage. transport_maps = hash:/etc/postfix/transport What is in here? This also had just the default comments. This mail server is only being used to send mail from the anti-virus alerts to our support staff. -Doug This email may contain confidential and privileged material for the sole use of the intended recipient and MSU-KCMS. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
