18 files changed, 201 insertions, 184 deletions

diff --git a/src/mailman/pipeline/docs/ack-headers.txt b/src/mailman/pipeline/docs/ack-headers.txt
index ca41df03e..49b203cad 100644
--- a/src/mailman/pipeline/docs/ack-headers.txt
+++ b/src/mailman/pipeline/docs/ack-headers.txt
@@ -1,3 +1,4 @@
+======================
 Acknowledgment headers
 ======================
 
@@ -8,8 +9,8 @@ changes depend on mailing list settings and others depend on how the message
 is getting sent through the system.  We'll take things one-by-one.
 
     >>> from mailman.pipeline.cook_headers import process
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.subject_prefix = u''
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.subject_prefix = ''
 
 When the message's metadata has a 'noack' key set, an 'X-Ack: no' header is
 added.
diff --git a/src/mailman/pipeline/docs/acknowledge.txt b/src/mailman/pipeline/docs/acknowledge.txt
index a4c68f900..72292cd80 100644
--- a/src/mailman/pipeline/docs/acknowledge.txt
+++ b/src/mailman/pipeline/docs/acknowledge.txt
@@ -1,3 +1,4 @@
+======================
 Message acknowledgment
 ======================
 
@@ -6,9 +7,9 @@ receive acknowledgments of their postings, Mailman will sent them such an
 acknowledgment.
 
     >>> handler = config.handlers['acknowledge']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.real_name = u'XTest'
-    >>> mlist.preferred_language = u'en'
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.real_name = 'XTest'
+    >>> mlist.preferred_language = 'en'
     >>> # XXX This will almost certainly change once we've worked out the web
     >>> # space layout for mailing lists now.
 
@@ -22,14 +23,14 @@ Subscribe a user to the mailing list.
 
     >>> usermgr = config.db.user_manager
     >>> from mailman.interfaces.member import MemberRole
-    >>> user_1 = usermgr.create_user(u'aperson@example.com')
+    >>> user_1 = usermgr.create_user('aperson@example.com')
     >>> address_1 = list(user_1.addresses)[0]
     >>> address_1.subscribe(mlist, MemberRole.member)
     <Member: aperson@example.com on _xtest@example.com as MemberRole.member>
 
 
 Non-member posts
-----------------
+================
 
 Non-members can't get acknowledgments of their posts to the mailing list.
 
@@ -49,13 +50,13 @@ person is also not a member, no acknowledgment will be sent either.
     ...
     ... """)
     >>> handler.process(mlist, msg,
-    ...     dict(original_sender=u'cperson@example.com'))
+    ...     dict(original_sender='cperson@example.com'))
     >>> virginq.files
     []
 
 
 No acknowledgment requested
----------------------------
+===========================
 
 Unless the user has requested acknowledgments, they will not get one.
 
@@ -71,19 +72,19 @@ Similarly if the original sender is specified in the message metadata, and
 that sender is a member but not one who has requested acknowledgments, none
 will be sent.
 
-    >>> user_2 = usermgr.create_user(u'dperson@example.com')
+    >>> user_2 = usermgr.create_user('dperson@example.com')
     >>> address_2 = list(user_2.addresses)[0]
     >>> address_2.subscribe(mlist, MemberRole.member)
     <Member: dperson@example.com on _xtest@example.com as MemberRole.member>
 
     >>> handler.process(mlist, msg,
-    ...     dict(original_sender=u'dperson@example.com'))
+    ...     dict(original_sender='dperson@example.com'))
     >>> virginq.files
     []
 
 
 Requested acknowledgments
--------------------------
+=========================
 
 If the member requests acknowledgments, Mailman will send them one when they
 post to the mailing list.
diff --git a/src/mailman/pipeline/docs/after-delivery.txt b/src/mailman/pipeline/docs/after-delivery.txt
index b910e89a6..da1a3af08 100644
--- a/src/mailman/pipeline/docs/after-delivery.txt
+++ b/src/mailman/pipeline/docs/after-delivery.txt
@@ -1,3 +1,4 @@
+==============
 After delivery
 ==============
 
@@ -7,7 +8,7 @@ bookkeeping pieces of information are updated.
 
     >>> import datetime
     >>> handler = config.handlers['after-delivery']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
     >>> post_time = datetime.datetime.now() - datetime.timedelta(minutes=10)
     >>> mlist.last_post_time = post_time
     >>> mlist.post_id = 10
diff --git a/src/mailman/pipeline/docs/archives.txt b/src/mailman/pipeline/docs/archives.txt
index d90228525..c6351a659 100644
--- a/src/mailman/pipeline/docs/archives.txt
+++ b/src/mailman/pipeline/docs/archives.txt
@@ -1,3 +1,4 @@
+========
 Archives
 ========
 
@@ -9,7 +10,7 @@ processes.
 
     >>> from mailman.app.lifecycle import create_list
     >>> handler = config.handlers['to-archive']
-    >>> mlist = create_list(u'_xtest@example.com')
+    >>> mlist = create_list('_xtest@example.com')
     >>> switchboard = config.switchboards['archive']
 
 A helper function.
diff --git a/src/mailman/pipeline/docs/avoid-duplicates.txt b/src/mailman/pipeline/docs/avoid-duplicates.txt
index fe91a9a71..adca9cbe5 100644
--- a/src/mailman/pipeline/docs/avoid-duplicates.txt
+++ b/src/mailman/pipeline/docs/avoid-duplicates.txt
@@ -1,3 +1,4 @@
+================
 Avoid duplicates
 ================
 
@@ -7,24 +8,24 @@ recipients from the list of recipients that earlier handler modules
 (e.g. CalcRecips) calculates.
 
     >>> handler = config.handlers['avoid-duplicates']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
 
 Create some members we're going to use.
 
     >>> from mailman.interfaces.member import MemberRole
     >>> address_a = config.db.user_manager.create_address(
-    ...     u'aperson@example.com')
+    ...     'aperson@example.com')
     >>> address_b = config.db.user_manager.create_address(
-    ...     u'bperson@example.com')
+    ...     'bperson@example.com')
     >>> member_a = address_a.subscribe(mlist, MemberRole.member)
     >>> member_b = address_b.subscribe(mlist, MemberRole.member)
     >>> # This is the message metadata dictionary as it would be produced by
     >>> # the CalcRecips handler.
-    >>> recips = dict(recips=[u'aperson@example.com', u'bperson@example.com'])
+    >>> recips = dict(recips=['aperson@example.com', 'bperson@example.com'])
 
 
 Short circuiting
-----------------
+================
 
 The module short-circuits if there are no recipients.
 
@@ -47,7 +48,7 @@ The module short-circuits if there are no recipients.
 
 
 Suppressing the list copy
--------------------------
+=========================
 
 Members can elect not to receive a list copy of any message on which they are
 explicitly named as a recipient.  This is done by setting their
diff --git a/src/mailman/pipeline/docs/calc-recips.txt b/src/mailman/pipeline/docs/calc-recips.txt
index adfbeabbf..03a22e5dc 100644
--- a/src/mailman/pipeline/docs/calc-recips.txt
+++ b/src/mailman/pipeline/docs/calc-recips.txt
@@ -1,3 +1,4 @@
+======================
 Calculating recipients
 ======================
 
@@ -6,18 +7,18 @@ of recipient addresses.  These addresses are calculated by one of the handler
 modules and depends on a host of factors.
 
     >>> handler = config.handlers['calculate-recipients']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
 
 Recipients are calculate from the list members, so add a bunch of members to
 start out with.  First, create a bunch of addresses...
 
     >>> usermgr = config.db.user_manager
-    >>> address_a = usermgr.create_address(u'aperson@example.com')
-    >>> address_b = usermgr.create_address(u'bperson@example.com')
-    >>> address_c = usermgr.create_address(u'cperson@example.com')
-    >>> address_d = usermgr.create_address(u'dperson@example.com')
-    >>> address_e = usermgr.create_address(u'eperson@example.com')
-    >>> address_f = usermgr.create_address(u'fperson@example.com')
+    >>> address_a = usermgr.create_address('aperson@example.com')
+    >>> address_b = usermgr.create_address('bperson@example.com')
+    >>> address_c = usermgr.create_address('cperson@example.com')
+    >>> address_d = usermgr.create_address('dperson@example.com')
+    >>> address_e = usermgr.create_address('eperson@example.com')
+    >>> address_f = usermgr.create_address('fperson@example.com')
 
 ...then subscribe these addresses to the mailing list as members...
 
@@ -38,7 +39,7 @@ start out with.  First, create a bunch of addresses...
 
 
 Short-circuiting
-----------------
+================
 
 Sometimes, the list of recipients already exists in the message metadata.
 This can happen for example, when a message was previously delivered to some
@@ -49,7 +50,7 @@ but not all of the recipients.
     ...
     ... Something of great import.
     ... """)
