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?
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!
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.
Follow the RFCs. Don't leave your outgoing server poorly configured.
A number of e-mail servers check for strict adherence of RFCs, which many spambots fail.
Implement DKIM and DMARC, maybe SPF.
If you're using a mailing list, beware on how SFP/DKIM and DMARC can break it.
Don't send unwanted bulk e-mail. Really. DON'T SEND UNWANTED BULK E-MAIL even if you're asking for donations to UNICEF.
Don't let your outgoing e-mail server be used to send unwanted bulk e-mail. Don't leave it as an open relay, don't bounce messages, filter for e-mail outgoing unwanted bulk e-mail.
If you can't sanitize it's output, consider using a different outbound e-mail server for the important stuff.
Don't let your network be used to send unwanted bulk e-mail.
If you can't sanitize your network, place your outgoing e-mail server somewhere else.
Don't place your outgoing e-mail server in a domestic internet access. Most of they are permanently blacklisted.
Beware of your ISP/data center's network.
If they are not active in blocking spammers on their system/network, you can become blacklisted as a collateral damage.
Be specially beware of shared hosts.
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.