Your message dated Wed, 10 Sep 2025 18:28:07 -0700
with message-id <2796524.mvXUDI8C0e@soren-laptop>
and subject line Re: Bug#464016: clients will truncate on bad multipart/digest
RFC822.SIZE
has caused the Debian Bug report #464016,
regarding clients will truncate on bad multipart/digest RFC822.SIZE
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.)
--
464016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464016
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: courier-imap
Version: 4.3.0.20081027-1
courier-imap will report an incorrect RFC822.SIZE to clients in
certain cases, causing them to lose the remainder of the message,
which may be a substantial part of the message.
Clients who take courier-imap's word for RFC822.SIZE, e.g.,
squirrelmail, fetchmail, will truncate the message. Clients who don't,
e.g., getmail, will deliver the whole message.
To test, use the following program to create a message in your
Maildir/new, and download it via courier-imap with your client.
E.g., getmail --trace shows
command FETCH ('1:1', '(UID RFC822.SIZE)') response ['1 (UID 1 RFC822.SIZE
91766)']
command uid FETCH ('1', '(RFC822)') response [('1 (UID 1 RFC822 {204926}'...
1 messages (91766 bytes) retrieved
When indeed the source and destination are actually larger:
-rw-r--r-- 1 199590 Feb 5 02:04 Maildir/cur/goo:2,S
-rw------- 1 199737 Feb 5 02:06
Mldir/new/1202148403.M722359P7032Q0R99925aad42b3fca6.jidanni2
Upon investigation, one finds the reported RFC822.SIZE constantly
truncates at part 150 of multipart/digest, no matter how the content
differs (except if the total message size is small, causing the bug to
not be triggered.)
#!/usr/bin/perl
use strict;
use warnings FATAL => 'all';
use MIME::Entity;
use constant N => 333;
my $top = MIME::Entity->build( Type => "multipart/digest", );
$top->preamble( [ "This should have ", N, " parts.\n" ] );
for ( 1 .. N ) {
my $part = MIME::Entity->build(
Type => 'message/rfc822',
'Content-Type' => undef,
'Content-Disposition' => undef,
'Content-Transfer-Encoding' => undef,
Top => 0,
Data => "Subject: Bla $_
Date: Mon, 04 Feb 2008 15:50:08 +0200
From: Bllla <b\@example.com>
X-Spam-Status: Yes, score=34.5 required=4.0 tests=DYN_RDNS_AND_INLINE_IMAGE,
FH_HELO_EQ_D_D_D_D,FORGED_OUTLOOK_HTML,HELO_DYNAMIC_IPADDR2,HTML_MESSAGE,
HTML_TAG_BALANCE_HEAD,J_CHSET3,J_SINGLE_FROM,MIME_HTML_ONLY,RATWARE_RCVD_PF,
RDNS_DYNAMIC,TVD_RCVD_IP,UNWANTED_LANGUAGE_BODY,URIBL_BLACK,URIBL_OB_SURBL,
URIBL_RHS_DOB,URIBL_SBL,URIBL_SC_SURBL autolearn=disabled
version=3.2.3-wed_jan_16_09_06_33_2008.jidanni2
X-Spam-Languages: ru.windows-1251
X-Size: 21518
X-File: zzzzzzzzz
"
);
$top->add_part($part);
}
$top->print( \*STDOUT );
--- End Message ---
--- Begin Message ---
On Wednesday, September 10, 2025 2:33:51 PM Mountain Standard Time Dan
Jacobson wrote:
> I can't help anymore because i'm on a pacific island without that
> equipment.
>
Thank you for your quick reply. I will close this bug under the assumption
that it has been resolved by an upstream release in the intervening years. If
anyone is still experiencing this issue feel free to reopen the bug report.
--
Soren Stoutner
[email protected]
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
