Re: [Fetchmail-users] message size error in fetchmail :SOLVED

[Chuck C. <cam...@ac...>]

On 10/31/2017 11:58 AM, Chuck Campbell wrote:
> On 10/31/2017 11:26 AM, Matthias Andree wrote:
>> Am 31.10.2017 um 16:46 schrieb Chuck Campbell:
>>> Networksoliutions (my email provider) just changed some things, and
>>> fetchmail no longer works to pop my mail. I get message length errors.
>>> I don't know how to resolve this. This configuration had been working
>>> perfectly for years (date in .fetchmailrc is from 2000) until last week.
>>>
>>> I'm putting some segments of verbose logging here:
>>>
>>>
>>> fetchmail: starting fetchmail 6.3.17 daemon
>>> fetchmail: 6.3.17 querying <mail server redacted> (protocol POP3) at
>>> Sun 29 Oct 2017
>>> 02:36:05 PM CDT: poll started
>> [...]
>>> fetchmail: POP3> UIDL
>>> fetchmail: POP3< +OK
>>> fetchmail: POP3< 1 1508958447.17539.atl4mail14,S=6598
>>> fetchmail: 1 is unseen
>> [...]
>>> fetchmail: POP3> LIST 1
>>> fetchmail: POP3< +OK 1 6677
>>> fetchmail: POP3> RETR 1
>>> fetchmail: POP3< +OK
>> [...]
>>> fetchmail: forwarding to localhost
>>> fetchmail: SMTP> MAIL FROM:<cen...@ce...>  BODY=8BITMIME
>>> SIZE=6677
>>> fetchmail: SMTP< 250 2.1.0<cen...@ce...>... Sender ok
>>> fetchmail: SMTP> RCPT TO:<user redacted@localhost>
>>> fetchmail: SMTP< 250 2.1.5 <user redacted@localhost>... Recipient ok
>>> fetchmail: SMTP> DATA
>>> fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
>>> fetchmail: message <email addr redacted>:1 was not the expected length
>>> (6846 actual != 6677 expected)
>>> fetchmail: SMTP>. (EOM)
>>> fetchmail: SMTP< 451 4.7.0 resource unavailable
>>> fetchmail: SMTP error: 451 4.7.0 resource unavailable
>>> fetchmail: SMTP> RSET
>>> fetchmail: SMTP< 250 2.0.0 Reset state
>>> fetchmail:  not flushed [...]
>> Hi Chuck,
>>
>>
>> fetchmail 6.3.17 isn't anywhere near recent, but I don't think this is
>> related.
>>
>> It's been two decades that I pulled my last Sendmail server from
>> service, but what prevents delivery is not the size warning, but the
>> "451 4.7.0 resource unavailable". I don't know if sendmail complains
>> about the size mismatch (FreeBSD's sendmail 8.15 via sendmail -bs will
>> happily accept an oversized message), or if it's running out of disk
>> space or inodes in the /var or any your delivery partitions, normally
>> the size mismatch is only a warning.
>>
>> Carefully check your mail log if sendmail sends any more details to
>> syslog, and check the output of "df" and "df -i".
>>
>>
>> HTH
>>
>> Regards,
>>
>> Matthias
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Fetchmail-users mailing list
>> Fet...@li...
>> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>
> I couldn't find a pre-built rpm for Centos 6 for any newer version.
>
> I built fetchmail-6.3.26 from sources, but must have done something wrong, 
> because it doesn't appear to do anything, and issues no info, even when 
> invoked with -vvvvv
>
> It appears as a running process, but I get no outputs at all. That is an a 
> different issue.
>
> I have a great deal of space available, but I'll have to remember how to check 
> available inodes. Curiously, using mpop with procmail, I can get the mail just 
> fine, so I have to believe there is no inode issue (delivery to the same disk/ 
> user).
>
> This may well be a sendmail (local) issue. I thought it was too much work to 
> replace it with qmail or postfix, until I know for sure it isn't a fetchmail 
> problem.
>
> -chuck
>
First, it turns out NOT to be a fetchmail problem, sorry for the noise. Now, in 
case anyone else comes looking for this, here is my solution:

Thanks for the suggestion to look into the maillog. It turns out that opendkim 
was trying to create a temp file, and selinux was not allowing it. I tried to 
use audit2allow to build a module to fix this, but that failed. I ended up doing 
this:

semanage permissive -a dkim_milter_t

All is working again. If there is a better way, I'd be happy to hear it.

-chuck

--