|
Matt,
In my eyes setting up SPF-records for the own domains is
not a defensive action to prevent spam but an active. The goal is to let
see the spammers: Hey this domain has records allowing valid messages only from
IP x.x.x.x
According to my reliability measurements SPFPASS is used up
to 40% by spammers. So it's not usable to add a negative weight and let bypass
valif messages.
On the other side spammers can't affect on valid SPF
records of my domains. If I can be sure that my customers are sending their
messages only trough my server I can set up strong SPF records. So spammers can
see this and other spam filters can use the record to block other messages with
my mailfrom domains but invalid sender IP's.
Even if this will not reduce the number of incomming spam
on other servers and my servers to, I hope it will significantly reduce the
forged mailfrom's containg my domains. The first positive thing I should can see
is a reduced number of NDR's.
Then I can only hope that more and more Admin's are going
to use SPF records. At a certain level domains without SPF-Records will drown
under the load of forged mailfrom adresses and they must set up SPF records as
solution.
And it should help also against zombies: Theoreticaly it
should be possible for Internet access providers to block SPF-TXT requests to
their DNS-servers from the own DUL and xDSL-Lines. Now a zombi-computer has big
problems to determine what domains he can use for forged
mailfroms.
Markus
To enter SPF settings in a majority DNS server out there,
especially those with control panels, is never going to happen. It is
also more technical than most can accomplish (not us for the most of
course). This will remain an implementation that is primarily applied to
larger domains and otherwise sporadically.
If the goal is to determine
if someone is forging local addresses, I use a filter that I call FORGEDFROM
which is a derivative of SPAMDOMAINS, using a single column file like
so:
@example.com
@example.net
@example.org
...
I whitelist AUTH, and also gatewayed mail servers, but there are
plenty of exceptions where people still use their ISP's mail server, so this
filter only gets 20% of my hold weight. It is much easier to implement,
especially since I don't have access to most of my customer's DNS
servers.
I also use SPAMDOMAINS for many larger domains and I fear that
false positives would cause double hits on SPF-FALSE and SPAMDOMAINS, so I
have chosen not to bother. This might change with time, but I don't
expect widespread use.
SPF has no promise in it's current format of
validating legitimate E-mail since spammers are using it, which seemingly was
the primary original goal, and due to mail servers sending E-mail with the
Mail >From of the client software, there is always going to be a fair
number of false positives caused by it's use.
For something to be
successful in this market, it would have to be built into the mail server and
not DNS, otherwise it won't ever become widely popular due to issues with
implementing it. With spammers hacking accounts in larger providers, and
hosting providers mixing spammers with legitimate customers on the same mail
servers, I remain unconvinced that there will a solution that is suitable to
the real issue at hand for some time to come. Yeah, I know...bah humbug
:)
IMO, the best way to stop forging is to stop zombie spammers.
The way to do this is FIRST implement port 587 as AUTH-only, and then widely
block port 25. This means that mail clients would exclusively use AUTH
on private networks and connect to their mail server on port 587 where only
AUTHed connections would be allowed. Then only servers would share
non-AUTH E-mail on port 25. The only reason why blocking port 25 is not
very common currently is because it is severely limiting to customers and
would cause support issues for the ISP. If you first did the migration
to port 587 AUTH-only connections, which would take several years to
accomplish in good order, ISP's could move forward with port 25 blocking and
cause many fewer issues as far as support and their clients were
concerned.
Basically what I am saying is that forging isn't the issue,
it's spam zombies, and to go after it as a forging issue is to miss the
point. The big caveat here is that spammers will turn to hacking AUTH in
much larger numbers, and E-mail server software should also widely implement a
'hijack' detection mechanism in order to help stem the abuse. I have
already noted much more hacking going on, first with Earthlink's properties,
and now with Prodigy as well. I have little faith that these things will
happen in the proper order or with the expedience necessary unfortunately,
especially because of what I consider to be a distraction focused on forging
coming from the likes of SPF, Microsoft and Yahoo. I feel that the big
players are missing the point, and they are the ones that heavily influence
E-mail client and server software which is where the changes first need to be
implemented.
Matt
Darin Cox wrote:
One other thing I left out...
As SPF becomes more widespread and ISPs implement it, SPF record inheritance
will become a viable solution to the customer using ISP mail servers
dilemma. That is, if the ISP sets SPF records that define what their mail
servers are, then we can reference their SPF records in the SPF records we
set up for a domain. So, by specifying to "inherit" the customer's ISPs
records, we tell SPF that email from the domain can come from our mail
servers or the ISPs mail servers without having to know and specify all of
the ISPs mail servers.
Darin.
----- Original Message -----
From: "Darin Cox" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, December 24, 2004 7:14 AM
Subject: Re: [Declude.JunkMail] SPF Success
Certainly. We have a few customers that use other mail servers, so for
those we set the basic SPF record that says we don't know where they will
send from. However, most customers are not savvy enough to change their
mail servers, so when we tell them our mail server address that's all they
will use.
One other point about SPF records. If you have domains that do not send
mail, drop an SPF record in that says they don't send mail at all. We've
had some success with that as well...especially if it's a domain that was
previously active but now just being held onto... like with a company name
change where you still want the website traffic, but no email from it
anymore.
Darin.
----- Original Message -----
From: "Markus Gufler" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, December 24, 2004 4:34 AM
Subject: RE: [Declude.JunkMail] SPF Success
As many Admin's who has the possibility to set up SPF records are ISPs with
their own DNS-Servers I just want to note that you should ensure, that each
customer is realy sending out mails only trough your MTA. If not you will
punish also legit messages.
The problem is: How to know if the messages processed on you MTA are the
only ones?
Ok, if there are relayed messages from one customer to a remote MTA we can
expect the customer is not using a local SMTP-Server who does MX lookups and
direct delivery. But what about customerside applications (for example CRM)
who does exactly that?
The solution of setting up "soft" SPF records will not more prevent you
anymore from being forged...
Markus
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darin Cox
Sent: Friday, December 24, 2004 3:01 AM
To: [email protected]
Subject: Re: [Declude.JunkMail] SPF Success
Middling success, but definitely beneficial...the biggest
benefit we've seen is in blocking forged spam from domains we
serve. By implementing SPF for those domains, we can fail
email that doesn't come from our servers. So, forging spam
that uses the destination address as the from address is
easily caught.
Darin.
----- Original Message -----
From: "Danny" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, December 23, 2004 8:48 PM
Subject: [Declude.JunkMail] SPF Success
I'm setting up SPF. Just wondering what success SPF has had with
marking spam for anyone?
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
