Bug 74254 - attaching files with long lines causes message loss
Summary: attaching files with long lines causes message loss
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Unmaintained
Component: general (show other bugs)
Version: 1.6
Platform: Compiled Sources Solaris
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-05 17:50 UTC by Unknown
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Kasch 2004-02-05 17:50:32 UTC
Version:           1.6 (using KDE KDE 3.2.0)
Installed from:    Compiled From Sources
Compiler:          gcc version 2.95.3 20010315 (release) 
OS:          Solaris

I've tried to attach a text file (HTML to be precise) with very long lines to a recipient with a mailbox on a cyrus 2.1.x IMAP server which imposes a line length limit of ~8k (which is way beyond the 998 chars required by RFC2822, section 2.1.1). The message was rejected with the (misleading) message "5.6.0 Message contains NUL characters (in reply to end of DATA command" but since the error mail contains a copy of the original message, it could not be delivered back to me (mailbox at the same site/system).

Apart from the postmaster, nobody was notified of the delivery failure.

My test setup:

postfix-2.0.14 delivering via LMTP to a cyrus-2.1.12 "murder".

to reproduce:

try to send a message with a text file attachment (> 8k chars/line) via KMail to a cyrus user.
Comment 1 Carsten Burghardt 2004-02-05 18:45:58 UTC
Subject: Re:  New: attaching files with long lines causes message loss

On Thursday 05 February 2004 17:50, Torsten Kasch wrote:
> I've tried to attach a text file (HTML to be precise) with very long lines
> to a recipient with a mailbox on a cyrus 2.1.x IMAP server which imposes a
> line length limit of ~8k (which is way beyond the 998 chars required by
> RFC2822, section 2.1.1). The message was rejected with the (misleading)
> message "5.6.0 Message contains NUL characters (in reply to end of DATA
> command" but since the error mail contains a copy of the original message,
> it could not be delivered back to me (mailbox at the same site/system).
>
> Apart from the postmaster, nobody was notified of the delivery failure.

I agree that this is bad but what should we do in your eyes? Change the 
attachment? And the error is not from kmail but from the imap server so I 
don't see kmail's fault.


Carsten

Comment 2 Torsten Kasch 2004-02-05 19:34:14 UTC
Well, "mutt" seems to be able to do this better. I've just created a test-attachment with

perl -e 'print "x" x 8190' > long.txt

While I didn't get it thru with KMail, mutt breaks up the long lines:

--- snip ---
[...]
Content-Type: TEXT/PLAIN
Content-Transfer-Encoding: QUOTED-PRINTABLE
Subject: 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
[...]
--- snip ---

which is deliverable; perhaps this "more conservative behavior" is an option for KMail as well? Losing mail is definitly not an option for me... ;-(

cheers, Torsten
Comment 3 Stephan Kulow 2004-06-02 20:23:16 UTC
Replaced tk@CeBiTec.Uni-Bielefeld.DE with null@kde.org due to bounces by reporter
Comment 4 Ingo Klöcker 2004-08-26 05:43:36 UTC
Fixed in KDE 3.3.1.