Ulf R. writes:
msg.defects [CloseBoundaryNotFoundDefect()]
This means that the message declares a MIME multipart Content-Type, and some part had a "start" boundary line but no "end" boundary line.
Is there a quick fix for this available?
No. If the sending software isn't quite broken, this defect means that a chunk of the message was lost somewhere. Ignoring this kind of defect is obviously a bad idea, and any other fix (on the Mailman side) requires knowing precisely what's causing the defect to be detected.
Is it a problem of the python code or the format of the HCL Notes Server?
Nothing's impossible, but I would bet that the problem is in the HCL Notes format. The MIME multipart spec goes back to the early 1980s, and I'm sure the Python Email package implements it exactly by default. I can't say more without the exact MIME structure of a message that causes this error, preferably the whole message (header and body).
That said, it might be something that (a) can be worked around with a slightly more lenient existing email policy, or (b) that we could create a new policy that ignores the problem.
In the .eml file I see 25 header fields calles "X-Notes-Item". May be it is an overflow?
Extremely unlikely. All header fields have been successfully processed by the time a CloseBoundaryNotFoundDefect can be detected, and the copy of the field you provide in your followup email is well-formed and contains no interesting content (such as non-ASCII characters, even after decoding the MIME-words). I cannot say why removing the first instance of the field would resolve the error without seeing the whole message.
Any ideas?
Not without the full message. If you're not comfortable sending the message to the list, but do trust us enough, you can send a message that causes the error to me and/or Mark Sapiro <mark@msapiro.net>.
Regards, Steve