Debian Bug report logs - #361354
mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: tb <tb@becket.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Fri, 07 Apr 2006 19:47:04 -0700

Package: mailutils-imap4d
Version: 1:0.6.1-4sarge2
Severity: grave
Justification: renders package unusable


I use imap4d using a traditional /var/spool/mail source (and don't use
folders or any of that fancy stuff); I just use it as a POP replacement
with gnus running gssapi as the authentication.

If the mailbox contains a message with an ASCII NUL (000) character,
then the reply to a FETCH command (at least, those generated by gnus,
such as:
30 UID FETCH 27 BODY.PEEK[]

will print a correct message count in {} in the reply, but then in the
message itself, printing of the message will stop with the character
before the ASCII NUL, and then the terminating ) is printed, followed
by
30 OK UID FETCH Completed

The problem seems pretty obvious: the code that reads and prints the
message into the reply is fooled by NULs because it is using C strings
to hold the data.

I have marked this bug report grave because spam is extremely common in
this sad world, and spam often includes such NUL characters.  This
prevents the use of imap4d with any such mail spool, rendering the
tool unusable.

In the message where I saw this, the NUL character was within a MIME
block, with type text/plain and encoding base64; the NUL occurred at the
end of the last line of the block, before the concluding boundary line.

The problem occurs as well if a "FETCH 27 BODY[TEXT]" command is used
(not surprisingly).

Clearly the bug is in fetch_io, in imap4d/fetch.c.  We are called from
fetch_operation, where there is no partial offset, so start and end are
ULONG_MAX.  The first main loop for fetch_io is the one chosen, and max
is set correctly (because the size printed between {} I know to be
correct).  Then we read chunks of 512 bytes at a time, and use util_send
to output them.  util_send cannot deal with chunks that have embedded
NULs.

pop3d is apparently able to handle the messages correctly.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages mailutils-imap4d depends on:
ii  libc6                  2.3.2.ds1-22      GNU C Library: Shared libraries an
ii  libcomerr2             1.37-2sarge1      common error description library
ii  libgcrypt11            1.2.0-11.1        LGPL Crypto library - runtime libr
ii  libgdbm3               1.8.3-2           GNU dbm database routines (runtime
ii  libgnutls11            1.0.16-13.2       GNU TLS library - runtime library
ii  libgpg-error0          1.0-1             library for common error values an
ii  libgsasl7              0.2.5-1           GNU SASL library
ii  libidn11               0.5.13-1.0        GNU libidn library, implementation
ii  libkrb53               1.3.6-2sarge2     MIT Kerberos runtime libraries
ii  libmailutils0          1:0.6.1-4sarge2   GNU Mail abstraction library
ii  libmysqlclient12       4.0.24-10sarge1   mysql database client library
ii  libpam0g               0.76-22           Pluggable Authentication Modules l
ii  libtasn1-2             0.2.10-3sarge1    Manage ASN.1 structures (runtime)
ii  netbase                4.21              Basic TCP/IP networking system
ii  zlib1g                 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information

Message #10 received at 361354@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 361354-submitter@bugs.debian.org

Cc: 361354@bugs.debian.org

Subject: Re: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Sun, 12 Nov 2006 06:29:24 -0800

Hi Thomas,

For my part, I do have to wonder if an mbox with an embedded NUL is even a
valid mbox file.  What is your MTA/MDA for this setup?

Have you by chance tested newer versions of mailutils-imap4d from etch or
sid?  Etch currently has version 1.0 of mailutils, and sid has version 1.1;
we could hope that this bug might be fixed upstream.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #18 received at 361354@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 361354-submitter@bugs.debian.org

Cc: 361354@bugs.debian.org

Subject: Re: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Sun, 12 Nov 2006 14:45:25 -0800

found 361354 1:1.1+dfsg1-1
thanks

Ok, this bug still manifests in mailutils 1.1, the current version in
unstable.

Observing the effects myself, and rereading your report carefully, I do have
to question again the severity assigned to this bug.  While the
NUL-containing message is truncated when read, retrieving other messages
from the mailbox works fine, including those after the broken message in the
mbox.  You also note that this problem primarily affects spam, but spam by
definition is mail you don't want to read, so if that's really the only
occurrence of NULs in mails, I have a hard time regarding this as grave...
:)

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #28 received at 361354-quiet@bugs.debian.org (full text, mbox, reply):

From: Thomas Bushnell BSG <tb@becket.net>

To: Steve Langasek <vorlon@debian.org>, 361354-quiet@bugs.debian.org

