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" <[email protected]>
Sent: Monday, April 8, 2019 7:13 PM
To: [email protected]
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)" <[email protected]>
wrote:
>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
>[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
