Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas <m...@mtcc.com> 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 <m...@mtcc.com> wrote: > > On 2/10/23 9:36 PM, Murray S. Kucherawy wrote: > > On Fri, Feb 10, 2023 at 12:06 PM Evan Burke <evan.burke= > 40mailchimp....@dmarc.ietf.org> wrote: > >> >> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker <d...@dcrocker.net> 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
