ikiWiki

Tämä sivu on vain luettavissa. Voit katsoa sen lähdekoodia, mutta et muuttaa sitä. Kysy ylläpitäjältä jos pidät tätä estoa virheellisenä.
====== DMARC and SPF considered harmful ======

This page is also visible at http://www.spfconsideredharmful.org 

DMARC and SPF break many long-time common email usage patterns like forwarding and mailing lists. 

Email is valuable because the user is in control, and these methods try to restrict what the user can do and lock-in the user to their ISP email account. 

The value of DMARC and SPF in fighting spam and domain misuse is also very limited and short lived, as the spammers very quickly adapt, so the end result is just to break email for many users without getting much in return. 

Please look at DKIM and better multi-factor email filtering solutions instead.

===== SPF does not protect against spam =====

  * SPF does not protect against SPAM
  * SPF does not even try to do anything against SPAM
  * SPF might accidently block some SPAM, but that is not its purpose
  * SPF is trying to protect your service against spoofing attacks, i.e., someone claiming to be you and sending emails on your name.
  * SPF does not protect you against [[https://en.wikipedia.org/wiki/Internationalized_domain_name#ASCII_spoofing_concerns|internationalized domain name]] look-alike domain phishing or spam

===== Many internet users forward their emails =====

Surprisingly many internet users forward their emails, for example
  * to read all their email from a single mailbox,
  * forward email from old address to current mailbox address,
  * temporarily forward emails to their mobile address while traveling, or 
  * use an email forwarding service as their permanent personal address (e.g. university alumni addresses such as alumni.mit.edu, professional organisations such as acm.org or ieee.org, iki.fi, and many others).

Using the power of email like this is more common for experienced users, thought leaders and high value contacts and customers making it important that you consider the reliability of your email reaching the recipients.

===== "Fixes" that break things =====

There have been many projects that claim to //fix email// which do not take into account the many and varying ways people use email in the real world. The flexibility of the non-centralized email infrastructure is a major reason why email has been and is so successful, and many of these proposed schemes only work for those users who are locked into a single email provider with no flexibility.

Spammers quickly adapt their behaviour to work around any new limitations or filtering methods, so you may end up breaking lots of legitimate email for very little benefit in the end.

Unfortunately the non-centralized email infrastructure does also leave room for spam and other problems. These are pretty well under control using modern filtering tools which use multiple matching criteria to evaluate messages.

===== Using DMARC with "reject" will prevent many people from receiving your emails ===== 

If you set up DMARC with "reject" you're in effect saying you don't want email from you to be delivered reliably. Same is true for dropping incoming messages based on DMARC or SPF alone, you're saying you don't want your users to receive some of their real emails.

===== Using -all SPF causes many people to not receive your emails =====

==== For domain administrators (sending side) ====

Usually the instructions for SPF say you should use the "-all" setting. This is misguided.

Please keep in mind that SPF is not compatible with many traditional ways people use email, e.g. forwarding emails or mailing lists. 

Especially if you use the strict ''-all'' setting, you will experience your own real emails not being delivered to many recipients, as the email arrives via the forwarding email server(s) instead of the original server and thus may not pass a SPF ''-all'' check at the final recipient mailbox. 

The SPF people have a clunky proposed workaround (envelope address rewriting) for some of these issues, but expecting //everyone else on the internet to change to accommodate me// will not happen, so **you should use at most the ''~all'' setting with SPF for your own domain** (SPF ''~all'' means SoftFail, i.e. //accept but mark// instead of reject).

==== For email administrators (receiving side) ====

If you run an email server, you should similarly not block incoming email only based on any single reason, including the "SPF -all" check, but use SPF as one of multiple scoring methods. Otherwise your users will lose real email sent by organisations who have mistakenly configured their SPF with ''-all''.

==== For users receiving emails ====

If you can not receive emails you need because of too tight filtering at your email provider, one solution is to use a email provider who works better, e.g. gmail.com

If you are an iki.fi member, you can configure iki.fi to forward your email to multiple addresses, and add e.g. gmail.com backup email address, where you can look for messages dropped by the misbehaving email provider.
===== Automated emails and SPF =====

  * SPF could be used in cases where you have automated systems sending emails and where users have easy ways of changing those addresses [i.e. not using the email they registered with], as then users can make the address go to some place which do work with SPF.
  * You should never force normal users normal emails to have SPF records, instead make sure your automated emails are sent from different subdomain and that subdomain have proper SPF records. This means that everybody sending from that special subdomain agrees on their emails being blocked when going through email forwarding service.

===== More information =====

More information (in Finnish) at IKI:
  * [[faq:spf]] including instructions for ISPs
  * [[faq:grossdharmaalistaus]]
  * [[faq:spamassassin]]

More information around the internet:
  * http://david.woodhou.se/why-not-spf.html (slightly old)
ikiWiki

Käyttäjän työkalut

Sivuston työkalut

Sivutyökalut
