FAQ
(I've already reported this to the Mailman jitterbug database.)

The daily digest of mailman-users messages I receive has broken MIME
multipart structure. One of the multipart boundaries is not correctly
nested. Here's the structure of yesterday's digest, for example:

--132.151.1.90.9001.6311.929163771.576.10662
--132.151.1.90.9001.6311.929163771.576.10662
--132.151.1.90.9001.6311.929163771.576.10662
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--__--__--
--132.151.1.90.9001.6311.929163771.576.10662
--__--__----
--132.151.1.90.9001.6311.929163771.576.10662--

Note that the closing "--__--__----" boundary appears outside the
subpart in which it's valid.

I'm happy to help diagnose or correct this problem in the code, but
first I'd like to know whether this is a known problem for which a fix
may already exist.

Cheers,
- Bob

Search Discussions

  • Bob Glickstein at Jun 14, 1999 at 6:46 pm

    Bob Glickstein writes:
    The daily digest of mailman-users messages I receive has broken MIME
    multipart structure.
    Well, there's another bug: my report about the first bug was mangled
    by mailman's digest-creation code.

    My previous message included lines consisting solely of the character
    sequence dash-dash-underscore-underscore-dash-dash-underscore-
    underscore-dash-dash, to illustrate the sequence of MIME boundaries in
    a sample digest message. But because that very sequence of characters
    is used by mailman as a MIME digest separator, mailman correctly
    decided to alter those lines in the text of my message to avoid them
    being misinterpreted as structure. However, it did the alteration in
    a non-reversible way: it added a blank space after the first two
    dashes. (It also added a second space before the last two dashes in
    the line representing the closing boundary.)

    I can think of two better approaches off the top of my head. One is
    to qp-encode lines that might be mistaken for MIME boundaries.
    Another is not to reuse predictable boundary strings, but to generate
    new ones each time that are very unlikely to cause collisions.

    As before, I'm happy to help make the software better; just tell me
    whether my help is needed.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJun 12, '99 at 4:26p
activeJun 14, '99 at 6:46p
posts2
users2
websitelist.org

2 users in discussion

Bob Glickstein: 1 post Bob Glickstein: 1 post

People

Translate

site design / logo © 2022 Grokbase