Re: Penelope builds a kernel

[Diego Calleja <grundig@teleline.es>]

Please leave this discussion about fetchmail out of the list....

On 15 Jan 2002, James Antill wrote:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Benjamin LaHaise <bcrl@redhat.com>:
> > > FYI, it's easy to fix, just use the correct ordering of download,
> transmit, 
> > > delete that sendmail and other MTAs use.
> > 
> > I don't understand what you think you're seeing, but I am sure of
> > this; if I had been enough of a drug-addled lunatic to allow fetchmail
> > to delete mail before getting a positive acknowledge from the
> > downstream MTA, someone in the pool of over two thousand people who
> have sent
> > me bug reports and patches would have called me on it some time in the
> > six years of production use well before *you* entered the picture.
> > 
> > It's likely you're being hosed by an MTA that's sending back bogus 2xx
> > responses.  That's happend before.  Fetchmail can't magically cope
> > with MTAs that tell it lies.
> > 
> > Fetchmail *already works the way you recommend* -- as any idiot can
> > verify by reading the short section of the main driver loop where
> > dispatch and delete takes place.  That's been an invariant of the code
> > since day one, and you thus clearly have no bloody idea what you are
> > flaming about.
> 
>  I'll bite, as I've been forced to use it at times.
> 
> 1. User configures fetchmail to download from imap/pop3 account (with
> the messages kept on the server and just recorded -- Ie. nothing is
> deleted server side).
> 
> 2. User has exim as local transport, and also gets normal SMTP
> traffic.
> 
> 3. User enables sender_verify, sender_verify_hosts_callback and
> sender_verify_callback_domains which catches loads of spam and is
> happy.
> 
>  Then...
> 
> .. User runs fetchmail
> .. fetchmail feeds email to exim
> .. exim does callback verification, and refuses email.
> .. fetchmail pretends it has delivered email, so _even if_ you hack your
>   MTA to say don't verify from localhost lost emails will never be
>   delivered by fetchmail (even though they are still on the server,
>   and fetchmail knew they didn't get sent).
> 
> ....and that assumes that you swallow the argument that you should have
> to reconfigure your MTA to work around fetchmail bugs.
> 
> -- 
> James Antill -- james@and.org
> The Hurd itself is aggressively multi-threaded and all of the locking has
> been done with an eye towards multi-processor systems. That said, we have
> not yet used a microkernel that stably supports multiple cpus.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/