Index | Thread | Search

From:
Claudio Jeker <cjeker@diehard.n-r-g.com>
Subject:
Re: smtpd smuggling
To:
Omar Polo <op@omarpolo.com>
Cc:
gilles@poolp.org, tech@openbsd.org
Date:
Wed, 24 Jan 2024 14:22:28 +0100

Download raw body.

Thread
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