[BALUG-Admin] So, DMARC. A week ago.

[Rick Moen]

1. New Problem - Whee!

At the beginning of this month, Yahoo (or whatever they're called)
and Google tightened down the screws on requiring DMARC and encouraging
DKIM (and/or SPF).

https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
https://support.google.com/a/answer/81126?visit_id=638429646339446077-2384736010&rd=1
See links for GMail's alleged implementation, which has numerous parts.
The page _claims_ the Feb. 1 enforcement is just for "bulk senders —
those who send more than 5,000 messages to Gmail addresses in one day",
but word around the Net is that they started spamboxing mail from even
_tiny_ mail sending domains not in compliance.


2. Parts of the Problem

(Gods, I hope my MTA uses TLS for transmitting mail.  It's been so long
since I looked at that, I'm not sure.  Anyway, that was a hard
requirement for reaching GMail starting 2023-12-31, per above pages.)

Here, verbatim, are the requirements Gmail says it henceforth requires
of all sending domains (with some others for "bulk senders"):

 o Set up SPF or DKIM email authentication for your domain.

 o Ensure that sending domains or IPs have valid forward and reverse DNS
   records, also referred to as PTR records. Learn more

 o Use a TLS connection for transmitting email. For steps to set up TLS in
   Google Workspace, visit Require a secure connection for email.

 o Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever
   reaching a spam rate of 0.30% or higher. Learn more about spam rates.

 o Format messages according to the Internet Message Format standard (RFC
   5322).

 o Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC
   quarantine enforcement policy, and impersonating Gmail From: headers
   might impact your email delivery.

 o If you regularly forward email, including using mailing lists or inbound
   gateways, add ARC headers to outgoing email. ARC headers indicate the
   message was forwarded and identify you as the forwarder. Mailing list
   senders should also add a List-id: header, which specifies the mailing
   list, to outgoing messages.

(I'm blearily looking up what is meant by "ARC headers", and I have
never previously had cause or interest to look at Google's Postmaster
Tools.)


3. DKIM Considered Harmful

Long rant not indulged here:  DKIM is mailing list-hostile (though
mitigations are possible).  I'm sitting out DKIM mail-signing, but also 
my present host can't do it as equipped anyway.  DMARC is a metastandard
atop either or both of SPF and DKIM.  By the definition of DMARC, if you
have both (a) a valid DMARC DNS record and (b) _either_ DKIM or SPF (or
both), then you are DMARC-compliant.


4. SPF Is My Jedi Master

linuxmafia.com has had bullet-proof, simple SPF for ages.  I like SPF
and consider it well-scoped, well-implemented for preventing others to
believably forge your domain for mail.  It's good here, it works.  Here:

:r! dig -t txt @ns1.linuxmafia.com linuxmafia.com +short
"v=spf1 ip4:96.95.217.99 -all"

Dirt-simple:  It says "If mail arrives from any IP other than
96.95.217.99 purporting to be from linuxmafia.com, please treat it as
forged."


5.  Let's Look at a Good DMARC RR

So, obviously I need a value DMARC record as of a week ago.  A couple 
of years ago, I tried one, and could swear I remember it impairing my 
deliverability of mailing list mail (but can't remember details), not
to mention the avalanche of DMARC "report" mails that are the hallmark
of that botched (IMO) Yahoo anti-forgery metastandard.

But, let's look at the RR for mxtoolbox.com.  The RR is always hostname 
_dmarc , and is a TXT record.  In mxtoolbox.com's case, that's a CNAME
pointing to mxtoolbox.com.hosted.dmarc-report.com .  Here 'tis:

:r! dig -t txt mxtoolbox.com.hosted.dmarc-report.com +short
"v=DMARC1; p=reject; rua=mailto:634990a7@mxtoolbox.dmarc-report.com,mailto:634990a7@mxtoolbox.dmarc-report.net; ruf=mailto:634990a7@forensics.dmarc-report.com; fo=1; pct=100"

Breaking that down:

FQDN:  mxtoolbox.com.hosted.dmarc-report.com.
TTL:  300
class: IN
RR type: TXT   

TXT record breakdown (from within doublequotes):

Version:  v=DMARC1;    
Action to take if the mail fails authentication:  p=reject
Report URIs for Aggregate data to (optional): rua=mailto:634990a7@mxtoolbox.dmarc-report.com,mailto:634990a7@mxtoolbox.dmarc-report.net; 
Report URIs for Forensics/Failure data to (optional): ruf=mailto:634990a7@forensics.dmarc-report.com;
Forensic Options:  fo=1;
Percentage of mail subjected to filtering:  pct=100



6.  Let's build a _dmarc.linuxmafia.com DMARC RR

So, in consultation with the pages mentioned below, I constructed one
(and these were my resulting notes):

Include v=DMARC1;  because DMARCv1 is the only game in town.  Note that
this tag must appear first, or the RR is not a valid DMARC record.

Start policy adoption with p=none; (mostly because of mailing list
forwarding).
https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/

Include sp=none;  This is the "p" policy setting, except as applied to
subdomains.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-sp

Omit aspf=$THING option for now; defaults to "relaxed" SPF alignment
(though I think all mail from linuxmafia.com will originate from that
FQDN as MailFROM and Header From domains).
https://mxtoolbox.com/dmarc/details/dmarc-tags/aspf

Include fo=s;   This generates an SPF failure report if the message
failed SPF evaluation, regardless of its alignment.  This setting is
used to decide what to send to addresses specified in the RUF tag.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-failure-reporting-options

Include rua=mailto:hostmaster@linuxmafia.com;   This says where to send
DMARC Aggregate Feedback reports to.  Be warned that this can be a lot
of... stuff.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-rua

Include ruf=mailto:hostmaster@linuxmafia.com;   This says where to send
failure/forensic reports, which are much more detailed than are DMARC
Aggregate reports.  Only a few mail senders issue those.  Prepare to
revise/lose this if I get swamped with reports.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-ruf

Omit rf=$THING (report format), because there's only one format
(Authentication Failure Reporting Format = AFRF) so far, and it's
default, making this tag so far pointless.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-report-format

Include ri=604800;  report interval (default 86400 = 1 day), so that
reporting sites send me aggregate reports every 7 days rather than
daily.
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-report-interval

Include pct=100;  Means apply the declared policy to mail purporting to
be mine 100% of the time.  Since I'm saying "none" for now, this will
matter really only when I shift to p=quarantine; or p=reject; .
https://mxtoolbox.com/dmarc/details/dmarc-tags/dmarc-percentage


Results in:
_dmarc.linuxmafia.com   300  IN  TXT "v=DMARC1; p=none; sp=none; rua=mailto:hostmaster@linuxmafia.com; ruf=mailto:hostmaster@linuxmafia.com; fo=s; ri=604800; pct=100"



7.  How about Y'all?  What are you guys doing about the problem?