Re: [dmarc-ietf] Signaling MLMs

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

> 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.
>

You have it absolutely backwards.

DMARC says if either (aligned) SPF validates or (aligned) DKIM validates,
it passes.

Michael Hammer

> 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> 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
>>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>