No, I think you seriously misunderstand what the IETF does. It doesn't do product specifications, it does interoperability specifications.
This is seriously off-topic for the DMARC working group list anyway. Scott K P.S. There are open source components to accomplish all the requirements you listed, some assembly required. Discussion though should happen somewhere else. On April 9, 2019 12:27:06 AM UTC, "Douglas E. Foster" <fost...@bayviewphysicians.com> wrote: >Scott, you misunderstand what this type of standard would look like. >It >would defines Use Cases that the device should address, with some >acknowledgement to the tradeoffs between perceived risk and perceived >difficulty of implementation. > >Implementation suggestions may be part of the use case. It would be >hard >to implement SPF-like capability without using SPF data, but there are >many >ways that SPF data could be utilized. > >There are also fundamental security principles that everyone should be >following. > "Trusted communication (whitelist) should not occur until and unless >the >identity of the correspondent is confirmed." > Escalation of privilege (in this context, bypassing integrity >tests) >should be limited to the minimum necessary set of privileges to achieve >the >business requirement. > Mr. O'Driscoll's comments seemed to make the same mistake. The >configuration of email defenses will be different between a residential > >ISP, a large bank, and the US Army. However, the principles and use >cases >will be similar because any threat actor could take aim at any target. > >What differs is the perceived risk and the perceived complications from > >mitigating the risk, matched to each organizatoin's tolerance for risk. > > Nothing in this standard could be an absolute mandate, because only >government has the legal authority to say "This product cannot be sold >for >purpose X because it does not have feature Y," It could say, "You >must >implement this feature to claim compliance with RFC xxxx" This type >of >standard can and would pressure vendors to move in the right direction. > It >would also help purchases know how to be more intelligent shoppers. > > There is plenty of difficulty in reaching a consensus statement on >something like this, not least because each vendor wants to look >acceptable, no matter how inferior his current product may be. Just >because a topic is difficult does not mean there is no reason to >discuss >it. Working Groups exist because these issues take time and effort to > >flesh out. It is hard to argue that spam-getting-through is not an >important topic, but I suppose some people may try to do so. > > > > > >---------------------------------------- > From: "Scott Kitterman" <skl...@kitterman.com> >Sent: Monday, April 8, 2019 7:13 PM >To: dmarc@ietf.org >Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs > >On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" ><kb...@drkurt.com> >wrote: >>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster < >>fost...@bayviewphysicians.com> wrote: >> >>> I don't know how to express my shock at today's conversations. One >>of >>> the shocks comes from this: >>> >>> We have consensus that the better email filters do not need the >DMARC >>for >>> PSDs standard, because they are already blocking non-existent >>domains. >>> >> >>This neglects the benefit to the domain operators of receiving the >>reports >>about abuse of their domain space. For the end recipient of the bogus >>traffic, there is no difference. >> >> >>> The inferior email filters are not expected to implement this >>feature, >>> because they are inferior products. >>> >> >>Somewhat tautological, but most likely true. >> >> >>> Therefore the new standard has no expected benefit, but we need to >>finish >>> it anyway. >>> >> >>Incorrect - see my first point. > >The entire thing is further premised on the false premise that because >two >small mail operators find one filtering technique appropriate for their > >situation and scale, anyone that has a different design is inferior. > >Scott K > >_______________________________________________ >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
