Re: [dmarc-ietf] Signaling MLMs

Hector, it sounds like you are saying that SPF is all we need, so scrap
DMARC.   If it is something else please clarify.

Doug

On Fri, Apr 14, 2023, 4:44 PM Hector Santos <hsantos=
40isdg.net@dmarc.ietf.org> wrote:

>
>
> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy <superuser@gmail.com>
> wrote:
>
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <vesely@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" <
>> superuser@gmail.com> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <vesely@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
>