-    >>> recips = set((u'qperson@example.com', u'zperson@example.com'))
+    >>> recips = set(('qperson@example.com', 'zperson@example.com'))
     >>> msgdata = dict(recips=recips)
     >>> handler.process(mlist, msg, msgdata)
     >>> sorted(msgdata['recips'])
@@ -57,7 +58,7 @@ but not all of the recipients.
 
 
 Regular delivery recipients
----------------------------
+===========================
 
 Regular delivery recipients are those people who get messages from the list as
 soon as they are posted.  In other words, these folks are not digest members.
@@ -86,13 +87,13 @@ for details.
 
 
 Digest recipients
------------------
+=================
 
 XXX Test various digest deliveries.
 
 
 Urgent messages
----------------
+===============
 
 XXX Test various urgent deliveries:
     * test_urgent_moderator()
diff --git a/src/mailman/pipeline/docs/cleanse.txt b/src/mailman/pipeline/docs/cleanse.txt
index 0940cdb4b..778ecb19d 100644
--- a/src/mailman/pipeline/docs/cleanse.txt
+++ b/src/mailman/pipeline/docs/cleanse.txt
@@ -1,3 +1,4 @@
+=================
 Cleansing headers
 =================
 
@@ -6,7 +7,7 @@ related to additional permissions that can be granted to the message and other
 headers can be used to fish for membership.
 
     >>> handler = config.handlers['cleanse']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
 
 Headers such as Approved, Approve, and Urgent are used to grant special
 pemissions to individual messages.  All may contain a password; the first two
@@ -62,7 +63,7 @@ Pegasus mail.  I don't remember what program uses X-Confirm-Reading-To though
 
 
 Anonymous lists
----------------
+===============
 
 Anonymous mailing lists also try to cleanse certain identifying headers from
 the original posting, so that it is at least a bit more difficult to determine
@@ -73,8 +74,8 @@ and Reply-To headers in the posted message are taken from list attributes.
 Hotmail apparently sets X-Originating-Email.
 
     >>> mlist.anonymous_list = True
