a way to get more verbose logging from the postfix procmail maildrop ?
When I upgraded from 7.3 to 8.2 I switched from
sendmail to postfix on my dial-in workstation.
I am getting errors from deferred mail that confuse
me. Is there a way to get a more detailed log (in
particular the output of the procmail command that
seems to be causing temporary failures.)
Here is an example of the message in /var/log/mail
May 26 22:15:51 swanage postfix/pipe[17490]:
95A5D158AA: to=
* David Corking
When I upgraded from 7.3 to 8.2 I switched from sendmail to postfix on my dial-in workstation.
I am getting errors from deferred mail that confuse me. Is there a way to get a more detailed log (in particular the output of the procmail command that seems to be causing temporary failures.)
man procmail: EXTENDED DIAGNOSTICS Extended diagnostics can be turned on and off through setting the VERBOSE variable.
Here is an example of the message in /var/log/mail
May 26 22:15:51 swanage postfix/pipe[17490]: 95A5D158AA: to=
, orig_to= , relay=procmail, delay=29812, status=deferred (temporary failure)
In my mail log, *deferred* only occurs on an error (afaict) such as 'name service error' or 'server dropped connection', etc.
How can I find out what is causing the failure? (it is happening to *all* my mail - hundred of different messages, and happens repeatedly as long as the mail is 'deferred'.)
procmail never delivers the mail (it does not write anything in its own log.)
If procmail does not log anything, procmail is not being handed the mail or procmail is not available in $PATH or permissions are wrong ??? Are you using fetchmail to get your mail? -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
The 03.05.26 at 22:24, David Corking wrote:
When I upgraded from 7.3 to 8.2 I switched from sendmail to postfix on my dial-in workstation.
Like me.
I am getting errors from deferred mail that confuse me. Is there a way to get a more detailed log (in particular the output of the procmail command that seems to be causing temporary failures.)
Sounds familiar. Check this: are you trying to deliver mail to root at some stage, or do you have a /root/.procmailrc file (even /etc/procmail)? Don't. Postfix can not deliver mail to root using procmail, only to users, because it runs it as "nobody". Mail to root has to be aliased to some other user. Procmail program can not even read those files and silently fails. It is comented in "doc/packages/postfix/html/faq.htm" -- Cheers, Carlos Robinson
--- "Carlos E. R."
The 03.05.26 at 22:24, David Corking wrote:
When I upgraded from 7.3 to 8.2 I switched from sendmail to postfix on my dial-in workstation.
Like me.
I am getting errors from deferred mail that confuse me. Is there a way to get a more detailed log (in particular the output of the procmail command that seems to be causing temporary failures.)
Sounds familiar.
Check this: are you trying to deliver mail to root at some stage, or do you have a /root/.procmailrc file (even /etc/procmail)? Don't. Postfix can not deliver mail to root using procmail, only to users, because it runs it as "nobody". Mail to root has to be aliased to some other user. Procmail program can not even read those files and silently fails.
It is comented in "doc/packages/postfix/html/faq.htm"
Thanks Carlos. In /etc/aliases I had root: david1, \root I used YaST to change it to root: david1 But sadly it did not fix the problem. All my mail is still deferred. __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca
On Wed, 2003-05-28 at 07:35, David Corking wrote:
Thanks Carlos.
In /etc/aliases I had
root: david1, \root
I used YaST to change it to
root: david1
But sadly it did not fix the problem. All my mail is still deferred.
I don't want to sound wrong, but you did remember to run newaliases after you made the changes didn't you? Ken
--- Ken Schneider
Thanks Carlos.
In /etc/aliases I had
root: david1, \root
I used YaST to change it to
root: david1
But sadly it did not fix the problem. All my mail is still deferred.
I don't want to sound wrong, but you did remember to run newaliases after you made the changes didn't you?
Thanks for the reminder, Ken. I think that yast took care of this for me, but I just ran: swanage:~ # newaliases swanage:~ # rcpostfix restart Shutting down mail service (Postfix) done Starting mail service (Postfix) done swanage:~ # rcpostfix reload Reload mail service (Postfix) done Postfix is still logging all the local mails as deferred. :-( __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca
--- David Corking
--- Postfix is still logging all the local mails as deferred.
rpm -q --provides postfix smtp_daemon rpm -q --what-requires smtp_daemon --what-requires: unknown option rpm -q --whatrequires smtp_daemon fetchmail-6.2.1-25 cron-3.0.1-701 mailx-10.3-31 hylafax-4.1.5-43 mutt-1.4i-220 rpm -q --whatprovides smtp_daemon
I tried to simplify by getting rid of anything not
essential.
First I reset all my /etc/sysconfig/postfix values
back to the default and did the simplest possible
dialup setup with the MTA module in YaST2. Mail still
deferred for no reason.
Then I removed spamassassin, perl-spamassassin and
procmail.
rpm thinks all is ok (that I don't *need* procmail)
postfix-2.0.6-8
Yet my log messages changed to this
May 28 11:23:16 swanage postfix/pipe[8984]:
40320158AD: to=
On 05/28/2003 11:45 PM, David Corking wrote:
May 28 11:23:16 swanage postfix/pipe[8984]: 40320158AD: to=
, orig_to= , relay=procmail, delay=163463, status=bounced (Command died with status 1: "/usr/bin/procmail") May 28 11:23:16 swanage pipe[9070]: fatal: pipe_comand: execvp /usr/bin/procmail : No such file or directory This is very puzzling. If postfix doesn't use procmail out of the box, why does my postfix keep trying to send mail to it (obviously fails as I deleted it ;-| ). What is it using it for? Surely not as a delivery agent - it has one built-in. What does it mean by a "relay"?
What do you have set up in Yast>System>Editor for sysconfig>Network>Mail>Postfix>POSTFIX_MDA? -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
The 03.05.28 at 11:45, David Corking wrote:
This is very puzzling. If postfix doesn't use procmail out of the box, why does my postfix keep trying to send mail to it (obviously fails as I deleted it ;-| ). What is it using it for? Surely not as a delivery agent - it has one built-in. What does it mean by a "relay"?
This happened to me at first, but with vscan instead. I had to delete
those emails, I think - after all, they were test messages, and it was the
first time I was using postfix.
This is a "normal" delivery (debug info), for a mail from "root" to "cer":
May 28 19:32:05 nimrodel postfix/pickup[4557]: 0583E1328D: uid=0 from=<root>
May 28 19:32:05 nimrodel postfix/cleanup[4642]: 0583E1328D: message-id=<20030528173204.0583E1328D@nimrodel.valinor>
May 28 19:32:05 nimrodel postfix/qmgr[2005]: 0583E1328D: from=
Why is postfix even calling the pipe program in this simple config?
Maybe it "remembers" the old config for those messsages. Check what happens to "new" emails. If not, try this. In Yast2, go to "Network/Basic", then to "Mail Transfer Agent". Then select "Connection type: Permanent" (I use that even if it is "Dial up"), "Disable AMaViS" - for the moment - and set "Forward root's mail to" some user. My setting is: Outgoing mail Outgoing mail server --> none Outgoing details... Masquerading ... none except: (x) Masquerade local domains (Don't remember why) Incoming mail [x] Accept remote SMTP connections Forward root's mail to: "cer" Incoming details... Downloading... (nothing, manual setup) Aliases... (root --> cer) Virtual domains... a few, like: robin1.listas@tiscali.es cer Then press "finish", and you should be done. Don't use /etc/procmailrc, delete it - I have not being able to use it, it is not read (user nobody) and it will complain. The file /root/.procmailrc is useless anyway. If you have pending mail that doesn't get delivered, you can delete it (but wait a bit first, just in case it needs some time to process it). The command "mailq" will list them, and "postsuper -d queue_id" will delete them, one by one. There are some others I haven't tried, like "-r queue_id" (requeue) that perhaps could work in your case; worth a try, don't you think? If those mails are valuable, they are stored somewhere in /var/spool/postfix/something/?/?/*, the "something" depending on the cause. Then, when it works, and before enabling amavis viruscan - if you want - check first that amavis does work by manually calling "antivir". If it fails, mail delivery will fail as well. -- Cheers, Carlos Robinson
* David Corking
--- David Corking
a écrit : [ big snip ] Yet my log messages changed to this May 28 11:23:16 swanage postfix/pipe[8984]: 40320158AD: to=
, orig_to= , relay=procmail, delay=163463, status=bounced (Command died with status 1: "/usr/bin/procmail") May 28 11:23:16 swanage pipe[9070]: fatal: pipe_comand: execvp /usr/bin/procmail : No such file or directory This is very puzzling. If postfix doesn't use procmail out of the box, why does my postfix keep trying to send mail to it (obviously fails as I deleted it ;-| ). What is it using it for? Surely not as a delivery agent - it has one built-in. What does it mean by a "relay"?
Why is postfix even calling the pipe program in this simple config?
You said that you were retrieving your mail with foremail. Look at ~/.fetchmailrc for *mda*, ie: mda '/usr/bin/procmail -d %T' AND, if you deliver with fetchmail in a postfix system, the procmail recipes will be looked for at ~/.procmailrc (it's in TFM). -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
--- Patrick Shanahan
--- David Corking
a écrit : [ big snip ] Yet my log messages changed to this May 28 11:23:16 swanage postfix/pipe[8984]: 40320158AD: to=
, orig_to= , relay=procmail, delay=163463, status=bounced (Command died with status 1: "/usr/bin/procmail") May 28 11:23:16 swanage pipe[9070]: fatal: pipe_comand: execvp /usr/bin/procmail : No such file or directory This is very puzzling. If postfix doesn't use procmail out of the box, why does my postfix keep trying to send mail to it (obviously fails as I deleted it ;-| ). What is it using it for? Surely not as a delivery agent - it has one built-in. What does it mean by a "relay"?
Well despite the horrific log messages, that last drastic change seemed to fix some things. Mail comes in and goes out now, and gets delivered locally in a reasonably sane manner, and the kind followups from Carlos, Joe and Patrick put this in perspective. First the (not very) bad news -- those log messages were much more drastic than the temporary failure - the messages were actually bounced back out to my ISP (which probably dropped them on the floor - I hope :-/) I suppose the missing procmail seemed like a fatal error to postfix - now my full 'deferred' queue is empty, but although I am missing some mail I don't think it is valuable. Joe:
What do you have set up in Yast>System>Editor for sysconfig>Network>Mail>Postfix>POSTFIX_MDA?
local (when I first set up postfix I had "local", but when I tried to get spam-assassin to work I changed it to "procmail") Patrick:
You said that you were retrieving your mail with foremail. Look at ~/.fetchmailrc for *mda*, ie: mda '/usr/bin/procmail -d %T'
No - retrieving with fetchmail not foremail.
AND, if you deliver with fetchmail in a postfix system, the procmail recipes will be looked for at ~/.procmailrc (it's in TFM).
Now the penny is dropping. I don't have 'mda' declared in /etc/fetchmailrc or in ~/.fetchmailrc, but man 1 fetchmail says it defaults to port 25 (postfix). Postfix first has to filter it (if I specify a content filter like procmail - I no longer have one.) Then postfix resolves aliases. If MDA is set to local, its built-in MDA delivers it to /var/spool/mail. (my procmail recipes in ~/.procmailrc are complex but don't seem to be looked at by postfix in this arrangement - if they were my mail would be in ~/Mail/IN.personal instead of /var/spool/mail/david1 This is ok - I can work on this later.) Carlos :
Why is postfix even calling the pipe program in this simple config?
Maybe it "remembers" the old config for those messsages. Check what happens to "new" emails.
Aha - it does seem like the deferred mail was remembering an old config, which suggests my tweaks were causing the mail to get more and more lost.
delete them, one by one. There are some others I haven't tried, like "-r queue_id" (requeue) that perhaps could work in your case; worth a try, don't you think?
Yes I should have tried it before they were fatally bounced. I will try it next time I change the postfix config (I want procmail and spamassassin back) and I will make a fresh backup of /var/spool/postfix :-) However I will feel safer getting fetchmail to deliver directly to procmail which I never tried before (local port 25 always worked fine - on 7.3 - and probably will again if I am careful.) Thanks all. __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca
* David Corking
--- Patrick Shanahan
a écrit You said that you were retrieving your mail with foremail. Look at ~/.fetchmailrc for *mda*, ie: mda '/usr/bin/procmail -d %T'
No - retrieving with fetchmail not foremail.
My fatfinger, meant fetchmail....
AND, if you deliver with fetchmail in a postfix system, the procmail recipes will be looked for at ~/.procmailrc (it's in TFM).
Now the penny is dropping. I don't have 'mda' declared in /etc/fetchmailrc or in ~/.fetchmailrc, but man 1 fetchmail says it defaults to port 25 (postfix).
with *no* defined 'mda', aiui, postfix will deliver your mail to your local mailbox, usually /var/spool/mail/$USER.
Postfix first has to filter it (if I specify a content filter like procmail - I no longer have one.)
Postfix does not filter mail. It delivers to the addressee, if possible.
Then postfix resolves aliases. If MDA is set to local, its built-in MDA delivers it to /var/spool/mail.
(my procmail recipes in ~/.procmailrc are complex but don't seem to be looked at by postfix in this arrangement - if they were my mail would be in ~/Mail/IN.personal instead of /var/spool/mail/david1 This is ok - I can work on this later.)
Procmail will *never* be called unless you assign it as the 'mda' somewhere, in your case I believe that the assignment should be made in fetchmailrc. [snip]
However I will feel safer getting fetchmail to deliver directly to procmail which I never tried before (local port 25 always worked fine - on 7.3 - and probably will again if I am careful.)
Then assign procmail as the 'mda' in fetchmailrc as: set logfile "/home/pat/.procmail/fetchmail.log" set postmaster "pat" set bouncemail set spambounce set properties "v" set daemon 150 poll linuxfreemail.com with proto IMAP timeout 60 user '$USERNAMEthere' there with password '$PASSWORD' is '$USERNAMEhere' here options fetchall stripcr mda '/usr/bin/procmail -d %T' gud luk, -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
--- Patrick Shanahan
Procmail will *never* be called unless you assign it as the 'mda' somewhere, in your case I believe that the assignment should be made in fetchmailrc.
Thanks Patrick - all I will have to do to make this work is rewrite my local aliases from /etc/aliases into procmail or .forward format (I only have one line) As I postscript I should cross-reference this earlier post I just saw. http://lists.suse.com/archive/suse-linux-e/2003-May/0375.htm/ (since I googled for help rather than CTRL-F'd the May index I missed it) This shows how I got in a mess when I config'd spamassassin. I ended with procmail being called at the wrong time (twice it seems.) If I had read David Krider's message *before* I installed spamassassin this would never have happened. My summary :- As argument to smtpd, procmail is 'filtering' then handing back to postfix for delivery. As 'mailbox_command' procmail is 'delivering'. As far as I can see (and as I experienced) procmail should not be called in both places (at least not without smart* use of command-line options and clever editing of procmailrc 's ) * "smart" = "smarter than I feel right now" Thanks again to all. __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca
* David Corking
As I postscript I should cross-reference this earlier post I just saw.
http://lists.suse.com/archive/suse-linux-e/2003-May/0375.htm/
(since I googled for help rather than CTRL-F'd the May index I missed it)
This shows how I got in a mess when I config'd spamassassin. I ended with procmail being called at the wrong time (twice it seems.) If I had read David Krider's message *before* I installed spamassassin this would never have happened.
My summary :-
As argument to smtpd, procmail is 'filtering' then handing back to postfix for delivery. As 'mailbox_command' procmail is 'delivering'.
As far as I can see (and as I experienced) procmail should not be called in both places (at least not without smart* use of command-line options and clever editing of procmailrc 's )
Yes, calling procmail twice is expensive and unnecessary. I believe that you would be better served by assigning procmail as the 'mda' in fetchmailrc. I read the referenced post by David Krider and am glad that I didn't begin with procmail that way. I started with: Procmail Quick Start: http://www.ii.com/internet/robots/procmail/qs/ from Nancy McGough. It is a very well explained and basic approach to a beginning unknowning user as I was (and still am in many ways). I would suggest that you comment the procmail lines in /etc/postfix/main.cf and try the fetchmail approach. You can always revert if you find that you dislike this approach. gud luk, -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
The 03.05.28 at 21:17, David Corking wrote:
However I will feel safer getting fetchmail to deliver directly to procmail which I never tried before (local port 25 always worked fine - on 7.3 - and probably will again if I am careful.)
But that works for only one user, whereas handling procmail from postfix is systemwide. What I have is, in "/etc/sysconfig/postfix" POSTFIX_MDA="procmail" and suseconfig does the job - it did for me, at least :-) - this translates in "/etc/postfix/main.cf" as: mailbox_command = /usr/bin/procmail at the end of the file. Then, "master.cf" has: # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} I think that's all. -- Cheers, Carlos Robinson
participants (5)
-
Carlos E. R.
-
David Corking
-
Joe Morris (NTM)
-
Ken Schneider
-
Patrick Shanahan