On Wednesday 29 March 2017 11:12:33 William Herrin wrote:
On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb <daknob.mac@gmail.com> wrote:
Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following:
SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf.
DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS.
When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address.
However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail.
Hello,
Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces@nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists.
This is incomplete. TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except to test that parts of the message haven't been altered. DMARC adds policy to both to check them against the header From:. Mailing list software may not work with DMARC-reject senders (but Nanog does). ---- SPF checks the envelope sender only. Some Microsoft implementations purportedly check the header From:, but they aren't supposed to. Microsoft at one time tried to extend SPF to check the header Sender or From via SPF 2.0, which didn't catch on. Large mail receivers have also extended SPF checks internally in various ways to try to infer whether messages are forged, but that's not really SPF. DKIM doesn't by default check anything except that the headers and body that were signed have not been altered since the signature was added. It definitely has nothing to do with the envelope sender. There was an ADSP extension to DKIM to add policy to the header From: address, but it is superceded by DMARC. DMARC adds sender policy to both mechanisms. For DMARC to pass, either SPF or DKIM must pass and the identifier must be aligned with the header From:. So for DMARC+SPF to pass not only must the message come from a source authorized by the envelope sender domain, but that domain must be the same domain (or parent domain or subdomain) of the header From: address. For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM signing domain must be the same domain (or parent domain or subdomain) of the header From: address. Again, DMARC requires only one or the other mechanism to pass. So messages forwarded intact should be OK if they have an aligned DKIM signature. Mailing lists run by mailing list software usually alter the envelope sender. They can therefore create and pass their own SPF policy. However, if the From: address is preserved, this will not be an aligned message and will not pass DMARC+SPF. And of course if they don't modify the envelope sender, SPF will never pass. Mailing lists often modify either the subject line or message body. This breaks the existing DKIM signature. If they preserve the From: address, they will therefore never pass DMARC because they can't create an aligned signature. To work with DMARC-reject senders, mailing lists should either: a) not alter the existing message headers or body, so that pre-existing signatures can pass (Nanog works fine, for instance, so I doubt the OP on this thread is related). or b) replace the From: address, remove existing DKIM signatures, and add their own DKIM signature or c) reject posts from senders in DMARC-reject domains Other mail forwarders should not alter signed message headers or the message bodies. Microsoft's forwarding in particular tends to break forwarded messages by running them through Exchange internally, which likes to rewrite the message. This often breaks the DKIM signatures.