Re: [dmarc-ietf] Signaling MLMs

Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC failure.  In standard boolean logic is it an OR condition:

IF SPF FAILS or DKIM FAILS Then Reject.

I hope you can understand this technical implementation detail.

—
HLS

> On Apr 14, 2023, at 5:44 PM, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
> 
> 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 <mailto:40isdg.net@dmarc.ietf.org>> wrote:
>> 
>> 
>>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy <superuser@gmail.com <mailto:superuser@gmail.com>> wrote:
>>> 
>>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely <vesely@tana.it <mailto: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 <mailto:superuser@gmail.com>> wrote:
>>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <vesely@tana.it <mailto: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 <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc