Wietse:
> - Don't accept mail with a broken end-of-data sequence (Postfix
> currently allows zero or more <CR> followed by <LF>). Or more
> generally, don't accept <CR> or <LF> that aren't part of a <CR><LF>
> sequence. Postfix does not support BDAT with BINARYMIME, so there
> is no valid use of stray <CR> or <LF> bytes.
Vijay S Sarvepalli:
> If Postfix pursues a way to not accept 'broken end-of-data sequence'
> as you state. Will plain <!CR><LF>.<!CR><LF> and <CR><LF<.<CR><LF>
> be the only sequences Postfix will accept? I can see potentially
Postfix would reject the first form, which contains stray <LF> (i.e.
<LF> that is not immediately preceded by <CR>).
> some clients breaking that I looked into (mostly scripting shell/perl/
> etc.), a lot of them seem to use <LF>.<LF> and no <CR> at all.
> That's the only issue I can see as potential compatibility problem.
Indeed. <LF> is the native UNIX end-of-line byte, and may be sent
by naively implemented scripts. The use of <CR> as the 'native'
end-of-line byte has ceased as MacOS 9 deployments fell to dust.
Rejecting stray <CR> and <LF> while receiving mail will prevent
Postfix from receiving "smuggled" SMTP commands after a malformed
end-of-data sequence, and thus, it will prevent Postfix from
forwarding them.
So would rejecting an SMTP command pipelining protocol violation
when the SMTP server receives a "smuggled" DATA command that is
immediately followed by message content, but an attacker may
try to position DATA<CR><LF> immediately before a packet boundary.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
