Re: fetchmail/procmail was: Yet another Linux distribution! :-)
On Sun, 3 May 1998 wrl@gandalf.wconsult.com wrote:
> 'From Bill Leach <bleach@bellsouth.net>'
>
> I don't think so Jason...
>
> Fetchmail is also pretty robust about mail handling but it expect whatever
> it 'hands a message too' to do something with the message.
>
> I won't even pretend to know the nature of the problems but I suspect that
> it deals with the idea that the MTA's all honor the "SIZE" message whereas
> I don't believe that Procmail does. Fetchmail's problem then is that once
> I has 'the ok' from Procmail to transfer the message, there is nothing that
> fetchmail can do if procmail later fails.
No, it should always check the return code of the subprocess (if it is
using procmail) before it erases the message from the server. If the
return code is bad it should never erase the message.
This is what it does with smtp, I see no reason why it couldn't with
procmail as well.
Procmail 'spools' the email into /var/spool/mail just as safely as exim or
sendmail does into it's queue.
You see, the MTA calls procmail to put the message into the mailbox, so it
HAS to be reliable!
> Procmail OTOH was designed to take mail that is presumably already stored
> on the system's HD and process that mail for delivery.
What is the difference from taking mail that is stored on a hard disk from
taking mail that is stored on a remote mailserver? Very little IMHO.
> BTW, the only program that has lost mail on my system has been Procmail
> (configuration error on my part of course but the mail was lost).
> Fetchmail has never lost a message, exim has never lost a message.
I've had older versions of fetchmail drop email when the MTA gave errors
:<
Jason
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: