On Sat, 2 Sep 2006, John Peacock wrote:
Charlie Brady wrote:
I believe that is a misinterpretation of the RFCs. All information about
the SMTP transaction obtained from the client must be discarded, but
there is nothing which says that connection information must be
discarded.
OK, re-reading the RFC, I can go along with that interpretation. I'm not sure
how it is going to work, though, because currently we clone the following
connection parameters:
remote_host
remote_ip
remote_info
remote_port
local_ip
local_port
relay_client
and then ditch the original connection object. I think that the RBL code is
tied to the original connection, and hence vanishes in a puff of smoke when we
do that. The alternative to cloning is to reuse the same connection object and
delete the parameters that aren't on that list, ...
As long as information which is part of the transaction is stored in the
transaction, and information which is part of the connection is stored in
the connection, then we can reuse the connection, and create a new
transaction when required to by TLS.
Moreover, the RFCs are only concerned with correct delivery
of email. We are concerned with discrimination of ham from spam, and
additional information may help us. It's important, however, that we
only use post-TLS information for authentication, authorization and
sender and recipient address determination.
This mindset, however, is not something that I believe belongs in the core code.
Qpsmtpd, as shipped as the core, should be as completely RFC-compliant as we
can manage it.
Sure, but I don't see any compromise here. We need to accumulate as much
information as we can to make a correct ham/spam assessment. Discarding
information *can't* help. We are required, however, to start a fresh SMTP
transaction once TLS is negotiated.
When is there ever a problem with using a single connection object for the
duration of a a connection? Do we currently store some information in the
connection object which should be in the transaction? If so, shouldn't we
just fix that?
---
Charlie
