Matt Sergeant wrote:
On 22-May-08, at 10:45 PM, John Peacock wrote:
STARTTLS is not required to happen immediately after EHLO (not HELO,
which doesn't support ESMTP extensions). And yes, you must completely
discard every portion of the SMTP state that has occurred up to that
point (just like with RSET).
SMTP state and qpsmtpd/filtering state are not the same thing. The RFCs
talk about destroying SMTP state. It already does that without having
to destroy any notes() AFAICT. But it shouldn't blithely throwing away
qpsmtpd/filtering state - it's none of the RFC's business.
The RFC is extremely plain on this point: after STARTTLS has been sent
and negotiated, the MTA must behave as if a completely new transaction
has started (as indeed, it has). The transaction *must* be reset and
all information contained therein must be thrown away. In practice,
there isn't anything there to begin with, since all of the well-formed
MTA's always sent STARTTLS as soon as practical (i.e. as soon as they
see the initial EHLO banner), if they are going to send it at all.
I don't think we should care so much about the RFCs. If there are bits
in connection notes that might help determining if this is spam (or some
other thing we're trying to detect) before STARTTLS we need to allow
qpsmtpd to keep that information.
Indeed. It makes sense, for example, for a source-IP reputation checker
to launch its queries at connect time, and query the results at a later
phase (eg: rcpt/data) to make the decisions then, independent of whether
TLS was established or not.
My hack to the async DNSBL code does that.
