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.