Re: utf8 messages
Brandon Long <[email protected]> Fri, 15 Aug 2014 12:44:58 -0700
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <CABa8R6vB=HqU42w1nkyY0zouVupradeMaf+7tu4F-1eSmFmfQA@mail.gmail.com> |
--===============6481398315956489909== Content-Type: multipart/alternative; boundary=001a11c1ec9a9ec0850500b041f4 --001a11c1ec9a9ec0850500b041f4 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 14, 2014 at 6:42 PM, Ned Freed <[email protected]> wrote: > > On Wed, Aug 13, 2014 at 6:34 PM, Ned Freed <[email protected]> > wrote: > > > > > Let me try one more time, since something isn't making it through. > > > > > > > I have three messages. One message has an entirely 7bit header with > 2047 > > > > encoded subject. Another message is a 6532 message, with the > subject in > > > > utf8. A third message is has a cp-1250 8bit subject. There are two > 8bit > > > > bytes in the subject in both of the last two messages, and in the > cp1250 > > > > case, those two bytes happen to also be a valid utf8 character. > > > > > > > We want to be able to parse all three of those and do so correctly. > We > > > > know the third type is technically invalid, but we see millions of > such > > > > messages every day, dropping all of those would be a dis-service to > our > > > > users. We currently see way more of such messages than we do of 6532 > > > > messages... though in practice, the most common charset now is > utf-8, so > > > I > > > > guess those are now the same as 6532 messages that have leaked. > > > > > > I thought I understood the problem you were attempting to solve, but > now > > > I'm > > > totally confused, because this seems to hqve nothing to do with > additional > > > labeling of legitimate EAI messages at all. > > > > > > My point is that without a label, I can't tell the difference between the > > 6532 messages and the illegitimate messages, given just the message. > > Yes, that's exactly what I thought. But given that, surely it makes more > sense > to label the illegimate messages as such, especially since you're going to > want > to set the EAI message bit for some of them, making it essentally an > orthogonal > setting? > > Did you even bother to read the rest of my response? > Yes, but I didn't understand it until this response. It is an interesting alternative. You still seem to be assuming an external eai bit, but even without that, yes, theoretically we could mark any non legitimate message at smtp-in time. It would be harder to do at imap APPEND time, though, since I believe clients assume the messages as uploaded are stored as is.. I'd have to test to see if that was a failure. Potentially, I would have to be careful with any source of messages to make sure .. and that means we may need to upgrade our other api's and migration tools to have a bit for eai. Brandon --001a11c1ec9a9ec0850500b041f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">On Thu, Aug 14, 2014 at 6:42 PM, Ned Freed <span dir=3D"ltr"><<a= href=3D"mailto:[email protected]" target=3D"_blank">ned.freed@mrochek.= com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">>= On Wed, Aug 13, 2014 at 6:34 PM, Ned Freed <<a href=3D"mailto:ned.freed= @mrochek.com">[email protected]</a>> wrote:<br> <br> > > > Let me try one more time, since something isn't making i= t through.<br> > ><br> > > > I have three messages.=C2=A0 One message has an entirely 7bi= t header with 2047<br> > > > encoded subject.=C2=A0 Another message is a 6532 message, wi= th the subject in<br> > > > utf8.=C2=A0 A third message is has a cp-1250 8bit subject.= =C2=A0 There are two 8bit<br> > > > bytes in the subject in both of the last two messages, and i= n the cp1250<br> > > > case, those two bytes happen to also be a valid utf8 charact= er.<br> > ><br> > > > We want to be able to parse all three of those and do so cor= rectly.=C2=A0 We<br> > > > know the third type is technically invalid, but we see milli= ons of such<br> > > > messages every day, dropping all of those would be a dis-ser= vice to our<br> > > > users.=C2=A0 We currently see way more of such messages than= we do of 6532<br> > > > messages... though in practice, the most common charset now = is utf-8, so<br> > > I<br> > > > guess those are now the same as 6532 messages that have leak= ed.<br> > ><br> > > I thought I understood the problem you were attempting to solve, = but now<br> > > I'm<br> > > totally confused, because this seems to hqve nothing to do with a= dditional<br> > > labeling of legitimate EAI messages at all.<br> > ><br> <br> > My point is that without a label, I can't tell the difference betw= een the<br> > 6532 messages and the illegitimate messages, given just the message.<b= r> <br> </div></div>Yes, that's exactly what I thought. But given that, surely = it makes more sense<br> to label the illegimate messages as such, especially since you're going= to want<br> to set the EAI message bit for some of them, making it essentally an orthog= onal<br> setting?<br> <br> Did you even bother to read the rest of my response?<br></blockquote><div><= br></div><div>Yes, but I didn't understand it until this response. =C2= =A0It is an interesting alternative. =C2=A0You still seem to be assuming an= external eai bit, but even without that, yes, theoretically we could mark = any non legitimate message at smtp-in time. =C2=A0It would be harder to do = at imap APPEND time, though, since I believe clients assume the messages as= uploaded are stored as is.. I'd have to test to see if that was a fail= ure. =C2=A0Potentially, I would have to be careful with any source of messa= ges to make sure .. and that means we may need to upgrade our other api'= ;s and migration tools to have a bit for eai.</div> <div><br></div><div>Brandon</div><div><br></div><div>=C2=A0</div></div></di= v></div> --001a11c1ec9a9ec0850500b041f4-- --===============6481398315956489909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-822 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-822 --===============6481398315956489909==--