Subject: Re: Bug#361354: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Mon, 13 Nov 2006 14:21:17 -0800

[Message part 1 (text/plain, inline)]

On Sun, 2006-11-12 at 06:29 -0800, Steve Langasek wrote:
> Hi Thomas,
> 
> For my part, I do have to wonder if an mbox with an embedded NUL is even a
> valid mbox file.  What is your MTA/MDA for this setup?

Perfectly ordinary Debian exim and mail spool file format.

If you believe that this is not valid mbox format, then the bug should
be refiled against exim4.

> Have you by chance tested newer versions of mailutils-imap4d from etch or
> sid?  Etch currently has version 1.0 of mailutils, and sid has version 1.1;
> we could hope that this bug might be fixed upstream.

I checked with the upstream source when I filed the report, IIRC, and
verified that the relevant bug is there too.

Thomas

[signature.asc (application/pgp-signature, inline)]

Message #33 received at 361354-quiet@bugs.debian.org (full text, mbox, reply):

From: Thomas Bushnell BSG <tb@becket.net>

To: Steve Langasek <vorlon@debian.org>, 361354-quiet@bugs.debian.org

Subject: Re: Bug#361354: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Mon, 13 Nov 2006 14:22:49 -0800

[Message part 1 (text/plain, inline)]

On Sun, 2006-11-12 at 14:45 -0800, Steve Langasek wrote:
> found 361354 1:1.1+dfsg1-1
> thanks
> 
> Ok, this bug still manifests in mailutils 1.1, the current version in
> unstable.
> 
> Observing the effects myself, and rereading your report carefully, I do have
> to question again the severity assigned to this bug.  While the
> NUL-containing message is truncated when read, retrieving other messages
> from the mailbox works fine, including those after the broken message in the
> mbox.  You also note that this problem primarily affects spam, but spam by
> definition is mail you don't want to read, so if that's really the only
> occurrence of NULs in mails, I have a hard time regarding this as grave...
> :)

No, it is worse than that (at least, using emacs gnus as the mail
client): the connection is hosed.  Creating a *new* connection and
reading later messages works fine.

But the IMAP connection open is hosed because the client and server get
out of sync: the server advertises how many bytes it will send, and then
sends fewer bytes, and the client stays waiting for the rest of the
data.

Thomas

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 361354-quiet@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@dodds.net>

To: Thomas Bushnell BSG <tb@becket.net>

Cc: 361354-quiet@bugs.debian.org

Subject: Re: Bug#361354: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Mon, 13 Nov 2006 14:47:27 -0800

On Mon, Nov 13, 2006 at 02:22:49PM -0800, Thomas Bushnell BSG wrote:
> On Sun, 2006-11-12 at 14:45 -0800, Steve Langasek wrote:
> > found 361354 1:1.1+dfsg1-1
> > thanks

> > Ok, this bug still manifests in mailutils 1.1, the current version in
> > unstable.

> > Observing the effects myself, and rereading your report carefully, I do have
> > to question again the severity assigned to this bug.  While the
> > NUL-containing message is truncated when read, retrieving other messages
> > from the mailbox works fine, including those after the broken message in the
> > mbox.  You also note that this problem primarily affects spam, but spam by
> > definition is mail you don't want to read, so if that's really the only
> > occurrence of NULs in mails, I have a hard time regarding this as grave...
> > :)

> No, it is worse than that (at least, using emacs gnus as the mail
> client): the connection is hosed.  Creating a *new* connection and
> reading later messages works fine.

> But the IMAP connection open is hosed because the client and server get
> out of sync: the server advertises how many bytes it will send, and then
> sends fewer bytes, and the client stays waiting for the rest of the
> data.

Ah, this wasn't obvious to me when using telnet as my client. ;)  Fair
enough.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #43 received at 361354@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: Thomas Bushnell BSG <tb@becket.net>, 361354@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#361354: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Tue, 14 Nov 2006 01:35:46 +0000

[Message part 1 (text/plain, inline)]

This one time, at band camp, Thomas Bushnell BSG said:
> On Sun, 2006-11-12 at 06:29 -0800, Steve Langasek wrote:
> > Hi Thomas,
> > 
> > For my part, I do have to wonder if an mbox with an embedded NUL is even a
> > valid mbox file.  

It is.  mbox format specifies a blank line, followed by ^'From ' is the
message seperator.  \0's make no difference.

> > What is your MTA/MDA for this setup?
> 
> Perfectly ordinary Debian exim and mail spool file format.
> 
> If you believe that this is not valid mbox format, then the bug should
> be refiled against exim4.

Not necessary, see above.

