Download raw body.
smtpd smuggling
On Wed, Jan 24, 2024 at 11:24:01AM +0100, Omar Polo wrote: > On 2023/12/27 18:13:47 +0100, Omar Polo <op@omarpolo.com> wrote: > > On 2023/12/21 08:54:37 +0000, gilles@poolp.org wrote: > > > Hello, > > > > > > December 20, 2023 10:34 AM, "Omar Polo" <op@omarpolo.com> wrote: > > > > > > [...] > > > At some point, we tried being strict but it broke interoperability with a > > > few clients, including some printers doing SMTP, so we backtracked. There > > > was also a point in time were the state machine was much stricter and did > > > an exclusive read/write mode dance controlled by server response, so in: > > > > > > > > > "\n.\r\nMAIL FROM:<>" > > > > > > > > > The "\n.\r\n" would switch the server to write mode which would cause the > > > transaction to error out: "MAIL FROM" would be pending which meant client > > > had tried to pipeline outside of pipelining. I just tried and it seems it > > > no longer is the case. That would have prevented misunderstanding DATA as > > > a relay AND as a destination by erroring the transaction. OpenSMTPD would > > > not smuggle and it would not allow input from an MTA that smuggles. > > The handling of "." is exempted from the pipeline check. I tried to > rearrange the code but with that I had a lot of pipeline errors then. > > > > [...] > > > Well, I think being more strict is the way to go even if it breaks some > > > legacy SMTP clients out there. It should be sane by default so maybe an > > > option could be introduced to help those who have to deal with hardware > > > shipping old clients: they'd have to explicitly degrade strictness. > > > > > > just my 2cents > > > > Here's another try that also adds a knob for this. The idea is to save > > whether bare LF are accepted in the struct io --since at least for the > > filters we need bare LF-- instead of hardcoding it in the relevant > > files. > > I'd like to retract the diff. While it worked for me for the vast > majority of the mails, I had a case of a fairly important mail being > rejected due to this strictness. Fun thing: it was from amazon and > forwarded to me by a gmail address. > > maybe we could be strict only with the "." hanling. I'm surprised by this. I thought this was a solved issue since qmail enforces strict CRLF encoding and did this for a very very long time. See also http://pobox.com/~djb/docs/smtplf.html -- :wq Claudio
smtpd smuggling