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@xxxxxxxxxxx>: 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
