Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On 2/10/23 3:11 PM, Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: | resign for DKIM on behalf of the Originator though the | Originator increases risk of losing control of their private key. I'm pretty sure that the best practice here is to just create a selector(s) for the ESP's, etc, signing keys. You definitely don't want to be handing your private keys out. And almost as if on cue, Namecheap who should know better didn't. https://www.namecheap.com/status-updates/archives/74848 Mike___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On 2/12/23 12:15 AM, Wei Chuang wrote: Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether senders or receivers should filter for spam (and if there is, it would be good to reference it). Sender filtering is especially pertinent and may well have clues of how a sender can mitigate it. A breakdown of how spammers defeat that outbound filtering would be really useful. For example, is the spam intended for mailboxes on the sending domain (eg, gmail)? Or do they go through a two stage process where they first get the spam through the sender, and then test it on the intended receiving domains? All of that would be really helpful. Many MBP have outbound and inbound spam filters. Many domains also use third party Outbound Filtering Services and Inbound Filtering Services as mentioned in the Problem Statement draft. If there is a BCP, I think it's sort of table stakes that outbound filtering takes place. That goes for ESP's with marketing email as well. I expect that that is just preaching to the choir though. I understand that Google is not going to tell us exactly how it makes its filtering and reputation decisions, but that sort of begs the question of whether we can know what is "best" or "common" given that we don't know what is "not best" and "not common" out in the industry. Obviously if we can observe behavior from the outside (eg, not signing To: and Subject:) that's fair game. But a nebulous "lowers the reputation" leaves us to just speculate as to what that means. That is not a very good place to be in for a standards body. I think that stake holders are going to have to come to some consensus of what they will and won't share. That in turn will inform the wg what it can and can't do. If the problem statement remains really vague, that means the solution space is going to be further constrained. There will alway be this tension between what is proprietary and what can be shared so that we collectively work on the problem. Perhaps the way to break the impasse is to say let's move away from reputation systems as they are inherently non-deterministic to some deterministic solution for DKIM replay. As an example, a couple of the proposals work on signing MAIL FROM recipients and verifying the actual recipient against the signed recipients. The computed will be consistent when evaluated at different times unlike reputation systems. But that breaks indirect mail flows, right? How does a sender know that the MX domain isn't the final domain? Of course if you don't want to support indirect flows, all you need to do is put up a SPF record and not DKIM sign it. No need to do any unnatural layer violating acts. Why do you say it weakens it? Isn't it pretty common to import the SPF record of ESPs, and in this case outbound filters into the sending domain's SPF record? If it does weaken it, wouldn't that apply to the ESP case too? Fair enough. Yes that applies there too. But how does it weaken it? Or is that what the Fair Enough is pertaining to? Mike___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/12/23 1:47 PM, Murray S. Kucherawy wrote: On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. What I'm starting to think is that if we can collect that into the problem statement that may well be all we need to do if we determine that there is no there there in the solution space (given the solutions on offer now, that seems to be the case). Also: we can't write a BCP if we can't know what they may be because of the proprietary nature of the filtering/reputation. If the clues we find are well known to them then, well, it's sort of like what are we supposed to do? I'm doubtful, but I'll see if the data I still have can reveal this sort of correlation given the participants I had and the data they submitted. If there are any large operators that could run such a survey, I'm sure the WG would appreciate it. And of course if operators start enforcing it fairly uniformly, spammers will just pursue other mechanisms. That's yet another reason why there probably isn't much we can do long term. FWIW, I've started collecting some of the clues I've seen along the way here. If I get enough of them, I'll write a short I-D about it. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Setting a stage for detection
On 2/12/2023 1:44 PM, Murray S. Kucherawy wrote: Would this work if it passes through more than one layer of aliasing? That is, can this work if "Separate-Envelope" appears more than once? Do they all have to be signed, order preserved, etc.? So, well, umm I was merely tossing off an idea and have no idea what the fine-grained details of either its specification or its handling sequences should be. Certainly pursuit of any proposal in this space needs to worry about real-world handling sequences, such as going through multiple mediators and the different ways mediators can preserve or break things. For example, one version of this is "what happens when there are multiple signatures from different domains?" While I've heard some discussion of real-world treatment of such cases, I haven't heard enough to know what is normal or, for that matter, useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On 2/12/23 1:34 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether senders or receivers should filter for spam (and if there is, it would be good to reference it). Sender filtering is especially pertinent and may well have clues of how a sender can mitigate it. A breakdown of how spammers defeat that outbound filtering would be really useful. For example, is the spam intended for mailboxes on the sending domain (eg, gmail)? Or do they go through a two stage process where they first get the spam through the sender, and then test it on the intended receiving domains? All of that would be really helpful. I think it's sufficient for us to acknowledge that, in either direction, no spam filter is 100% accurate. It can be tempting to say "You shouldn't sign spam, and if you do, you're the problem", but I'm sympathetic to those in that business who are faced with the reality that they'll never get it 100% right. Instead, I think we have to accept that reputable signers will occasionally be tricked into signing spam, and the goal then is to try to develop some new signal that can be provided to verifiers to handle those cases. The problem statement document proposed for the WG does spell this out, I think. What do you find missing in terms of the details? Some of the nitty gritty probably varies from one email provider to the next, for example. It didn't exactly call it out? It called out outsourced outbound filtering I thought, but that's just acknowledging that it exists? Or did I miss something? Maybe what's needed is essentially what you wrote. "while senders intent on keeping a good reputation must filter outbound mail for spam and other abuse, these filters are not 100% effective." Basically saying if you're not filtering outbound mail for abuse, you're part of the problem. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: > > It's certainly possible to collect data that might correlate something > like "Subject signed vs. not signed" with a spam score, and that could feed > in to a best practices document. I don't know who might be up for > investing the time into such a survey, however. OpenDKIM used to collect > such summaries from volunteer participants; I can see if the data sitting > around in those tables had enough information for such a survey, but it > almost certainly won't be current data. > > What I'm starting to think is that if we can collect that into the problem > statement that may well be all we need to do if we determine that there is > no there there in the solution space (given the solutions on offer now, > that seems to be the case). Also: we can't write a BCP if we can't know > what they may be because of the proprietary nature of the > filtering/reputation. If the clues we find are well known to them then, > well, it's sort of like what are we supposed to do? > I'm doubtful, but I'll see if the data I still have can reveal this sort of correlation given the participants I had and the data they submitted. If there are any large operators that could run such a survey, I'm sure the WG would appreciate it. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Setting a stage for detection
On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker wrote: > There appears to be no perfect way to distinguish a Replay attack from a > legitimate re-posting by an Alias or even a Mailing list (that preserves > the original DKIM signature.) > > The only 'signal' that is valid, also is ambiguous. The signal is that > the rfc5321.Mail command has an address that is not in any of the > rfc5322 address fields. The ambiguity, of course, is that that's also > true for Alias. > > I'm wondering about designing some assistance by the author's platform > and the Aliasing platform, to flag what they've done. > > Imagine adding a header field like "Separate-Envelope:", possibly > listing the domain name of the site putting the flag there, and having > them add a DKIM signature to cover it and the rest of the message. > Interesting. Would this work if it passes through more than one layer of aliasing? That is, can this work if "Separate-Envelope" appears more than once? Do they all have to be signed, order preserved, etc.? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Setting a stage for detection
On Sun, Feb 12, 2023 at 1:21 PM Dave Crocker wrote: > One of the continuing problems with anti-abuse discussions is that > discussion always goes to detecting bad actors. While of course there need > to be discussions about them, the problem is that there seem to be no > discussions about good actors. > > DKIM and a mechanism such as I'm proposing gives the receiver a noise-free > message flow to evaluate. It can be used for finding bad actors, of > course, but I think its primary benefit is in finding good actors. > I think this is a strong point. One of the things that's stuck with me since we were working on what became RFC 4871 is the notion that you only really know anything when DKIM succeeds. (But then, of course, you need to be cautious about over-interpreting exactly what it's telling you.) You can't conclude anything from a failure because there are so many legitimate failure modes. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote: > Another thing that should probably be discussed is outbound spam > filtering. At a high level, this is really about the sender sending spam. > But email afaik is silent on whether senders or receivers should filter for > spam (and if there is, it would be good to reference it). Sender filtering > is especially pertinent and may well have clues of how a sender can > mitigate it. A breakdown of how spammers defeat that outbound filtering > would be really useful. For example, is the spam intended for mailboxes on > the sending domain (eg, gmail)? Or do they go through a two stage process > where they first get the spam through the sender, and then test it on the > intended receiving domains? All of that would be really helpful. > I think it's sufficient for us to acknowledge that, in either direction, no spam filter is 100% accurate. It can be tempting to say "You shouldn't sign spam, and if you do, you're the problem", but I'm sympathetic to those in that business who are faced with the reality that they'll never get it 100% right. Instead, I think we have to accept that reputable signers will occasionally be tricked into signing spam, and the goal then is to try to develop some new signal that can be provided to verifiers to handle those cases. The problem statement document proposed for the WG does spell this out, I think. What do you find missing in terms of the details? Some of the nitty gritty probably varies from one email provider to the next, for example. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Setting a stage for detection
On 2/12/2023 12:48 PM, Wei Chuang wrote: In this model, let's consider the Receiver's actions. 1. Say the spammer doesn't want to participate in creating a Separate-Envelope, how would a receiver detect this as Replay? Is the idea that Separate-Envelope identifies the Alias or Mailing-lIst? Is the verification process that the Receiver notices that the header is missing? One of the continuing problems with anti-abuse discussions is that discussion always goes to detecting bad actors. While of course there need to be discussions about them, the problem is that there seem to be no discussions about good actors. DKIM and a mechanism such as I'm proposing gives the receiver a noise-free message flow to evaluate. It can be used for finding bad actors, of course, but I think its primary benefit is in finding good actors. With that said, now to comment on your bad actor line of consideration: A message arrives that has the address disparity which raises concern. And it does not have the signed flag noting who created the disparity. Today and forever, this could be a message from a good actor or a bad actor. It will take conservative heuristics to handle, but ultimately the handling would be pretty much the same as today. The mechanism I've suggested does not make things worse for this scenario... Except that some fraction of traffic is now trying to help the analysis. If the mechanism becomes used by the primary domain names that are being abused, that means that the absence of the mechanism from a message means it is more likely the message is problematic. But only "more likely". 2. You've noted what happens when the spammer participates in generating Separate-Envelope 3. A non-spammer should have a Separate-Envelope, which will validate. FWIW a different approach but overlaps this idea is that a sender identifies the domain they intend to send to. The receiving system verifies that they are the intended recipient domain. I think John Levine has a draft about this. I have a draft that expands some of that idea further. I don't really understand what you are describing. Senders always know the domain they are sending to. And I don't know what it means for a receiver to 'verify' that they are the intended recipient, since domain getting mail was intended (by someone) to get it. Further, 'intention' is distributed, given Mediators. I also don't know what draft by Levine you are referring to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Setting a stage for detection
On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker wrote: > Folks, > > There appears to be no perfect way to distinguish a Replay attack from a > legitimate re-posting by an Alias or even a Mailing list (that preserves > the original DKIM signature.) > > The only 'signal' that is valid, also is ambiguous. The signal is that > the rfc5321.Mail command has an address that is not in any of the > rfc5322 address fields. The ambiguity, of course, is that that's also > true for Alias. > > I'm wondering about designing some assistance by the author's platform > and the Aliasing platform, to flag what they've done. > > Imagine adding a header field like "Separate-Envelope:", possibly > listing the domain name of the site putting the flag there, and having > them add a DKIM signature to cover it and the rest of the message. > This could also be done by a spammer doing Replay, of course. But the > point is that this added mechanism now creates a noise-free basis for > evaluating this class of traffic associated with that signed domain. > Agreed that reputation systems can play a role when the spammer decides to participate. It's not that the receiving filter could not detect the disparity > between envelope and content addresses. It's that the receiver is > getting a flag from whomever did it. > > If, for example, the domain name is of the originating service, then > it's clearly not Replay. > > If it is from an Aliasing site, the receiver can quickly build up a > reputation for that site, to aid in determining replay or not. > > Thoughts? > In this model, let's consider the Receiver's actions. 1. Say the spammer doesn't want to participate in creating a Separate-Envelope, how would a receiver detect this as Replay? Is the idea that Separate-Envelope identifies the Alias or Mailing-lIst? Is the verification process that the Receiver notices that the header is missing? 2. You've noted what happens when the spammer participates in generating Separate-Envelope 3. A non-spammer should have a Separate-Envelope, which will validate. FWIW a different approach but overlaps this idea is that a sender identifies the domain they intend to send to. The receiving system verifies that they are the intended recipient domain. I think John Levine has a draft about this. I have a draft that expands some of that idea further. -Wei > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker@mastodon.social > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Setting a stage for detection
Folks, There appears to be no perfect way to distinguish a Replay attack from a legitimate re-posting by an Alias or even a Mailing list (that preserves the original DKIM signature.) The only 'signal' that is valid, also is ambiguous. The signal is that the rfc5321.Mail command has an address that is not in any of the rfc5322 address fields. The ambiguity, of course, is that that's also true for Alias. I'm wondering about designing some assistance by the author's platform and the Aliasing platform, to flag what they've done. Imagine adding a header field like "Separate-Envelope:", possibly listing the domain name of the site putting the flag there, and having them add a DKIM signature to cover it and the rest of the message. This could also be done by a spammer doing Replay, of course. But the point is that this added mechanism now creates a noise-free basis for evaluating this class of traffic associated with that signed domain. It's not that the receiving filter could not detect the disparity between envelope and content addresses. It's that the receiver is getting a flag from whomever did it. If, for example, the domain name is of the originating service, then it's clearly not Replay. If it is from an Aliasing site, the receiver can quickly build up a reputation for that site, to aid in determining replay or not. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/12/23 9:36 AM, Murray S. Kucherawy wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. What I'm starting to think is that if we can collect that into the problem statement that may well be all we need to do if we determine that there is no there there in the solution space (given the solutions on offer now, that seems to be the case). Also: we can't write a BCP if we can't know what they may be because of the proprietary nature of the filtering/reputation. If the clues we find are well known to them then, well, it's sort of like what are we supposed to do? Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 12/02/2023 17:28, Murray S. Kucherawy wrote: Have they not been getting consideration? I know I've been replying to many of his comments. I didn't mean to imply he was being ignored, sorry if it sounded that way. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas wrote: > It's never been especially clear to me whether deployments do their > filtering up front, ie at the MX, or farther down the line. There are > certainly advantages to do it right at the MX with less burden on using AR > to signal all of what the filters consider the interesting bits that > standard A-R might not support. But there may be good architectural reasons > to postpone the filtering to later in the pipeline even if means that > you're holding the spam longer before discarding it > Yep; there's no "right" way. I've seen both kinds of architecture work, and A-R tries to anticipate all sorts of options (by not precluding any of them). > But regardless of A-R just cataloging what those interesting bits might be > could be useful in documenting how they can be used to detect replay spam. > Also: I think there is more to it than whether the signature verifies, per > say. The signature actually verifies, but it's the scrutiny that matters. > Saying it doesn't verify essentially decouples from any reputation of the > domain. But that is hardly the only way to look at it. Saying it verifies, > but has problems is another way to view it. For wetware investigators an > A-R that did that could be really confusing. > It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On Sat, Feb 11, 2023 at 4:48 PM Stephen Farrell wrote: > FWIW, as this discussion has a bit of a flavour of one person > arguing with a bigger bunch of people, I'd like to say that > Mike is asking good questions that deserve consideration. > Have they not been getting consideration? I know I've been replying to many of his comments. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether senders or receivers should filter for spam (and if there is, it would be good to reference it). Sender filtering is especially pertinent and may well have clues of how a sender can mitigate it. A breakdown of how spammers defeat that outbound filtering would be really useful. For example, is the spam intended for mailboxes on the sending domain (eg, gmail)? Or do they go through a two stage process where they first get the spam through the sender, and then test it on the intended receiving domains? All of that would be really helpful. Many MBP have outbound and inbound spam filters. Many domains also use third party Outbound Filtering Services and Inbound Filtering Services as mentioned in the Problem Statement draft. I understand that Google is not going to tell us exactly how it makes its filtering and reputation decisions, but that sort of begs the question of whether we can know what is "best" or "common" given that we don't know what is "not best" and "not common" out in the industry. Obviously if we can observe behavior from the outside (eg, not signing To: and Subject:) that's fair game. But a nebulous "lowers the reputation" leaves us to just speculate as to what that means. That is not a very good place to be in for a standards body. I think that stake holders are going to have to come to some consensus of what they will and won't share. That in turn will inform the wg what it can and can't do. If the problem statement remains really vague, that means the solution space is going to be further constrained. There will alway be this tension between what is proprietary and what can be shared so that we collectively work on the problem. Perhaps the way to break the impasse is to say let's move away from reputation systems as they are inherently non-deterministic to some deterministic solution for DKIM replay. As an example, a couple of the proposals work on signing MAIL FROM recipients and verifying the actual recipient against the signed recipients. The computed will be consistent when evaluated at different times unlike reputation systems. Why do you say it weakens it? Isn't it pretty common to import the SPF record of ESPs, and in this case outbound filters into the sending domain's SPF record? If it does weaken it, wouldn't that apply to the ESP case too? Fair enough. Yes that applies there too. The other two points are observations which I think I largely agree with. -Wei On Sat, Feb 11, 2023 at 2:40 PM Michael Thomas wrote: > > On 2/10/23 9:36 PM, Murray S. Kucherawy wrote: > > On Fri, Feb 10, 2023 at 12:06 PM Evan Burke 40mailchimp@dmarc.ietf.org> wrote: > >> >> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: >> >>> On 2/10/2023 11:35 AM, Wei Chuang wrote: >>> > ARC is a tool to help support modern Indirect Mail Flows, and I >>> > believe belongs in the solution space to be explored. >>> >>> Since ARC uses the same technology as DKIM and uses it in pretty much >>> the same was, my understanding is that it, too, has the potential for >>> replay. Having a reference to this fact makes sense to me. >>> >>> It doesn't need more than a mention, at this point, I believe, which >>> makes the current quick, reference exactly the right text, IMO. >>> >> >> +1 >> >> I realize there are some mixed opinions on ARC, but it's actively used on >> several of the world's largest email systems - some of the same ones where >> DKIM replay attacks are focused - so it's worth consideration as part of >> the solution space. It may not end up being a viable option, but now isn't >> the time to write it off. >> > > Speaking only as a participant: > > I also don't think a comment like "ARC has the same problem, for largely > the same reasons" is by itself harmful here. > > What I think we should be sure to avoid is expending WG energy trying to > solve this problem in ARC-space. That, I would argue, is outside the > charter. > > I see that they took out a lot of other mentions in this rev, but I have a > real problem with editorializing that ARC does this or ARC does that which > is to say the least, controversial. It's really not germane to this wg and > imo the easiest thing to do is nothing at all wrt ARC. > > Mike > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
