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.
>
> _______________________________________________
> fetchmail-users mailing list
> fet...@li...
> https://lists.berlios.de/mailman/listinfo/fetchmail-users
>
>
>   

Hi Peter,

You were correct - it was not a 4xx error. Soory for this - think I've 
been looking at too many logs!!! I think I've solved my problem by 
disabling dns lookup whilst doing fetchmail.

Thanks for all the replies and help.

Rgds. Otto.