Hello,
The RFC for SMTP states the following (section 2.3.8):
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a <CRLF>
sequence.
As a result, OpenSMTPD rejects DATA containing <CR> with the following:
500 5.0.0 <CR> is only allowed before <LF>
requiring that clients encode DATA if <CR> is part of it.
My question is: are we too strict ?
Not two MTA do the same thing. Some will leave '\r' in the body and then
write it to the user mailbox or relay it. Other change it into a '\n' or
skip it. The first ones take the risk of a MUA not handling '\r' well or
an MTA rejecting later, the second ones break DKIM-signatures.
The only good way to deal with this is to stick to the RFC ... BUT users
then experience message rejections when using broken clients (semarie@'s
printer is an example of one).
So:
a- do we leave '\r' in the body ?
b- do we turn '\r' into '\n'
c- do we keep strict behavior ?
d- do we keep strict behavior + provide a knob for '\r' to work ?
--
Gilles Chehade @poolpOrg
https://www.poolp.org patreon: https://www.patreon.com/gilles
