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?
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.
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.
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.
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?
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.
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.
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.
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.
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."
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.
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.
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.
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...)
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...
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.
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.