On 11 January 2018 at 03:24, li...@lazygranch.com <li...@lazygranch.com> wrote: > On Wed, 10 Jan 2018 21:59:26 -0500 >> On 1/10/2018 9:53 PM, li...@lazygranch.com wrote:
> I help with a few people I know that set up their own email to pass > SPF and DKIM, but realistically no major corporation is going to give a > sample of fecal matter to my opinion, presuming I could ever find the > person in charge. > > Google is of the opinion that all you need is DKIM. Seems to me they > are correct, but we have to work with whatever the sysop wants to > implement. (Google provides SPF for their cloud servers as a means to > get the IP space. I see hacking from that space of course, so the list > comes in handy for blocking.) > > Maybe there is a way to check DKIM first, then skip the SPF check. The > number of servers that only do SPF but not DKIM is small. I have one > contact whose email employs neither SPF or DKIM. That is plus.net. In > the spirit of making the world a better place, I will contact them and > see how far I get. > Why reinvent the wheel? As Scott has said, this is what DMARC is for. Google follows DMARC (although it doesn't implement it for outgoing mails). DMARC allows senders to specify what receivers should do with emails that purport to be from their domain (looking, critically, at the 'From:' header) and which fail SPF *and* DKIM. openDMARC uses headers added by openDKIM and can also look at headers added by a local SPF checker (or perform its own SPF checking). A perfect DKIM implementation of email for a domain makes SPF redundant but (a) having an SPF record may improve 'reputation' and (b) a few servers may (very unwisely IMO) reject emails based purely on SPF. But IMO both DKIM and SPF are useless in practice without alignment, because they test against (envelope) parameters which aren't seen by most recipients. I guess what you are suggesting is openDMARC with an aggressive 'policy override', where a presumed DMARC 'quarantine' (or if you prefer 'reject') policy is implemented for all incoming emails that have a DKIM header or which have a connected SPF policy, even if sender's DNS has not specified such a policy in their DMARC DNS entry or lacks a DMARC policy. On top of this you might need to whitelist emails from mailing lists, which create problems for DMARC (or vice-versa, depending on your point of view). This would require patching openDMARC. An alternative if you use Thunderbird is to get the 'DKIM Verifier' add-on, this uses a background colo(u)r on the 'From:' header to indicate DKIM pass/fail and, critically, alignment. Pretty cool.
