From 1582819 at bugs.launchpad.net Fri Jun 10 18:01:39 2016 From: 1582819 at bugs.launchpad.net (=?utf-8?b?SGFya2EgR3nFkXrFkQ==?=) Date: Fri, 10 Jun 2016 22:01:39 -0000 Subject: [Bug 1582819] Re: subject encoding bug References: <20160517171308.21663.96093.malonedeb@wampee.canonical.com> <20160519164446.303.13485.malone@chaenomeles.canonical.com> Message-ID: <20160610215554.M26645@gamma.ttk.pte.hu> > and you presumably want 'adatb?zis', not 'adatb?zi s'. There are always > whitespace issues when mixing encoded words and plain text in one > header. The proper encoding of that header is > > Subject: PIVOT kutat?sfinansz?roz?si adatb?zis > > Granted, various MUAs are more forgiving of the defects, but the Mailman > issue is really in the underlying Python email package which insists > that the terminating ?= be followed by white space in order that the > encoded word be recognized as such. > Just to be clear, if I have a Q encoded word as in rfc2047, and there is a \n and space after it, mailman puts an extra space in place. The only solution is if I encode all "words" even if that is not needed. rfc2047 allow to have encoded words mixed with non encoded texts. "Ordinary ASCII text and 'encoded-word's may appear together in the same header field. However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'" So this is a BUG in the underlying python package. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1582819 Title: subject encoding bug To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1582819/+subscriptions From mark at msapiro.net Fri Jun 10 19:48:57 2016 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 10 Jun 2016 23:48:57 -0000 Subject: [Bug 1582819] Re: subject encoding bug References: <20160517171308.21663.96093.malonedeb@wampee.canonical.com> Message-ID: <20160610234857.31112.86673.malone@soybean.canonical.com> There is and probably always will be discrepancies in the way MUAs handle header folding/unfolding and RFC2047 decoding. There is a possible ambiguity in the part of RFC2047 you quote. 'linear-white- space' is any number of white space characters, so if part of the header is an encoded word followed by some white space followed by ordinary ASCII text, how much of the white space is the separating linear-white- space and how much is leading white space in the text field? Thus the only unambiguous way to represent this is to never begin a text field with white space. This is further complicated by header folding and unfolding. RFC5322 sec 2.2.3 is clear on how headers should be folded and unfolded. Folding is done per "The general rule is that wherever this specification allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP." and unfolding per "Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP." This is clear, but contradicts the original RFC822 sec 3.1 which says "The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP- char may instead be inserted." and "Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char." This effectively says that when folding you can insert multiple whitespace characters, but when unfolding, you don't remove any. Thus the standards have been buggy and even the best intentioned MUAs have to guess about what to do. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1582819 Title: subject encoding bug To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1582819/+subscriptions From futatuki at poem.co.jp Sat Jun 18 05:01:28 2016 From: futatuki at poem.co.jp (Yasuhito FUTATSUKI at POEM) Date: Sat, 18 Jun 2016 09:01:28 -0000 Subject: [Merge] lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1 Message-ID: <20160618090123.14348.83055.launchpad@ackee.canonical.com> Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/297825 Updationg old Japanese translation of documents, placed under messages/ja sub directory. I called for review at Mailman-i18n list one month ago, but sadly there is no response, no feedback at all. However I believe it is not worse than to remain to be out of date. -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 191078 bytes Desc: not available URL: