>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 "[email protected]", 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). --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
