On 10/3/19 9:05 PM, Eric Faurot wrote: > On Thu, Sep 19, 2019 at 05:48:17PM +0000, [email protected] wrote: > >>> 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. >> > > Here is a diff for that. > Note that it strips the '\r' on all input, not just DATA. > > Eric. > > Index: smtp_session.c > =================================================================== > RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v > retrieving revision 1.414 > diff -u -p -r1.414 smtp_session.c > --- smtp_session.c 3 Oct 2019 05:08:21 -0000 1.414 > +++ smtp_session.c 3 Oct 2019 18:55:52 -0000 > @@ -1109,14 +1109,9 @@ smtp_io(struct io *io, int evt, void *ar > if (line == NULL) > return; > > - if (strchr(line, '\r')) { > - s->flags |= SF_BADINPUT; > - smtp_reply(s, "500 %s <CR> is only allowed before <LF>", > - esc_code(ESC_STATUS_PERMFAIL, ESC_OTHER_STATUS)); > - smtp_enter_state(s, STATE_QUIT); > - io_set_write(io); > - return; > - } > + /* Strip trailing '\r' */ > + while (len && line[len - 1] == '\r') > + line[--len] = '\0'; > > /* Message body */ > eom = 0; > See my previous mail. This will break existing dkim signatures on mails which have trailing '\r'. Even though clients must not send those, they apparently do. Do we want to invalidate them as well? If that's the case, just remove this check, because if the old signatures don't matter than the new signature from filter-dkimsign (and others) won't matter as well.
Seriously, these solutions are like trying to fit a too large carpet, annoying bumps will just be moved around. If we *really* want to fix this we need to make it fit within the specifications: RFC 5321 section 4.1.1.4: The receiver normally sends a 354 response to DATA, and then treats the lines (strings ending in <CRLF> sequences, as described in Section 2.3.7) following the command as mail data from the sender. This command causes the mail data to be appended to the mail data buffer. The mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible. The custom of accepting lines ending only in <LF>, as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves, and SMTP server systems MUST NOT do this, even in the name of improved robustness. In particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication. This means stop opportunistic scanning for '\r' in iobuf!
