openssl-users: DKIM, DMARC and all that jazz, and what it means to us

[Jakob Bohm]

On 15/02/2019 16:03, Richard Levitte wrote:
> Hi all,
>
> It seem like DMARC, SPF, DKIM, or *something* is tripping us up quite
> a bit.  Earlier this afternoon (that's what it is in Sweden at least),
> us postmasters got a deluge of bounce reports from mailman, basically
> telling us that it got something like this:
>
> <user at example.com>: host aspmx.l.google.com[74.125.140.26] said:
>      550-5.7.1 This message does not have authentication information or fails to
>      pass 550-5.7.1 authentication checks. To best protect our users from spam,
>      the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
>      https://support.google.com/mail/answer/81126#authentication for more 550
>      5.7.1 information. f1si3266960wro.105 - gsmtp (in reply to end of DATA
>      command)
>
> There's very little fact of what actually triggered these bounces, but
> they always come from Google, so we're guessing that they're becoming
> increasingly aggressive in their checks of DKIM, SPF, ARC, who knows
> (they don't seem to check DMARC, 'cause we do have one with p=none and
> an address to sent DMARC reports to, and I'm hearing absolutely
> nothing from Google, but I do hear from others)
>
> So, to mitigate the problem, we've removed all extra decoration of the
> messages, i.e. the list footer that's usually added and the subject
> tag that indicates what list this is (I added the "openssl-users:"
> that you see manually).
>
> So IF you're filtering the messages to get list messages in a
> different folder, based on the subject line, you will unfortunately
> have to change it.  If I may suggest something, it's to look at this:
>
>      List-Id: <openssl-users.openssl.org>
>
> Cheers,
> Richard ( role: postmaster )
>
I have had some fruitless discussion with the mailman authors a while
back.  They seemed to insist that DMARC etc. were bad ideas and that
senders complying were broken and needed half-assed workarounds.

In my own role as postmaster, I see all these systems implementing
variations of the same concepts, that have pretty simply implications
for mailing list software:

1. The global mail system is increasingly implementing checks for
   spoofed source addresses.  List gateways thus need to be
   increasingly conservative in what they send out.

2. If posts contain any kind of digital signature (PGP, S/MIME,
   DKIM etc.), the mailing list software must either preserve the
   validity by not changing anything signed or remove that signature.
    Leaving a now-invalid signature in place makes the post obviously
   bogus to anyone checking, resulting in bounces and lost mail.
    (Optionally, the list gateway may add headers describing the
   validity of those signatures before processing, perhaps even
   rejecting posts with invalid signatures to reduce spam).

3. When sending out the mails, the various from addresses must be
   appropriately authorized, either by being the list gateway itself or
   by satisfying all the known checks for any preserved addresses.

4. As mass senders of mail, mailing list gateways should themselves
   implement all the checkable features in the standards: strict SPF
   records for its own domain, DKIM signatures for any mails with
   the list gateway as source, DMARC records telling recipients to
   discard/reject messages pretending to be from the list without
   satisfying all these checks.

5. The enforcement strictness in DMARC, SPF and DKIM DNS records
   should not be taken as license to violate the requirements.  For
   example an SPF rule of +all should not be treated as permission
   to use the posters domain in envelope-from.
    Frustration with spam may lead recipient systems to enforce
   more strictly than requested by the source domain.

More specific rules:

A. SPF requires the envelope-from (SMTP MAIL FROM) address to always
   be that of the list gateway, even if the posters domain has no SPF
   record.

B. A valid DKIM signature from the posters domain can allow keeping
   the poster as From: address if the DKIM signature is undamaged.

C. Some DKIM signatures allow appending a mailing list footer to the
   end of plaintext mails and adding the mailing list headers to the
   mail, others do not.  In practice this is determined by
   implementation details in the posters mail server (for example,
   most versions of exim don't sign in that permissive way).
    Programmatically this can be determined by directly comparing the
   coverage indicated in the DKIM header to the intended mail
   modifications.

D. DMARC DNS records indicate if a sending domain wants to restrict
   header-From (etc.) pointing to that domain to only be used with
   at least one of DKIM and SPF passing for header-From.  Rule 5
   applies, but so does rule C.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded