Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to
DMARCbis
On 5/1/2023 6:51 AM, Alessandro Vesely wrote:
Been there, done that. For the message I'm replying to, I have:
Authentication-Results: wmail.tana.it;
spf=pass smtp.mailfrom=ietf.org;
dkim=pass reason=&qu
Sent: Monday, May 1, 2023 9:26 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to
> DMARCbis
>
> On 5/1/2023 6:51 AM, Alessandro Vesely wrote:
> >
> > Been there, done that. For the message I'm replying to, I have:
>
On 5/1/2023 6:51 AM, Alessandro Vesely wrote:
Been there, done that. For the message I'm replying to, I have:
Authentication-Results: wmail.tana.it;
spf=pass smtp.mailfrom=ietf.org;
dkim=pass reason="Original-From: transformed" header.d=google.com;
dkim=pass (whitelisted)
Perhaps it should be the other way around.
Addressing the mailing list problem was part of the prior milestone, which
indicates its relative importance. ARC got us past the milestone but does
not provide certainty for the list.operator.
Your concept provides a reliable solution starting from
On Mon 01/May/2023 04:25:17 +0200 Emanuel Schorsch wrote:
I want to ask about the "hollow victory" aspect and what would turn it into a
more meaningful victory. If fromHeader rewriting is the damage we want to avoid
it seems there's two options:
1) Have the mailingList make a decision based on
Yes, I think there is value in recommending a specific rewrite format, and
recommending that the unmodified From be stored in an ORIGINAL-FROM:
header. This solves the user problem, but does not provide feedback to
the list.
About feedback options:
A feedback mechanism could be public or
I want to ask about the "hollow victory" aspect and what would turn it into
a more meaningful victory. If fromHeader rewriting is the damage we want to
avoid it seems there's two options:
1) Have the mailingList make a decision based on what they know about the
evaluator. This would need some
Everything depends on an evaluator who trusts the alternate authentication
protocol. We have at least three trust techniques:
- local policy at evaluator
- ARC set trusted by evaluator
- ATPS trusted by evaluator.
Until the list knows that the evaluator will accept the credentials, he has
to
> On Apr 29, 2023, at 4:42 PM, Douglas Foster
> wrote:
>
> ...
>
> But I need to clarify whether I understand your point. What I am hearing is:
> For the short term, mailing lists should refuse postings from DMARC-enforcing
> domains. That position can be relaxed only if all
