Your message dated Sat, 23 Jul 2005 16:30:08 +0200
with message-id <[EMAIL PROTECTED]>
and subject line (no subject)
has caused the attached Bug report 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 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)
--------------------------------------
Received: (at submit) by bugs.debian.org; 28 Jan 2004 19:00:00 +0000
>From [EMAIL PROTECTED] Wed Jan 28 11:00:00 2004
Return-path: <[EMAIL PROTECTED]>
Received: from nctec.net (p15145151.pureserver.info) [217.160.200.11]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Aluuu-00030G-00; Wed, 28 Jan 2004 11:00:00 -0800
Received: from astral.evil.lan (pD9FF9F5E.dip.t-dialin.net [217.255.159.94])
(using TLSv1 with cipher RC4-MD5 (128/128 bits))
(No client certificate requested)
by p15145151.pureserver.info (Postfix) with ESMTP id F21D147404C
for <[EMAIL PROTECTED]>; Wed, 28 Jan 2004 19:59:57 +0100 (CET)
From: Felix =?iso-8859-15?q?B=FCnemann?= <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: fetchmail truncates email body for messages that are terminated in
header
Date: Wed, 28 Jan 2004 19:59:30 +0100
User-Agent: KMail/1.6
MIME-Version: 1.0
Content-Disposition: inline
Organization: netconsult Technet GmbH
Message-Id: <[EMAIL PROTECTED]>
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_SaAGAXzFKYgDK3I"
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_01_27
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no
version=2.60-bugs.debian.org_2004_01_27
X-Spam-Level:
--Boundary-00=_SaAGAXzFKYgDK3I
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Package: fetchmail
Version: 6.2.4-6
There is a very important bug in fetchmail, that can lead to stopping of ma=
il=20
delivery process.
=46etchmail checks wether the mail is endet by the terminating character '.=
'=20
during header parsing (readheaders()). If it finds this terminating charact=
er=20
thile parsing headers it will sett the flag suppress_body to TRUE. This wil=
l=20
lead to suppressing of the processing of the mail body by readbody().
But, as the header functions have already read the terminating '.' from the=
=20
socket, it will be missing from the final message send to the smtp server.
So from the SMTP server we use for sending on messages we will get:
354 Waitng for Data, end with a . on a single line.
<now wait for ever until timeout occurs>
Now my approach is to add a flag emulate_body, which is set, if we detect s=
uch=20
a mail with an "empty" body. If this flag is set we use an emulated body=20
consisting only of ".\r\n". For saving me from too much coding I tricked th=
is=20
into the readbody() function with a check for an early abort on processing=
=20
when emulate_body flag is set.
Now the smtp server will get his . to terminate the DATA and everyone will =
be=20
happy, no more mails stuck.
My solution is probably not the best as it was done at a client-site under=
=20
extreme time pressure and I'm not familiar with the fetchmail codebase at=20
all.
Also the patch is hand-extracted from my full fixed 6.2.4-6 source package'=
s=20
fetchmail_6.2.4-6.diff.gz, so it may not apply cleanly against a vanilla=20
source.
Here is an imaginary sample mail, for you:
=2D--start---
=46rom: EvilGuy <[EMAIL PROTECTED]>
To: NiceGuy <[EMAIL PROTECTED]>
=2E
=2D--end---
Without Patch, the local-site.org SMTP receives this:
=2D--start---
>>250 SomeMailServer at midnight.
<<MAIL From: [EMAIL PROTECTED]
>>250 OK
<<RCPT To: [EMAIL PROTECTED]
>>250 OK
<<DATA
>>354 End data with <CR><LF>.<CR><LF>
<<From: EvilGuy <[EMAIL PROTECTED]>
<<To: NiceGuy <[EMAIL PROTECTED]>
=2D--end---
With the patch this changes to:
=2D--start---
>>250 SomeMailServer at midnight.
<<MAIL From: [EMAIL PROTECTED]
>>250 OK
<<RCPT To: [EMAIL PROTECTED]
>>250 OK
<<DATA
>>354 End data with <CR><LF>.<CR><LF>
<<From: EvilGuy <[EMAIL PROTECTED]>
<<To: NiceGuy <[EMAIL PROTECTED]>
<<.
>>250 Ok: queued as DEADBEEF
<<QUIT
>>221 Go Away!
=2D--end---
=2D-=20
Mit freundlichen Grue=DFen,
=46elix Buenemann
netconsult Technet GmbH
--Boundary-00=_SaAGAXzFKYgDK3I
Content-Type: text/x-diff;
charset="iso-8859-15";
name="fetchmail_emulatebody.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="fetchmail_emulatebody.patch"
--- fetchmail-6.2.4.orig/driver.c
+++ fetchmail-6.2.4/driver.c
@@ -427,6 +424,7 @@
flag suppress_forward = FALSE;
flag suppress_readbody = FALSE;
flag retained = FALSE;
+ flag emulate_body = FALSE;
if (msgcodes[num-1] < 0)
{
@@ -519,7 +517,7 @@
ctl, num,
/* pass the suppress_readbody flag only if the
underlying
* protocol does not fetch the body separately */
- separatefetchbody ? 0 : &suppress_readbody);
+ separatefetchbody ? 0 : &suppress_readbody,
&emulate_body);
if (err == PS_RETAINED)
suppress_forward = suppress_delete = retained = TRUE;
else if (err == PS_TRANSIENT)
@@ -583,7 +581,8 @@
err = readbody(mailserver_socket,
ctl,
!suppress_forward,
- len);
+ len,
+ emulate_body);
if (err == PS_TRANSIENT)
suppress_delete = suppress_forward = TRUE;
else if (err)
--- fetchmail-6.2.4.orig/fetchmail.h
+++ fetchmail-6.2.4/fetchmail.h
@@ -439,8 +439,9 @@
long reallen,
struct query *ctl,
int num,
- flag *suppress_readbody);
-int readbody(int sock, struct query *ctl, flag forward, int len);
+ flag *suppress_readbody,
+ flag *emulate_body);
+int readbody(int sock, struct query *ctl, flag forward, int len, flag
emulate_body);
#if defined(HAVE_STDARG_H)
void gen_send(int sock, const char *, ... )
__attribute__ ((format (printf, 2, 3)))
--- fetchmail-6.2.4.orig/transact.c
+++ fetchmail-6.2.4/transact.c
@@ -353,7 +346,8 @@
long reallen,
struct query *ctl,
int num,
- flag *suppress_readbody)
+ flag *suppress_readbody,
+ flag *emulate_body)
/* read message headers and ship to SMTP or MDA */
/* sock: to which the server is connected */
/* fetchlen: length of message according to fetch response */
@@ -361,6 +355,7 @@
/* ctl: query control record */
/* num: index of message */
/* suppress_readbody: whether call to readbody() should be supressed
*/
+/* emulate_body: wether to emulate a mail body */
{
struct addrblk
{
@@ -507,13 +502,19 @@
* has been mangled, the delimiter may occur directly after the
* header.
*/
+ /* causes . to be chopped from message */
if (protocol->delimited && line[0] == '.' && EMPTYLINE(line+1))
{
if (outlevel > O_SILENT)
report(stdout,
- GT_("message delimiter found while scanning
headers\n"));
+ GT_("message delimiter found while scanning headers
(IGNORED)\n"));
+#if 0
if (suppress_readbody)
*suppress_readbody = TRUE;
+#else
+ if (emulate_body)
+ *emulate_body = TRUE;
+#endif
if (linelen != strlen (line))
has_nuls = TRUE;
free(line);
@@ -1298,15 +1299,16 @@
return(PS_SUCCESS);
}
-int readbody(int sock, struct query *ctl, flag forward, int len)
+int readbody(int sock, struct query *ctl, flag forward, int len, flag
emulate_body)
/* read and dispose of a message body presented on sock */
/* ctl: query control record */
/* sock: to which the server is connected */
/* len: length of message */
/* forward: TRUE to forward */
+/* emulate_body: TRUE to output emulated body on truncated mails */
{
int linelen;
- unsigned char buf[MSGBUFSIZE+4];
+ unsigned char buf[MSGBUFSIZE+4]=".\r\n\0";
unsigned char *inbufp = buf;
flag issoftline = FALSE;
@@ -1320,10 +1322,11 @@
* instead drop out of the loop with a break statement when we see
* the message delimiter.
*/
+
while (protocol->delimited || len > 0)
{
set_timeout(mytimeout);
- if ((linelen = SockRead(sock, inbufp, sizeof(buf)-4-(inbufp-buf)))==-1)
+ if (!emulate_body && (linelen = SockRead(sock, inbufp,
sizeof(buf)-4-(inbufp-buf)))==-1)
{
set_timeout(0);
release_sink(ctl);
--Boundary-00=_SaAGAXzFKYgDK3I--
---------------------------------------
Received: (at 230126-done) by bugs.debian.org; 23 Jul 2005 14:30:13 +0000
>From [EMAIL PROTECTED] Sat Jul 23 07:30:13 2005
Return-path: <[EMAIL PROTECTED]>
Received: from krusty.dt.e-technik.uni-dortmund.de
(mail.dt.e-technik.uni-dortmund.de) [129.217.163.1] (postfix)
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1DwL13-0000gN-00; Sat, 23 Jul 2005 07:30:13 -0700
Received: from localhost (localhost [127.0.0.1])
by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 0407744019
for <[EMAIL PROTECTED]>; Sat, 23 Jul 2005 16:30:12 +0200 (CEST)
Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1])
by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 21338-10 for <[EMAIL PROTECTED]>;
Sat, 23 Jul 2005 16:30:10 +0200 (CEST)
Received: from m2a2.dyndns.org (p50914DF1.dip.t-dialin.net [80.145.77.241])
by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id A3D1844001
for <[EMAIL PROTECTED]>; Sat, 23 Jul 2005 16:30:10 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by merlin.emma.line.org (Postfix) with ESMTP id 045B07979C
for <[EMAIL PROTECTED]>; Sat, 23 Jul 2005 16:30:10 +0200 (CEST)
Received: from m2a2.dyndns.org ([127.0.0.1])
by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 15708-14 for <[EMAIL PROTECTED]>;
Sat, 23 Jul 2005 16:30:08 +0200 (CEST)
Received: by merlin.emma.line.org (Postfix, from userid 500)
id 8A28A77677; Sat, 23 Jul 2005 16:30:08 +0200 (CEST)
Date: Sat, 23 Jul 2005 16:30:08 +0200
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
User-Agent: nail 11.4 8/29/04
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: [EMAIL PROTECTED] (Matthias Andree)
X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-1.5 required=4.0 tests=BAYES_00,NOSUBJECT
autolearn=no version=2.60-bugs.debian.org_2005_01_02
There is no such bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
