September 19, 2019 7:26 PM, "Eric Faurot" <[email protected]> wrote:
> 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'? > It gets escaped, just like if '\n' had been sent in place of '\r'. foo\r.\rbar => foo\n..\nbar I don't think it's a good solution either but it's one used in real world, this is the approach Gmail (among others) took. >> 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... > The RFC doesn't require the server to reject mails with "bare" '\r' BUT since it states that we shouldn't transmit them, not rejecting them has the side-effect that we MUST alter DATA (and break DKIM for these). > 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. > I'm not sure the only problem is at the end of lines, but I don't think any solution that's graceful to bad clients will be correct so I'm okay with your suggestion.
