Your message dated Tue, 13 Jun 2006 23:51:09 -0300
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #373206,
regarding amavisd-new: eats the body of some emails without further notice
to be marked as having been forwarded to the upstream software
author(s) Mark Martinec <[EMAIL PROTECTED]>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Martin,
Another bug against amavisd-new 2.4.1, reported by a Debian user: If you
feed amavisd-new a message without headers, it loses the body.
I have verified and even amavisd-release won't work (message is delivered
with the body missing). Obviously, using D_PASS also loses the body.
On Tue, 13 Jun 2006, Elias Oltmanns wrote:
> Package: amavisd-new
> Version: 1:2.4.1-1
> Severity: important
>
> Testing my setup I encountered a problem which is probably best
> illustrated by the following protocol below. Basically, what happens
> is that emails with ``bad headers'' are delivered with there bodies
> removed if $final_bad_header_destiny is set to D_PASS.
>
> pts/1_13:56_~% telnet localhost 10024
> Trying 127.0.0.1...
> Connected to denkblock.local.
> Escape character is '^]'.
> 220 [127.0.0.1] ESMTP amavisd-new service ready
> ehlo localhost
> 250-[127.0.0.1]
> 250-VRFY
> 250-PIPELINING
> 250-SIZE
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250-DSN
> 250 XFORWARD NAME ADDR PROTO HELO
> mail from: <[EMAIL PROTECTED]>
> 250 2.1.0 Sender [EMAIL PROTECTED] OK
> rcpt to: <[EMAIL PROTECTED]>
> 250 2.1.5 Recipient [EMAIL PROTECTED] OK
> data
> 354 End data with <CR><LF>.<CR><LF>
> test mail.
> .
> 250 2.6.0 Ok, id=11247-04, from MTA([127.0.0.1]:10025): 250 OK
> id=1Fq7WG-0003Gb-FB
> quit
> 221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
> Connection closed by foreign host.
> pts/1_13:57_~% cat /var/mail/eo
> >From [EMAIL PROTECTED] Tue Jun 13 13:57:18 2006
> Return-path: <[EMAIL PROTECTED]>
> Envelope-to: [EMAIL PROTECTED]
> Delivery-date: Tue, 13 Jun 2006 13:57:18 +0200
> Received: from localhost ([127.0.0.1])
> by denkblock.local with esmtp (Exim 4.60)
> (envelope-from <[EMAIL PROTECTED]>)
> id 1Fq7WG-0003Gb-FB
> for [EMAIL PROTECTED]; Tue, 13 Jun 2006 13:57:18 +0200
> X-Quarantine-ID: <H4DIu8+6ncfH>
> X-Amavis-Alert: BAD HEADER MIME error: error: unexpected end of header
> Received: from localhost ([127.0.0.1])
> by localhost (denkblock.local [127.0.0.1]) (amavisd-new, port
> 10024)
> with ESMTP id H4DIu8+6ncfH for <[EMAIL PROTECTED]>;
> Tue, 13 Jun 2006 13:57:03 +0200 (CEST)
> Message-Id: <[EMAIL PROTECTED]>
> From: [EMAIL PROTECTED]
> Date: Tue, 13 Jun 2006 13:57:16 +0200
>
>
> You have new mail.
> pts/1_13:57_~%
>
> As you can see, amavisd-new has added alert headers and removed the
> body of the email just because it didn't like the header. However, my
> config files suggest a different behaviour:
> pts/1_13:59_~% grep 'final_.*_destiny' /etc/amavis/conf.d/*
> /etc/amavis/conf.d/20-debian_defaults:$final_virus_destiny = D_DISCARD;
> # (data not lost, see virus quarantine)
> /etc/amavis/conf.d/20-debian_defaults:$final_banned_destiny = D_BOUNCE;
> # D_REJECT when front-end MTA
> /etc/amavis/conf.d/20-debian_defaults:$final_spam_destiny = D_BOUNCE;
> /etc/amavis/conf.d/20-debian_defaults:$final_bad_header_destiny = D_PASS;
> # False-positive prone (for spam)
> /etc/amavis/conf.d/50-user:$final_virus_destiny = D_DISCARD; # (data
> not lost, see virus quarantine)
> /etc/amavis/conf.d/50-user:$final_banned_destiny = D_DISCARD; #
> D_REJECT when front-end MTA
> /etc/amavis/conf.d/50-user:$final_spam_destiny = D_PASS;
> /etc/amavis/conf.d/50-user:$final_bad_header_destiny = D_PASS; #
> False-positive prone (for spam)
> pts/1_14:06_~%
>
> The original body of the message is stored in
> /var/lib/amavis/tmp/amavis-20060613T122807-11247/email.txt.
>
> The severety of this bug has been set to important because without
> special arrangements the user's mua will just present an empty message
> to the user who might not even notice that potentially useful
> information in the body has actually been removed.
The only reason I didn't bump this to grave is that *anything* delivering
email without any headers whatsoever is quite rare...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--- End Message ---
