Slashdot Mirror
Ask Slashdot: How Useful Are DMARC and DKIM?
whoever57 writes How widely are DKIM and DMARC being implemented? Some time ago, Yahoo implemented strict checks on DKIM before accepting email, breaking many mailing lists. However, Spamassassin actually assigns a positive score (more likely to be spam) to DKIM-signed emails, unless the signer domain matches the from domain. Some email marketing companies don't provide a way for emails to be signed with the sender's domain — instead, using their own domain to sign emails. DMARC doesn't seem to have a delegation mechanism, by which a domain owner could delegate other domains as acceptable signatures for emails their emails. All of these issues suggest that the value of DKIM and DMARC is quite low, both as a mechanism to identify valid emails and as a mechanism to identify spam. In fact, spam is often dkim-signed.
Are Slashdot users who manage email delivery actually using DKIM and DMARC?
I do technical support for an industry leading antispam email appliance. Very, very few of the admins I speak with every day utilize DKIM.
The poster complains that some email marketing (spam) companies don't provide any way to avoid being caught by these anti-spam tools... sounds like a good thing to me...
Your post advocates a
(X ) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(X ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(X ) Requires immediate total cooperation from everybody at once
(X ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(X ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(X ) Armies of worm riddled broadband-connected Windows boxes
(X ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(X ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
(X ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
(X ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
(X ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
(X ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
DMARC would work a lot better if Google for one didn't wrongly try to internally forward as-is *and then bounce* email from DMARC-controlled domains, thus making it impossible for example to get through for many support queries, and causing spurious problems with (say) Google Calendar when the account ID is in a DMARC-controlled domain.
Left hand vs right hand Google? You guys are meant to be smart!
That and randomly chucking email from DMARC-controlled domains in SPAM folders...
Rgds
Damon
http://m.earth.org.uk/
A lot of the mail I get that goes into quarantine or marked as spam comes from outsourced senders, where Domain.com uses some 3rd party to send mail on behalf of it. This can be ISPs, companies like Constantcontact.com or God-only-knows what else. Of course, the company who bought this service probably doesn't know or want to understand what the problem is, and the company that's doing the outsourcing has no real incentive to make sure their hosts (including SPF, etc) are configured properly.
Are there any guides out there describing how to send e-mail *reliably* these days?
Seems that the RFCs don't cut it anymore, since there are so many undocumented rules that large e-mail providers (gmail, etc.) use.
If you'd go by the RFSs alone, your e-mail just ends up in a spam-filter (at best) most of the time.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
I send bulk email for an opt-in list with mailman (opt in as in you have to walk in the store and physically write your email on our sign up sheet).
We have Google host the email for the business and use self hosted for the important stuff.
To get SPF and DKIM working for the business I determined that I could not do this through google. The bounces get redirected to the wrong place and the sender auth fails. I needed bounces to come to me, not Google, so mailman could do the bounce processing. So I had to set up a separate self hosted mail machine with a separate domain, so that the sending domain could match the sender and the bounces could come back to the same place and get bounce processed.
Email sucks and SPF, SKIM and probably DMARC suck.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Default scores in SpamAssassin have been assigned based on tests against a large corpus of both emails to obtain a statistical likelihood that a given email will be spam or not for ages, so I take the positive score (more likely to be spam) as a pretty solid indication that its use doesn't provide a good indicator of legitimate mail. Ironically, the biggest culprit for that is probably one of DKIM's biggest proponents, the sheer volume of spam from compromised Yahoo accounts and signed by Yahoo's outbound mail relays is largely responsible for that positive score in my experience - if only they'd do better spam filtering of their outbound email... Not that they are the only ESP with that failing, of course.
UNIX? They're not even circumcised! Savages!
All of the work-arounds for mailing lists are broken in one way or another. Often so much so, that it breaks the overall usability of the mailing list in quite subtle and annoying ways.
All mailing lists that I am subscribed to have taken the more expedient option of banning Yahoo users from subscribing to their lists. This has the nice side-effect that it makes users switch to a more modern e-mail provider in the process. After everything was said and done, most users were actually quite thankful for this...
I think, Yahoo would have been smart to wait with the switch until after they worked on getting OAR to work. But that would actually require putting some work into this project; and as of lately, I am not sure Yahoo is really clear on which technologies they still want to seriously invest into, as opposed to putting everything into extended maintenance mode.
What they mention is not a list of solutions, but a list of silly work-arounds, which break well-established semantics of e-mail headers. Falsifying information about the author of the message (that is, the From header) for the sole sake of making the message compatible with DKIM is broken.
Why the mailing lists broke... They didn't follow RFC 2476 with regard to RFC2822 headers and what can and can not be rewritten, and then they failed to sign the messages with their own mail server signatures.
If you are going to send messages, the policies and protocols force you to take responsibility for the fact that you've sent them, and if you're unwilling to do that, then you don't get to send mail to people who don't like you not taking responsibility.
Too bad, so sad, fix your configuration or you lose.
Former technical support rep for an email marketing company, here.
You only need DKIM if you send a massive amount of mail to users at Yahoo or Microsoft (outlook.com, hotmail) domains.
The purpose of DKIM is to verify the mail you're sending is actually coming from your domain and not someone who is spoofing your domain.
Nobody cares about DMARK.
Yahoo and Microsoft throttle email based on whether or not your domain has proper DKIM keys setup.
If you don't have them set up you can only spam about a thousand messages before you get blocked.
However if you set up DKIM you can spam Yahoo and Microsoft mail (hotmail, outlook.com, etc) users all day long and those mail providers will turn a blind eye.
Basically, there are two sides to implementing SPF and DKIM:
- Outgoing mail: yes, it's probably a good idea to set up SPF and DKIM on your outgoing mail-servers and DNS. You'll less likely end up in the "junk" folder of Hotmail or GMail. Setting up SPF and DKIM is actually not as hard as some people seem to think. There are enough free services on the Internet that will check if your config is correct. While you are at it, make sure your mailserver is configured to use the STARTTLS SMTP command. Most spammers don't use TLS over SMTP, so it's a little extra that can give you an advantage in anti-spam filters.
- Incoming mail: this is where most of the problems arise. There are a lot of mail servers out there that don't implement it, or don't implement correctly. For my personal mail setup (which runs on PostFix), I decided to implement them as they should be (SPF softfail/hardfail according to sender DNS records etc...). If you run a business, this might result in loss of business mail, so might want to ignore SPF and DKIM
TL;DR: Configure it for your outgoing email, ignore it for incoming mail. ("Be Strict with Yourself and Lenient Towards Others" - Fan Chunren )
...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
I have DKIM and SPF in place for a domain that needs to send out important emails. It is not that difficult to get in place (assuming you're already comfortable with DNS, SMTP, Public/Private key encryption and debugging email problems). Setting up OpenDKIM alongside a PostFix install is straight-forward. And you don't need to buy a Certificate from a CA to get it working for the public.
Google checks both the SPF and DKIM when receiving mail, and you can see the results their servers come up with in the header of the received mail. Your message will also display "signed-by: [domain.tld]" in the header details popup.
I have never seen or gotten reports of emails that pass both DKIM and SPF checks going into Google's "spam" folder or otherwise being delayed/redirected.
In short, I find it very useful to help assure my customers that data will be kept flowing properly, to the best of my ability anyway. Haven't looked into DMARC much.
These mechanisms are only valid for "transactional" business email, where business correspondents need the email credibly labelled by the sending company. It's OK for stuff where you establish who to talk to by mail, telephone or wild-ass-guess, and make deals based on that lebel of security.
It's utterly inappropriate for mailing lists, remailers, discussion groups or material gatewayted between email and usenet or web services. The workaround are lies, told to convince the anti-spam functions of DKIM et all to let it through.
About a week after DKIM broke all the IETF and ISOC lists, the spammers were signing their spam so as to be deliverable once more. I was on the ISOC list at the time, and some unkind words got said about Yahoos.
davecb@spamcop.net
p=reject is a extremely strict check: if it doesn't pass, the email service drops it. It is only for transactional business mail, and should never be applied to mailing-list mail. Ask the IETF authors.
Yahoo, AOL and friends were under severe pressure to "do something, anything". They did do something, it's just that ...
A week or so later the spam had proper signatures.
davecb@spamcop.net
I implemented the strictest controls possible for a site that was being heavily phished and it worked very well. Here's the things you have to understand about DMARC, DKIM, and SPF (since SPF matters to DMARC too).
As a basic overview, here's what these do.
SPF = Only allow emails from specific domains / ip addresses
DKIM = When an email arrives, verify the signature with the domain it claims to be from to ensure it actually came from there
DMARC = How strict should we be with SPF and DKIM?
DMARC in itself isn't an actual verification system. What DMARC does is allows you to tell mail servers exactly how to handle emails that do not pass SPF and/or DKIM checks. Without DMARC, mail servers have to guess and basically follow their own rules. If you've taken the time to document where email from a particular domain comes from (including 3rd party services), ensured that your SPF includes everything, and have verified that all emails are signed with DKIM then eventually you can be strict enough with your DMARC settings to say that anything not passing both SPF and DKIM can simply be trashed. That's what the strictest setting looks like. You can also tell mail servers to send it to the spam folder, just in case you missed something. You can tell it to treat SPF strictly and ignore DKIM or vice versa. You can tell it to apply your DMARC rules to a percentage of your emails (to make it easier to transition into to using it with a small group of messages). You can also have providers send you an XML based email of the days activity to see how messages were handled from different services and where those messages originated. The reports can be a pain to make sense of but once you have everything setup properly you tend to stop looking at them.
It's important to remember, because SPF if easier to implement since it's just a DNS rule. For DKIM you have to actually sign the email before it's sent which may or may not be possible from all of your various points of email origin. DKIM is better, but that makes it more complicated. And that's why you have to have something like DMARC so that you can tell mail servers just how thoroughly those rules have been implemented.
The site that I implemented it for was a very old site where people managed high dollar transactions over email. Phishing was RAMPANT but even more so because there was a good chance a phisher could pass off an email as actually coming from our domain. The combination of 3 protocols in strict mode stopped that completely. It didn't stop PHISHING, but it did secure our domain against it. After that phishers had to use other domains, leaving off a middle letter, trying spelling variations, etc. This gave us the ability to work with registrars to either buy the domains or report the domains for abuse.
As an early poster said, you can't completely stop phishing but there are preventative measures you can take to protect compromised accounts.
After that we took additional steps to secure users accounts. We started recording ip addresses with all logins or return visits along with geographic data from MaxMind. Once we had enough sample data to create a general point of origin, we started locking accounts if they were accessed more than 200 miles from their normal center point and always if they logged in from a different country. As soon as the account was locked for a geographic reason, we sent users an email notifying them that their account had been accessed from another country or outside of their area and that if this lock was in error, they could click a link to disable that function for 2 weeks while they were traveling. Otherwise they should change their password. Users really appreciated it. We expected some usability frustration, but overall these users were very happy to know we were watching out for them.
People also tried to create fake accounts on the system to initiate transactions. For that, we took a page out of Fark's playbook. On Fark, when you get blocked / banned you don't KNOW you've been banned.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
DKIM, SPF and DMARC are in reality not very wide implemented, but the thing is many biggies in the tech scene implemented them, so that millions of mail adresses are now being affected by them. The thing is, anyone can sign his emails with DKIM. This only tells that he's able to do it, it doesn't tell anything about if it is Spam or not. In fact, many spammers were the first to sigh their mails with it. DKIM is only a mechanism to make sure the sending domain is not being forged, nothing more, nothing less. DKIM alone is harmless. You can tell your milter what to do with such mails, if you want to. The next thing is SPF or Sender Policy Framework. This in short allows administrators to setup an IP or bunch of hosts as official mail exchanges, so that you can tell your MTA to discard mails which do not originate in such stuff. Problem is, for example, web based recommendation formulars, in which you enter your mail adress - broken. Using other MTAs on the road - broken. Forwarding/bouncing mails - might also be broken. DMARC then is the top of the former two, because the reason of this standard is the ability to provide a policy what other MTAs should do if either a) DKIM or b) SPF or both do fail at the same time. DMARC is not a way to get less spam, it is only a way to be able to reduce the abuse of your own domain with spam. And it does break quite much legitimate use cases of email, so it is a bad idea.
That's not the case at all.
DKIM allows mail providers to detect that a message was tampered with in transmit, and DMARC tells mail providers to trash tampered messages.
Therefore, a mailing list has several options.
Option one is: don't tamper with the signed data in transit. This is very easy. It means not doing things like editing the subject line or adding signatures to the end of mails, but any good email client can auto label or filter mailing list messages anyway, so this is not a big deal.
Option two is: tamper with it, but resign under your own sending identity. This means the From header will be "wrong", but not really, because the message isn't really "from" the sender at this point. It would be more accurate to say the message resembles one sent by the original sender, but really, from a security POV, the mailing list could have done anything.
I prefer option one, myself, but either works.