-    >>> mlist.description = u'A Test Mailing List'
-    >>> mlist.preferred_language = u'en'
+    >>> mlist.description = 'A Test Mailing List'
+    >>> mlist.preferred_language = 'en'
     >>> msg = message_from_string("""\
     ... From: bperson@example.com
     ... Reply-To: bperson@example.org
diff --git a/src/mailman/pipeline/docs/cook-headers.txt b/src/mailman/pipeline/docs/cook-headers.txt
index 2c6381c8f..127cd8aeb 100644
--- a/src/mailman/pipeline/docs/cook-headers.txt
+++ b/src/mailman/pipeline/docs/cook-headers.txt
@@ -1,3 +1,4 @@
+===============
 Cooking headers
 ===============
 
@@ -7,14 +8,14 @@ transformations.  Some headers get added, others get changed.  Some of these
 changes depend on mailing list settings and others depend on how the message
 is getting sent through the system.  We'll take things one-by-one.
 
-    >>> mlist = create_list(u'_xtest@example.com')
-    >>> mlist.subject_prefix = u''
+    >>> mlist = create_list('_xtest@example.com')
+    >>> mlist.subject_prefix = ''
     >>> mlist.include_list_post_header = False
     >>> mlist.archive = True
 
 
 Saving the original sender
---------------------------
+==========================
 
 Because the original sender headers may get deleted or changed, CookHeaders
 will place the sender in the message metadata for safe keeping.
@@ -28,8 +29,8 @@ will place the sender in the message metadata for safe keeping.
 
     >>> from mailman.pipeline.cook_headers import process
     >>> process(mlist, msg, msgdata)
-    >>> msgdata['original_sender']
-    u'aperson@example.com'
+    >>> print msgdata['original_sender']
+    aperson@example.com
 
 But if there was no original sender, then the empty string will be saved.
 
@@ -45,7 +46,7 @@ But if there was no original sender, then the empty string will be saved.
 
 
 X-BeenThere header
-------------------
+==================
 
 The X-BeenThere header is what Mailman uses to recognize messages that have
 already been processed by this mailing list.  It's one small measure against
@@ -57,8 +58,8 @@ mail loops.
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, {})
-    >>> msg['x-beenthere']
-    u'_xtest@example.com'
+    >>> print msg['x-beenthere']
+    _xtest@example.com
 
 Mailman appends X-BeenThere headers, so if there already is one in the
 original message, the posted message will contain two such headers.
@@ -75,7 +76,7 @@ original message, the posted message will contain two such headers.
 
 
 Mailman version header
-----------------------
+======================
 
 Mailman will also insert an X-Mailman-Version header...
 
@@ -98,12 +99,12 @@ Mailman will also insert an X-Mailman-Version header...
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, {})
-    >>> msg['x-mailman-version']
-    u'3000'
+    >>> print msg['x-mailman-version']
+    3000
 
 
 Precedence header
------------------
+=================
 
 Mailman will insert a Precedence header, which is a de-facto standard for
 telling automatic reply software (e.g. vacation(1)) not to respond to this
@@ -115,8 +116,8 @@ message.
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, {})
-    >>> msg['precedence']
-    u'list'
+    >>> print msg['precedence']
+    list
 
 But Mailman will only add that header if the original message doesn't already
 have one of them.
@@ -128,12 +129,12 @@ have one of them.
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, {})
-    >>> msg['precedence']
-    u'junk'
+    >>> print msg['precedence']
+    junk
 
 
 RFC 2919 and 2369 headers
--------------------------
+=========================
 
 This is a helper function for the following section.
 
@@ -180,7 +181,7 @@ But normally, a list will include these headers.
 
     >>> mlist.include_rfc2369_headers = True
     >>> mlist.include_list_post_header = True
-    >>> mlist.preferred_language = u'en'
+    >>> mlist.preferred_language = 'en'
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ... Message-ID: <12345>
@@ -202,7 +203,7 @@ But normally, a list will include these headers.
 If the mailing list has a description, then it is included in the List-Id
 header.
 
-    >>> mlist.description = u'My test mailing list'
+    >>> mlist.description = 'My test mailing list'
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ...
@@ -225,20 +226,20 @@ set the List-ID header.  Start by creating a new domain.
 
     >>> from mailman.interfaces.domain import IDomainManager
     >>> manager = IDomainManager(config)
-    >>> domain = manager.add(u'mail.example.net')
-    >>> mlist.host_name = u'mail.example.net'
+    >>> domain = manager.add('mail.example.net')
+    >>> mlist.host_name = 'mail.example.net'
 
     >>> process(mlist, msg, {})
     >>> print msg['list-id']
     My test mailing list <_xtest.example.com>
 
-    >>> mlist.list_id = u'_xtest.mail.example.net'
+    >>> mlist.list_id = '_xtest.mail.example.net'
     >>> process(mlist, msg, {})
     >>> print msg['list-id']
     My test mailing list <_xtest.mail.example.net>
 
-    >>> mlist.host_name = u'example.com'
-    >>> mlist.list_id = u'_xtest.example.com'
+    >>> mlist.host_name = 'example.com'
+    >>> mlist.list_id = '_xtest.example.com'
 
 Any existing List-ID headers are removed from the original message.
 
@@ -313,7 +314,7 @@ List-Archive header either.
 
 
 Archived-At
------------
+===========
 
 RFC 5064 (draft) defines a new Archived-At header which contains the url to
 the individual message in the archives.  The stock Pipermail archiver doesn't
@@ -326,7 +327,7 @@ available to us now.
 
 
 Personalization
----------------
+===============
 
 The To field normally contains the list posting address.  However when
 messages are fully personalized, that header will get overwritten with the
diff --git a/src/mailman/pipeline/docs/decorate.txt b/src/mailman/pipeline/docs/decorate.txt
index b805e23cf..ee2f4d10e 100644
--- a/src/mailman/pipeline/docs/decorate.txt
+++ b/src/mailman/pipeline/docs/decorate.txt
@@ -1,3 +1,4 @@
+==================
 Message decoration
 ==================
 
@@ -6,7 +7,7 @@ original message.  A handler module takes care of this based on the settings
 of the mailing list and the type of message being processed.
 
     >>> from mailman.pipeline.decorate import process
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
     >>> msg_text = """\
     ... From: aperson@example.org
     ...
@@ -16,7 +17,7 @@ of the mailing list and the type of message being processed.
 
 
 Short circuiting
-----------------
+================
 
 Digest messages get decorated during the digest creation phase so no extra
 decorations are added for digest messages.
@@ -35,7 +36,7 @@ decorations are added for digest messages.
 
 
 Decorating simple text messages
--------------------------------
+===============================
 
 Text messages that have no declared content type character set are by default,
 encoded in us-ascii.  When the mailing list's preferred language is 'en'
@@ -45,9 +46,9 @@ placeholder variables, the message's payload will be prepended by the verbatim
 header, and appended with the verbatim footer.
 
     >>> msg = message_from_string(msg_text)
-    >>> mlist.msg_header = u'header\n'
-    >>> mlist.msg_footer = u'footer'
-    >>> mlist.preferred_language = u'en'
+    >>> mlist.msg_header = 'header\n'
+    >>> mlist.msg_footer = 'footer'
+    >>> mlist.preferred_language = 'en'
     >>> process(mlist, msg, {})
     >>> print msg.as_string()
     From: aperson@example.org
@@ -63,9 +64,9 @@ data.  An example of such information is the mailing list's "real name" (a
 short descriptive name for the mailing list).
 
     >>> msg = message_from_string(msg_text)
