On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > 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'
I don't think it's a good solution. What happens if there is a dot right after the '\r'? > c- do we keep strict behavior ? > d- do we keep strict behavior + provide a knob for '\r' to work ? I'm not sure the RFC actually requires the server to reject mails with "bare" '\r'. It just says the client must not transmit them. So maybe we should just discard them at receive time... To me, the only real problem with '\r' is at the end of lines. It's confusing since you never really know whether it's part of the content or the protocol. So I suggest that we strip all '\r' found at the end of a line, and retain the others. Eric.
