do you use SPF TXT RRs? (RFC4408)
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. how many of you are using SPF records? Do you have an opinion on their use/non use of? take care, greg
how many of you are using SPF records? Do you have an opinion on their use/non use of?
We use SPF on most client domains. On inbound filtering, we add no score for a lack of SPF record, and we reject mail if the SPF record hardfails. We've seen it reduce domain-imposter spam. It's not the ultimate spam fighting tool, but it does give you some control over your own domain for whoever will listen to it, which is handy. The only 'DoS Mitigation' I can think of is that the presence of a hardfail record would help keep your domain off the various DBLs. You could call "getting a domain blacklisted" a denial of service, I suppose. Nathan
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing. I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter. -j On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
On 10/04/2010 09:54 AM, John Adams wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
There should really be no reason to sign with DK too. It's historic.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
Me either. Mike
-j
On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott<Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
We've seen percentage gains when signing with DK, and we carefully monitor our mail acceptance percentages with ReturnPath. It's around 4-6%. I'd like to stop using it, but some people still check DK. -j On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas <mike@mtcc.com> wrote:
On 10/04/2010 09:54 AM, John Adams wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
There should really be no reason to sign with DK too. It's historic.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
Me either.
Mike
-j
On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott<Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
On 10/04/2010 10:05 AM, John Adams wrote:
We've seen percentage gains when signing with DK, and we carefully monitor our mail acceptance percentages with ReturnPath. It's around 4-6%. I'd like to stop using it, but some people still check DK.
Sigh. I was hoping not to hear that. It's been about 5 years since the issue of rfc4871. It might be helpful to name and shame. Mike
-j
On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas<mike@mtcc.com> wrote:
On 10/04/2010 09:54 AM, John Adams wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
There should really be no reason to sign with DK too. It's historic.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
Me either.
Mike
-j
On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott<Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
On Oct 4, 2010, at 10:16 AM, Michael Thomas wrote:
On 10/04/2010 10:05 AM, John Adams wrote:
We've seen percentage gains when signing with DK, and we carefully monitor our mail acceptance percentages with ReturnPath. It's around 4-6%. I'd like to stop using it, but some people still check DK.
Sigh. I was hoping not to hear that. It's been about 5 years since the issue of rfc4871. It might be helpful to name and shame.
Mike
At least in that case, the spammer has to have control of the sending domain. SPF is not intended to protect from that case. It is intended to protect from the case where spammers Joe-job domains they can't control. Removing a few points probably isn't a bad idea so long as you have a list of domains for which points should be added. Owen
-j
On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas<mike@mtcc.com> wrote:
On 10/04/2010 09:54 AM, John Adams wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
There should really be no reason to sign with DK too. It's historic.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
Me either.
Mike
-j
On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott<Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
On Mon, 04 Oct 2010 13:30:55 PDT, Owen DeLong said:
Removing a few points probably isn't a bad idea so long as you have a list of domains for which points should be added.
140 million .coms. Throw-away domains. I do believe that Marcus Ranum had "trying to enumerate badness" on his list of "Six stupidest security ideas". This won't scale as long as you have more spammers adding new domains faster than your NOC staff can add them to the blacklist. (And even centralized blacklists run by dedicated organizations haven't solved the problem yet, so I'm not holding my breath waiting for that to work out...)
dig throwaway1.com NS dig throwaway2.com NS etc etc ... and then check_sender_ns_access in postfix, for example. Scales much better than whackamoling one domain after the other on the same NS On Mon, Oct 4, 2010 at 4:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
140 million .coms. Throw-away domains. I do believe that Marcus Ranum had "trying to enumerate badness" on his list of "Six stupidest security ideas". This won't scale as long as you have more spammers adding new domains faster than your NOC staff can add them to the blacklist.
(And even centralized blacklists run by dedicated organizations haven't solved the problem yet, so I'm not holding my breath waiting for that to work out...)
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Mon, 04 Oct 2010 17:05:12 EDT, Suresh Ramasubramanian said:
dig throwaway1.com NS dig throwaway2.com NS
etc etc ... and then check_sender_ns_access in postfix, for example.
Yes, that *is* better than whack-a-mole on the same DNS server, but... The NANOG lurker in the next cubicle used to do that. Turned out the bang-for-buck wasn't as good as we hoped - it doesn't take too many false-positive errors blocking 20,000 domains hosted on the same DNS server as one spammer before the collateral damage becomes too painful. Our cost of dealing with a false positive is a lot higher than a false negative, especially once you factor in goodwill - people don't like spam, but a false positive on something they consider important causes more ire than 10x as many false negatives. That, and when our block list hit 150K entries or so, its size caused *other* issues with various things that were never designed for block lists quite that big...
On Oct 4, 2010, at 1:59 PM, Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Oct 2010 13:30:55 PDT, Owen DeLong said:
Removing a few points probably isn't a bad idea so long as you have a list of domains for which points should be added.
140 million .coms. Throw-away domains. I do believe that Marcus Ranum had "trying to enumerate badness" on his list of "Six stupidest security ideas". This won't scale as long as you have more spammers adding new domains faster than your NOC staff can add them to the blacklist.
Yes, getting rid of domain tasting and taking some other steps to bring sanity to the domain name process would really help, IMHO.
(And even centralized blacklists run by dedicated organizations haven't solved the problem yet, so I'm not holding my breath waiting for that to work out...)
Fair enough. It's not a panacea, but, it can be a component of a solution. Owen
it was the backskatter they were referring to, where spamers forge your domain as the source of the email. Thanks John for your comments, -g On Oct 4, 2010, at 12:54 PM, John Adams wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
-j
On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
take care, greg
--On Monday, October 04, 2010 9:54 AM -0700 John Adams <jna@retina.net> wrote:
Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing.
I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter.
FUD most likely, that's the stock in trade for almost all "security audit" firms.
-j
On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
that does not follow at all.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of?
I don't use them. --bill
take care, greg
On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote:
how many of you are using SPF records? Do you have an opinion on their use/non use of?
1. Not using them, and don't have any (observed) problems despite years of closely monitoring mail logs looking for just such issues. 2. Note that they don't stop spam, don't stop forgery, and don't prevent backscatter (aka outscatter). [Similar/related technologies have similar/related problems, so these points aren't really SPF-specific.] 3. As others have pointed out, you can just easily be DoS'd when using them as you could be without. ---Rsk
On 10/4/10 12:47 PM, Greg Whynott wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake..
how many of you are using SPF records? Do you have an opinion on their use/non use of? It is ironic to see recommendations requiring use of SPF due to DoS concerns. SPF is a macro language expanded by recipients that may combine cached DNS information with MailFrom local-parts to synthesize 100 DNS transactions targeting any arbitrary domain unrelated to those seen within any email message. A free >300x DDoS attack while spamming.
SPF permits the use of 10 mechanisms that then require targets to be resolved which introduces a 10x multiplier. The record could end with "+all", where in the end, any message would pass. Since SPF based attacks are unlikely to target email providers, it seems few recommending SPF consider that resolving these records containing active content might also be a problem. -Doug
On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
This is pure unadulterated BS from someone who doesnt understand either DDOS mitigation, or SPF .. or more likely both. -- Suresh Ramasubramanian (ops.lists@gmail.com)
i think it was an observation they made, and suggestions to make things better. I don't think the message was "fix this or you'll be off the air one day.". if they have a 56k port speed(stuck in the 80's), there is potential there for a DoS from a large volume of spam back splatter.. 8) over all, I'm inclined to accept your assumptions. -g On Oct 4, 2010, at 2:38 PM, Suresh Ramasubramanian wrote:
On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
This is pure unadulterated BS from someone who doesnt understand either DDOS mitigation, or SPF .. or more likely both.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
how many of you are using SPF records? Do you have an opinion on their use/non use of?
I use your SPF records (if you offer any) to prevent my servers from slamming your servers with backscatter from someone forging your address and sending me undeliverable email. Without SPF records, you'll receive an undeliverable report for messages "from" you that I can't deliver -- just like the RFC says I "must." Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mon, 4 Oct 2010, Greg Whynott wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
Bullshit.
I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS.
In my experience the presence of SPF records causes more problems than the absence, because it is incompatible with forwarded mail. If you are forced to use it, don't use -all unless that's the entirety of the record.
Do you have an opinion on their use/non use of?
It's easiest to just ignore them. The whole idea was wrong-headed from the start. Use DKIM instead. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On 10/04/2010 11:47 AM, Greg Whynott wrote:
A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record.
We publish a ~all record for our domain. I think it's bad practice to publish any other result because you're making assertions which are almost definitely untrue. +all implies that anywhere on the internet is a valid origination, and -all implies you are certain nothing else could ever send an email on behalf of your domain. The most common situation where another host sends on your domain's behalf is a forwarding MTA, such as NANOG's mailing list. A lot of MTAs will only trust that the final MTA handling the message is a source host. In the case of a mailing list, that's NANOG's server. All previous headers are untrustworthy and could easily be forged. I'd bet few, if any, people have NANOG's servers listed in their SPF, and delivering a -all result in your SPF could easily cause blocked mail for anyone that drops hard failing messages. If you're going to filter using SPFs, I believe best practice is to consider all mail from a +all or neutral record the same as mail that soft or hard fails a ~all or -all record. By filtering, I mean I would simply subject those messages to additional testing, but never block exclusively based upon an SPF result. I would just ignore SPF and that's what I do on MTAs I configure. All you'll really be preventing with SPF is some backscatter and messages which forge the source information for domains that have even bothered to publish accurate records. A huge amount of the spam you get will pass SPF (or return neutral) and possibly pass DKIM as well because the big spam operations register new domains and set up SPF before they start spamming. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867
Am 05.10.2010 um 00:55 schrieb Kevin Stange:
The most common situation where another host sends on your domain's behalf is a forwarding MTA, such as NANOG's mailing list.
Proper mailing lists don't do that (i. e. nanog with Mailman): Return-Path: <nanog-bounces+stb=lassitu.de@nanog.org> -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
On 10/4/10 6:55 PM, Kevin Stange wrote:
The most common situation where another host sends on your domain's behalf is a forwarding MTA, such as NANOG's mailing list. A lot of MTAs will only trust that the final MTA handling the message is a source host. In the case of a mailing list, that's NANOG's server. All previous headers are untrustworthy and could easily be forged. I'd bet few, if any, people have NANOG's servers listed in their SPF, and delivering a -all result in your SPF could easily cause blocked mail for anyone that drops hard failing messages. Kevin,
nanog.org nor mail-abuse.org publish spf or txt records containing spf content. If your MTA expects a message's MailFrom or EHLO be confirmed using spf, then you will not receive this message, refuting "a lot of MTAs ...". This also confuses SPF with Sender-ID. SPF confirms the EHLO and MailFrom, whereas Sender-ID confirms the PRA. However, the PRA selection is flawed since it permits forged headers most consider to be the originator. To prevent Sender-ID from misleading recipients or failing lists such as nanog.org, replicate SPF version 2 records at the same node declaring mfrom. This is required but doubles the DNS payload. :^( Many consider -all to be an ideal, but this reduces delivery integrity. MailFrom local-part tagging or message id techniques can instead reject spoofed bounces without a reduction in delivery integrity. -Doug
participants (15)
-
bmanning＠vacation.karoshi.com -
Douglas Otis -
Greg Whynott -
John Adams -
Kevin Stange -
Michael Loftis -
Michael Thomas -
Nathan Eisenberg -
Owen DeLong -
Rich Kulawiec -
Stefan Bethke -
Suresh Ramasubramanian -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
William Herrin