You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Carnegie, Martin" <Ma...@atcoitek.com> on 2004/10/01 21:47:34 UTC
[SA-List] IPlanet and SA
We are currently seeing emails from external customers being marked as
spam in SA when they come from an ISP called Shaw. I have been talking
to their tech support about these emails as I think that this is all on
their end due to the format of the email. As a Shaw customer myself. I
sent an email from my account (through their web interface) and here is
the message headers
========================================================================
============
Microsoft Mail Internet Headers Version 2.0
Received: from is031.atco.com ([10.3.64.64]) by is030.atco.com with
Microsoft SMTPSVC(5.0.2195.6713);
Wed, 8 Sep 2004 16:26:58 -0600
Received: from atcoinss.atco.ca ([192.210.10.20]) by is031.atco.com with
Microsoft SMTPSVC(5.0.2195.6713);
Wed, 8 Sep 2004 16:26:58 -0600
Received: from atcoinss.atco.ca ([192.210.10.20])
by atcoinss.atco.ca (SMSSMTP 4.0.0.59) with SMTP id
M2004090816261702419
for <ma...@atcoitek.com>; Wed, 08 Sep 2004 16:26:17 -0600
Received: from [24.71.223.10] (helo=pd3mo2so.prod.shaw.ca)
by atcoinss.atco.ca with esmtp (Exim )
for martin.carnegie@atcoitek.com
id 1C5AtN-0003nf-Tt; Wed, 08 Sep 2004 16:26:17 -0600
Received: from pd4mr3so.prod.shaw.ca
(pd4mr3so-qfe3.prod.shaw.ca [10.0.141.214]) by l-daemon
(Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004))
with ESMTP id <0I...@l-daemon> for
martin.carnegie@atcoitek.com;
Wed, 08 Sep 2004 16:09:28 -0600 (MDT)
Received: from shaw.ca ([10.0.122.165])
by pd4mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01
(built Mar
15 2004)) with ESMTP id <0I...@pd4mr3so.prod.shaw.ca> for
martin.carnegie@atcoitek.com; Wed, 08 Sep 2004 16:09:28 -0600 (MDT)
Received: from [10.0.144.80] by pd3ims1.prod.shaw.ca (mshttpd); Wed,
08 Sep 2004 16:09:28 -0600
Date: Wed, 08 Sep 2004 16:09:28 -0600
From: Martin Carnegie <ma...@shaw.ca>
Subject: testing
To: martin.carnegie@atcoitek.com
Message-id: <31...@shaw.ca>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.18 (built Jul 28 2003)
Content-type: text/html; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on
atcoinss.atco.ca
X-Spam-Level: ****
X-Spam-Status: No, hits=4.1 required=5.0
tests=FAKE_HELO_SHAW_CA,HTML_30_40,
HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY autolearn=no
version=2.63
Return-Path: martin_c@shaw.ca
X-OriginalArrivalTime: 08 Sep 2004 22:26:58.0656 (UTC)
FILETIME=[F44D7E00:01C495F2]
========================================================================
============
As the message is coming in as HTML, I took a look at the source and
this is all it contains
========================================================================
============
<BODY>test for shaw.</BODY>
========================================================================
============
So I understand why SA marks it as it does, but according to Shaw, they
cannot change any settings that would change the score. I have asked
them to either properly format the HTML or make it plain text, which is
not something they say can be done.
Has anyone had experience with IPlanet that would know if there is some
setting that they could adjust?
I know that I can whitelist them, but we prefer that they would fix
their system rather than we have to maintain a whitelist.
Hopefully I have enough information for someone to assist.
Thanks
Martin Carnegie
Re: [SA-List] IPlanet and SA
Posted by Kelson <ke...@speed.net>.
Carnegie, Martin wrote:
> Received: from [24.71.223.10] (helo=pd3mo2so.prod.shaw.ca)
> by atcoinss.atco.ca with esmtp (Exim )
> for martin.carnegie@atcoitek.com
> id 1C5AtN-0003nf-Tt; Wed, 08 Sep 2004 16:26:17 -0600
(This looks like the section FAKE_HELO_SHAW_CA is firing on.)
If I'm reading correctly, that means that the mailserver on
atcoinss.atco.ca could not find reverse DNS info for 24.71.223.10. This
is odd, because an nslookup yields shawidc-mo1.cg.shawcable.net. Also,
pd3mo2so.prod.shaw.ca resolves to that IP.
From what I can tell, FAKE_HELO_SHAW_CA checks to see that a HELO of
shaw.ca matches an rDNS of shaw.ca or shawcable.net, which should have
worked (i.e. it should have matched and cause the rule to not fire).
So it looks like it *may* be a glitch with rDNS lookup on your end, or
possibly with the settings of trusted_networks.
It's worth noting also that FAKE_HELO_SHAW_CA doesn't seem to be in SA
3.0 except as an orphaned description in the dutch ruleset.
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: [SA-List] IPlanet and SA
Posted by Matt Kettler <mk...@evi-inc.com>.
At 03:47 PM 10/1/2004, Carnegie, Martin wrote:
>X-Spam-Status: No, hits=4.1 required=5.0
>tests=FAKE_HELO_SHAW_CA,HTML_30_40,
> HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY autolearn=no
> version=2.63
Here's a question for you. How'd your copy of SA 2.63 end up with a score
of 4.1? Have you modified any scores?
Grepping through 50_scores.cf for a stock copy of 2.63 I get these scores
None of which total to anything which might round to 4.1.
0.298 0.904 2.800 0.585 (score FAKE_HELO_SHAW_CA)
0.160 0.001 0.100 0.100 (score HTML_MESSAGE)
1.107 1.717 1.259 1.184 (score HTML_MIME_NO_HTML_TAG)
0.666 0.100 0.248 0.320 (score MIME_HTML_ONLY)
0.837 0.809 0.919 0 (score HTML_30_40)
---------------------------------------------------
3.062 3.53 5.326 2.845 (totals)
Other than this minor point, I'd agree with the others that fixing the
FAKE_HELO match would be worthwhile. The HTML rule matches aren't nearly so
bad on their own.
>I am really surprised that the Sun software is unable to do things correctly.
I'm in general the opposite. I'm really surprised when Sun software can do
things correctly.
I'm extraordinarily unimpressed with IPlanet, which caused difficulty with
one of my home ISPs that used IPlanet at the time. Their mail servers had
trouble exchanging mail due to lack of RFC compliance at the SMTP layer
(since fixed). It could have been the ISPs fault, or Sun's who knows, but
the problem was something very fundamental like lack of generating HELO's
prior to issuing mail. I was quite shocked the MTA could even be configured
that way without great effort on the part of the ISP.