Re: [Declude.JunkMail] SPF Success

[Matt]

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: <Declude.JunkMail@declude.com> 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: <Declude.JunkMail@declude.com> 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: Declude.JunkMail@declude.com 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: <declude.junkmail@declude.com> 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/ =====================================================