-    >>> mlist.msg_header = u'$real_name header\n'
-    >>> mlist.msg_footer = u'$real_name footer'
-    >>> mlist.real_name = u'XTest'
+    >>> mlist.msg_header = '$real_name header\n'
+    >>> mlist.msg_footer = '$real_name footer'
+    >>> mlist.real_name = 'XTest'
     >>> process(mlist, msg, {})
     >>> print msg.as_string()
     From: aperson@example.org
@@ -78,8 +79,8 @@ You can't just pick any interpolation variable though; if you do, the variable
 will remain in the header or footer unchanged.
 
     >>> msg = message_from_string(msg_text)
-    >>> mlist.msg_header = u'$dummy header\n'
-    >>> mlist.msg_footer = u'$dummy footer'
+    >>> mlist.msg_header = '$dummy header\n'
+    >>> mlist.msg_footer = '$dummy footer'
     >>> process(mlist, msg, {})
     >>> print msg.as_string()
     From: aperson@example.org
@@ -90,7 +91,7 @@ will remain in the header or footer unchanged.
 
 
 Handling RFC 3676 'format=flowed' parameters
---------------------------------------------
+============================================
 
 RFC 3676 describes a standard by which text/plain messages can marked by
 generating MUAs for better readability in compatible receiving MUAs.  The
@@ -102,9 +103,9 @@ When Mailman sees text/plain messages with such RFC 3676 parameters, it
 preserves these parameters when it concatenates headers and footers to the
 message payload.
 
