←back to thread

422 points km | 1 comments | | HN request time: 0s | source
Show context
michaelmior ◴[] No.41831072[source]
> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line

What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway.

Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things.

> Even if an established protocol (HTTP, SMTP, CSV, FTP) technically requires CRLF as a line ending, do not comply.

I'm hoping this is satire. Why intentionally introduce potential bugs for the sake of making a point?

replies(13): >>41831206 #>>41831210 #>>41831225 #>>41831256 #>>41831322 #>>41831364 #>>41831391 #>>41831706 #>>41832337 #>>41832719 #>>41832751 #>>41834474 #>>41835444 #
chasil ◴[] No.41831210[source]
FYI, Sendmail accepts LF without CR, but Exchange doesn't.
replies(2): >>41831846 #>>41835526 #
1. isThereClarity ◴[] No.41835526[source]
sendmail 8.18.1 includes patches to correct this behaviour (and options to turn it back on) due to its role in SMTP smuggling, CVE-2023-51765. See https://ftp.sendmail.org/RELEASE_NOTES

  sendmail is now stricter in following the RFCs and rejects
  some invalid input with respect to line endings
  and pipelining:
  ...snip...
  - Accept only CRLF . CRLF as end of an SMTP message
    as required by the RFCs, which can disabled by the
    new srv_features option 'O'.
  - Do not accept a CR or LF except in the combination
    CRLF (as required by the RFCs).  These checks can
    be disabled by the new srv_features options
   'U' and 'G', respectively.  In this case it is
   suggested to use 'u2' and 'g2' instead so the server
   replaces offending bare CR or bare LF with a space.
   It is recommended to only turn these protections off
   for trusted networks due to the potential for abuse.