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, but I think that was not working
(which is if I remember was how clone() came to be added).
> 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. If individual admins want to play loose and fast with some of
the [more ancient and trusting] RFC's, that is their business (and I do it
myself).
John