-    >>> mlist.msg_header = u'header'
-    >>> mlist.msg_footer = u'footer'
-    >>> mlist.preferred_language = u'en'
+    >>> mlist.msg_header = 'header'
+    >>> mlist.msg_footer = 'footer'
+    >>> mlist.preferred_language = 'en'
     >>> msg = message_from_string("""\
     ... From: aperson@example.org
     ... Content-Type: text/plain; format=flowed; delsp=no
@@ -116,14 +117,14 @@ message payload.
     >>> # Don't use 'print' here as above because it won't be obvious from the
     >>> # output that the soft-line break space at the end of the 'Here is a
     >>> # message' line will be retained in the output.
-    >>> msg['content-type']
-    u'text/plain; format="flowed"; delsp="no"; charset="us-ascii"'
+    >>> print msg['content-type']
+    text/plain; format="flowed"; delsp="no"; charset="us-ascii"
     >>> [line for line in msg.get_payload().splitlines()]
     ['header', 'Here is a message ', 'with soft line breaks.', 'footer']
 
 
 Decorating mixed-charset messages
----------------------------------
+=================================
 
 When a message has no explicit character set, it is assumed to be us-ascii.
 However, if the mailing list's preferred language has a different character
@@ -131,10 +132,10 @@ set, Mailman will still try to concatenate the header and footer, but it will
 convert the text to utf-8 and base-64 encode the message payload.
 
     # 'ja' = Japanese; charset = 'euc-jp'
-    >>> mlist.preferred_language = u'ja'
-    >>> mlist.msg_header = u'$description header'
-    >>> mlist.msg_footer = u'$description footer'
-    >>> mlist.description = u'\u65e5\u672c\u8a9e'
+    >>> mlist.preferred_language = 'ja'
+    >>> mlist.msg_header = '$description header'
+    >>> mlist.msg_footer = '$description footer'
+    >>> mlist.description = '\u65e5\u672c\u8a9e'
 
     >>> from email.message import Message
     >>> msg = Message()
@@ -153,14 +154,13 @@ convert the text to utf-8 and base-64 encode the message payload.
     <BLANKLINE>
     5pel5pys6KqeIGhlYWRlcgpGcmFuw6dhaXNlCuaXpeacrOiqniBmb290ZXI=
 
-
 Sometimes the message even has an unknown character set.  In this case,
 Mailman has no choice but to decorate the original message with MIME
 attachments.
 
-    >>> mlist.preferred_language = u'en'
-    >>> mlist.msg_header = u'header'
-    >>> mlist.msg_footer = u'footer'
+    >>> mlist.preferred_language = 'en'
+    >>> mlist.msg_header = 'header'
+    >>> mlist.msg_footer = 'footer'
     >>> msg = message_from_string("""\
     ... From: aperson@example.org
     ... Content-Type: text/plain; charset=unknown
@@ -198,7 +198,7 @@ attachments.
 
 
 Decorating multipart messages
------------------------------
+=============================
 
 Multipart messages have to be decorated differently.  The header and footer
 cannot be simply concatenated into the payload because that will break the
@@ -209,9 +209,9 @@ When the outerpart is multipart/mixed, the header and footer can have a
 Content-Disposition of 'inline' so that MUAs can display these headers as if
 they were simply concatenated.
 
-    >>> mlist.preferred_language = u'en'
-    >>> mlist.msg_header = u'header'
-    >>> mlist.msg_footer = u'footer'
+    >>> mlist.preferred_language = 'en'
+    >>> mlist.msg_header = 'header'
+    >>> mlist.msg_footer = 'footer'
     >>> part_1 = message_from_string("""\
     ... From: aperson@example.org
     ...
@@ -258,7 +258,7 @@ they were simply concatenated.
 
 
 Decorating other content types
-------------------------------
+==============================
 
 Non-multipart non-text content types will get wrapped in a multipart/mixed so
 that the header and footer can be added as attachments.
@@ -297,7 +297,7 @@ that the header and footer can be added as attachments.
 
 
 Personalization
----------------
+===============
 
 A mailing list can be 'personalized', meaning that each message is unique for
 each recipient.  When the list is personalized, additional interpolation
diff --git a/src/mailman/pipeline/docs/file-recips.txt b/src/mailman/pipeline/docs/file-recips.txt
index 81510b6e7..479ae9975 100644
--- a/src/mailman/pipeline/docs/file-recips.txt
+++ b/src/mailman/pipeline/docs/file-recips.txt
@@ -1,3 +1,4 @@
+===============
 File recipients
 ===============
 
@@ -6,11 +7,11 @@ include file.  This file must be called members.txt and it must live in the
 list's data directory.
 
     >>> handler = config.handlers['file-recipients']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
 
 
 Short circuiting
-----------------
+================
 
 If the message's metadata already has recipients, this handler immediately
 returns.
@@ -28,11 +29,11 @@ returns.
     A message.
     <BLANKLINE>
     >>> msgdata
-    {'recips': 7}
+    {u'recips': 7}
 
 
 Missing file
-------------
+============
 
 The include file must live inside the list's data directory, under the name
 members.txt.  If the file doesn't exist, the list of recipients will be
@@ -52,7 +53,7 @@ empty.
 
 
 Existing file
--------------
+=============
 
 If the file exists, it contains a list of addresses, one per line.  These
 addresses are returned as the set of recipients.
@@ -80,7 +81,7 @@ in the recipients list.
 
     >>> from mailman.interfaces.member import MemberRole
     >>> address_1 = config.db.user_manager.create_address(
-    ...     u'cperson@example.com')
+    ...     'cperson@example.com')
     >>> address_1.subscribe(mlist, MemberRole.member)
     <Member: cperson@example.com on _xtest@example.com as MemberRole.member>
 
diff --git a/src/mailman/pipeline/docs/filtering.txt b/src/mailman/pipeline/docs/filtering.txt
index f895220f0..241f282d9 100644
--- a/src/mailman/pipeline/docs/filtering.txt
+++ b/src/mailman/pipeline/docs/filtering.txt
@@ -1,3 +1,4 @@
+=================
 Content filtering
 =================
 
@@ -5,7 +6,7 @@ Mailman can filter the content of messages posted to a mailing list by
 stripping MIME subparts, and possibly reorganizing the MIME structure of a
 message.
 
-    >>> mlist = create_list(u'test@example.com')
+    >>> mlist = create_list('test@example.com')
 
 Several mailing list options control content filtering.  First, the feature
 must be enabled, then there are two options that control which MIME types get
@@ -20,7 +21,7 @@ for these variables, then we'll explain them in more detail below.
 
 
 Filtering the outer content type
---------------------------------
+================================
 
 A simple filtering setting will just search the content types of the messages
 parts, discarding all parts with a matching MIME type.  If the message's outer
@@ -28,7 +29,7 @@ content type matches the filter, the entire message will be discarded.
 
     >>> from mailman.interfaces.mime import FilterAction
 
-    >>> mlist.filter_types = [u'image/jpeg']
+    >>> mlist.filter_types = ['image/jpeg']
     >>> mlist.filter_action = FilterAction.discard
 
     >>> msg = message_from_string("""\
@@ -73,11 +74,11 @@ crafted internally by Mailman.
     <BLANKLINE>
     xxxxx
     >>> msgdata
-    {'isdigest': True}
+    {u'isdigest': True}
 
 
 Simple multipart filtering
---------------------------
+==========================
 
 If one of the subparts in a multipart message matches the filter type, then
 just that subpart will be stripped.
@@ -118,7 +119,7 @@ just that subpart will be stripped.
 
 
 Collapsing multipart/alternative messages
------------------------------------------
+=========================================
 
 When content filtering encounters a multipart/alternative part, and the
 results of filtering leave only one of the subparts, then the
@@ -178,7 +179,7 @@ part with just one subpart, the entire message is converted to the left over
 part's content type.  In other words, the left over inner part is promoted to
 being the outer part.
 
-    >>> mlist.filter_types = [u'image/jpeg', u'text/html']
+    >>> mlist.filter_types = ['image/jpeg', 'text/html']
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ... Content-Type: multipart/alternative; boundary=AAA
@@ -204,11 +205,11 @@ being the outer part.
 
 Clean up.
 
-    >>> mlist.filter_types = [u'image/jpeg']
+    >>> mlist.filter_types = ['image/jpeg']
 
 
 Conversion to plain text
-------------------------
+========================
 
 Many mailing lists prohibit HTML email, and in fact, such email can be a
 phishing or spam vector.  However, many mail readers will send HTML email by
@@ -265,7 +266,7 @@ name of the file containing the message payload to filter.
 
 
 Discarding empty parts
-----------------------
+======================
 
 Similarly, if after filtering a multipart section ends up empty, then the
 entire multipart is discarded.  For example, here's a message where an inner
@@ -337,7 +338,7 @@ the entire inner multipart/mixed is discarded.
 
 
 Passing MIME types
-------------------
+==================
 
 XXX Describe the pass_mime_types setting and how it interacts with
 filter_mime_types.
diff --git a/src/mailman/pipeline/docs/nntp.txt b/src/mailman/pipeline/docs/nntp.txt
index 3f48be1da..dda104309 100644
--- a/src/mailman/pipeline/docs/nntp.txt
+++ b/src/mailman/pipeline/docs/nntp.txt
@@ -1,13 +1,14 @@
-NNTP (i.e. Usenet) Gateway
-==========================
+============
+NNTP Gateway
+============
 
 Mailman has an NNTP gateway, whereby messages posted to the mailing list can
 be forwarded onto an NNTP newsgroup.  Typically this means Usenet, but since
 NNTP is to Usenet as IP is to the web, it's more general than that.
 
     >>> handler = config.handlers['to-usenet']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.preferred_language = u'en'
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.preferred_language = 'en'
     >>> switchboard = config.switchboards['news']
 
 Gatewaying from the mailing list to the newsgroup happens through a separate
@@ -46,8 +47,8 @@ However, other posted messages get gated to the newsgroup via the nntp queue.
 The list owner can set the linked newsgroup and the nntp host that its
 messages are gated to.
 
-    >>> mlist.linked_newsgroup = u'comp.lang.thing'
-    >>> mlist.nntp_host = u'news.example.com'
+    >>> mlist.linked_newsgroup = 'comp.lang.thing'
+    >>> mlist.nntp_host = 'news.example.com'
     >>> handler.process(mlist, msg, {})
     >>> len(switchboard.files)
     1
diff --git a/src/mailman/pipeline/docs/reply-to.txt b/src/mailman/pipeline/docs/reply-to.txt
index e57b97e5d..2652753d6 100644
--- a/src/mailman/pipeline/docs/reply-to.txt
+++ b/src/mailman/pipeline/docs/reply-to.txt
@@ -1,3 +1,4 @@
+================
 Reply-to munging
 ================
 
@@ -8,8 +9,8 @@ changes depend on mailing list settings and others depend on how the message
 is getting sent through the system.  We'll take things one-by-one.
 
     >>> from mailman.pipeline.cook_headers import process
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.subject_prefix = u''
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.subject_prefix = ''
 
 Reply-to munging refers to the behavior where a mailing list can be configured
 to change or augment an existing Reply-To header in a message posted to the
@@ -30,7 +31,7 @@ this mis-feature.
 
 
 Reply to list
--------------
+=============
 
 A list can be configured to add a Reply-To header pointing back to the mailing
 list's posting address.  If there's no Reply-To header in the original
@@ -38,8 +39,8 @@ message, the list's posting address simply gets inserted.
 
     >>> from mailman.interfaces.mailinglist import ReplyToMunging
     >>> mlist.reply_goes_to_list = ReplyToMunging.point_to_list
-    >>> mlist.preferred_language = u'en'
-    >>> mlist.description = u''
+    >>> mlist.preferred_language = 'en'
+    >>> mlist.description = ''
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ...
@@ -47,8 +48,8 @@ message, the list's posting address simply gets inserted.
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'_xtest@example.com'
+    >>> print msg['reply-to']
+    _xtest@example.com
 
 It's also possible to strip any existing Reply-To header first, before adding
 the list's posting address.
@@ -62,8 +63,8 @@ the list's posting address.
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'_xtest@example.com'
+    >>> print msg['reply-to']
+    _xtest@example.com
 
 If you don't first strip the header, then the list's posting address will just
 get appended to whatever the original version was.
@@ -77,17 +78,17 @@ get appended to whatever the original version was.
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'bperson@example.com, _xtest@example.com'
+    >>> print msg['reply-to']
+    bperson@example.com, _xtest@example.com
 
 
 Explicit Reply-To
------------------
+=================
 
 The list can also be configured to have an explicit Reply-To header.
 
     >>> mlist.reply_goes_to_list = ReplyToMunging.explicit_header
-    >>> mlist.reply_to_address = u'my-list@example.com'
+    >>> mlist.reply_to_address = 'my-list@example.com'
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ...
@@ -95,8 +96,8 @@ The list can also be configured to have an explicit Reply-To header.
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'my-list@example.com'
+    >>> print msg['reply-to']
+    my-list@example.com
 
 And as before, it's possible to either strip any existing Reply-To header...
 
@@ -109,8 +110,8 @@ And as before, it's possible to either strip any existing Reply-To header...
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'my-list@example.com'
+    >>> print msg['reply-to']
+    my-list@example.com
 
 ...or not.
 
@@ -123,5 +124,5 @@ And as before, it's possible to either strip any existing Reply-To header...
     >>> process(mlist, msg, {})
     >>> len(msg.get_all('reply-to'))
     1
-    >>> msg['reply-to']
-    u'my-list@example.com, bperson@example.com'
+    >>> print msg['reply-to']
+    my-list@example.com, bperson@example.com
diff --git a/src/mailman/pipeline/docs/replybot.txt b/src/mailman/pipeline/docs/replybot.txt
index 6c4d896a4..36bc6198f 100644
--- a/src/mailman/pipeline/docs/replybot.txt
+++ b/src/mailman/pipeline/docs/replybot.txt
@@ -1,3 +1,4 @@
+==========================
 Automatic response handler
 ==========================
 
@@ -6,12 +7,12 @@ receives on its posting address, owner address, or robot address.  Automatic
 responses are subject to various conditions, such as headers in the original
 message or the amount of time since the last auto-response.
 
-    >>> mlist = create_list(u'_xtest@example.com')
-    >>> mlist.real_name = u'XTest'
+    >>> mlist = create_list('_xtest@example.com')
+    >>> mlist.real_name = 'XTest'
 
 
 Basic automatic responding
---------------------------
+==========================
 
 Basic automatic responding occurs when the list is set up to respond to either
 its -owner address, its -request address, or to the posting address, and a
@@ -24,7 +25,7 @@ a second response will be sent, with 0 meaning "there is no grace period".
 
     >>> mlist.autorespond_owner = ResponseAction.respond_and_continue
     >>> mlist.autoresponse_grace_period = datetime.timedelta()
-    >>> mlist.autoresponse_owner_text = u'owner autoresponse text'
+    >>> mlist.autoresponse_owner_text = 'owner autoresponse text'
 
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
@@ -69,7 +70,7 @@ response.
 
 
 Short circuiting
-----------------
+================
 
 Several headers in the original message determine whether an automatic
 response should even be sent.  For example, if the message has an "X-Ack: No"
@@ -157,14 +158,14 @@ header is ignored.
 
 
 Available auto-responses
-------------------------
+========================
 
 As shown above, a message sent to the -owner address will get an auto-response
 with the text set for owner responses.  Two other types of email will get
 auto-responses: those sent to the -request address...
 
     >>> mlist.autorespond_requests = ResponseAction.respond_and_continue
-    >>> mlist.autoresponse_request_text = u'robot autoresponse text'
+    >>> mlist.autoresponse_request_text = 'robot autoresponse text'
 
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
@@ -196,7 +197,7 @@ auto-responses: those sent to the -request address...
 ...and those sent to the posting address.
 
     >>> mlist.autorespond_postings = ResponseAction.respond_and_continue
-    >>> mlist.autoresponse_postings_text = u'postings autoresponse text'
+    >>> mlist.autoresponse_postings_text = 'postings autoresponse text'
 
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
@@ -227,7 +228,7 @@ auto-responses: those sent to the -request address...
 
 
 Grace periods
--------------
+=============
 
 Automatic responses have a grace period, during which no additional responses
 will be sent.  This is so as not to bombard the sender with responses.  The
diff --git a/src/mailman/pipeline/docs/scrubber.txt b/src/mailman/pipeline/docs/scrubber.txt
index dec1c1f64..8bc33aa13 100644
--- a/src/mailman/pipeline/docs/scrubber.txt
+++ b/src/mailman/pipeline/docs/scrubber.txt
@@ -1,3 +1,4 @@
+============
 The scrubber
 ============
 
@@ -7,8 +8,8 @@ scrub attachments from messages so that binary goop doesn't end up in an
 archive message.
 
     >>> from mailman.pipeline.scrubber import process, save_attachment
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.preferred_language = u'en'
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.preferred_language = 'en'
 
 Helper functions for getting the attachment data.
 
@@ -38,7 +39,7 @@ Helper functions for getting the attachment data.
 
 
 Saving attachments
-------------------
+==================
 
 The Scrubber handler exposes a function called save_attachments() which can be
 used to strip various types of attachments and store them in the archive
@@ -61,11 +62,11 @@ this is an unfortunate double negative).
     ... 
     ... R0lGODdhAQABAIAAAAAAAAAAACwAAAAAAQABAAACAQUAOw==
     ... """)
-    >>> save_attachment(mlist, msg, 'dir')
-    u'<http://www.example.com/pipermail/_xtest@example.com/dir/xtest.gif>'
+    >>> print save_attachment(mlist, msg, 'dir')
+    <http://www.example.com/pipermail/_xtest@example.com/dir/xtest.gif>
     >>> data = read_attachment('dir/xtest.gif')
-    >>> data[:6]
-    'GIF87a'
+    >>> print data[:6]
+    GIF87a
     >>> len(data)
     34
 
@@ -93,21 +94,21 @@ Content-Disposition: filename.  This is the default.
     ... 
     ... R0lGODdhAQABAIAAAAAAAAAAACwAAAAAAQABAAACAQUAOw==
     ... """)