> > Have you by chance tested newer versions of mailutils-imap4d from etch or
> > sid?  Etch currently has version 1.0 of mailutils, and sid has version 1.1;
> > we could hope that this bug might be fixed upstream.
> 
> I checked with the upstream source when I filed the report, IIRC, and
> verified that the relevant bug is there too.

I grant you that this message is likely spam (who else puts a \0 in an
email?) and that it seems to only truncate the one message.  This (at
least IMHO) downgrades the bug, but doesn't make it a non-bug.  There is
a (vanishingly small?) possibility that a wanted email could be
truncated by this bug.  I suggest a severity normal or important,
depending on how likely you think this scenario is.

I leave it to others who are actually responsible for the package to
decide, but that's my advice.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #48 received at 361354-quiet@bugs.debian.org (full text, mbox, reply):

From: Stephen Gran <sgran@debian.org>

To: Thomas Bushnell BSG <tb@becket.net>, 361354-quiet@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#361354: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Tue, 14 Nov 2006 01:37:13 +0000

[Message part 1 (text/plain, inline)]

This one time, at band camp, Thomas Bushnell BSG said:
> On Sun, 2006-11-12 at 14:45 -0800, Steve Langasek wrote:
> > 
> > Observing the effects myself, and rereading your report carefully, I do have
> > to question again the severity assigned to this bug.  While the
> > NUL-containing message is truncated when read, retrieving other messages
> > from the mailbox works fine, including those after the broken message in the
> > mbox.  You also note that this problem primarily affects spam, but spam by
> > definition is mail you don't want to read, so if that's really the only
> > occurrence of NULs in mails, I have a hard time regarding this as grave...
> > :)
> 
> No, it is worse than that (at least, using emacs gnus as the mail
> client): the connection is hosed.  Creating a *new* connection and
> reading later messages works fine.
> 
> But the IMAP connection open is hosed because the client and server get
> out of sync: the server advertises how many bytes it will send, and then
> sends fewer bytes, and the client stays waiting for the rest of the
> data.

This was unclear to me from the earlier messages I saw.  Sounds like
grave is reasonable, then.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 361354-submitter@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 361354-submitter@bugs.debian.org

Subject: Re: mailutils-imap4d: Incorrect FETCH reply if message contains ascii NUL character

Date: Sat, 02 Dec 2006 15:15:30 +0000

[Message part 1 (text/plain, inline)]

Here's a patch that should fix the problem.  The package builds and
passes its test suite with this patch applied.  However I don't know how
to use the server and I don't have appropriate test data for this bug,
so the fix still needs to be verified.

Ben.

--- imap4d/fetch.c~	2006-03-12 14:25:50.000000000 +0000
+++ imap4d/fetch.c	2006-12-02 14:34:24.000000000 +0000
@@ -1160,12 +1160,11 @@
       offset = 0;
       if (max)
 	{
-	  util_send (" {%u}\r\n", max);
+	  util_send (" {%lu}\r\n", max);
 	  while (mu_stream_read (rfc, buffer, sizeof (buffer) - 1, offset,
 			      &n) == 0 && n > 0)
 	    {
-	      buffer[n] = '\0';
-	      util_send ("%s", buffer);
+	      util_send_raw (buffer, n);
 	      offset += n;
 	    }
 	}
@@ -1190,13 +1189,11 @@
 	  end -= n;
 	  buffer += n;
 	}
-      /* Make sure we null terminate.  */
-      *buffer = '\0';
       util_send ("<%lu>", start);
       if (total)
 	{
 	  util_send (" {%s}\r\n", mu_umaxtostr (0, total));
-	  util_send ("%s", p);
+	  util_send_raw (p, total);
 	}
       else
 	util_send (" \"\"");
--- imap4d/imap4d.h~	2006-04-07 15:08:54.000000000 +0100
+++ imap4d/imap4d.h	2006-12-02 14:27:16.000000000 +0000
@@ -242,6 +242,7 @@
   
 /* Helper functions.  */
 extern int  util_out (int, const char *, ...);
+extern int  util_send_raw (const char *, size_t);
 extern int  util_send (const char *, ...);
 extern int  util_send_qstring (const char *);
 extern int  util_send_literal (const char *);
--- imap4d/util.c~	2006-04-07 15:08:55.000000000 +0100
+++ imap4d/util.c	2006-12-02 14:25:55.000000000 +0000
@@ -348,6 +348,15 @@
 }
 
 int
