[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nmh-workers] ARC: Forwarding with DMARC, DKIM, and SPF.

From: Ken Hornstein
Subject: Re: [nmh-workers] ARC: Forwarding with DMARC, DKIM, and SPF.
Date: Tue, 05 Feb 2019 12:34:14 -0500

>I think you're right on both counts, and that's what I used to think
>too.  I know SPF, a bit about DKIM, and still less about DMARC, but I
>think DMARC complains because although SPF and DKIM are individually
>happy the headers are not in `alignment': DKIM's are still upstream
>compared to SPF.  Failure can result.

Oh, hm.  Maybe you're right?

Here's my current understanding of the world.

- SPF.  Sender Policy Framework, RFC 7208.  A domain publishes TXT
  records in DNS that lists addresses/names that are valid (or not valid)
  to originate mail from.  The receiving MTA uses these to check
  during a SMTP HELO or MAIL FROM command.  The idea here being that
  if you say your email address is "address@hidden", you have to be connecting
  from one of the addresses that Gmail actually says is a valid originator.
  This is mostly outside the scope of MUAs like nmh, except that if your
  email domain is asserting an SPF record you need to make sure you are
  submitting email one of their servers, so when final delivery happens
  it comes from a host that is listed in the SPF record.  You can use
  a command like "host -t txt pobox.com" to see what an example SPF
  record looks like.

- DKIM.  DomainKeys Identified Mail, RFC 6376.  Basically, you place a
  RSA public key in your DNS and you MTA uses this to sign selected
  header fields; the technica details are complicated but seem
  straightforward.  You can see an example DKIM key in the DNS by using
  the command "host -t txt sasl._domainkey.pobox.com".  This is normally
  out of scope of a MUA like nmh; in the normal course of things MUAs
  don't have access to the domain key, so the MTA does that.  I suppose
  MUAs could validate the DKIM record, but I do not know how common that
  is; I get the impression that it is normally done by a receiving MTA.

- DMARC.  Domain-based Message Authentication, Reporting, and Conformance,
  RFC 7489.  You publish a record in DNS that defines how you want other
  domains to treat mail coming from your domain with respect to SPF and
  DKIM.  The rules get complicated quickly, but it is important to know
  that this is just policy and the inputs are SPF and DKIM (and the
  From: header field).

Where things get "interesting" is §3.1.2 of RFC 7489.  Basically it says
there that a SPF match according to DMARC only counts if the domains match
between the SPF-authenticated MAIL FROM address and the "From" header.
This wouldn't be necessarily true when using dist(1).  It looks like the
default in absense of a specific SPF policy is "relaxed" (sigh, read the
RFC for what that means) and there's not a way of saying "never use SPF".

But .... in reading §6.6.2, it suggests to me that if ANY of the "identifier
alignment" checks pass ("one or more"), then the whole message passes
DMARC.  So, for example, if SPF fails but there is a valid DKIM signature,
then that's ok.  You're allowed multiple DKIM signatures and only one has
to match to consinder it a "pass".

So our hypothetical usage of dist(1), assuming the dist(1)ed message
isn't modified, should still have a valid DKIM signature and be ok?  But
the rules are complicated and maybe I'm mis-reading them.  I could certainly
believe that more aggressive spam rules are being applied and a dist(1)ed
message is failing them.

As a mostly unrelated side note, I see that basically DMARC doesn't
even try to deal with messages that have multiple addresses in the From
header (it mentions them, but says it only works with messages with one
address in the From header).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]