-    >>> save_attachment(mlist, msg, 'dir')
-    u'<http://www.example.com/pipermail/_xtest@example.com/dir/attachment.gif>'
+    >>> print save_attachment(mlist, msg, 'dir')
+    <http://www.example.com/pipermail/_xtest@example.com/dir/attachment.gif>
     >>> data = read_attachment('dir/xtest.gif')
     Traceback (most recent call last):
     IOError: [Errno ...] No such file or directory:
         u'.../archives/private/_xtest@example.com/dir/xtest.gif'
     >>> data = read_attachment('dir/attachment.gif')
-    >>> data[:6]
-    'GIF87a'
+    >>> print data[:6]
+    GIF87a
     >>> len(data)
     34
 
 
 Scrubbing image attachments
----------------------------
+===========================
 
 When scrubbing image attachments, the original message is modified to include
 a reference to the attachment file as available through the on-line archive.
@@ -182,7 +183,7 @@ The URL will point to the attachment sitting in the archive.
 
 
 Scrubbing text attachments
---------------------------
+==========================
 
 Similar to image attachments, text attachments will also be scrubbed, but the
 placeholder will be slightly different.
@@ -220,6 +221,6 @@ placeholder will be slightly different.
 
 
 Clean up
---------
+========
 
     >>> config.pop('test config')
