> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
>
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <ves...@tana.it
> <mailto:ves...@tana.it>> wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"
>> > <superu...@gmail.com <mailto:superu...@gmail.com>> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <ves...@tana.it
>> >> <mailto:ves...@tana.it>> wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that
>> >>> publish a
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>>
>> Agreed. Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection of
> messages merely because they fail authentication on ingress.
And respectfully, SPF always had a strong reject, hard fail policy concept
since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.
Why Not? It was optimized. It served a purpose to address spoofs. Partial,
Neutral and Unknown results were possible. That was suppose to be feed to a
heuristics, highly subjective Reputation Engine. After exactly 20 years of
data, SPF rejection rate is 6.3% of the incoming rejection reasons.
https://winserver.com/public/spamstats.wct
>> I agree there are better solutions, but they're not yet developed. As ugly
>> as
>> it may be, From: munging is the emerged solution. It is a _fact_. Now
>> repeat
>> again that the IETF standardized facts, not theories...
>
> Let's put the challenge back on you: Where's your evidence that From munging
> is the emerged consensus solution that this working group should standardize?
> Where is this _fact_? If we advance that as a Proposed Standard, the
> community will quite reasonably ask why we think this is true, and we're
> going to need to be able to answer them. If working group consensus agrees,
> then away we go.
As much as I am an original mail engineering purest (anyone here ever work with
Fidonet?) and therefore consider it to be a fundamental taboo to destroy
originating copyrighted authorship of anything, the MLS/MLM needs to evolve to
handle the various 1::many broadcasting distributions under a new security
umbrella.
Because the current DMARCbis umbrella ist not providing 100% coverage, for the
MLS./MLM, it needs to do one of two things; restrict subscription/submissions
or strip the security and rewrite the copyrighting authorship, perpetuating a
potential harm including legal.
The latter is not preferred. The former would be normal part of a protocol
complete algorithm. You would do the former always. It’s the easiest. No need
to modify the MLS. Just the MLM low code provisional scripts.
—
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
