On Fri, May 14, 2004 at 12:29:18PM +0100, Ryan Lumsden wrote:
I have spent better half of the day searching news groups and googling for
the
answer to this problem. No one seems to have a solution.
This is my last chance otherwise I will have to swith to something other then
fetchmail.
That's probably your best option. I have observed a high resistance to
change around here. Please let me know what you choose instead.
I have a similar annoyance with fetchmail; in some circumstances it makes up
arbitary MAIL FROM: lines for SMTP. Given an incoming mail with
Return-Path: <>
then instead of using that, it decides that a null return path is a "bad
thing" and takes an address from the From: header instead. If this is a spam
with
From: <>
then it doesn't like that either, so fetchmail fakes a return path of
<pop3-login-name>@<pop3-host>. In my case, my POP3 login name contains an
'@' sign, so fetchmail fakes up
MAIL FROM:<brian(_at_)example(_dot_)com@pop3.example.com>
which my local MTA rejects as being syntactically invalid. Therefore the
message remains on the server until manually deleted.
This is a case of fetchmail being too clever for its own good; the sender
explicitly said MAIL FROM:<> (as recorded in the Return-Path: header), so if
fetchmail is trying to convert POP3 back to SMTP, that's what it should use.
I've taken some time to investigate other issues with fetchmail and sorting
out patches, but there doesn't seem to be anyone interested in applying
them. I wonder if ESR is trying to force the project to fork, so that he can
have another example to use in the Cathedral and the Bazaar.
Regards,
Brian.