The Dummy’s Guide to DMARC (Pt. 1 of 2)

Who is this for?
If you use a free email service like GMail, Yahoo, Outlook, etc. then this doesn’t apply to you – DMARC configuration only applies to those with their own domain and access to its associated DNS records.

DMARC is something I was first introduced to at my last job and, to be entirely honest, I never quite wrapped my head around the concept. However, a recent personal experience forced me to revisit it and I managed to unlock its secrets!

Honestly, DMARC isn’t really all that complicated. Basically, it’s primarily a reporting protocol that actually monitors two other authentication processes – SPF and DKIM – and then takes the next step by proactively recommending an action based on those results.

The main idea behind all three of these acronyms is to set up your mail server to ensure that bad actors out there are unable to spoof your domain and send spam/phishing messages that appear to come from you.

The easiest way to illustrate this is to briefly explain each of the three acronyms (and their function):

SPF

Sender Policy Framework is a method where a receiving e-mail server will check back with the source domain and confirm that the message was sent through one of a list of “verified SMTP servers.”

SPF isn’t foolproof, as spammers have learned how to tweak message header info to make the receiving server believe that the source IP matches the real SPF record. But it’s a start.

An example of a SPF record added to a domain’s DNS could be:

v=spf1 include:_spf.google.com ~all

Further Reference:

DKIM

Domain Keys Identified Message involves the generation of a key for inclusion in the sending domain’s DNS records. The sending domain then “digitally signs” each message sent – any receiving server will verify this signature with the key of the sending server.

Generating a valid DKIM record for your domain involves digging into your domain provider’s admin console, but a simple example of a DKIM record added to a domain’s DNS could be:

v=DKIM1; k=rsa; p=<uniqueHash>

Further Reference:

DMARC

Domain-based Message Authentication, Reporting and Conformance is a protocol designed to provide you with reporting feedback from receiving servers and to tell those servers what they should do when they receive a message (supposedly) from your domain that fails one or more authentication tests (like SPF or DKIM!).

An example of a DMARC record would be:

v=DMARC1; p=reject; rua=mailto:reporting@foo.com; ruf=mailto:reporting@foo.com;

where “p=” indicates the desired action (options are none, quarantine or reject), “rua=” indicates an email address to send aggregate reports about received messages to and “ruf=” indicates an email address to send forensic reports to.

Further Reference:

Conclusion

Now that we’ve explained the basics, stay tuned for Part Two of “The Dummy’s Guide to DMARC” where we’ll cover how to implement this in your own environment!

Pulling the ripcord on Google Keep

After consolidating my assorted online notes to Google Keep at the very beginning of this year and working with it for all of 2020, I finally decided to concede defeat and accept that I kind of hate it as a tool.

Between the horse-y way it presents your note collection as large, asymmetrical blocks and the fact that the note editor doesn’t provide even basic formatting options, it simply wasn’t doing the trick for me.

So, after deciding to commit to Evernote (I tool that I used to use erratically a number of years back), I set out to figure out how to move all of my Keep notes to it.

While Evernote doesn’t have a direct “import from Google Keep” function built-in, they DO provide basic instructions. And, by ‘basic’ I mean ‘useless.’

A bit of digging reveals that Evernote can import files in .enex (Evernote XML) format so, if you can get your exported notes into that then you’re in business.

Fortunately, some clever bugger has already figured out how to do this specifically for Google Keep exports: Charles Roberto Canato has posted a Python script to GitLab that handles this for you.

The instructions are a little incomplete so, for those of you who might need some extra pointers:

  1. This script will require you to first unzip the file you download from Google Takeout
  2. The version of python bundled with my clean install of macOS 10.11 “Big Sur” didn’t include the parsedatetime module, so run sudo python3 -m pip install parsedatetime to resolve that
  3. I found that the script didn’t produce an .enex file unless you explicitly specify an output file, despite the fact that Step 4a in the script’s README.md file says this is optional

Evernote did an excellent job of importing all of my notes (including the tags I’d assigned them in Keep) so, from there, it’s just a matter of spending some time setting up appropriate notebooks (don’t miss the ability to “stack” notebooks into categories!) and then shuffle your notes around as necessary!

Migrating to G Suite: Fit

Although I’m not a particularly active person, I do use a Wear OS watch (currently a Fossil Gen 5, which I recommend). As a result, that, along with my Pixel 2, are constantly trying to track my activity.

I had configured Wear OS to use my G Suite Basic account and the watch was constantly throwing me authentication errors. I’ve ignored them for a while but finally took a little time to dig into it.

I was originally thinking that G Suite accounts simply didn’t support Google Fit, but it turns out it has to do with G Suite’s device management.

According to this post on the Wear OS community forums…

From Google Admin:

  1. Go to Device Management -> Setup -> Mobile Management and verify that Mobile Management, if enabled, is set to “Basic”
  2.  Go to Device Management -> Password Policies and disable “Requires users to set a password”

This did the trick for me – thank you, ricerocket!