Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

Peter Pentchev wrote:
> On Fri, Apr 13, 2007 at 09:30:34PM +0800, Otto Rodusek (AP-SGP) wrote:
>   
>> Matthias Andree wrote:
>>     
>>> Otto Rodusek (AP-SGP) schrieb:
>>>       
>>>> I'm having some minor problems issues with fetchmail v6.3.5.
>>>>         
>>>   
>>>       
>>>> This only happens on junk mails and never on "real" mail.
>>>>         
>>>   
>>>       
>>>> Is there any possible solution to this?? (Currently I have to regularly 
>>>> login to the webmail access on the ISP and manually clean those emails).
>>>>         
>>> Not inside fetchmail.
>>>   
>>>       
>>>> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
>>>> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
>>>> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
>>>>         
>>> As you see here, your local MTA doesn't accept the sender domain,
>>> click4solutions..., and temporarily refuses the message, so fetchmail
>>> tries again at the next poll cycle.
>>>
>>> Messages about size mismatches are warnings (most of the time at least)
>>> and don't make fetchmail abort the delivery voluntarily.
>>>
>>> You might try to blacklist that click4sol... domain in your MTA so it
>>> responds with some code between 500 and 599 inclusively, then fetchmail
>>> will know it's pointless to retry.
>>>       
>> Hi Matthias,
>>
>> 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).
>>     
>
> (I've rearranged the messages a bit to provide some context; once again,
> top-posting seems to be a less-than-brilliant idea :)
>
> Errr...
>
> Are you really saying that in your logs you have seen a case when your
> mail server gives a 4xx response - a 451 DNS temporary failure or apny
> other 4xx response - AND fetchmail flushes the message on the ISP side?
>
> If you are saying that, please provide logs - that would be a very, very
> serious bug in fetchmail :)  A 4xx response means that your local mail
> server DID NOT receive the message, so fetchmail must not remove it from
> the ISP's mailbox, and it should retry downloading it later.
>
> I'm really not sure that is the case.  If you can really find such
> a situation in your logs - your mailserver giving a 4xx response and
> fetchmail DELE'ting the message from the ISP side - then you would have
> found a bug indeed.  Until then, Matthias's explanation seems correct,
> at least to me.
>
> Note that there is a big difference between a 4xx and a 5xx response;
> a 5xx code means a permanent failure, your mailserver will never accept
> this message, no matter how many times fetchmail tries again in the
> future, and in this case fetchmail may indeed flush the message on the
> ISP side - no sense keeping messages that it will never be able to
> deliver.
>
> G'luck,
> Peter
>
>   
Hi,

Sorry for the top reply - diff user groups use diff protocols - I will 
bottom post to this mailgroup.

I will re-verify my logs just to make sure. I have read the follow up 
email from Matthais and will disable dns lookup on fetchmail retrieval 
and see if that solves the problem.

Thanks for all the replies.

Rgds. Otto.