Risky Business #225 -- Will DMARC actually help anyone?
Fri, 02/10/2012 - 15:49
Topic Source:
On this week's show we're taking a look at the DMARC anti-phishing effort. we mentioned it on the news last week, but we're going to get into it properly with our good buddy Paul Ducklin. He's along after the news.
This week's show is sponsored by Tenable Network Security.
Tenable's chief executive Ron Gula will be along in this week's sponsor interview to chat about the theft of Symantec's source code. He doesn't think it's a world ender, and you know what, he's probably right! He's along after this week's feature interview.
Mon, 02/20/2012 - 23:04
#2
Apple allows 17.0.0.0 because they own it.
Along with other entities that own large blocks of v4 space:
Solve the IPv4 exhaustion problem - take back these addresses.
3 General Electric
4 BBN Planet
6 Army Information Systems Center
8 BBN (corporate)
9 IBM
11 DoD Intel Information Systems
12 AT&T
13 Xerox PARC
14 Public Data Network
15 HP
16 DEC
17 Apple
18 MIT
19 Ford
20 Computer Sciences Corporation
21 DDN-RVN
22 Defense Information Systems Agency
25 Royal Signals and Radar Establishment
26 Defense Information Systems Agency
28 ARPA DSI JPO
29 Defense Information Systems Agency
30 Defense Information Systems Agency
32 Norsk Informasjonsteknologi
33 DLA Systems Automation Center
34 Halliburton Co.
35 Merit Network Inc.
36 Stanford
38 PSI
40 Eli Lilly and Co.
43 Japan Inet
44 Amateur Radio Digital Communications
45 Interop Show Network
47 Bell-Northern Research
48 Prudential
49 Joint Tactical Command, Control and Communications Agency
51 Department of Social Security of UK
52 Du Pont
53 cap debis ccs
54 Merck
55 Army National Guard Bureau
56 U.S. Postal Service
57 Societe Internationale de Telecommunications Aeronautiques
61 Asia Pacific Network Information Center
62 European Regional Internet Registry/RIPE NCC
63 InterNIC
Tue, 02/21/2012 - 09:52
#3
We mentioned this in 226, but
We mentioned this in 226, but thanks for the list! Some surprises there.
Mon, 02/27/2012 - 10:00
#4
Solve IPv4 exhaustion? 'Fraid not.
This very point was raised on an IPv6 course I went on last year, and the (very knowledgeable) instructor said that it would buy far less time than you might think - not even a few years. And I have worked with one Class A owner which has a very large number of hosts on their Class A network. Clients can be changed easily enough by simply changing the DHCP scope, but to change all their servers and network devices onto an RFC1918 network would cost millions and would be a logistical nightmare.
Mon, 03/05/2012 - 11:01
#5
Please stop the fucking
Please stop the fucking beeping!
Mon, 03/05/2012 - 12:40
#6
I can't... many listeners put
I can't... many listeners put the show on speakers when their kids are about. If I stop the beeping, they can't listen.
It's a necessity, I'm afraid.
Listener Hans du Plooy wrote the following in an e-mail he sent me via the Risky.Biz contact form. I am posting it here with permission:
The real reason I'm writing is Paul Ducklin's comments on SPF. He slipped up on a few very crucial details, and I want to set the record straight. First: SPF is *not* an anti-spam technology. It does not try to address the spam problem, and fails hopelessly where it's applied in this fashion. SPF (and DKIM) are anti-forgery tools. Nothing more.
That said, it is true that SPF can help reduce spam, but only because spammers like to forge sender addresses. The rationale is that if your server bounces the mail (bad practise) the spammy stuff gets a second change of being delivered to some unlucky hotmail user. But we're now starting to see the tables turning. Spammers are setting up domains with SPF records and signing their mails with DKIM to take advantage of spam filters' inherent trust of mail that is properly authenticated in this fashion.
Both technologies fall down in one point: the From: address that your mail client displays is part of the data portion of mail and bears no relation to the envelope sender (usually shows up as the Return-path header), the latter being considered for validating SPF and key signing. So, spammer registers some funky domain, gives it valid SPF records, signs his mail, and Joe Average doesn't know the difference because the From field still says bob@hotmail.com
The second issue with Paul's comments is his pointing out that Hotmail/Gmail/Yahoo et al use the tilde or doesn't use SPF at all. The reason for this is that SPF is inherently flawed but almost every spam filter in the world requires SPF records to be present, so they *have* to have them.
The problem is that 3rd party mail scanning services break SFP. Mail forwarding breaks it. There are two common places this happens. Many people forward one address to another for whatever reason. Also, may companies who host their own mail but doesn't want to deal with antivirus/spam scanning use 3rd parties like Postini or App River. If their mail gateways then check SPF, every mail from a domain that has SPF records will fail, because it's not possible for the sender domain to know where the mail might end up being forwarded. This is one of the reasons domainskeys (and DKIM, it's successor) came along. Mail can be forwarded a million times, as long as the signature still matches the body.
A urther problem is that there isn't any clear definition of what a recipient server is expected to do with a mail that fails SPF validation. There are four operatiors:
+all - accept mail from any server
-all - hard fail, i.e. no servers except the ones listed, reject mail otherwise
~all - soft fail, i.e. defer mail if it's from a server not listed (good for testing, DKIM has a similar option)
?all - I'm doing this for compliance, but don't care.
But every single piece of software I've worked with that does SPF checking, calls it "spam protection" and gives you the choice of how it should respond to each of the above. And every one comes with different defaults and every clueless sysadmin changes them to something else. So you can see why the big mail providers don't publish strict SPF records.
SPF causes so much problems for mail system admins that mentioning it will get you banned on the Postfix mailing list (a very friendly list, in general).
What concerns me most about DMARK is that SPF is included in the mix. That is a shitty idea, if I've ever seen one. It would have been pretty nice if it was DKIM plus the reporting stuff.
I hope this helps shed some light on the issue of SPF. I tremendously enjoy the podcast - thank you and keep it up! If you ever come to London, I'll buy you a beer.