Re: utf8 messages
Brandon Long <[email protected]> Wed, 13 Aug 2014 01:00:32 -0700
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <CABa8R6vBqS1ewmTtHh8tTOdzobsWpvSEokRxOqpj1Oq3hA+vsw@mail.gmail.com> |
--===============4556963667732907252== Content-Type: multipart/alternative; boundary=089e01182d0aa99ff905007e2e1d --089e01182d0aa99ff905007e2e1d Content-Type: text/plain; charset=UTF-8 On Tue, Aug 12, 2014 at 7:54 AM, Ned Freed <[email protected]> wrote: > > > It is, or is supposed to be, a sealed system implemented as a set of > > > interlocking extensions to existing email facilities. > > > So, if I have an "email" message, I can no longer just parse it. > Instead, > > there are actually two > > types of email messages, and the only way to know how to parse it is to > > know a priori which type it is. > > Because all systems are "sealed" and there's never any leakage. > > Wrong on all counts, I'm afraid. First and foremost, in practice you have > never > been able to "just parse" email messages, for the simple reason that too > many > message creation agents don't follow the rules and create wildly > incompliant > messages. So there's always some heuristics involved, unless of course > you're > willing to only accept syntacticaly valid messages, in which case yes, you > can "just parse" messages, including EAI messages. > > Where the lines are drawn has always been a tradeoff, and one which has > changed over the years. It used to be the case that a lot more crap was > generally tolerated. The spam problem has led to an overall tightening up > what's tolerated. > > Second, because of overall lack of compliance, there have always been > many types of messages. > > Third, of course there's leakage. > Ok, let me try to rephrase my point. Before, there were two types of messages, well specified / syntactically correct message, and not. The not well specified messages amount to a non-trivial number, but best effort/heuristic results are fine. If we imagine handling 1B messages/day, 2% being the "not well specified", we have 20M messages handled by heuristic. If we have only 1% heuristic failures, that's 200k bad messages a day. Eh, maybe ok. Especially since in practice, these tend to be spam messages or the 8bit chars in the header are limited to some "content preview" header or other boneheadedness, or best case, its only a character or two that's broken. Adding under-specified 6532 messages to the mix means that we are now generating messages that can easily slip into the second pool. We try our best to only generate well specified / syntactically correct messages.. "be conservative in what you send" and all, but now we're being forced to take steps that we know will increase the number of failures. We're attempting to adjust our heuristics to compensate, but that seems like a poor response compared to making the messages be well specified. Now, one can add some bit outside of the message to say its 6532... and then modify everything that exchanges or stores messages to also exchange and store that bit. Passing messages to procmail? Guess we need a new env var. Maildrop programs used by smtp servers to pass messages to imap servers. Mailing list software. Mailing list archives. How you call spamassassin. The thread about this during the discussion suggested adding a new field to the From_ mbox separator. Guess a new attribute field in the maildir spec? > > The problem we're having with 6532 messages, is that we moved from > > > > explicitly identified charsets via 2047/etc mechanisms, to "its just > > > > utf8"... and sometimes we mis-detect the utf8 as cp1250 or other > > > encodings. > > > > > > No message created prior to the release of support for RFC 6532 can be > > > assumed > > > to be a RFC 6532 message. Now, if you want to vet those messages using > some > > > sort of process to insure such a message meets the syntax and at least > > > looks > > > semantically sensible, then I suppose you could set the flag in the > > > metadata. > > > > > > But if you can't distinguish such messages from legitimate RFC 6532 > > > created and > > > submitted by compliant clients, it sounds to me like you're not > retaining a > > > really critical piece of envelope/metadata in your implementation. > > > > > > Yes. And the most obvious place for that information, to me, is in the > > headers of the message. Assuming that every mechanism for exchanging > email > > messages needs an explicit external piece of data... > > Sorry, I'm not going to revisit or defend past design decisions. My point > was > and is that when you said that a piece of information was missing, that > statement was incorrect. > I'm saying that requiring the information to be external grossly increases the development required to support the standard. I already pointed out some common tools above. For us, not having to add a new piece of external metadata means that all we have to do is upgrade our parser... and validate how we use addresses and fix hopefully minor issues. If we have to use external metadata, then we have 100s of data paths and data stores that need to be upgraded. We've also already agreed that leaks happen, which means separating the metadata from the data itself guarantees that under specified data will leak. Making the message itself well specified means that re-synchronization can take place, that messages can pass through agnostic mechanisms (whether agnostic by choice or by happenstance) and be understood on the other side. You may not like or agree with how this was done. (For that matter, I never > said I liked or agreed with how it was done.) But for better or worse, > there's > now a standard in place, and absent compelling evidence of there being a > problem with implementing that standard - evidence which AFAICT you have > not > provided - it's not appropriate to propose competing mechanisms to that > standard. > I thought implementation feedback was a useful thing, and generally desired prior to something becoming a standard. I also thought that internet standards were generally considered a work in progress... 6532 is standards track but not a STD. I also wasn't proposing a competing mechanism, I was proposing that implementation experience showed, to me, a strong possibility that a clarification or change to the standard would be beneficial. Also, frankly, there is nothing in the standards that say we MUST not do this, so thanks for the exhortation from authority, I'll take it under advisement. Frankly, I don't understand this concept of refusing to revisit or defend. I tried to find and follow the discussion in the eai wg archives... and to me, the decision seemed under explored. The original section spent a lot of real estate on the importance of such an explicit in message spec, only to be removed. I found two threads about it, about equal numbers of people contributing to either side (like 1-2 on each side), a somewhat heavy handed dismissal of the need, a call for consensus that passed due mostly to non-contributors. Perhaps more took place in meetings, or there were other discussions that someone could point me to. Perhaps you can explain to me what 'compelling evidence of there being a problem implementing the standard' would mean in practice? Brandon --089e01182d0aa99ff905007e2e1d 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 Tue, Aug 12, 2014 at 7:54 AM, Ned Freed <span dir=3D"ltr"><<a= href=3D"mailto:[email protected]" target=3D"_blank" class=3D"cremed">n= [email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"">> > It is, or is supposed to be, a s= ealed system implemented as a set of<br> > > interlocking extensions to existing email facilities.<br> <br> > So, if I have an "email" message, I can no longer just parse= it.=C2=A0 Instead,<br> > there are actually two<br> > types of email messages, and the only way to know how to parse it is t= o<br> > know a priori which type it is.<br> > Because all systems are "sealed" and there's never any l= eakage.<br> <br> </div>Wrong on all counts, I'm afraid. First and foremost, in practice = you have never<br> been able to "just parse" email messages, for the simple reason t= hat too many<br> message creation agents don't follow the rules and create wildly incomp= liant<br> messages. So there's always some heuristics involved, unless of course = you're<br> willing to only accept syntacticaly valid messages, in which case yes, you<= br> can "just parse" messages, including EAI messages.<br> <br> Where the lines are drawn has always been a tradeoff, and one which has<br> changed over the years. It used to be the case that a lot more crap was<br> generally tolerated. The spam problem has led to an overall tightening up<b= r> what's tolerated.<br> <br> Second, because of overall lack of compliance, there have always been<br> many types of messages.<br> <br> Third, of course there's leakage.<br></blockquote><div><br></div><div>O= k, let me try to rephrase my point. =C2=A0Before, there were two types of m= essages, well specified / syntactically correct message, and not. =C2=A0The= not well specified messages amount to a non-trivial number, but best effor= t/heuristic results are fine.</div> <div><br></div><div>If we imagine handling 1B messages/day, 2% being the &q= uot;not well specified", we have 20M messages handled by heuristic. = =C2=A0If we have only 1% heuristic failures, that's 200k bad messages a= day. =C2=A0Eh, maybe ok. =C2=A0Especially since in practice, these tend to= be spam messages or the 8bit chars in the header are limited to some "= ;content preview" header or other boneheadedness, or best case, its on= ly a character or two that's broken.</div> <div><br></div><div>Adding under-specified 6532 messages to the mix means t= hat we are now generating messages that can easily slip into the second poo= l. =C2=A0We try our best to only generate well specified / syntactically co= rrect messages.. "be conservative in what you send" and all, but = now we're being forced to take steps that we know will increase the num= ber of failures. =C2=A0We're attempting to adjust our heuristics to com= pensate, but that seems like a poor response compared to making the message= s be well specified.</div> <div><br></div><div>Now, one can add some bit outside of the message to say= its 6532... and then modify everything that exchanges or stores messages t= o also exchange and store that bit. =C2=A0Passing messages to procmail? =C2= =A0Guess we need a new env var. =C2=A0Maildrop programs used by smtp server= s to pass messages to imap servers. =C2=A0Mailing list software. =C2=A0Mail= ing list archives. =C2=A0How you call spamassassin. =C2=A0The thread about = this during the discussion suggested adding a new field to the From_ mbox s= eparator. =C2=A0Guess a new attribute field in the maildir spec?</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"><div class=3D""> > > The problem we're having with 6532 messages, is that we moved= from<br> > > > explicitly identified charsets via 2047/etc mechanisms, to &= quot;its just<br> > > > utf8"... and sometimes we mis-detect the utf8 as cp1250= or other<br> > > encodings.<br> > ><br> > > No message created prior to the release of support for RFC 6532 c= an be<br> > > assumed<br> > > to be a RFC 6532 message. Now, if you want to vet those messages = using some<br> > > sort of process to insure such a message meets the syntax and at = least<br> > > looks<br> > > semantically sensible, then I suppose you could set the flag in t= he<br> > > metadata.<br> > ><br> > > But if you can't distinguish such messages from legitimate RF= C 6532<br> > > created and<br> > > submitted by compliant clients, it sounds to me like you're n= ot retaining a<br> > > really critical piece of envelope/metadata in your implementation= .<br> > ><br> <br> > Yes.=C2=A0 And the most obvious place for that information, to me, is = in the<br> > headers of the message.=C2=A0 Assuming that every mechanism for exchan= ging email<br> > messages needs an explicit external piece of data...<br> <br> </div>Sorry, I'm not going to revisit or defend past design decisions. = My point was<br> and is that when you said that a piece of information was missing, that<br> statement was incorrect.<br></blockquote><div><br></div><div>I'm saying= that requiring the information to be external grossly increases the develo= pment required to support the standard. =C2=A0I already pointed out some co= mmon tools above. =C2=A0For us, not having to add a new piece of external m= etadata means that all we have to do is upgrade our parser... and validate = how we use addresses and fix hopefully minor issues. =C2=A0If we have to us= e external metadata, then we have 100s of data paths and data stores that n= eed to be upgraded.</div> <div><br></div><div>We've also already agreed that leaks happen, which = means separating the metadata from the data itself guarantees that under sp= ecified data will leak. =C2=A0Making the message itself well specified mean= s that re-synchronization can take place, that messages can pass through ag= nostic mechanisms (whether agnostic by choice or by happenstance) and be un= derstood on the other side.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> You may not like or agree with how this was done. (For that matter, I never= <br> said I liked or agreed with how it was done.) But for better or worse, ther= e's<br> now a standard in place, and absent compelling evidence of there being a<br= > problem with implementing that standard - evidence which AFAICT you have no= t<br> provided - it's not appropriate to propose competing mechanisms to that= <br> standard.<br></blockquote><div><br></div><div>I thought implementation feed= back was a useful thing, and generally desired prior to something becoming = a standard. =C2=A0I also thought that internet standards were generally con= sidered a work in progress... 6532 is standards track but not a STD.</div> <div><br></div><div>I also wasn't proposing a competing mechanism, I wa= s proposing that implementation experience showed, to me, a strong possibil= ity that a clarification or change to the standard would be beneficial. =C2= =A0Also, frankly, there is nothing in the standards that say we MUST not do= this, so thanks for the exhortation from authority, I'll take it under= advisement.</div> <div><br></div><div>Frankly, I don't understand this concept of refusin= g to revisit or defend. =C2=A0I tried to find and follow the discussion in = the eai wg archives... and to me, the decision seemed under explored. =C2= =A0The original section spent a lot of real estate on the importance of suc= h an explicit in message spec, only to be removed. =C2=A0I found two thread= s about it, about equal numbers of people contributing to either side (like= 1-2 on each side), a somewhat heavy handed dismissal of the need, a call f= or consensus that passed due mostly to non-contributors. =C2=A0Perhaps more= took place in meetings, or there were other discussions that someone could= point me to.</div> <div><br></div><div>Perhaps you can explain to me what 'compelling evid= ence of there being a problem implementing the standard' would mean in = practice?</div><div><br></div><div>Brandon</div><div><br></div></div></div> </div> --089e01182d0aa99ff905007e2e1d-- --===============4556963667732907252== 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 --===============4556963667732907252==--