https://bugzilla.novell.com/show_bug.cgi?id=246829 ------- Comment #8 from jnelson-suse@jamponi.net 2007-02-21 06:25 MST ------- (In reply to comment #7)
Looks like correct behavior to me. fetchmail gets a permanent error back to the sender address, so it is pointless to ever retry the message; given the fetchall keyword, the only reasonable reaction is to flush the message else fetchmail would end up trying a message again and again and again that it can never deliver.
It's absolutely INCORRECT behavior. For ANY REASON, fetchmail should not delete a message until it is successfully delivered. That's how fetchmail has behaved (except for bugs) for years, that's what the docs and manpage indicate, and that's what people expect. As for the fetchall keyword, that has nothing to do with deleting messages, only whether or not fetchmail will retrieve *all* messages or only ones it thinks it hasn't seen yet (used in conjunction with the 'keep' and 'uidl' directives). Fetchmail *should* try again and again.
Fetchmail cannot derive from the SMTP dialog that there is a local configuration issue, but must assume that your Postfix doesn't like the sender's address.
I wonder if Postfix's returning a 530 code is the right thing to see here (should be some 400 series code instead, because it's not the sender address at fault, but the history of the SMTP session), and Postfix's refusal of the RSET command is outright scary.
Are there any pertinent Postfix patches in openSUSE or should we take this upstream to Wietse Venema?
I don't know whether postfix should return a 4xx or 5xx error but it's not relevant - fetchmail should not delete the message and continue. That's a bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.