3 ms·

I'm not sure why you say "these things aren't meant to change often". If you rotate your keys, or make tweaks, then they change as often as that happens. Ther

I'm not sure why you say "these things aren't meant to change often". If you rotate your keys, or make tweaks, then they change as often as that happens. There are potential problems of buggy-scripts nuking MX/DKIM/other records (though perhaps the A-record will be used as a fallback, not all clients do that). But "buggy scripts" can take down everything and anything, SMTP is not special in that regard. One of the reasons I love my DNS-hosting/reselling service is because it uses git for revision control. I can happily commit DNS records, revert them, and have them reviewed via pull-requests, etc. I'm not the first person to have done that, but it has been very useful https://dns-api.com/ https://dns-api.com/

walrus01 6y ago
As a side note, if you host your own authoritative nameservers (such as a very basic debian or centos + bind9 setup), you can set up your own self hosted gitlab and oxidized to retrieve the contents of /etc/bind/ on a cron job, put them into git and store them for revision control. https://www.google.com/search?channel=fs&client=ubuntu&q=gitlab+oxidized https://www.google.com/search?channel=fs&client=ubuntu&q=git...
beagle3 6y ago
I'm not familiar enough (or at all) with DKIM internals to know which side is broken, but I had a DKIM verifier extension on Thunderbird, which would verify either against a cached key or the current key. One person who emails me rotates their keys often (weekly or so), and unless I read and verify it a day or two after it is sent, the verifier complains, and there's no way for me to know that the message is authentic. I have to trust my service provider that they did a timely DKIM verification, and I don't want to do that.
- walrus01 6y ago
  In my opinion that's not what DKIM was ever meant to do. Yes a email client can examine dkim headers and do something based on that. But it's much better used as a method for influencing a metric of spam or not spam on your MX smtpd that receives incoming traffic. Not as a guaranteed 100% "this is legit" indicator. It's a thing used to influence a weighting score on my postfix setup. Note that there is not a lot of technical barrier preventing a spammer from setting up a very basic opendkim daemon and key, and using a one time throwaway domain name to spam from, along with the appropriate dkim records in the DNS zonefile. But it's a barrier that not a lot want to jump through.
  - beagle3 6y ago
    Used as you suggest, there’s a good chance a fishing/scam email will go through since it only affects spam score. I’ve had several scam emails, including from @paypal addresses, which did pass my mail service’s filter, but flagged by the DKIM verifier. I want defense in depth; I’m ok with the occasional visible false warning. Rotating DKIM keys often makes it unusable on the mail client. (Not sure that’s a problem with DKIMs intended use, but if keys are rotated slowly enough - e.g. once a month - it’s usable for that too)
    - walrus01 6y ago
      If it came from a fake "paypal.com" address but was not received from the MX for paypal.com, your incoming spam filtering has issues other than DKIM... Something like that would get 5+ extra points added to it by a basic spamassassin setup. With a common setup that is postfix + opendkim as a mail filter on the incoming, that should also get caught. I guess the point I was trying to make is that DKIM was really intended to be deployed on the service-provider side, and smtpd mail filtering side, rather than on the client.
      - beagle3 6y ago
        I agree they did something wrong. But I don’t run my own server - and I do run my own client.... And it’s not the MX that says where mail comes from, it’s the SPF record (if you have one). Google had, for a very long time, an issue where any g-suite/gmail user could SPF as any g-suite domain; so servers that didn’t check DKIM (most until recently, and probably still) would let it through happily.

walrus01 6y ago

As a side note, if you host your own authoritative nameservers (such as a very basic debian or centos + bind9 setup), you can set up your own self hosted gitlab and oxidized to retrieve the contents of /etc/bind/ on a cron job, put them into git and store them for revision control. https://www.google.com/search?channel=fs&client=ubuntu&q=gitlab+oxidized https://www.google.com/search?channel=fs&client=ubuntu&q=git...

beagle3 6y ago

I'm not familiar enough (or at all) with DKIM internals to know which side is broken, but I had a DKIM verifier extension on Thunderbird, which would verify either against a cached key or the current key. One person who emails me rotates their keys often (weekly or so), and unless I read and verify it a day or two after it is sent, the verifier complains, and there's no way for me to know that the message is authentic. I have to trust my service provider that they did a timely DKIM verification, and I don't want to do that.

walrus01 6y ago
In my opinion that's not what DKIM was ever meant to do. Yes a email client can examine dkim headers and do something based on that. But it's much better used as a method for influencing a metric of spam or not spam on your MX smtpd that receives incoming traffic. Not as a guaranteed 100% "this is legit" indicator. It's a thing used to influence a weighting score on my postfix setup. Note that there is not a lot of technical barrier preventing a spammer from setting up a very basic opendkim daemon and key, and using a one time throwaway domain name to spam from, along with the appropriate dkim records in the DNS zonefile. But it's a barrier that not a lot want to jump through.
- beagle3 6y ago
  Used as you suggest, there’s a good chance a fishing/scam email will go through since it only affects spam score. I’ve had several scam emails, including from @paypal addresses, which did pass my mail service’s filter, but flagged by the DKIM verifier. I want defense in depth; I’m ok with the occasional visible false warning. Rotating DKIM keys often makes it unusable on the mail client. (Not sure that’s a problem with DKIMs intended use, but if keys are rotated slowly enough - e.g. once a month - it’s usable for that too)
  - walrus01 6y ago
    If it came from a fake "paypal.com" address but was not received from the MX for paypal.com, your incoming spam filtering has issues other than DKIM... Something like that would get 5+ extra points added to it by a basic spamassassin setup. With a common setup that is postfix + opendkim as a mail filter on the incoming, that should also get caught. I guess the point I was trying to make is that DKIM was really intended to be deployed on the service-provider side, and smtpd mail filtering side, rather than on the client.
    - beagle3 6y ago
      I agree they did something wrong. But I don’t run my own server - and I do run my own client.... And it’s not the MX that says where mail comes from, it’s the SPF record (if you have one). Google had, for a very long time, an issue where any g-suite/gmail user could SPF as any g-suite domain; so servers that didn’t check DKIM (most until recently, and probably still) would let it through happily.