Hello. Recently I found that some mail have very interesting signature in gentoo-user-ru mailing list. Signature is looking like this: �│ИМ╒▀╛z╨Н│ИМ╒┼+┌f╒√)Ю√+- Firstly I though that users enjoy such signature but when more such mails come from different users I found that this is bug in our mailing lists. Take a look at mail source: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Received: (qmail 16991 invoked by uid 1000); 2 Apr 2007 19:04:26 +0400 Subject: [gentoo-user-ru] WM5 From: "=?koi8-r?Q?=E7=CC=D5=D3=CB=C5=D2_?= =?koi8-r?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2_?= =?koi8-r?Q?=E9=C7=CF=D2=C5=D7=C9=DE?=" <rsc@rsc.pp.ru> To: gentoo-user-ru@lists.gentoo.org In-Reply-To: <20070402110554.GA28175@oei2.npp> References: <20070402110554.GA28175@oei2.npp> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Date: Mon, 02 Apr 2007 19:04:25 +0400 Message-Id: <1175526265.13808.75.camel@localhost> 4SDL1M8tzsnC1cTYINPJzsjSz87J2snS1cXUIMvPztTBy9TZL8vBzMXOxMHS2CDTIFdpbmRvd3Mg TW9iaWxlIDUuMA0K1dPU0s/K09TXz80/DQo= -- gentoo-user-ru@gentoo.org mailing list ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I've reduced the number of headers but you see that the problem is in signature which mailing list adds: -- gentoo-user-ru@gentoo.org mailing list All mail clients decode this list signature from base64 encoding and add such "beautiful" signature at the end of letter. TIA
Created attachment 115401 [details] Example of buggy message
Created attachment 115405 [details] Screenshot of buggy message in gmail
Created attachment 115406 [details] Screenshot of buggy message in gmail
Severity changed on critical as this behavior does not allow our users which use gmail reader to see messages at all! See screenshot in comment #3!
I've passed this on to the upstream mlmmj folk, hopefully have a fix soon.
(In reply to comment #5) > I've passed this on to the upstream mlmmj folk, hopefully have a fix soon. Robbin, but is it possible temporary disable signature addition for gentoo-user-ru until it's not fixed upstream? This bug makes mailing list less usable for some of our users and all others receive mails from surprised users and following unnecessary discussions... In any way, thank you very much for looking at this.
yeah, I disabled the footer for the moment. still pending on upstream for a real fix - I don't want to have to pass mails through procmail/formail :-(
Could we disable footer for gentoo-doc-ru? TIA
disabled on gentoo-doc-ru
Robin, do you have any answer from upstream? If not, what version of mlmmj do we have installed? How this footer is defined in configs? I'm going to subscribe tomlmmj mailing list and ask for help there... May be a bit activity here helps.
No response from them. We're on 1.2.14 now, will be moving to 1.2.15 with the new lists server (couple of config niceties added). The disabled footer was: [footer] -- gentoo-doc-ru@gentoo.org mailing list [/footer] The core of the problem is that it doesn't think about MIME encodings properly when dealing with adding the footer. The best fix would be, if the body has a non-plaintext type, add the footer in another MIME block, rather than trying to add it to the existing block.
And now we have the answer. It'll be never fixed. See URL.
seems like there's nothing more for us to do here.
Mike, it's not possible to resolve this bug as UPSTREAM as this bug is about our broken mailing lists (our infrastructure) and not about mailing list software. This bug make us look unprofessional as some mails do not have footer some do have, some have strange symbols at the end and some in some cases are unreadable. I suggest to disable this footer at all. In any case most of mails do not have this footer visible now (see archives.gentoo.org). If we really do need this footer, then we should fix this bug somehow, either fixing mlmmj or may be using different software.
We cannot handle adding MIME signatures without parsing MIME content, because we might have to use the provided boundary. But even considering the three cases (mime with no boundary, mime multipart, no mime) should not be impossible to do. There are two possible solutions for this bug: Patch mlmmj ourselves, change list software. Infra, what do you think about either?
rbu: two more options: 3. Disable footer everywhere 4. Get rid of base64 encoding on the input path to mlmmj. Somebody writing a patch for mlmmj is my preference, followed by disabling the footer, but a reliable procmail/foo rule for the conversion wouldn't go wrong either. It would have to go on stdin, and be absolutely reliable in the face of any badly encoding base64/mime structures.
*** Bug 230929 has been marked as a duplicate of this bug. ***
Upstream claims fixed a while ago.
