Hacker News Reader

Comment by teddyh | Hacker News Reader

> Display a banner on any email that doesn’t have a DKIM signature but comes from a domain that’s implemented DKIM (I’ve never seen this, I’m assuming possible?)

IIUC, it’s mostly not possible, because there is no sure way to know if a domain has “implemented DKIM”.

You can, in theory, do a DNS query for “_domainkey.example.com” and see if you get NXDOMAIN or NOERROR; the latter usually¹ means that there are subdomains present, which in turn would imply that there are some DKIM keys present in DNS (although you can’t know what the selector names are). But you don’t know if these keys are active, or if they are meant to be activated later. Or there might be multiple authenticated senders for a domain name, and some might use DKIM signing, but others might not.

1. Not all DNS servers obey the standards correctly, so the NXDOMAIN/NOERROR distinction only mostly works.

View on HN

It is possible for providers who see a statically significant potion of mail traffic to see all or almost all DKIM selectors.

I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.

> It is possible for providers who see a statically significant potion of mail traffic to see all or almost all DKIM selectors.

Yes, but you can’t know that every authenticated sender is using DKIM at all. If the mail you just recieved from a new sender (even if it is from a domain which you have recieved DKIM signed mail from before) passes SPF but is not signed using DKIM, they are quite probably from a valid, albeit rarely used, mail sender who simply does not use DKIM.

> I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.

No, they can’t be saying that, since elsewhere they say that only 105 out of 2 million MailChannel domains are using DKIM. Therefore, they can’t be reasonably suggesting to block all mail from all but 105 of these domains.

You're pointing out the inherent challenge of domain authentication. Large domain owners like Google lock their domains down by publishing restrictive SPF records that do not authorize anyone other than their own IP space. For everyone else, SPF is a gigantic hole that you can drive a truck through.

For this and other reasons, people who actually work in the email industry do not trust SPF when authenticating domains. An SPF pass is necessary but not sufficient to know that someone is responsible for the email you just received. A far more trustworthy element is a valid DKIM signature; this certifies that the domain owner signed the message contents with a key they presumably control themselves.

The logical way to fix this seems to me to be for DMARC to implement some way for the domain to not just require SPF or DKIM, but explicitly require DKIM specifically.

This is how other similar things have solved similar problems, like DANE, CAA DNS records, and HSTS headers in HTTP. CAA records, in particular, long had a similar problem which was only solved with RFC 8657; discussion here: <https://news.ycombinator.com/item?id=34035148>

I thought it already was required and if you specify adkim in your record.

No, my understanding is that the “adkim” tag in DMARC only affects how strictly the DKIM check is done, but not whether a DKIM signature is actually required.

Reply on news.ycombinator.com