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.