From: Matthias A. <mat...@gm...> - 2007-04-13 15:41:13
|
Otto Rodusek (AP-SGP) schrieb: > Thanks for the quick reply. I'm confused as to which failure part is > causing fetchmail to "not flush" messages on the ISP server. You say its > because of the "dns" error on my server - however this same "dns" error > happens on many other messages and these messages still gets flushed > from the ISP side.(I have analyzed the successful logs - where > successful means the message is download from ISP and flushed on ISP > side )( I only give you the log of the failed message ie the message > that does not get flushed). It only doesn't get flushed when I have this > messge: > > ........fetchmail: message ro...@am...@mail.sg.gs:1 was not the > expected length (30792 actual != 30347 expected) not flushed. I understand that this line is very misleading (and updating to 6.3.8 won't fix that part). However it is really the 451 reply that fetchmail got back from the SMTP server after the MAIL FROM:<...> command that causes the "not flushed". If it's a 551 reply, then fetchmail has received a definite "this domain doesn't exist" and can decide to drop the message. 400 series codes in mail protocols such as SMTP and LMTP mean "temporary error, retrying later may succeed", 500 series code mean "retrying is pointless, don't bother". HTH MA |