Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely <[e-mail]>]

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
--