Subject: [dmarc-ietf] Mailing List Digest Considerations

From: Hector Santos <[email-masked]>
Date: Tue, 07 Jul 2020 07:52:44 -0400

Our MLM/MLS has long supported creating a List Digest for various 
list.  Each list created by an admin comes with an option to also 
create a digest for subscribers who may prefer it.

What would be, if any, DKIM, DMARC and ARC consideration when digests 
are created?

A few items comes to mind:

- I don't think preserving the 5322.From is useful because there will 
be many authors in a digest.  There would be only 1 from, the list agent.

- A digest is probably the most modified form of a collection of list 
submissions.

- I believe the MLM may create the digest differently than others.  I 
don't recall a standard method for created a digest.

- Based on my current view for the available list digests, they are on 
the lower side of having subscribers.

Is a List Digest a non-consideration as an MLM output?

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Laura Atkins <[email-masked]>
Date: Tue, 7 Jul 2020 13:08:51 +0100

> On 7 Jul 2020, at 12:52, Hector Santos <hsantos=[email-masked]> wrote:
> 
> Our MLM/MLS has long supported creating a List Digest for various list.  Each list created by an admin comes with an option to also create a digest for subscribers who may prefer it.
> 
> What would be, if any, DKIM, DMARC and ARC consideration when digests are created?

None, really. In the case of a list digest, the MLM is actually the creator of the message. It’s the list that is the 5322.from address and all the associated authentication belongs to the list. The individual digest contributors are part of the body of the message. 

laura

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 07 Jul 2020 14:20:09 +0200

> What would be, if any, DKIM, DMARC and ARC consideration when digests

user posts to maillist should only be ARC sealed

digist post could be dkim signed aswell, since content is dkim breaked 
anyway

but both should still be ARC sealed

then DMARC can test if it passes from original senders

have i missed anything ?

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Jul 2020 09:00:59 -0400

> then DMARC can test if it passes from original senders

Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC.

Another thing that just came to mind is the number of messages in a 
digest.

What if its set to 1?  if possible.  In our MLM, the admin sets this 
amount, not the subscriber.  But I have seen another MLM, forget which 
one, allowing the user to set the digest amount. How would a digest of 
1, if allowed, be different from a normal non-digest submission 
distribution.  I see it as the only form of a MLM output that would 
have not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. 
The list digest agent can do what it wants without any debate.

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 07 Jul 2020 17:18:38 +0200

> Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC.

when i post to dovecot maillist i get DMARC PASS on my own domain, and 
dovecot maillist do only ARC sealing

> Another thing that just came to mind is the number of messages in a 

does not matter

> What if its set to 1?

see above

>  if possible.  In our MLM, the admin sets this
> amount, not the subscriber.

so if users do it it will break dkim mlm digest signing ? :=)

> But I have seen another MLM, forget which
> one,

mlmmj ?, mailman can behave nicely aswell, more or less just unwilling 
admins that turns it into break dkim

> allowing the user to set the digest amount. How would a digest of
> 1,

are digest not sent daily or weekly ?, it have never being on more then 
1 msg

> if allowed, be different from a normal non-digest submission
> distribution.

are how digest is done imho

>  I see it as the only form of a MLM output that would

digest is dkim signed from mlm, thats not the same as mlm forward and 
break dkim original senders dkim signing, thats why its diffrents 
problem to solve

> The list digest agent can do what it wants without any debate.

so can ietf of breaking dkim, but not provide a dkim pass on there own 
problem

---

From: Grant Taylor <[email-masked]>
Date: Tue, 7 Jul 2020 22:43:24 -0600

> Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC.

My issue with ARC is that, as I understand it, receiving systems have to 
choose to trust each ARC signer's assertion signature.  As such, there 
is a massive scalability problem to trust random / individual server 
operators (like myself).

Thus, I'm disinclined to do much with ARC if my ARC assertion signature 
is going to be ignored because I'm not on a trusted list.

> Another thing that just came to mind is the number of messages in a digest.
> 
> distribution.  I see it as the only form of a MLM output that would have 
> not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. The list 
> digest agent can do what it wants without any debate.

Mailman has the ability to ""wrap DMARC protected messages as an RFC 
5322 attachment to thee outgoing message.  This would be the 1-to-1 
relation that I think you are talking about.

Seeing as how the RFC 5322 messages are actually /attachments/ -or- 
synthetic text, there is little, if any, concern about DMARC alignment 
of the outer wrapper message.

IMHO, The outer wrapper message would ideally be DKIM signed and DMARC 
protected.  ;-)

-- 
Grant. . . .
unix || die

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 8 Jul 2020 08:50:21 +0200

On Wed 08/Jul/2020 06:43:24 +0200 Grant Taylor wrote:
> Mailman has the ability to ""wrap DMARC protected messages as an RFC 5322 
> attachment to thee outgoing message.  This would be the 1-to-1 relation that I 
> think you are talking about.

Contemplated as item 1.6, Message_wrapping, in the DMARC mitigation page[*].

Best
Ale
-- 

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail