You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Søren Therkelsen <th...@mailme.dk> on 2005/12/16 11:30:10 UTC

Novice question regarding mail server identity check

Hi,
 
I'm not running a mail server but just a annoyed receiver of spam.
 
It seems to me that a lot of spam is send through mail servers disguised a
different mail server (possibly acknowledged as trustworthy)
 
I get to that conclusion from reading the mailheader and comparing the
"helo" from the originating mail server with the IP-address of the same.
 
It might have been thougt of before and there might be good reasons for not
making an identity check -
but i would like your thought on this
 
 
Regards
 
Søren
 
Return-path: <HYPERLINK
"mailto:k.valentine@alv.kth.se"k.valentine@alv.kth.se>
Envelope-to: HYPERLINK "mailto:myadr@domain.dk"myadr@domain.dk
Delivery-date: Fri, 16 Dec 2005 11:09:06 +0100
Received: from [81.19.232.213] (helo=webmail3.mailme.dk)
 by mailme.dk with esmtp (Exim 4.52)
 id 1EnCWQ-0002yQ-2n
 for HYPERLINK "mailto:myadr@domain.dk"myadr@domain.dk; Fri, 16 Dec 2005
11:09:06 +0100
Received: from [218.65.120.230] (helo=uwo.ca)
------------------------------Why should a Canadian university have there
mail server in China?
 by webmail3.mailme.dk with smtp (Exim 4.52)
 id 1EnBeW-0006Ed-8c
 for HYPERLINK "mailto:myadr@domain.dk"myadr@domain.dk; Fri, 16 Dec 2005
10:13:25 +0100
Message-ID: <HYPERLINK
"mailto:1134723758.2121@alv.kth.se"1134723758.2121@alv.kth.se>
From: "Kris Valentine" <HYPERLINK
"mailto:k.valentine@alv.kth.se"k.valentine@alv.kth.se>
To: HYPERLINK "mailto:myadr@domain.dk"myadr@domain.dk
Date: Fri, 16 Dec 2005 06:02:38 -0300
MIME-Version: 1.0
X-Mailer: Pegasus Mail for Win32 (v3.12a)
X-SA-Exim-Connect-IP: 218.65.120.230
X-SA-Exim-Mail-From: HYPERLINK
"mailto:k.valentine@alv.kth.se"k.valentine@alv.kth.se
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
webmail3.mailme.dk
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=99.0 tests=none autolearn=unavailable 
 version=3.1.0
Subject: Stock Momentum Alert
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Version: 4.0 (built Sat, 24 Jul 2004 09:53:34 +0200)
 
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: 15-12-2005
 

Re: Novice question regarding mail server identity check

Posted by Kai Schaetzl <ma...@conactive.com>.
Mouss wrote on Mon, 19 Dec 2005 04:31:32 +0100:

> so? which section of the rfc says we must reject dynamic IPs?

> fqdn

(snipped the rest)

"mouss", you try to argue about things nobody said and you try to argue 
about words instead of meaning. This is bound to fail, I won't continue.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com




Re: Novice question regarding mail server identity check

Posted by mouss <us...@free.fr>.
Kai Schaetzl a écrit :
> Søren Therkelsen wrote on Fri, 16 Dec 2005 11:30:10 +0100:
> 
> 
>>Received: from [218.65.120.230] (helo=uwo.ca) 
>>------------------------------Why should a Canadian university have there 
>>mail server in China?
> 
> 
> Why not? The answer may be obvious in this case, but if you try to 
> generalize that this method fails. There is nothing that forces a mail 
> server to use a domain suffix for heloing that matches the GeoIP lookup. 
> Actually, that may be quite uncommon for various reasons.
> 
> There are *much* better methods to get rid of this spam. 1. that IP is on a 
> lot of RBLs since it is dynamic IP space.

so? which section of the rfc says we must reject dynamic IPs? just
because you do that doesn't solve the problem.
and, how do you detect dynamic IPs. most are not listed and some lists
include non dynamic IP.

 2. if one uses some helo
> verification the above helo will fail because it has only one dot.

ahuh? I didn't yet take a read at rfc4821...
what makes you believe that foo.com.uk is better than foo.com?

as far as I can tell, helo should be fqdn which means:
	goes to the top (all nodes valid, and includes a tld).
so
	mouss.usebsd.free.nice.guy
isn't fqdn because "guy" isn't a valid tld, but
	localhost
	arpa
	ws
	com
	yahoo.com
	mouss.yahoo.com
are fqdn. it's not about how many dots your have.

This doesn't mean you should accept "helo arpa", but there's no need to
change the law just because it doesn't suit you.

Re: Novice question regarding mail server identity check

Posted by Kai Schaetzl <ma...@conactive.com>.
Søren Therkelsen wrote on Fri, 16 Dec 2005 11:30:10 +0100:

> Received: from [218.65.120.230] (helo=uwo.ca) 
> ------------------------------Why should a Canadian university have there 
> mail server in China?

Why not? The answer may be obvious in this case, but if you try to 
generalize that this method fails. There is nothing that forces a mail 
server to use a domain suffix for heloing that matches the GeoIP lookup. 
Actually, that may be quite uncommon for various reasons.

