On Thu, Aug 14, 2003 at 09:59:27PM -0700, Michael Epting wrote: | I haven't changed any configuration files and I don't see any new | fetchmail bugs, but I'm having big problems the last few days. | | Sid, fetchmail, exim3 (I've been meaning to upgrade to exim4, but I'm | not going to do that when my mail is already broken.) | | I'm seeing stuff like this in my fetchmail log: | | fetchmail: awakened at Thu Aug 14 21:50:22 2003 | fetchmail: 3 messages for epting at popd.ix.netcom.com (57678 octets). | fetchmail: reading message [EMAIL PROTECTED]:1 of 3 (3274 | octets) fetchmail: SMTP error: 501 | <[EMAIL PROTECTED]@[]>: | malformed address: @[]> may not follow | <[EMAIL PROTECTED]
This is exim's response to fetchmail. You have exim's syntax checking turned on, so it will reject any incoming message which is syntactically not a valid email message. This is a good feature if your MTA receives mail directly from the internet because it blocks a fair amount of junk. However, when the only SMTP client exim will ever see is fetchmail, you really can't use any checks in exim itself. That is because fetchmail is the only one that will see the rejection, and then fetchmail just sits tight because it isn't responsible for delivering bounces to the sender, particularly because it doesn't have the (*envelope*) sender address available to send the bounce to. Since you are using exim 3, make sure the variables 'headers_check_syntax' and 'headers_sender_verify' are set to false. | This results in my not getting any mail. Actually, until today the | problem seemed to be spam-related, but as you can see, this problem | message is on debian-user. It is (usually) spam-related. | I've been able to remove the logjam by using Mozilla mail and deleting | messages from the server that have these "bad" headers. They seem to | be in the Reply To: header. | Am I the only one seeing this? Probably :-). (other people probably don't have their software fighting with itself ;-)) | Does anybody know how to tell fetchmail to fetch the "bad" messages | anyway? Since fetchmail isn't the one with the problem, it isn't fetchmail that needs to do anything different. I suppose you could find room for improvement in fetchmail (eg more granularity in recognizing the errors and attempting to deliver the rest of the messages even though one failed, but this would probably require coding) but if you correct your exim setup then the problem will disappear. HTH, -D -- One OS to rule them all, one OS to find them, One OS to bring them all and in the darkness bind them, In the Land of Redmond, where the Shadows lie. http://dman13.dyndns.org/~dman/
pgp00000.pgp
Description: PGP signature