+util_send_raw (const char *data, size_t len)
+{
+  if (daemon_param.transcript)
+    syslog (LOG_DEBUG, "sent: %s", data);
+
+  return mu_stream_sequential_write (ostream, data, len);
+}
+
+int
 util_send (const char *format, ...)
 {
   char *buf = NULL;
@@ -360,10 +369,7 @@
   if (!buf)
       imap4d_bye (ERR_NO_MEM);
 
-  if (daemon_param.transcript)
-    syslog (LOG_DEBUG, "sent: %s", buf);
-
-  status = mu_stream_sequential_write (ostream, buf, strlen (buf));
+  status = util_send_raw (buf, strlen(buf));
   free (buf);
 
   return status;
-- END --

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 361354@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 361354@bugs.debian.org

Subject: NMU uploaded

Date: Mon, 4 Dec 2006 12:34:16 +0100

Hi,

I uploaded an NMU of your package.

Please see this as help to get the package into a releaseable condition for
etch.

Please find the used diff below.


Cheers,
Andi

diff -ur ../mailutils-1.1+dfsg1~/debian/changelog ../mailutils-1.1+dfsg1/debian/changelog
--- ../mailutils-1.1+dfsg1~/debian/changelog	2006-11-30 13:32:44.000000000 +0000
+++ ../mailutils-1.1+dfsg1/debian/changelog	2006-12-04 11:21:49.000000000 +0000
@@ -1,3 +1,11 @@
+mailutils (1:1.1+dfsg1-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix issue with mails containing \0. Thanks to Ben Hutchings for
+    the patch. Closes: #361354
+
+ -- Andreas Barth <aba@not.so.argh.org>  Mon,  4 Dec 2006 11:21:05 +0000
+
 mailutils (1:1.1+dfsg1-3) unstable; urgency=medium
 
   * debian/control: switch back to guile-1.6 as guile-1.8 is not yet ready
diff -ur ../mailutils-1.1+dfsg1~/imap4d/fetch.c ../mailutils-1.1+dfsg1/imap4d/fetch.c
--- ../mailutils-1.1+dfsg1~/imap4d/fetch.c	2006-03-12 14:25:50.000000000 +0000
+++ ../mailutils-1.1+dfsg1/imap4d/fetch.c	2006-12-04 11:15:59.000000000 +0000
@@ -1160,12 +1160,11 @@
       offset = 0;
       if (max)
 	{
-	  util_send (" {%u}\r\n", max);
+	  util_send (" {%lu}\r\n", max);
 	  while (mu_stream_read (rfc, buffer, sizeof (buffer) - 1, offset,
 			      &n) == 0 && n > 0)
 	    {
-	      buffer[n] = '\0';
-	      util_send ("%s", buffer);
+	      util_send_raw (buffer, n);
 	      offset += n;
 	    }
 	}
@@ -1190,13 +1189,11 @@
 	  end -= n;
 	  buffer += n;
 	}
-      /* Make sure we null terminate.  */
-      *buffer = '\0';
       util_send ("<%lu>", start);
       if (total)
 	{
 	  util_send (" {%s}\r\n", mu_umaxtostr (0, total));
-	  util_send ("%s", p);
+	  util_send_raw (p, total);
 	}
       else
 	util_send (" \"\"");
diff -ur ../mailutils-1.1+dfsg1~/imap4d/imap4d.h ../mailutils-1.1+dfsg1/imap4d/imap4d.h
--- ../mailutils-1.1+dfsg1~/imap4d/imap4d.h	2006-04-07 14:08:54.000000000 +0000
+++ ../mailutils-1.1+dfsg1/imap4d/imap4d.h	2006-12-04 11:18:43.000000000 +0000
@@ -245,6 +245,7 @@
 extern int  util_send (const char *, ...);
 extern int  util_send_qstring (const char *);
 extern int  util_send_literal (const char *);
+extern int  util_send_raw (const char *, size_t);
 extern int  util_start (char *);
 extern int  util_finish (struct imap4d_command *, int, const char *, ...);
 extern int  util_getstate (void);
diff -ur ../mailutils-1.1+dfsg1~/imap4d/util.c ../mailutils-1.1+dfsg1/imap4d/util.c
--- ../mailutils-1.1+dfsg1~/imap4d/util.c	2006-04-07 14:08:55.000000000 +0000
+++ ../mailutils-1.1+dfsg1/imap4d/util.c	2006-12-04 11:19:42.000000000 +0000
@@ -398,6 +398,15 @@
   return util_send ("{%u}\r\n%s", strlen (buffer), buffer);
 }
 
