Re: Most common mail header fields seen with nonsyntactic values
Peter Occil <[email protected]> Tue, 24 Jul 2018 23:17:08 -0400
| Newsgroups | gmane.ietf.rfc822,gmane.ietf.dmarc |
|---|---|
| Message-ID | <[email protected]> |
--===============5621126742248027206== Content-Type: multipart/alternative; boundary="_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_" --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Adding additional mailing lists because three header fields listed below (R= eceived-SPF, Authentication-Results, Arc-Authentication-Results) are within= their scope. --Peter From: Peter Occil Sent: Monday, July 23, 2018 11:28 PM To: [email protected] Subject: Most common mail header fields seen with nonsyntactic values The following is a list of email header fields where I find a significant p= roportion of those fields in practice using a different form from the docum= ented syntax of those fields. This list is, for the moment, for your information only.=C2=A0 Whether the = documents defining the header fields listed below should be updated (whethe= r to accommodate how those fields are used in practice or otherwise), or wh= at error handling a program should use if it encounters any of these header= fields, are matters that require further discussion.=C2=A0 (In one case, t= he note in RFC 5322 provides guidance on error handling, but in many other = cases, those documents don't seem to suggest or require any particular erro= r-handling behavior.) ARC-Authentication-Results. Some nonsyntactic values of this header field contain a "header.b" paramete= r value containing a slash, which cannot occur in a "pvalue". Authentication-Results. Many nonconforming Authentication-Results values are of an unusual form tha= t I've already reported elsewhere, in the "dmarc" mailing list.=C2=A0 Unlik= e most of the other forms I report here, this one may be truly nonconformin= g. Other nonsyntactic Authentication-Results values-- - don't mention the domain name of the authentication server (they generall= y have a comment like "(sender IP is ...)"), - contain a "header.b" parameter value containing a slash, which cannot occ= ur in a "pvalue", - contain an "x-tls.subject" parameter right after the authserv name (which= only one specific implementation apparently generates), and/or - contain "d=3D<pvalue>" or "reason=3D<pvalue>" after the form "<method>=3D= <result> (comment)", which doesn't conform to the documented syntax. Content-ID. Of the Content-ID header fields I've seen in practice, a significant propor= tion of them (almost half) do not follow the syntax of "msg-id", even thoug= h they contain angle-brackets.=C2=A0 Some examples use UUIDs inside angle-b= rackets rather than "msg-id"s with an at-sign, while other examples, such a= s "<example.jpg>" and "<down_arrow>", were obviously generated to be messag= e-unique rather than "world-unique" as required by RFC 2045 sec. 7.=C2=A0 (= On the other hand, I see very few instances of Message-ID header fields not= following the syntax of that header field.)=C2=A0 A smaller number of fiel= ds do not use angle-brackets at all, and some of them include the values "h= tml-body" and "text-body". List-Archive. All of the nonsyntactic List-Archive values I've seen so far involve GitHub= URLs.=C2=A0 Here the URL appears without angle brackets. List-ID. Some List-ID values either include no dots or domain names, or they are num= bers or underscore-separated number sequences with no angle-brackets. List-Unsubscribe. Many nonsyntactic List-Unsubscribe values involve either URLs not appearing= in angle brackets, or URLs encoded with RFC 2047 encoded words (compare wi= th Content-Location, which does allow the latter). Received. Many nonsyntactic Received bodies-- - include fractional seconds in the date and time, - include unquoted IPv6 addresses (which contain colons and don't conform t= o the "received-token" syntax),=20 - have no semicolon before the date/time, and/or - include a "for" clause containing "<multiple recipients>" (without the qu= otation marks). In one case, I have noticed a Received header field with an ASCII control c= haracter (U+0001, I think) in the "by" clause; unfortunately such a field i= s not downgradable under RFC 6857, nor can it appear in a generated header = field under RFC 5322. Received-SPF. Many nonsyntactic Received-SPF bodies include an unquoted IPv6 in the "clie= nt-ip" parameter (which conform to neither "dot-atom" nor "quoted-string" b= ecause of the colons), and some include an unquoted email address in the "e= nvelope-from" parameter. Return-Path. Many Return-Path header-field values don't include angle brackets (and appe= ar as "addr-spec", rather than "path" as required by RFC 5322.)=C2=A0 A ver= y small number also include a display name (and appear as "mailbox" under t= hat RFC). ------- For other standard header fields, nonconforming values occur very rarely if= at all (in my experience). --Peter --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} ..MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style></head><body lang=3DEN-US link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>Adding additional mailing lists beca= use three header fields listed below (Received-SPF, Authentication-Results,= Arc-Authentication-Results) are within their scope.</p><p class=3DMsoNorma= l><o:p> </o:p></p><p class=3DMsoNormal>--Peter</p><p class=3DMsoNormal= ><o:p> </o:p></p><div style=3D'mso-element:para-border-div;border:none= ;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNo= rmal style=3D'border:none;padding:0in'><b>From: </b><a href=3D"mailto:pocci= [email protected]">Peter Occil</a><br><b>Sent: </b>Monday, July 23, 2018 11:28 = PM<br><b>To: </b><a href=3D"mailto:[email protected]">[email protected]</a>= <br><b>Subject: </b>Most common mail header fields seen with nonsyntactic v= alues</p></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorm= al>The following is a list of email header fields where I find a significan= t proportion of those fields in practice using a different form from the do= cumented syntax of those fields.<o:p></o:p></p><p class=3DMsoNormal><o:p>&n= bsp;</o:p></p><p class=3DMsoNormal>This list is, for the moment, for your i= nformation only. Whether the documents defining the header fields lis= ted below should be updated (whether to accommodate how those fields are us= ed in practice or otherwise), or what error handling a program should use i= f it encounters any of these header fields, are matters that require furthe= r discussion. (In one case, the note in RFC 5322 provides guidance on= error handling, but in many other cases, those documents don't seem to sug= gest or require any particular error-handling behavior.)<o:p></o:p></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>ARC-Authenticati= on-Results.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p clas= s=3DMsoNormal>Some nonsyntactic values of this header field contain a "= ;header.b" parameter value containing a slash, which cannot occur in a= "pvalue".<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></= p><p class=3DMsoNormal>Authentication-Results.<o:p></o:p></p><p class=3DMso= Normal><o:p> </o:p></p><p class=3DMsoNormal>Many nonconforming Authent= ication-Results values are of an unusual form that I've already reported el= sewhere, in the "dmarc" mailing list. Unlike most of the ot= her forms I report here, this one may be truly nonconforming.<o:p></o:p></p= ><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Other nonsy= ntactic Authentication-Results values--<o:p></o:p></p><p class=3DMsoNormal>= <o:p> </o:p></p><p class=3DMsoNormal>- don't mention the domain name o= f the authentication server (they generally have a comment like "(send= er IP is ...)"),<o:p></o:p></p><p class=3DMsoNormal>- contain a "= header.b" parameter value containing a slash, which cannot occur in a = "pvalue",<o:p></o:p></p><p class=3DMsoNormal>- contain an "x= -tls.subject" parameter right after the authserv name (which only one = specific implementation apparently generates), and/or<o:p></o:p></p><p clas= s=3DMsoNormal>- contain "d=3D<pvalue>" or "reason=3D&l= t;pvalue>" after the form "<method>=3D<result> (co= mment)", which doesn't conform to the documented syntax.<o:p></o:p></p= ><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> = </o:p></p><p class=3DMsoNormal>Content-ID.<o:p></o:p></p><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoNormal>Of the Content-ID header field= s I've seen in practice, a significant proportion of them (almost half) do = not follow the syntax of "msg-id", even though they contain angle= -brackets. Some examples use UUIDs inside angle-brackets rather than = "msg-id"s with an at-sign, while other examples, such as "&l= t;example.jpg>" and "<down_arrow>", were obviously = generated to be message-unique rather than "world-unique" as requ= ired by RFC 2045 sec. 7. (On the other hand, I see very few instances= of Message-ID header fields not following the syntax of that header field.= ) A smaller number of fields do not use angle-brackets at all, and so= me of them include the values "html-body" and "text-body&quo= t;.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoN= ormal>List-Archive.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p= ><p class=3DMsoNormal>All of the nonsyntactic List-Archive values I've seen= so far involve GitHub URLs. Here the URL appears without angle brack= ets.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso= Normal>List-ID.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>Some List-ID values either include no dots or domain name= s, or they are numbers or underscore-separated number sequences with no ang= le-brackets.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cla= ss=3DMsoNormal>List-Unsubscribe.<o:p></o:p></p><p class=3DMsoNormal><o:p>&n= bsp;</o:p></p><p class=3DMsoNormal>Many nonsyntactic List-Unsubscribe value= s involve either URLs not appearing in angle brackets, or URLs encoded with= RFC 2047 encoded words (compare with Content-Location, which does allow th= e latter).<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>Received.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p>= </p><p class=3DMsoNormal>Many nonsyntactic Received bodies--<o:p></o:p></p>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>- include fr= actional seconds in the date and time,<o:p></o:p></p><p class=3DMsoNormal>-= include unquoted IPv6 addresses (which contain colons and don't conform to= the "received-token" syntax), <o:p></o:p></p><p class=3DMsoNorma= l>- have no semicolon before the date/time, and/or<o:p></o:p></p><p class= =3DMsoNormal>- include a "for" clause containing "<multip= le recipients>" (without the quotation marks).<o:p></o:p></p><p cla= ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>In one case, I hav= e noticed a Received header field with an ASCII control character (U+0001, = I think) in the "by" clause; unfortunately such a field is not do= wngradable under RFC 6857, nor can it appear in a generated header field un= der RFC 5322.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cl= ass=3DMsoNormal>Received-SPF.<o:p></o:p></p><p class=3DMsoNormal><o:p> = ;</o:p></p><p class=3DMsoNormal>Many nonsyntactic Received-SPF bodies inclu= de an unquoted IPv6 in the "client-ip" parameter (which conform t= o neither "dot-atom" nor "quoted-string" because of the= colons), and some include an unquoted email address in the "envelope-= from" parameter.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p><= /p><p class=3DMsoNormal>Return-Path.<o:p></o:p></p><p class=3DMsoNormal><o:= p> </o:p></p><p class=3DMsoNormal>Many Return-Path header-field values= don't include angle brackets (and appear as "addr-spec", rather = than "path" as required by RFC 5322.) A very small number a= lso include a display name (and appear as "mailbox" under that RF= C).<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoN= ormal>-------<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cl= ass=3DMsoNormal>For other standard header fields, nonconforming values occu= r very rarely if at all (in my experience).<o:p></o:p></p><p class=3DMsoNor= mal><o:p> </o:p></p><p class=3DMsoNormal>--Peter<o:p></o:p></p><p clas= s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p></= p></div></body></html>= --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_-- --===============5621126742248027206== 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 --===============5621126742248027206==--