On 2020-08-09 6:54 p.m., Tõnu Tammer wrote:
DMARC relies on SPF and DKIM. The latter is particularly important for
the mailing lists to ensure that DMARC works. And when I read the cases
it is clear that the issue is not of DMARC but of DKIM.
Indeed, one of the proposed workarounds, Recognized Transformations of
Messages, addresses DKIM verification algorithm. Yet, it is being
discussed on this list rather than ietf-dkim. I hope it becomes a WG
draft soon.
RFC for DKIM says very clearly in the introductory part that and I
quote "Message transit from author to recipient is through relays
that typically make no substantive change to the message content
and thus preserve the DKIM signature." If this is not the case, the
relay is actually violating DKIM standard.
As Dave said, MLMs may need to carry out some transformations while
usual relays don't —except those which add **SPAM** subject tags or
antivirus footers.
The l= tag is one of the early envisaged provisions to address footer
additions. It was deprecated because of the possibility to add
malicious footers. Of course, adding a footer /is/ a substantive change.
However tight we define recognized transformations, they have to allow
the addition of a few lines and a URL. Hence, they can be malicious.
Therefore, we need to differentiate two classes of domain owners,
those who can afford such risk and those who want top strictness.
The lists we manage, we have made sure they follow the RFC and there is
no issue of DKIM preservation.
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Turn_off_all_message_modifications
Some lists, however, have taken a different approach and to make
sure we have delivery there also, we've looked at the elements
which are used for DKIM calculation. We realise that not including
the content into hash calculation can have a drawback but given
that non-DKIM compliant lists do with content what they wish
anyway, it's not much of a drawback. At the same time, prevention
against spoofing and misuse is retained, which is the key for
DMARC.
That only works if you trust the MLM. We cannot rely on trust,
because there is no widespread common reputation system. DMARC does
provide for "trusted_forwarder" and "mailing_list" policy override types:
However, before this action is taken, the Mail Receiver can consult
external information to override the Domain Owner's policy. For
example, if the Mail Receiver knows that this particular email came
from a known and trusted forwarder (that happens to break both SPF
and DKIM), then the Mail Receiver may choose to ignore the Domain
Owner's policy.
However, that kind of hush hush is not deterministic, since the
protocol does not define the "external information". Providing for a
URL pointing to such external source might help.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
