add faq for smtp smuggling, fix bug around handling "\nX\n" for any X, reject bare carriage returns and possibly smtp-smuggling attempts

mox was already strict in its "\r\n.\r\n" handling for end-of-message in an
smtp transaction.

due to a mostly unrelated bug, sequences of "\nX\n", including "\n.\n" were
rejected with a "local processing error".

the sequence "\r\n.\n" dropped the dot, not necessarily a big problem, this is
unlikely to happen in a legimate transaction and the behaviour not
unreasonable.

we take this opportunity to reject all bare \r.  we detect all slightly
incorrect combinations of "\r\n.\r\n" with an error mentioning smtp smuggling,
in part to appease the tools checking for it.

smtp errors are 500 "bad syntax", and mention smtp smuggling.
This commit is contained in:
Mechiel Lukkien
2024-01-01 18:30:31 +01:00
parent 4b8b53e776
commit 1f9b640d9a
10 changed files with 269 additions and 40 deletions

View File

@ -1650,6 +1650,11 @@ func (c *conn) cmdData(p *parser) {
panic(fmt.Errorf("remote sent too much DATA: %w", errIO))
}
if errors.Is(err, smtp.ErrCRLF) {
c.writecodeline(smtp.C500BadSyntax, smtp.SeProto5Syntax2, fmt.Sprintf("invalid bare \\r or \\n, may be smtp smuggling (%s)", mox.ReceivedID(c.cid)), err)
return
}
// Something is failing on our side. We want to let remote know. So write an error response,
// then discard the remaining data so the remote client is more likely to see our
// response. Our write is synchronous, there is a risk no window/buffer space is