https://bugs.kde.org/show_bug.cgi?id=360205
--- Comment #11 from Pali Rohár <pali.ro...@gmail.com> --- On Monday 07 March 2016 15:05:24 Erik Quaeghebeur via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360205 > > --- Comment #10 from Erik Quaeghebeur <kdeb...@equaeghe.nospammail.net> --- > (In reply to Jan Kundrát from comment #8) > > > More generally, as far as I've understood (and modulo folding), > > > a header value MUST NOT contain any line breaks. > > > > There is RFC2047 which specifies how to send Unicode. It gets triggered by > > presence of LFs in my testing, and I think that this usage is actually > > kosher -- but i'll be happy to be proven wrong by a quite from some other > > RFC. > > The token definition in RFC822 that allowed bare CR and bare LF was updated in > RFC2822 to preclude them: > > RFC2047 Section 5. (1) on p.7: > « An ’encoded-word’ may replace a ’text’ token (as defined by RFC 822) in any > Subject or Comments header field [...] » So it means that UTF-8 encoded unicode character "newline" in MIME Base64 is valid content for Subject header. Right? > RFC822 Section 3.3 on p.10: > « text = <any CHAR, including bare CR & bare LF, but NOT including CRLF> » Ah, so old RFC 822 allows directly "\n" in Subject. I did not know that. > RFC2822 Section 3.2.1 on p.10: > « text = %d1-9 / %d11 / %d12 / %d14-127 / obs-text ; Characters excluding > CR and LF » > > (RFC5322 doesn't reintroduce them.) > > So digesting them is needed for dealing with old messages, but producing them > is, in my understanding, against the latest RFC. Right, my original question about newlines was because I wanted to know if compliant email client needs to deal with such thing. So answer is yes, "\n" in Subject is valid character. -- You are receiving this mail because: You are watching all bug changes.
