procmail
[Top] [All Lists]

Re: Procmail doesn't react to incoming mail

1996-12-16 04:32:02
On Monday 16 December 96, at 17 h 4, the keyboard of Tony Nugent 
<tony(_at_)trishul(_dot_)sci(_dot_)gu(_dot_)edu(_dot_)au> wrote:

I retract this disclaimer and can now say categorically that fetchmail
does indeed deliver email locally via smtp.  It works just GREAT!

Disclaimer: I didn't use fetchmail yet, just read the documentation and 
the source code. I can say that I disagree with some statements.

INSTALL:

Actually, using an MDA is now almost always the wrong thing; the MDA
facility has been retained only for people who can't or won't run a
along with local mail and normal Internet mail.  Two: because the port
25 listener returns a positive acknowledge, fetchmail can be sure
you're not going to lose mail to a disk-full or some other
resource-exhaustion problem.

All MDA should return a sensible exit code, telling if they delivered 
successfully or not. At least procmail does it, taking care of the risks 
of "disk full" and so on.

The choice in fetchmail was probably triggered by the horrible ancestor 
popclient which wrote directly to mail spools without even testing the 
return code. Not all MDA are so stupid. 

Since fetchmail tests the return code of the MDA (only if W*EXIT* macros 
are defined, beware), it is probably safe and certainly more efficient to 
give messages to procmail directly.

It does indeed deliver via smtp via my sendmail daemon.  The
`Received: ' header lines show a delivery path exactly as they do if
they are delivered to me via my remote ~/.forward files, and none of
the other header files are touched.  Moreover, not only can fetchmail

I use this at the beginning of my .procmailrc:

:0f
| formail -A"X-Received: from $MAILHOST to $HOSTNAME by $MAILER for 
<$USER>; $DATE" 

Some variables are set by the system (USER for instance), other by 
procmail (DATE=`date`) and other by my the POP client (gwpop) which calls 
procmail with MAILER=gwpop.