+int
+util_send_raw (const char *data, size_t len)
+{
+  if (daemon_param.transcript)
+    syslog (LOG_DEBUG, "sent: %s", data);
+
+  return mu_stream_sequential_write (ostream, data, len);
+}
+
 /* Send an unsolicited response.  */
 int
 util_out (int rc, const char *format, ...)
-- 
  http://home.arcor.de/andreas-barth/

Message #63 received at 361354-close@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 361354-close@bugs.debian.org

Subject: Bug#361354: fixed in mailutils 1:1.1+dfsg1-3.1

Date: Mon, 04 Dec 2006 11:47:06 +0000

Source: mailutils
Source-Version: 1:1.1+dfsg1-3.1

We believe that the bug you reported is fixed in the latest version of
mailutils, which is due to be installed in the Debian FTP archive:

libmailutils-dev_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/libmailutils-dev_1.1+dfsg1-3.1_amd64.deb
libmailutils1_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/libmailutils1_1.1+dfsg1-3.1_amd64.deb
mailutils-comsatd_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/mailutils-comsatd_1.1+dfsg1-3.1_amd64.deb
mailutils-imap4d_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/mailutils-imap4d_1.1+dfsg1-3.1_amd64.deb
mailutils-mh_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/mailutils-mh_1.1+dfsg1-3.1_amd64.deb
mailutils-pop3d_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/mailutils-pop3d_1.1+dfsg1-3.1_amd64.deb
mailutils_1.1+dfsg1-3.1.diff.gz
  to pool/main/m/mailutils/mailutils_1.1+dfsg1-3.1.diff.gz
mailutils_1.1+dfsg1-3.1.dsc
  to pool/main/m/mailutils/mailutils_1.1+dfsg1-3.1.dsc
mailutils_1.1+dfsg1-3.1_amd64.deb
  to pool/main/m/mailutils/mailutils_1.1+dfsg1-3.1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 361354@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Barth <aba@not.so.argh.org> (supplier of updated mailutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon,  4 Dec 2006 11:21:05 +0000
Source: mailutils
Binary: mailutils-mh mailutils-imap4d mailutils-comsatd mailutils-pop3d libmailutils-dev mailutils libmailutils1
Architecture: source amd64
Version: 1:1.1+dfsg1-3.1
Distribution: unstable
Urgency: high
Maintainer: Jordi Mallach <jordi@debian.org>
Changed-By: Andreas Barth <aba@not.so.argh.org>
Description: 
 libmailutils-dev - Development files for GNU mailutils
 libmailutils1 - GNU Mail abstraction library
 mailutils  - GNU mailutils utilities for handling mail
 mailutils-comsatd - GNU mailutils-based comsatd daemon
 mailutils-imap4d - GNU mailutils-based IMAP4 Daemon
 mailutils-mh - GNU mailutils-based MH utilities
 mailutils-pop3d - GNU mailutils-based POP3 Daemon
Closes: 361354
Changes: 
 mailutils (1:1.1+dfsg1-3.1) unstable; urgency=high
 .
   * Non-maintainer upload.
   * Fix issue with mails containing \0. Thanks to Ben Hutchings for
     the patch. Closes: #361354
Files: 
 983b0fdd9fbd294f511353ebd58a3a8d 1024 libs optional mailutils_1.1+dfsg1-3.1.dsc
 2114fe13d36e897577f0d6dd3977c825 21260 libs optional mailutils_1.1+dfsg1-3.1.diff.gz
 7e4950d3e1108589e5d63acc7408a349 724494 libs optional libmailutils1_1.1+dfsg1-3.1_amd64.deb
 52a25ba1a6e21c67981506e6c60f80fa 537892 libdevel optional libmailutils-dev_1.1+dfsg1-3.1_amd64.deb
 8390aa5a43fdbc04f717ed4bc9b8d5cf 313030 mail optional mailutils_1.1+dfsg1-3.1_amd64.deb
 46211340ae840d97174c271562bba9a6 121194 net optional mailutils-imap4d_1.1+dfsg1-3.1_amd64.deb
 6b99dbbe9f047b7814f584283f54bfb7 103546 net optional mailutils-pop3d_1.1+dfsg1-3.1_amd64.deb
 e174aa3f91e3ab937437b2433a8c45f4 87088 net optional mailutils-comsatd_1.1+dfsg1-3.1_amd64.deb
 024a1527b6615698371af31a886bbbf1 1012676 mail optional mailutils-mh_1.1+dfsg1-3.1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFdAeHmdOZoew2oYURAnGeAKCy0oqNBjjgRdomSCfWX3XFBA05HQCfSlge
ytOM8KKxJ0JSw3nCikIpOQ4=
=ee/g
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.