Your message dated Mon, 25 Mar 2013 20:00:34 +0100
with message-id <[email protected]>
and subject line Re: Bug#703738: fetchmail: Dot at 1st column of any line cuts
delivered message
has caused the Debian Bug report #703738,
regarding fetchmail: Dot at 1st column of any line cuts delivered message
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
703738: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703738
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: fetchmail
Version: 6.3.21-4
Severity: important
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fetchmail depends on:
ii adduser 3.113+nmu3
ii debianutils 4.3.2
ii libc6 2.13-38
ii libcomerr2 1.42.5-1
ii libgssapi-krb5-2 1.10.1+dfsg-4
ii libkrb5-3 1.10.1+dfsg-4
ii libssl1.0.0 1.0.1e-1
ii lsb-base 4.1+Debian8
Versions of packages fetchmail recommends:
ii ca-certificates 20130119
Versions of packages fetchmail suggests:
pn fetchmailconf <none>
pn resolvconf <none>
ii sendmail-bin [mail-transport-agent] 8.14.4-2.1
-- Configuration Files:
/etc/default/fetchmail changed:
START_DAEMON=yes
-- no debconf information
Hallo maintainer,
fetchmail break messages with '.' character at 1st column of mail body.
It sometimes happens receiving mails from MS Outlook where line is
wrapped just before last dot in a text paragraph. Affected message
is cut to delivered and undelivered part. Cut position is at the
described dot, start of message is delivered and the rest disappears.
No error message is issued to user.
How to reproduce this bug:
No MS tools are neccessary to simulate problem. You can simply compose
a message similar to the following and send it as plain text to a mailserver.
Then fetch this mail via fetchmail (tested with POP3 protocol) and show it.
-------
Sample message. This message wil be partially delivered.
Cut point is here:
..
This part of message will never be delivered by fetchmail
-------
Changing fetchmail to another package, e.g. mpop leads to delivery
of whole message.
Thank you for your help,
Pavel Vavra
--- End Message ---
--- Begin Message ---
Pavel,
This is not a fetchmail bug; I would reconsider if there were evidence
to counter the findings shown below.
1. Your server or load balancer or firewall (on the server side) appears
to have truncated the message. One possibility is that its "TOP" command
does not implement byte stuffing correctly.
The POP3 server is supposed to prepend a dot to all lines that start
with one, and failed.
RFC-1939, section 3 and 7:
<http://tools.ietf.org/html/rfc1939#page-3>
<http://tools.ietf.org/html/rfc1939#page-11>
Smaller differences in sizes are to be expected, because many servers do
not calculate sizes correctly (sometimes yielding on-disk sizes), but
major differences like this (1753 != 2327) hint to a server fault.
From your log:
> Mar 25 09:37:47 pom64 fetchmail[21757]: message ***@mail.***.cz:1604
was not the expected length (1753 actual != 2327 expected)
I re-tested with fetchmail, with one and two dots, with POP3/TOP,
POP3/RETR, IMAP4, and in neither case would the message be truncated.
Please talk to your POP3 server's operator and make them do proper byte
stuffing for TOP and RETR commands.
Note: The server did not mention "Exchange" in its greeting banner.
I am now closing this bug.
Best regards
Matthias
Am 25.03.2013 15:50, schrieb Pavel Vávra:
> Hallo again,
> my last test shows that server responds fine when command RETR is used
> instead of TOP. TOP is acording to RFC1939 extension to POP3, but RETR is
> base command of POP3 protocol. Using RETR in this case will solve problem.
>
> |Sample message. This message wil be partially delivered.
> |Cut point is here:
> |..
> |This part of message will never be delivered by fetchmail
>
> First '|' character to echh line is added manually by me.
>
> Well, I've found discussion about RETR and TOP in man page and I want to set
> fetchall to use RETR instead of TOP. Fetchmail fails during start saying that
> fetchall and keep set both to on is not allowed in server mode. But I have
> uidl set ON too. I didn't find a solution for server, where I need to archive
> all emails on my workstation, but time to time I need web access to check and
> read some messages. Is any other way how to force RETR command with existing
> configuration (aleady sent to this bug)?
>
> Pavel
>
signature.asc
Description: OpenPGP digital signature
--- End Message ---