diff --git a/src/mailman/pipeline/docs/subject-munging.txt b/src/mailman/pipeline/docs/subject-munging.txt
index b2972683b..68ad940e8 100644
--- a/src/mailman/pipeline/docs/subject-munging.txt
+++ b/src/mailman/pipeline/docs/subject-munging.txt
@@ -1,3 +1,4 @@
+===============
 Subject munging
 ===============
 
@@ -8,20 +9,20 @@ changes depend on mailing list settings and others depend on how the message
 is getting sent through the system.  We'll take things one-by-one.
 
     >>> from mailman.pipeline.cook_headers import process
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
-    >>> mlist.subject_prefix = u''
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
+    >>> mlist.subject_prefix = ''
 
 
 Inserting a prefix
-------------------
+==================
 
 Another thing CookHeaders does is 'munge' the Subject header by inserting the
 subject prefix for the list at the front.  If there's no subject header in the
 original message, Mailman uses a canned default.  In order to do subject
 munging, a mailing list must have a preferred language.
 
-    >>> mlist.subject_prefix = u'[XTest] '
-    >>> mlist.preferred_language = u'en'
+    >>> mlist.subject_prefix = '[XTest] '
+    >>> mlist.preferred_language = 'en'
     >>> msg = message_from_string("""\
     ... From: aperson@example.com
     ...
@@ -50,8 +51,8 @@ the beginning of the header's value.
     ... """)
     >>> msgdata = {}
     >>> process(mlist, msg, msgdata)
