Re: [dmarc-ietf] Gaining Legitimacy
Replying to something almost two weeks old, apologies: On Tue, Apr 18, 2023 at 7:10 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > When John says that list members plead their case, but their pleas are > dismissed unsympathetically, it is evidence that mailing lists have a > legitimacy problem. As with many social issues, there are extremes: AOL > has unmoveably chosen security over list access. The EDU community has > chosen list access over perceived security benefits. In the middle are > people who might be convinced, but need convincing. These are the people > that should be the focus of effort by mailing list advocates. > The first sentence here contains a presumption that mailing lists are under some obligation to prove their legitimacy. This perhaps underscores the chasm between the two perspectives. > As an administrator of a business email system, I find myself in that > middle ground. So here are the areas where I would like to be convinced: > >1. Why is it necessary for mailing lists, in general, to modify >content? RFC 7960 needed a companion document on this topic, When I >read 7960, I was unmoved because my thought was, "Intermediaries should not >be modifying content in the first place."There must be others who have >the same response. I doubt that RFC 7960 changed any attitudes, because >it never addressed the "why" behind the problem. > > Because consumers of mailing lists expect them to. Users like the Subject tags and the footers and the MIME rewriting and the whatever-else mutations subscribers have come to rely on for (it is not an exaggeration when I say) decades. They have developed automations around them (sorting, filtering, etc.). These features have evolved over many years and are now pretty typical, to the point where a list that doesn't do those things would be an outlier. The mutations have not been standardized, however, probably because nobody has ever felt a need to do so, and some are probably specific to particular implementations. And there's little need to specify them openly; they are all just text and MIME mutations that are fully compatible with whatever transport and storage are applied and the display software that ultimately consumes them. I feel compelled to repeat the same refrain you've heard before: Mailing lists have been around for a long time, and none of this mattered. DKIM appeared early this century, and suddenly there was a problem. Paragraph renumbering is automatic, sorry... > >1. Even if I become convinced, in concept, that SOME mailing lists >need to make SOME content changes, I would not conclude that ANY mailing >list must be allowed to make ANY change, without limit. Before embracing >a particular list, I would want to know the particulars of what changes >that list makes, and why those changes are necessary to the success of that >list. Isn't that reasonable? Are there any industry norms for this type >of disclosure?If not, why not? If there are norms, why am I unable to >find such information for this list? For this forum, I don't know what >attachments are allowed, whether posts are subject to malware scanning, >whether TinyURLs and their equivalents are allowed, or anything else >related to participation security. I just checked the link at the bottom >of every message, and it contained nothing about these topics. > > I don't think anyone is arguing that absolutely any change is allowed, or should be. There's a relatively small number of mutations that are common. We could probably write them all down; in fact, I think back far enough in this list's archive, I took a run at doing so. But they are in some cases hard to describe, and they can be applied in varying combinations. And since we're talking about DKIM, two implementations that differ by a byte produce different results. Note that this is squarely the problem that the DKIM transforms drafts were trying to address. I think this is probably the first time that there has been a demand made that a subscriber should know a priori how messages to that list might be mutated before distribution. There are no industry norms of this type of which I am aware, probably for the same reason I gave above. If such standards came into existence today, what would we expect people to do with them? What would you do with them? What could we hope automated systems could do with them? > >1. Assuming that the first two objections are overcome, the last one >remains critical. Acceptance of broken signatures will mean that I >delegate responsibility for sender authentication from myself to the list >server. Can the list under discussion be trusted to ensure that both >MailFrom and From are free of deception? Given my assumption that we are >talking about closed lists, this should be feasible.Ale's abuse >demonstration was
[dmarc-ietf] Third party signatures
Some thoughts about the third party signature discussion that happened over the last couple of weeks while I was away: I wrote ATPS as an experiment in 2012. At the time we were still finishing DKIM (RFC 6376 was only five months earlier), and still talking about whether a third party signing solution was even possible. Doug Otis had a similar "TPA" draft out at the time, but neither of us were getting any traction from the working group. The community was quite dubious that the general idea could work, and TPA had a lot of complexity to it that I thought we could do without (or, at least, if we did need it, we could add it in later). Since I had an open source platform to play with, I decided to implement something, include it in the platform, ship it, and see what happens. I managed to get an AD to sponsor what became RFC 6541 to encourage other implementations to try it. In the years that followed, I think I only ever saw one consumer of that platform, other than me, enable the ATPS feature and try it out. I know of only Hector's code as another implementation. There have been claims that it was not "marketed" well, but I never saw any of this as something in need of marketing. If it's a feature people needed, they would ask for it and turn it on, and we would hear that it solved a problem. It wasn't hard to configure. To me, that doesn't say we did a poor job of "marketing" it, but more that a path to its success wasn't clear in the contexts where we really needed it. There are two main reasons I can see for this, as both an implementer and a consumer of this stuff, when it comes to mailing lists and the DMARC problem: (1) Scale. For mailing lists, ATPS only works if you list in your DNS all other domains that run lists to which your users subscribe. If you have a handful of users, you might be able to work this out. If you have a GMail number of users, you now have giant problems of user support and keeping that list current: "You mean I have to register every domain where I join a list? This sucks!" "I forgot to de-register a domain years ago, sorry. (And now that domain is still an authorized third party.)" "I typed the domain name wrong, how come it doesn't work?" "Why can't you auto-detect all of this?" (2) Security. ATPS doesn't specify what stuff the third party will generate as you. That third party now, practically, has one of your signing keys. Suppose you decide you trust the domain owner; do you trust the list? If you declare through ATPS that you trust ietf.org, and the list server here doesn't validate mail at ingress, then I can send unauthenticated mail through the list as you and it'll be as valid as if you signed it yourself. That might be OK for a marketing partner you're paying, but it's not awesome for free mailing lists. So I don't think it really helps us here, at least not in its current form. Unless I've misunderstood the proposal, amending ATPS to be a per-user thing only trades some of the second problem for more of the first problem. And I think the conditional signatures ideas suffer from the same two issues I identified above. I also have a vague inkling that we shouldn't be talking about ATPS in a DMARC document because that's a layering violation, in the sense that DMARC is built atop DKIM and SPF, and ATPS augments DKIM. We might get away with saying something like "You ought to consider things that make DKIM more list-tolerant", but forcing people to undertake all the DNS and user work that ATPS entails drags a lot of stuff into DMARC that we probably don't want. Personally, I think the DKIM transforms drafts stand a better chance of success. They need implementation and integration with a willing MLM, and some experimental deployments, to see for sure. The notion of DKIM transforms is also a long shot because of the complexity with which lists modify messages. This is not me saying we should pivot to work on these other things, at least not right now. I'm just skeptical that ATPS as defined can solve our problem. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
Alex,
I agree with a suggestion to have a separate document, a great
starting point is to update the ATPS RFC document. However, DMARCbis
MUST open up the door for it and address the potential new security
issues with From Rewrite.
1) Address the MUST NOT p=reject with a new small section, a few
paragraphs citing the basic non-compliance issues with legacy MLS/MLM
verifiers of not following DMARC policy and instead creating a new
potential security threat which may required a security threat section
or add it to the current "Display Attack" security section. I don't
believe we can get by this by saying it will "never happen."
2) Update section 4.4.3 Extended Tag Extensions to update the door up
to 3rd party authorization, ATPS and possibly others.
Thanks
--
HLS
On 5/1/2023 9:49 AM, Brotman, Alex wrote:
This sounds like a separate document to me. (yes, I see Ale's draft below) And
IMO, I don't think we should hold up DMARCbis for that work.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
-Original Message-
From: dmarc On Behalf Of Hector Santos
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:
Authentication-Results: wmail.tana.it;
spf=pass smtp.mailfrom=ietf.org;
dkim=pass reason="Original-From: transformed" header.d=google.com;
dkim=pass (whitelisted) header.d=ietf.org
header.b=jAsjjtsp (ietf1);
dkim=fail (signature verification failed, whitelisted)
header.d=ietf.org
header.b=QuwLQGvz (ietf1)
However, not all signatures can be verified. Mailman tries and
preserve most header fields, but not all. For example, they rewrite
MIME-Version: from scratch and don't save the old one. So if a poster
signs that field and writes it differently (e.g. with a
comment) MLM transformation cannot be undone.
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
t-vesely-dmarc-mlm-transform__;!!CQl3mcHX2A!DfPhD9QIFk5QZaU-
JPkz748sZC
QtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZaB5XtMgrS
WZ9HPP
m2s$
And this was my result for your message, separating lines for easier
reading:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);
dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
adsp=dkim-fail author.d=tana.it signer.d=;
dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized signer);
dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta
header.i=tana.it;
adsp=dkim-fail author.d=tana.it signer.d=tana.it;
dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it
(originating signer);
Four signatures were added to your submission and the only one that counts is
the top one, the last one added.
It failed DMARC because tana.it did not authorized ietf.org. You can
easily resolve this by adding atps=y to your DMARC record:
v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it;
ruf=mailto:dmarcf...@tana.it;
and add an ATPS sub-domain record authorizing ietf.org in your dana.it
zone:
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;")
Do that and all ATPS compliant verifiers should show a DMARC=pass:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);
For a short list of signers, I updated my DMARC evaluator to also support ASL
"Authorized Signer List" to avoid the extra ATPS record.
So doing this will work across my evaluator for smaller scale mail senders
v=DMARC1; p=none; atps=y; asl=ietf.org; rua=mailto:dmarca...@tana.it;
ruf=mailto:dmarcf...@tana.it;
This will skip atps=y because asl=ietf.org was satisfied. It was show
how it was authorized:
dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);
Any ATPS or ASL idea will give us the author-defined trust of ietf.org
as a 3rd party signer.
That said, keeping with the suggestion DMARCBis should add MLS/MLM
semantics, I believe when the Receiver is receiving mail for a
MLS/MLM, it should have the following updated modern consideration
for a MLS/MLM:
1) It should honor policy first, by check for restrictive domains
2) It should honor the domain restrictive policy to avoid creating new
security problems and avoid delivery problems. This means to
implement s
Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
This sounds like a separate document to me. (yes, I see Ale's draft below) And
IMO, I don't think we should hold up DMARCbis for that work.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of Hector Santos
> 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:
> >
> > Authentication-Results: wmail.tana.it;
> > spf=pass smtp.mailfrom=ietf.org;
> > dkim=pass reason="Original-From: transformed" header.d=google.com;
> > dkim=pass (whitelisted) header.d=ietf.org
> > header.b=jAsjjtsp (ietf1);
> > dkim=fail (signature verification failed, whitelisted)
> > header.d=ietf.org
> > header.b=QuwLQGvz (ietf1)
> >
> > However, not all signatures can be verified. Mailman tries and
> > preserve most header fields, but not all. For example, they rewrite
> > MIME-Version: from scratch and don't save the old one. So if a poster
> > signs that field and writes it differently (e.g. with a
> > comment) MLM transformation cannot be undone.
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> > t-vesely-dmarc-mlm-transform__;!!CQl3mcHX2A!DfPhD9QIFk5QZaU-
> JPkz748sZC
> >
> QtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZaB5XtMgrS
> WZ9HPP
> > m2s$
> >
>
> And this was my result for your message, separating lines for easier
> reading:
>
> Authentication-Results: dkim.winserver.com;
> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
> adsp=none author.d=tana.it signer.d=ietf.org;
> dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
> signer);
>
> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
> adsp=none author.d=tana.it signer.d=ietf.org;
> dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
> signer);
>
> dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
> adsp=dkim-fail author.d=tana.it signer.d=;
> dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized
> signer);
>
> dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta
> header.i=tana.it;
>adsp=dkim-fail author.d=tana.it signer.d=tana.it;
>dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it
> (originating signer);
>
> Four signatures were added to your submission and the only one that counts is
> the top one, the last one added.
>
> It failed DMARC because tana.it did not authorized ietf.org. You can
> easily resolve this by adding atps=y to your DMARC record:
>
> v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it;
> ruf=mailto:dmarcf...@tana.it;
>
> and add an ATPS sub-domain record authorizing ietf.org in your dana.it
> zone:
>
> pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;")
>
> Do that and all ATPS compliant verifiers should show a DMARC=pass:
>
> Authentication-Results: dkim.winserver.com;
> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
> adsp=none author.d=tana.it signer.d=ietf.org;
> dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);
>
>
> For a short list of signers, I updated my DMARC evaluator to also support ASL
> "Authorized Signer List" to avoid the extra ATPS record.
> So doing this will work across my evaluator for smaller scale mail senders
>
> v=DMARC1; p=none; atps=y; asl=ietf.org; rua=mailto:dmarca...@tana.it;
> ruf=mailto:dmarcf...@tana.it;
>
>
> This will skip atps=y because asl=ietf.org was satisfied. It was show
> how it was authorized:
>
> dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);
>
>
> Any ATPS or ASL idea will give us the author-defined trust of ietf.org
> as a 3rd party signer.
>
> That said, keeping with the suggestion DMARCBis should add MLS/MLM
> semantics, I believe when the Receiver is receiving mail for a
> MLS/MLM, it should have the following updated modern consideration
> for a MLS/MLM:
>
> 1) It should honor policy first, by check for restrictive domains
>
> 2) It should honor the domain restrictive policy to avoid creating new
> security problems and avoid delivery problems. This means to
> implement subscription and submission controls. DMARCbis should pass
> the buck back to the restrictive domain who must deal with user's
> needs or not.
>
> 3) It should check if the submission's author domain authorizes the
> MLM signing domain by finding a ATPS record, if so
>
> 3.1) it can continue as the 3rd party signer and also keep the From as
> is, unchanged, or
>
> 3.2) it can also consider to rewrite. If rewrite is performed, the
> signing domain should have a security that does not allow any Display
> Attack Replays with the now altered 5322.From identity.
>
>
> --
> Hector Santos,
> https://u
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="Original-From: transformed" header.d=google.com;
dkim=pass (whitelisted) header.d=ietf.org
header.b=jAsjjtsp (ietf1);
dkim=fail (signature verification failed, whitelisted)
header.d=ietf.org
header.b=QuwLQGvz (ietf1)
However, not all signatures can be verified. Mailman tries and
preserve most header fields, but not all. For example, they rewrite
MIME-Version: from scratch and don't save the old one. So if a
poster signs that field and writes it differently (e.g. with a
comment) MLM transformation cannot be undone.
https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform
And this was my result for your message, separating lines for easier
reading:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
signer);
dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
adsp=dkim-fail author.d=tana.it signer.d=;
dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized signer);
dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta
header.i=tana.it;
adsp=dkim-fail author.d=tana.it signer.d=tana.it;
dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it
(originating signer);
Four signatures were added to your submission and the only one that
counts is the top one, the last one added.
It failed DMARC because tana.it did not authorized ietf.org. You can
easily resolve this by adding atps=y to your DMARC record:
v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it;
ruf=mailto:dmarcf...@tana.it;
and add an ATPS sub-domain record authorizing ietf.org in your dana.it
zone:
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;")
Do that and all ATPS compliant verifiers should show a DMARC=pass:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=none author.d=tana.it signer.d=ietf.org;
dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);
For a short list of signers, I updated my DMARC evaluator to also
support ASL "Authorized Signer List" to avoid the extra ATPS record.
So doing this will work across my evaluator for smaller scale mail senders
v=DMARC1; p=none; atps=y; asl=ietf.org;
rua=mailto:dmarca...@tana.it; ruf=mailto:dmarcf...@tana.it;
This will skip atps=y because asl=ietf.org was satisfied. It was show
how it was authorized:
dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);
Any ATPS or ASL idea will give us the author-defined trust of ietf.org
as a 3rd party signer.
That said, keeping with the suggestion DMARCBis should add MLS/MLM
semantics, I believe when the Receiver is receiving mail for a
MLS/MLM, it should have the following updated modern consideration
for a MLS/MLM:
1) It should honor policy first, by check for restrictive domains
2) It should honor the domain restrictive policy to avoid creating new
security problems and avoid delivery problems. This means to
implement subscription and submission controls. DMARCbis should pass
the buck back to the restrictive domain who must deal with user's
needs or not.
3) It should check if the submission's author domain authorizes the
MLM signing domain by finding a ATPS record, if so
3.1) it can continue as the 3rd party signer and also keep the From as
is, unchanged, or
3.2) it can also consider to rewrite. If rewrite is performed, the
signing domain should have a security that does not allow any Display
Attack Replays with the now altered 5322.From identity.
--
Hector Santos,
https://santronics.com
https://winserver.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
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 the receiving participant and his domain. ATSP for Users could provide a reliable solution framework starting from the sending participant and his domain. I don't think replacing the PSL has equal priority, and I think the problems created by our redesign are being underestimated. Doug Foster On Mon, May 1, 2023 at 6:52 AM Alessandro Vesely wrote: > 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 what they know about > the > > evaluator. This would need some mechanism for evaluators to indicate > what trust > > techniques they accept. > > > Can do better than that. Have evaluators indicate under what conditions > they > accept whitelisting agreements. If the MLM can meet such conditions they > set > up whitelisting, for a specific recipient, of messages signed by the > mailing > list, even if they break DMARC (see below). > > However, this cannot be part of DMARCbis. > > > > 2) Have the mailingList rewrite the fromHeader but store the original > > fromHeader and propagate the necessary trust information so that > downstream > > evaluators can undo the rewriting. > > > > Given that currently many mailingList do fromHeader rewriting it seems > that #2 > > would allow gradual adoption and flexibility for experimentation over > time to > > see what trust methods work and allow downstream evaluators to make > > personalized decisions depending on the recipients trust preferences. > > > 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) header.d=ietf.org > header.b=jAsjjtsp (ietf1); >dkim=fail (signature verification failed, whitelisted) header.d= > ietf.org > header.b=QuwLQGvz (ietf1) > > However, not all signatures can be verified. Mailman tries and preserve > most > header fields, but not all. For example, they rewrite MIME-Version: from > scratch and don't save the old one. So if a poster signs that field and > writes > it differently (e.g. with a comment) MLM transformation cannot be undone. > https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform > > > > What are your thoughts? What would be needed for that to result in a > non-hollow > > victory? > > > I'll propose another draft, here or in the ART WG, more or less like so: > > * The mailing list sends a message to the subscriber domain requesting > permission to send mailing list messages that may fail DMARC checks. > > * The message explains that list messages will be properly authenticated > using > ARC, but may fail DMARC alignment checks because they are being forwarded > by > the mailing list server. > > * The subscriber domain verifies the request with the subscriber and, if > the > subscriber agrees to receive mailing list messages, provides a DMARC > override > specific for the mailing list server's domain and the recipient. > > * The DMARC override allows mailing list messages to bypass DMARC checks > and be > delivered to the subscriber's inbox, so the mailing list won't rewrite > From: in > messages to that subscriber. > > Additionally, it may be helpful to provide regular reports or updates to > the > domain's IT team, detailing any issues or incidents related to the mailing > list's email traffic. This can help establish a sense of trust and > accountability between the mailing list operator and the domain, and > demonstrate that the mailing list is actively monitoring and addressing > any > potential security concerns. > > That has to be discussed, but not in the DMARCbis context, otherwise > someone > will say it's mission creeping, someone else will escalate it to mission > gallop, an they'd be somewhat right that such discussion delays DMARCbis > publication. IOW, let's proceed step by step. > > > Best > Ale > -- > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
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 what they know about the evaluator. This would need some mechanism for evaluators to indicate what trust techniques they accept. Can do better than that. Have evaluators indicate under what conditions they accept whitelisting agreements. If the MLM can meet such conditions they set up whitelisting, for a specific recipient, of messages signed by the mailing list, even if they break DMARC (see below). However, this cannot be part of DMARCbis. 2) Have the mailingList rewrite the fromHeader but store the original fromHeader and propagate the necessary trust information so that downstream evaluators can undo the rewriting. Given that currently many mailingList do fromHeader rewriting it seems that #2 would allow gradual adoption and flexibility for experimentation over time to see what trust methods work and allow downstream evaluators to make personalized decisions depending on the recipients trust preferences. 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) header.d=ietf.org header.b=jAsjjtsp (ietf1); dkim=fail (signature verification failed, whitelisted) header.d=ietf.org header.b=QuwLQGvz (ietf1) However, not all signatures can be verified. Mailman tries and preserve most header fields, but not all. For example, they rewrite MIME-Version: from scratch and don't save the old one. So if a poster signs that field and writes it differently (e.g. with a comment) MLM transformation cannot be undone. https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform What are your thoughts? What would be needed for that to result in a non-hollow victory? I'll propose another draft, here or in the ART WG, more or less like so: * The mailing list sends a message to the subscriber domain requesting permission to send mailing list messages that may fail DMARC checks. * The message explains that list messages will be properly authenticated using ARC, but may fail DMARC alignment checks because they are being forwarded by the mailing list server. * The subscriber domain verifies the request with the subscriber and, if the subscriber agrees to receive mailing list messages, provides a DMARC override specific for the mailing list server's domain and the recipient. * The DMARC override allows mailing list messages to bypass DMARC checks and be delivered to the subscriber's inbox, so the mailing list won't rewrite From: in messages to that subscriber. Additionally, it may be helpful to provide regular reports or updates to the domain's IT team, detailing any issues or incidents related to the mailing list's email traffic. This can help establish a sense of trust and accountability between the mailing list operator and the domain, and demonstrate that the mailing list is actively monitoring and addressing any potential security concerns. That has to be discussed, but not in the DMARCbis context, otherwise someone will say it's mission creeping, someone else will escalate it to mission gallop, an they'd be somewhat right that such discussion delays DMARCbis publication. IOW, let's proceed step by step. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
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 private. A public mechanism would presumably be in DNS, to indicate support for a particular technique. As applied to the methods mentioned: - Evaluator whitelisting is specific to a message source, so it is only suitable for private communication. - Public notice of ATSP participation provides certainty. Accepting the protocol means accepting valid signatures from the third party on behalf of the first party. A public assertion of participation also seems to present no particular increase in risk to the evaluator. - ARC does not provide certainty, since the interpretation of any single ARC set depends on the trust given to the ARC set creator, and the specific content of the ARC set in a particular message.Therefore, I don't see that public disclosure of ARC participation can provide the list with the information that it needs. So ARC feedback needs to be private. There has been some talk of providing a version of DMARC reports to senders when they are different from the domain owners. It would be a form of private notification, if all of the objections are overcome and deployment is sufficiently widespread. Doug Foster On Sun, Apr 30, 2023 at 10:25 PM 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 what they know about the > evaluator. This would need some mechanism for evaluators to indicate what > trust techniques they accept. > 2) Have the mailingList rewrite the fromHeader but store the original > fromHeader and propagate the necessary trust information so that downstream > evaluators can undo the rewriting. > > Given that currently many mailingList do fromHeader rewriting it seems > that #2 would allow gradual adoption and flexibility for experimentation > over time to see what trust methods work and allow downstream evaluators to > make personalized decisions depending on the recipients trust preferences. > > What are your thoughts? What would be needed for that to result in a > non-hollow victory? > > > On Sun, Apr 30, 2023, 9:54 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> 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 assume that rewrite is necessary to avoid message blocks, >> unsubscribes, and possibly blacklisting >> >> No such feedback exists at present, so even though ARC has some >> acceptance, it is a hollow victory. >> >> DF >> >> >> On Sun, Apr 30, 2023, 8:05 PM Hector Santos wrote: >> >>> >>> >>> On Apr 29, 2023, at 4:42 PM, Douglas Foster < >>> dougfoster.emailstanda...@gmail.com> 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 >>>participating domains have agreed to ignore DMARC Fail for messages from >>>the list (Ale floated some ideas about that approach.) >>>- For the longer term, we need a non-DKIM method for delegating >>>rights to a third party. >>> >>> >>> Ideally, the goal is to eliminate “From Rewrite” to return to the “good >>> ol’ days.” So the first time is to recognize having subscription and >>> submissions controls is a natural consideration for the DKIM Policy >>> "Protocol Complete” model. If the MLS supports the protocol, it would >>> consider this method more so than a destruction method that tear down >>> security. This will also pass the buck back to the domain owner to deal >>> with its user’s needs or not. >>> >>> You talk about "incomplete protocol" as if this is a commonly understood >>> and accepted term. I interpret it to mean a third-party authentication >>> method other than DKIM. DKIM does serve for third-party authentication >>> where it has been embraced and deployed. So the issue is that it has not >>> been practical for many situations and we do need another option. >>> >>> >>> Protocol complete is a client/server protocol negotiation concept. It >>> basically means the “State Machine”, the conversation between the client >>> and server is well-defined. No Loop Holes Very key concept in protocol >>> design. >>> >>> In terms of DKIM Signing Practices, you can read "Requirements for a >>> DomainKeys
