----- Original Message -----
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, March 06, 2004 7:23 PM
Subject: Re: [spf-discuss] A HELO Question
Now SOME folks have said that they would like to employ the same
anti-forgery checks against HELO for ALL mail and not just for MAIL FROM:
<>. I think that SPF can easily accomodate them, but that this feature
should be used at the receiver's own risk.
Based on all that... I would expect SPF to return "unknown" for any domain
OR helo name that doesn't have SPF info published, INCLUDING domains that
clearly don't exist. I think it's reasonable to block mail from domains
that don't exist, but I wouldn't depend on SPF to do this for you.. there
should be other policy built into the mailer to reject the mail if the
domain doesn't exist. I would not recommend to use this type of checking
on the HELO name though.
Remember the key focus is to protect LOCAL DOMAIN spoofing - first over
everything else.
Local Domain protection provides 100% reliable trusted results. The only
time results for remote domain checking can be trusted is with rejections
and even here, it can be a false negative (rejection) in forwarding
situations.
Look at this this way:
#1 SPF = IP :: RETURN PATH DOMAIN
If this association #1 says that the domain is SPF compliant, this
fundamentally implies that the IP is part of the SPF compliant network.
Therefore, the following must be TRUE
#2 SPF = IP :: NON-SPOOFED LOCAL DOMAIN HELO/EHLO
In other worlds, if association #2 is not true, than association #1 is
violated because the common entity is the IP address.
yes, I agree 100% that there are many systems that use non-FQDN, such as
dynamic IP MUAs that use the netbios name for the HELO/EHLO.
Thats fine - as long as their are not using your local domain names.
If they are, then associate #1 is violated even though it "might pass the
test"
The main problem with the original SPF lookup specification was that there
was no provision to even "double check" for a local domain helo/ehlo
spoofing if the return path domain was non-null and not local. So as long
as it was non-null and not local, the spammer did not have to change his
software. With the old logic, the spammer had less incentive to comply or
change software. And if he wanted to mask himself as being "somewhat SPF
compliant," all he had to do was google the net for "Received-SF:" and see
what systems out there used a "softfail" or "neutral"
The new SPF logic forces spammers to change their software because local
domain spoofing will no longer work.
Since implementing the new SPF logic, the new trap has shown that 10-15%
(see note 1) of the rejections are HELO/EHLO spoofers. These were
previously trapped by DMP but since we turned off DMP, we began to see all
this SPF bypassing the check.
Note 1: This rate was pretty consistent since the new logic was added over 1
week ago. Yesterday's stat showed it went down to 6%. I am going to see
if this is a result of them learning. Also, I can't tell you why we get
hit with these type of spoofing spammers, but we do. It does seem to come
for a selected group of IP addresses.
Also, on average we get hit with about 2500 connections. About ~70% or ~1750
connections drop or disconnect after the greeting or after issueing the
HELO/EHLO. We get alot of these:
**************************************************************************
Wildcat! SMTP Server v5.7.450.9b13
SMTP log started at Sat, 06 Mar 2004 00:04:04
Connection Time: 20040306 00:04:04 cid: 0001EF60
SSL Enabled: NO
Client IP: 200.11.203.100 (unknown)
00:04:04 S: 220-winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
00:04:04 S: 220-************** WARNING: FOR AUTHORIZED USE ONLY!
**********************
00:04:04 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY
COMPUTERS *
00:04:04 S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE
UNSOLICITED *
00:04:04 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL
RESTRICT ACCESS *
00:04:04 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY.
*
00:04:04 S:
220-************************************************************************
00:04:04 S: 220 winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
00:04:11 C: HELO SRV-INTERNET
00:04:11 S: 250 winserver.com, Pleased to meet you.
**************************************************************************
Wildcat! SMTP Server v5.7.450.9b13
SMTP log started at Sat, 06 Mar 2004 00:04:39
Connection Time: 20040306 00:04:39 cid: 0001EF61
SSL Enabled: NO
Client IP: 68.125.210.181 (unknown)
00:04:39 S: 220-winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
00:04:39 S: 220-************** WARNING: FOR AUTHORIZED USE ONLY!
**********************
00:04:39 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY
COMPUTERS *
00:04:39 S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE
UNSOLICITED *
00:04:39 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL
RESTRICT ACCESS *
00:04:39 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY.
*
00:04:39 S:
220-************************************************************************
00:04:39 S: 220 winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
00:04:42 C: HELO adsl-68-125-210-181.dsl.irvnca.pacbell.net
00:04:42 S: 250 winserver.com, Pleased to meet you
Now, this all started when we added the extended greeting. At first, I
thought that maybe these spammers "actually read" the greeting, but now I
think that they are using broken software that does not supported extended
response lines. Now that we have the new SPF logic again, I'm going to
disable the extended greeting and let it run for a few weeks to see how SPF
handles these.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com