-    >>> msgdata['origsubj']
-    u'Something important'
+    >>> print msgdata['origsubj']
+    Something important
     >>> print msg['subject']
     [XTest] Something important
 
@@ -64,8 +65,8 @@ Subject headers are not munged for digest messages.
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, dict(isdigest=True))
-    >>> msg['subject']
-    u'Something important'
+    >>> print msg['subject']
+    Something important
 
 Nor are they munged for 'fast tracked' messages, which are generally defined
 as messages that Mailman crafts internally.
@@ -77,8 +78,8 @@ as messages that Mailman crafts internally.
     ... A message of great import.
     ... """)
     >>> process(mlist, msg, dict(_fasttrack=True))
-    >>> msg['subject']
-    u'Something important'
+    >>> print msg['subject']
+    Something important
 
 If a Subject header already has a prefix, usually following a Re: marker,
 another one will not be added but the prefix will be moved to the front of the
@@ -110,7 +111,7 @@ option available in Mailman 3.
 
 
 Internationalized headers
--------------------------
+=========================
 
 Internationalization adds some interesting twists to the handling of subject
 prefixes.  Part of what makes this interesting is the encoding of i18n headers
@@ -129,14 +130,14 @@ set than the encoded header.
 
 
 Prefix numbers
---------------
+==============
 
 Subject prefixes support a placeholder for the numeric post id.  Every time a
 message is posted to the mailing list, a 'post id' gets incremented.  This is
 a purely sequential integer that increases monotonically.  By added a '%d'
 placeholder to the subject prefix, this post id can be included in the prefix.
 
-    >>> mlist.subject_prefix = u'[XTest %d] '
+    >>> mlist.subject_prefix = '[XTest %d] '
     >>> mlist.post_id = 456
     >>> msg = message_from_string("""\
     ... Subject: Something important
@@ -218,7 +219,7 @@ In this test case, we get an extra space between the prefix and the original
 subject.  It's because the original is 'crooked'.  Note that a Subject
 starting with '\n ' is generated by some version of Eudora Japanese edition.
 
-    >>> mlist.subject_prefix = u'[XTest] '
+    >>> mlist.subject_prefix = '[XTest] '
     >>> msg = message_from_string("""\
     ... Subject:
     ...  Important message
diff --git a/src/mailman/pipeline/docs/tagger.txt b/src/mailman/pipeline/docs/tagger.txt
index 9f0bcd4b2..a552401f7 100644
--- a/src/mailman/pipeline/docs/tagger.txt
+++ b/src/mailman/pipeline/docs/tagger.txt
@@ -1,3 +1,4 @@
+==============
 Message tagger
 ==============
 
@@ -9,7 +10,7 @@ its Subject: and Keywords: headers compared against these regular
 expressions.  The message then gets tagged with the topic names of each hit.
 
     >>> from mailman.pipeline.tagger import process
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
 
 Topics must be enabled for Mailman to do any topic matching, even if topics
 are defined.
@@ -52,11 +53,11 @@ the message metadata gets a key with a list of matching topic names.
     <BLANKLINE>
     <BLANKLINE>
     >>> msgdata['topichits']
-    ['bar fight']
+    [u'bar fight']
 
 
 Scanning body lines
--------------------
+===================
 
 The tagger can also look at a certain number of body lines, but only for
 Subject: and Keyword: header-like lines.  When set to zero, no body lines are
@@ -111,7 +112,7 @@ found.
     Keywords: barbaz
     <BLANKLINE>
     >>> msgdata['topichits']
-    ['bar fight']
+    [u'bar fight']
 
 However, scanning stops at the first body line that doesn't look like a
 header.
@@ -155,14 +156,14 @@ When set to a negative number, all body lines will be scanned.
     >>> process(mlist, msg, msgdata)
     >>> # Rather than print out 100 X-Ignore: headers, let's just prove that
     >>> # the X-Topics: header exists, meaning that the tagger did its job.
-    >>> msg['x-topics']
-    u'bar fight'
+    >>> print msg['x-topics']
+    bar fight
     >>> msgdata['topichits']
-    ['bar fight']
+    [u'bar fight']
 
 
 Scanning sub-parts
-------------------
+==================
 
 The tagger will also scan the body lines of text subparts in a multipart
 message, using the same rules as if all those body lines lived in a single
@@ -200,7 +201,7 @@ text payload.
     --BOUNDARY--
     <BLANKLINE>
     >>> msgdata['topichits']
-    ['bar fight']
+    [u'bar fight']
 
 But the tagger will not descend into non-text parts.
 
diff --git a/src/mailman/pipeline/docs/to-outgoing.txt b/src/mailman/pipeline/docs/to-outgoing.txt
index 5305db19f..9d467bb5e 100644
--- a/src/mailman/pipeline/docs/to-outgoing.txt
+++ b/src/mailman/pipeline/docs/to-outgoing.txt
@@ -1,3 +1,4 @@
+====================
 The outgoing handler
 ====================
 
@@ -10,7 +11,7 @@ basically describes how to encode the recipient's address in the originator
 headers for unambigous bounce processing.
 
     >>> handler = config.handlers['to-outgoing']
-    >>> mlist = config.db.list_manager.create(u'_xtest@example.com')
+    >>> mlist = config.db.list_manager.create('_xtest@example.com')
     >>> switchboard = config.switchboards['out']
 
     >>> def queue_size():