Re: Question regarding RFC 2369
Alexey Melnikov <[email protected]> Sat, 21 Jul 2018 15:32:13 +0100
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <1532183533.1694870.1448275552.60F55C41@webmail.messagingengine.com> |
This is a multi-part message in MIME format. --===============7962862987810802676== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153218353316948702" This is a multi-part message in MIME format. --_----------=_153218353316948702 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Peter, I deleted [email protected] from the reply, as they are not directly responsible for maintenance of RFC that you are quoting. I think ietf- [email protected] is a better mailing list for this discussion (See <https://www.ietf.org/mailman/listinfo/ietf-822> to subscribe)[email protected] might also be of interest, as SMTP behaviour is discussed there. On Thu, Jul 19, 2018, at 12:24 PM, Peter Occil wrote: > RFC 2369 sec. 2 currently says: > > MTAs MUST NOT insert whitespace within the brackets [contained > in list header fields], but client applications should treat any> whitespace, that might be inserted by poorly behaved MTAs, > as characters to ignore. > > To the extent the first clause applies to software generating messages > that might contain list header fields, usually for the purpose of > first sending them, this makes it harder for software to encode > message header fields in a generic manner rather than having to deal > with special cases like the list header fields, since, among other > things, such software may seek to comply with line length limitations > in RFC 5322 by folding long lines in accordance with that RFC.> > If the cited clause does apply to such software, a suggested change to > that statement in a future revision of that RFC might be that > whitespace "SHOULD NOT" be inserted between the brackets, but that > software generating (as opposed to retransmitting) messages containing > list header fields might choose to do so due to line length > limitations in Internet messages or because of the need or desire to > handle messages generically regardless of what header fields it has. > (But I note that this change should not encourage MTAs to disobey SMTP > or other transport protocols they may implement.)> > --Peter --_----------=_153218353316948702 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <!DOCTYPE html> <html> <head> <title></title> <style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style> </head> <body><div>Hi Peter,<br></div> <div>I deleted <a href=3D"mailto:[email protected]">[email protected]</a> from= the reply, as they are not directly responsible for maintenance of RFC tha= t you are quoting. I think <a href=3D"mailto:[email protected]">ietf-822@ie= tf.org</a> is a better mailing list for this discussion (See <<a hr= ef=3D"https://www.ietf.org/mailman/listinfo/ietf-822">https://www.ietf.org/= mailman/listinfo/ietf-822</a>> to subscribe).<br></div> <div><a href=3D"mailto:[email protected]">[email protected]</a> migh= t also be of interest, as SMTP behaviour is discussed there.<br></div> <div><br></div> <div>On Thu, Jul 19, 2018, at 12:24 PM, Peter Occil wrote:<br></div> <blockquote type=3D"cite"><div><p style=3D"margin: 0in 0in 0.0001pt;"><span= class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"si= ze" style=3D"font-size:11pt">RFC 2369 sec. 2 currently says:</span></span><= br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D= "font-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:1= 1pt"> </span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><sp= an class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"= size" style=3D"font-size:11pt"> MTAs MUST NOT insert whitespace= within the brackets [contained</span></span><br></p><p style=3D"margin: 0i= n 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-se= rif"><span class=3D"size" style=3D"font-size:11pt"> in list hea= der fields], but client applications should treat any</span></span><br></p>= <p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-f= amily:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">&n= bsp; whitespace, that might be inserted by poorly behaved MTAs,<= /span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"= font" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style= =3D"font-size:11pt"> as characters to ignore.</span></span= ><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style= =3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-siz= e:11pt"> </span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;">= <span class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class= =3D"size" style=3D"font-size:11pt">To the extent the first clause applies t= o software generating messages that might contain list header fields, usual= ly for the purpose of first sending them, this makes it harder for software= to encode message header fields in a generic manner rather than having to = deal with special cases like the list header fields, since, among other thi= ngs, such software may seek to comply with line length limitations in RFC 5= 322 by folding long lines in accordance with that RFC.</span></span><br></p= ><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-= family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">&= nbsp;</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span cla= ss=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" = style=3D"font-size:11pt">If the cited clause does apply to such software, a= suggested change to that statement in a future revision of that RFC might = be that whitespace "SHOULD NOT" be inserted between the brackets, but that = software generating (as opposed to retransmitting) messages containing list= header fields might choose to do so due to line length limitations in Inte= rnet messages or because of the need or desire to handle messages generical= ly regardless of what header fields it has. (But I note that this change sh= ould not encourage MTAs to disobey SMTP or other transport protocols they m= ay implement.)</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;">= <span class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class= =3D"size" style=3D"font-size:11pt"> </span></span><br></p><p style=3D"= margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibr= i, sans-serif"><span class=3D"size" style=3D"font-size:11pt">--Peter</span>= </span><br></p></div> </blockquote><div><br></div> </body> </html> --_----------=_153218353316948702-- --===============7962862987810802676== 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 --===============7962862987810802676==--