Most common mail header fields seen with nonsyntactic values
Peter Occil <[email protected]> Mon, 23 Jul 2018 23:28:51 -0400
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
--===============2454379250852920576==
Content-Type: multipart/alternative;
boundary="_528B80D6-0EA6-48B4-B5C7-BE6C17B73512_"
--_528B80D6-0EA6-48B4-B5C7-BE6C17B73512_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
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. Whether the docum=
ents defining the header fields listed below should be updated (whether to =
accommodate how those fields are used in practice or otherwise), or what er=
ror handling a program should use if it encounters any of these header fiel=
ds, are matters that require further discussion. (In one case, the note in=
RFC 5322 provides guidance on error handling, but in many other cases, tho=
se documents don't seem to suggest or require any particular error-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. Unlike mos=
t of the other forms I report here, this one may be truly nonconforming.
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. Some examples use UUIDs inside angle-bracke=
ts rather than "msg-id"s with an at-sign, while other examples, such as "<e=
xample.jpg>" and "<down_arrow>", were obviously generated to be message-uni=
que rather than "world-unique" as required by RFC 2045 sec. 7. (On the oth=
er 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 a=
ngle-brackets at all, and some of them include the values "html-body" and "=
text-body".
List-Archive.
All of the nonsyntactic List-Archive values I've seen so far involve GitHub=
URLs. 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.) A very sma=
ll number also include a display name (and appear as "mailbox" under that R=
FC).
-------
For other standard header fields, nonconforming values occur very rarely if=
at all (in my experience).
--Peter
--_528B80D6-0EA6-48B4-B5C7-BE6C17B73512_
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>The following is a list of email hea=
der fields where I find a significant proportion of those fields in practic=
e using a different form from the documented syntax of those fields.</p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>This list is, f=
or the moment, for your information only.=C2=A0 Whether the documents defin=
ing the header fields listed below should be updated (whether to accommodat=
e how those fields are used in practice or otherwise), or what error handli=
ng a program should use if it encounters any of these header fields, are ma=
tters that require further discussion.=C2=A0 (In one case, the note in RFC =
5322 provides guidance on error handling, but in many other cases, those do=
cuments don't seem to suggest or require any particular error-handling beha=
vior.)</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>AR=
C-Authentication-Results.</p><p class=3DMsoNormal><o:p> </o:p></p><p c=
lass=3DMsoNormal>Some nonsyntactic values of this header field contain a &q=
uot;header.b" parameter value containing a slash, which cannot occur i=
n a "pvalue".</p><p class=3DMsoNormal><o:p> </o:p></p><p cla=
ss=3DMsoNormal>Authentication-Results.</p><p class=3DMsoNormal><o:p> <=
/o:p></p><p class=3DMsoNormal>Many nonconforming Authentication-Results val=
ues are of an unusual form that I've already reported elsewhere, in the &qu=
ot;dmarc" mailing list.=C2=A0 Unlike most of the other forms I report =
here, this one may be truly nonconforming.</p><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p><p class=3DMsoNormal>Other nonsyntactic Authentication-Results=
values--</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal=
>- don't mention the domain name of the authentication server (they general=
ly have a comment like "(sender IP is ...)"),</p><p class=3DMsoNo=
rmal>- contain a "header.b" parameter value containing a slash, w=
hich cannot occur in a "pvalue",</p><p class=3DMsoNormal>- contai=
n an "x-tls.subject" parameter right after the authserv name (whi=
ch only one specific implementation apparently generates), and/or</p><p cla=
ss=3DMsoNormal>- contain "d=3D<pvalue>" or "reason=3D&=
lt;pvalue>" after the form "<method>=3D<result> (c=
omment)", which doesn't conform to the documented syntax.</p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p></p=
><p class=3DMsoNormal>Content-ID.</p><p class=3DMsoNormal><o:p> </o:p>=
</p><p class=3DMsoNormal>Of the Content-ID header fields I've seen in pract=
ice, a significant proportion of them (almost half) do not follow the synta=
x of "msg-id", even though they contain angle-brackets.=C2=A0 Som=
e examples use UUIDs inside angle-brackets rather than "msg-id"s =
with an at-sign, while other examples, such as "<example.jpg>&qu=
ot; and "<down_arrow>", were obviously generated to be mess=
age-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 heade=
r fields not following the syntax of that header field.)=C2=A0 A smaller nu=
mber of fields do not use angle-brackets at all, and some of them include t=
he values "html-body" and "text-body".</p><p class=3DMs=
oNormal><o:p> </o:p></p><p class=3DMsoNormal>List-Archive.</p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>All of the nonsyntac=
tic List-Archive values I've seen so far involve GitHub URLs.=C2=A0 Here th=
e URL appears without angle brackets.</p><p class=3DMsoNormal><o:p> </=
o:p></p><p class=3DMsoNormal>List-ID.</p><p class=3DMsoNormal><o:p> </=
o:p></p><p class=3DMsoNormal>Some List-ID values either include no dots or =
domain names, or they are numbers or underscore-separated number sequences =
with no angle-brackets.</p><p class=3DMsoNormal><o:p> </o:p></p><p cla=
ss=3DMsoNormal>List-Unsubscribe.</p><p class=3DMsoNormal><o:p> </o:p><=
/p><p class=3DMsoNormal>Many nonsyntactic List-Unsubscribe values involve e=
ither URLs not appearing in angle brackets, or URLs encoded with RFC 2047 e=
ncoded words (compare with Content-Location, which does allow the latter).<=
/p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Received.=
</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Many non=
syntactic Received bodies--</p><p class=3DMsoNormal><o:p> </o:p></p><p=
class=3DMsoNormal>- include fractional seconds in the date and time,</p><p=
class=3DMsoNormal>- include unquoted IPv6 addresses (which contain colons =
and don't conform to the "received-token" syntax), </p><p class=
=3DMsoNormal>- have no semicolon before the date/time, and/or</p><p class=
=3DMsoNormal>- include a "for" clause containing "<multip=
le recipients>" (without the quotation marks).</p><p class=3DMsoNor=
mal><o:p> </o:p></p><p class=3DMsoNormal>In one case, I have noticed a=
Received header field with an ASCII control character (U+0001, I think) in=
the "by" clause; unfortunately such a field is not downgradable =
under RFC 6857, nor can it appear in a generated header field under RFC 532=
2.</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Receiv=
ed-SPF.</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>M=
any nonsyntactic Received-SPF bodies include an unquoted IPv6 in the "=
client-ip" parameter (which conform to neither "dot-atom" no=
r "quoted-string" because of the colons), and some include an unq=
uoted email address in the "envelope-from" parameter.</p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Return-Path.</p><p c=
lass=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.)=C2=A0 A=
very small number also include a display name (and appear as "mailbox=
" under that RFC).</p><p class=3DMsoNormal><o:p> </o:p></p><p cla=
ss=3DMsoNormal>-------</p><p class=3DMsoNormal><o:p> </o:p></p><p clas=
s=3DMsoNormal>For other standard header fields, nonconforming values occur =
very rarely if at all (in my experience).</p><p class=3DMsoNormal><o:p>&nbs=
p;</o:p></p><p class=3DMsoNormal>--Peter</p><p class=3DMsoNormal><o:p> =
;</o:p></p></div></body></html>=
--_528B80D6-0EA6-48B4-B5C7-BE6C17B73512_--
--===============2454379250852920576==
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
--===============2454379250852920576==--