I'm of the opinion that the email client should indicate the presence of DKIM and SPF, then the user can decide what to do with the message. When I suggested this to Claws, I was encouraged to write my own plugin. I did learn Claws has a control-H feature to quickly display the header. Better than nothing I suppose.
As a peon, I end up using web forms for government contact, so I'm not directly effected by this ruling. But if Gmail followed suit, reject would be a defacto standard. I've never set DMARC to reject, so I have no idea if the email is actually rejected in real life. I haven't attempted to get contacts to use DKIM or SPF. My effort is to get contacts to use TLS. I'm still down to one contact that doesn't want to break what is "working." Comcast has some issues with SPF. Sometimes it works, sometimes it doesn't. I haven't managed to get any Comcast customer to contact tech support about this, which to be fair is asking them to complain about some feature they don't understand. Original Message From: m16+post...@monksofcool.net Sent: October 17, 2017 10:37 AM To: postfix-users@postfix.org Subject: Re: PSA: US government to set DMARC to reject On 17.10.17 19:07, Gary wrote: > https://cyber.dhs.gov/ > Binding Operational Directive 18-01 enforces some basic email > security, notably with DMARC set to reject. Interesting choice of words there. DMARC [...] tells a recipient what the domain owner would like done with the message. True so far. The next sentence however is Setting a DMARC policy of “reject” provides the strongest protection against spoofed email, ensuring that unauthenticated messages are rejected at the mail server, even before delivery. "Would like" a message to be rejected of course does not "ensure" this actually happens. That's a bad way to phrase an official US government statement. The recipient alone decides, if he even supports DMARC in the first place. -Ralph