There are *much* better methods to get rid of this spam. 1. that IP is on a 
lot of RBLs since it is dynamic IP space. 2. if one uses some helo 
verification the above helo will fail because it has only one dot.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com




Re: Novice question regarding mail server identity check

Posted by Rob Skedgell <ro...@nephelococcygia.demon.co.uk>.
On Friday 16 Dec 2005 10:30, Søren Therkelsen wrote:
> Hi,
>
> I'm not running a mail server but just a annoyed receiver of spam.
>
> It seems to me that a lot of spam is send through mail servers
> disguised a different mail server (possibly acknowledged as
> trustworthy)
>
> I get to that conclusion from reading the mailheader and comparing
> the "helo" from the originating mail server with the IP-address of
> the same.
>
> It might have been thougt of before and there might be good reasons
> for not making an identity check -
> but i would like your thought on this

This is probably why the SA installation contains a .cf file for fake 
HELO (20_fake_helo_tests.cf), and a lot of the rules for tests related 
to HELO/EHLO have fairly high scores:

$ grep HELO /usr/share/spamassassin/50_scores.cf
score FAKE_HELO_EMAIL_COM 1.440 1.440 1.665 1.335
score FAKE_HELO_EUDORAMAIL 1.360 1.440 1.665 1.705
score FAKE_HELO_EXCITE 0
score FAKE_HELO_LYCOS 0
score FAKE_HELO_MAIL_COM 1.920 1.920 2.220 2.369
score FAKE_HELO_MAIL_COM_DOM 2.160 2.160 2.498 2.700
score FAKE_HELO_MSN 2.080 2.060 2.358 2.509
score FAKE_HELO_YAHOO_CA 1.186 1.353 1.466 1.599
score FORGED_RCVD_HELO 0 0 0 0.135
score HELO_DYNAMIC_ADELPHIA 1.680 1.680 1.942 1.787
score HELO_DYNAMIC_ATTBI 2.400 2.400 2.775 2.692
score HELO_DYNAMIC_CHELLO_NL 1.624 0 2.035 0.170
score HELO_DYNAMIC_CHELLO_NO 0 # n=0 n=1 n=2 n=3
score HELO_DYNAMIC_COMCAST 2.800 2.800 3.237 3.500
score HELO_DYNAMIC_DHCP 3.280 2.664 3.792 3.066
score HELO_DYNAMIC_DIALIN 2.080 2.080 2.405 2.600
score HELO_DYNAMIC_HCC 3.280 3.280 3.792 4.100
score HELO_DYNAMIC_HEXIP 1.280 1.280 1.480 1.600
score HELO_DYNAMIC_HOME_NL 1.600 1.600 1.850 2.000
score HELO_DYNAMIC_IPADDR 3.360 3.360 3.885 4.200
score HELO_DYNAMIC_IPADDR2 3.280 3.213 3.792 3.818
score HELO_DYNAMIC_NTL 1.360 1.360 1.573 1.481
score HELO_DYNAMIC_OOL 1.840 1.839 2.127 2.012
score HELO_DYNAMIC_ROGERS 1.840 1.203 2.127 1.580
score HELO_DYNAMIC_RR2 1.440 1.440 1.665 1.605
score HELO_DYNAMIC_SPLIT_IP 2.880 2.880 3.330 2.191
score HELO_DYNAMIC_TELIA 0 # n=0 n=1 n=2 n=3
score HELO_DYNAMIC_VELOX 0 # n=0 n=1 n=2 n=3
score HELO_DYNAMIC_VTR 1.440 1.492 1.757 1.287
score HELO_DYNAMIC_YAHOOBB 2.240 2.240 2.590 2.800
score NO_RDNS_DOTCOM_HELO 0.356 0 0 0
score RCVD_FAKE_HELO_DOTCOM 2.160 1.652 2.590 2.281
score RCVD_HELO_IP_MISMATCH 3.200 3.200 3.700 4.000
score RCVD_NUMERIC_HELO 1.440 1.253 1.665 1.500
score SPF_HELO_PASS -0.001
score SPF_HELO_FAIL 0
score SPF_HELO_NEUTRAL 0
score SPF_HELO_SOFTFAIL 0 2.078 0 2.432

So yes, I'd say the devs have thought of this.

In addition, it's fairly common for spam sources to forge the name of 
the server they are connecting to as HELO/EHLO, so I had something like 
the following in Exim's smtp_helo ACL (for an old dyndns address which 
I no longer use), so they did't get as far as SpamAssassin:

# drop connections which try to helo as me
drop    condition =   ${if or{ \
                          {eq {$sender_helo_name}{$qualify_domain}} \
                          {eq {$sender_helo_name}{$interface_address}} \
                      }}
        hosts =       !$qualify_domain : !*.$qualify_domain
        message =     Liar. Go away.
        log_message = $sender_host_name \[$sender_host_address\] \
                      forged EHLO/HELO

-- 
Rob Skedgell <ro...@nephelococcygia.demon.co.uk>