Sigh,
Paul,
Do me a favor, go look at the SA code and see what "HELO_DYNAMIC_ATTBI"
is all about. Note that it is looking at the 'X-Spam-Relays-Untrusted'
meta-data thus SA already knows that client is untrusted, so it is NOT
a trusted_networks issue at all. So hacking the trust settings
will do NOTHING for this specific problem.
Please note that I'm talking explicitly about the "HELO_DYNAMIC_ATTBI"
rule, not the "HELO_DYNAMIC_IPADDR" rule (which is influenced by trust
settings).
Yes, that brandeis.edu mail server config is adding headers that are
arguably wrong (your observation on "localhost.localdomain") but those
headers have -nothing- to do with "HELO_DYNAMIC_ATTBI".
It could be squeaky-clean with regards to its headers and that problem
will still be there (thanks to the IMP-webmail code).
If you are going to argue with me, please stick to the point and don't
drag in extraneous unrelated stuff.
Yes, Hotmail/MSN/gmail etc also use HTTP, also add 'Received:' headers
that incorporate client data. Go look at one of those 'Received:'
headers, note that they do -not- look so close to a SMTP MTA 'Received:'
header that they fool SA. (IE their HTTP derived 'Received:' headers
are clearly different from SMTP MTA 'Received:' headers).
Thus SA is not 'fooled' into thinking that those are SMTP MTA 'Received:'
headers and trying to pull such things as HELO data out of them.
So your observation about your collection of Yahoo!, Hotmail or Gmail
ham proves my point, it is SPECIFIC to IMP-webmail.
We both agree that the problem lies with with IMP and its attempts to
"create/forge" an initial header, however your ""easy" work around"
has NO bearing on this problem. The fact that you suggested it shows
that you do not really understand the issue.
I will try one more time to bludgeon this point to death.
Here is a Hotmail added 'Received:' header derived from the HTTP client
data:
Received: from 12.215.145.214 by sea2fd.sea2.hotmail.msn.com with HTTP;
Fri, 09 Jan 2004 03:56:14 GMT
Note the specific part between the word 'from' and the word 'by', it
is JUST an IP address. There is NOTHING in that part that could be
construed to be a HELO string.
So when the SA parser generates the X-Spam-Relays-Untrusted entry for
this header it leaves the $helo part blank (see Received.pm).
Thus nothing for "HELO_DYNAMIC_ATTBI" to fire on.
Here is a IMP-webmail added 'Received:' header derived from the HTTP
client data:
Received: from h00c04f2d101a.ne.client2.attbi.com
(h00c04f2d101a.ne.client2.attbi.com [66.30.139.164])
by webmail.grad.brandeis.edu (IMP) with HTTP
for <[EMAIL PROTECTED]>; Sun, 27 Feb 2005 23:25:30 -0500
Note the specific part between the word 'from' and the word 'by', it looks
EXACTLY like a 'Received:' header added by a sendmail MTA. The SA header
parser is written to recognize that format and it "sees" what it thinks
is a HELO string in there. (see line 591 of Received.pm; SA 3.0.2).
So when the SA parser generates the X-Spam-Relays-Untrusted entry for
this header it adds a "helo=h00c04f2d101a.ne.client2.attbi.com" which
will trigger "HELO_DYNAMIC_ATTBI".
The name of the rule is just fine, it -is- looking for a particular HELO
string from the client. Of course, when talking about a HTTP stream the
whole concept of HELO is ridiculous.
The final analysis is that the IMP-webmail folks are being too clever
for their own good (too much stuff in that 'Received:' header) and SA
is not being defensive enough to not fall for the bogus data.
would one of the devs look at the following patch to see if it is a valid
fix for this problem:
*** lib/Mail/SpamAssassin/Message/Metadata/Received.pm-orig Wed Dec 15
21:10:02 2004
--- lib/Mail/SpamAssassin/Message/Metadata/Received.pm Thu Mar 3 13:44:05 2005
***************
*** 593,598 ****
--- 593,599 ----
$helo = $1; $rdns = $2; $ip = $3; $by = $4;
$rdns =~ s/^IDENT:([EMAIL PROTECTED])\@// and $ident = $1; # remove
IDENT lookups
$rdns =~ s/^([EMAIL PROTECTED])\@// and $ident = $1; # remove
IDENT lookups
+ /\swith HTTP for\s/ and $helo = ''; # defend against
IMP-webmail
goto enough;
}
}
On Thu, 3 Mar 2005, List Mail User wrote:
> Dave,
>
> You have a few valid points, and the rule may be misnamed with
> HELO at its prefix; But look at some email coming from the free services
> like Yahoo!, Hotmail or Gmail and you will see HTTP (as well as other
> protocols; Hotmail/MSN also uses both of the MS proprietary protocols "DAV"
> and "SMTPSVC"). I also have copies of some messages from "mindspring.com"
> (re. Earthlink), "gmx.com" and "mail.ru" where the initial hop was HTTP and
> these are "ham". In addition, I also have *lots* of saved spam from "mail.ru"
> where the transfer initially was HTTP.
>
> The name "HELO_xxx" may be bad, but the rule is good. The problems
> lie with IMP and its attempts to "create/forge" an initial header. Of course,
> an "easy" work around is to simply "unmark" the next hop as trusted, then the
[snip..]
> Paul Shupak
>
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
