http://bugzilla.spamassassin.org/show_bug.cgi?id=2462
------- Additional Comments From [EMAIL PROTECTED] 2004-12-01 23:34 -------
Daryl, you're exactly right.
If the last untrusted header contains header strings indicating that the user
authenticated to the trusted server, we can indeed extend the trust boundary to
include the next hop.
So the next question is -- can we differentiate (a) spammers connecting to a
server with TLS, then relaying unauthenticated spam, from (b) a real user
connecting to a server with TLS and authenticating? I know the idea of
spammers taking the performance hit to do a TLS handshake *seems* unlikely, but
given the CPU power of the zombie networks nowadays, it's really not that
unlikely in future, so I think we will see spam that does (a).
(there's already spam that *forges* Received lines claiming to do (a), but
that's not an issue as that's >1 line into the untrusted header set.)
a TLS connection without user authentication looks like this, afaics:
Received: from ... (... [209.204.169.179]) (authenticated bits=0) by
smtp1.supranet.net (8.12.10/8.12.10) with ESMTP id iAUCaOSD095285
(version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 30 Nov 2004
06:36:25 -0600 (CST)
or
Received: from ... (... [172.24.77.106])
(authenticated bits=0)
by ... (8.12.11/8.12.11) with ESMTP id i98HCirF017491
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
for <....>; Fri, 8 Oct 2004 10:12:44 -0700
and one with user auth looks like this:
Received: from ... ([...])
(authenticated user [EMAIL PROTECTED])
by smtp.film-tech.net (smtp.film-tech.net [66.98.221.156])
(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v6.8.5.R)
with ESMTP id 44-md50000000012.tmp
for <...>; Tue, 09 Nov 2004 20:35:57 -0600
AFAICS, the current patch doesn't differentiate them.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
