[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fetchmail/procmail was: Yet another Linux distribution! :-)

'From Bill Leach <bleach@bellsouth.net>'

On Sat, May 02, 1998 at 11:39:44PM -0600, Jason Gunthorpe wrote:
> 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.

We are probably wasting everyone's time now by not looking to see just what
fetchmail/procmail interface actually is...

As I understand it, the fetchmail/procmail interface is a kludge.  Fetchmail
is intended and designed to work with smtp for delivery.  Procmail OTOH
doesn't know anything about smtp.  What sort of error code is procmail
going to give to fetchmail and how is fetchmail to receive this code?

           b.leach@usa.net  LinuxPC@Hotmail.com
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
         See!  They do get some things right!

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: