From 557bed989ddde2ec6cbf5ca29b775a27360b1abc Mon Sep 17 00:00:00 2001
From: bwarsaw <>
Date: Sun, 22 May 2005 19:55:08 +0000
Subject: process(): One more bug fix, though this one should be safe.  Under
 email 2.5, it is possible for a message to be "not is_multipart()" but to
 have a None payload.  I know of at least one situation where this can happen:
 you have a Content-Type: multipart/* but there is nothing but two blank lines
 between the first boundary and the end boundary.  Under email 3, you get a
 string payload but under email 2.5 you get None.

Because there's nothing in such parts, they should be safe to ignore.
---
 Mailman/Handlers/Scrubber.py | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Mailman/Handlers/Scrubber.py b/Mailman/Handlers/Scrubber.py
index 31b37985..24bb575f 100644
--- a/Mailman/Handlers/Scrubber.py
+++ b/Mailman/Handlers/Scrubber.py
@@ -282,10 +282,17 @@ Url: %(url)s
         # If the message isn't a multipart, then we'll strip it out as an
         # attachment that would have to be separately downloaded.  Pipermail
         # will transform the url into a hyperlink.
-        # TK: Confirm also part is not None. (bug-id: 1099138)
         elif part and not part.is_multipart():
             payload = part.get_payload(decode=True)
             ctype = part.get_type()
+            # XXX Under email 2.5, it is possible that payload will be None.
+            # This can happen when you have a Content-Type: multipart/* with
+            # only one part and that part has two blank lines between the
+            # first boundary and the end boundary.  In email 3.0 you end up
+            # with a string in the payload.  I think in this case it's safe to
+            # ignore the part.
+            if payload is None:
+                continue
             size = len(payload)
             omask = os.umask(002)
             try:
-- 
cgit v1.2.3