Re: [dmarc-ietf] No submitters, Reflections on IETF 117 Conference and DMARC Meeting

[John Levine]

It appears that Dotzero   said:
>Nope. A real big NOPE! There is a reason that SUBMITTER/PRA and SENDER-ID
>are deprecated.

I agree.  They're dead, even Microsoft abandoned them years ago.  Even if they 
were
useful, which they are not, there is no chance of getting people to use them 
again.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Dotzero]

On Thu, Aug 3, 2023 at 1:39 PM Hector Santos  wrote:

> On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote:
> > On Mon, Jul 31, 2023 at 9:47 AM Hector Santos
> >  > > wrote:
> >
> >- I mentioned using the deprecated SUBMITTER/PRA
> > (RFC4405/RFC4407)
> > protocols as an implementation detail to access the author's DMARC
> > policy at the SMTP "MAIL FROM" stage. Wei expressed interest in
> > this
> > idea. This could also enhance the "auth=" idea to help manage local
> > policy SPF -ALL handling. Should SMTP immediately reject? The
> > PRA at
> > SMTP could aid this decision for SPF -ALL policies. Based on many
> > years of implementation, it's evident that many mailers are either
> > identical or are using the same software that supports
> > SUBMITTER/PRA,
> > possibly due to ongoing support for the deprecated SenderID
> > (RFC4406)
> > protocol.  [...]
> >
> >
> > Can you or Wei spell this out a little more?  What could a list
> > subscriber do with this algorithm that we don't have today?
> >
> > The issue we're facing in a DMARC world isn't determining who the
> > original sender is, but rather that with broken signatures, we can't
> > prove it to DMARC's satisfaction.  I'm not clear on how your idea
> > fixes that.
> >
>
> The utilization of SUBMITTER/PRA protocols possibly can help manage
> situations where SPF fails before any DKIM information is accessible.
> This strategy provides SPF processors with preliminary DMARC policy
> data, potentially mitigating the impact of SPF hard-fail situations.
> The advantages of this approach are especially clear when SPF fails,
> but DMARC can help to temper the initial rejection.
>

Nope. A real big NOPE! There is a reason that SUBMITTER/PRA and SENDER-ID
are deprecated.

>
> Through the SUBMITTER/PRA, it's possible to ascertain the presence of
> a DMARC p=none or an auth=dkim, giving operators the choice to delay
> immediate rejection and verify DKIM instead.
>

This is absolutely false. There is no way to validate a relationship
between the From email address which DMARC is based on and the
SUBMITTER/PRA, which can be any arbitrary email address. Back in the day
when Harry Katz and Craig Spiezle from Microsoft were pushing Sender-ID, I
used to drive them a bit crazy by sending them emails with their email
addresses in the From and my email address as the SUBMITTER/PRA. Guaranteed
to get a neutral every time rather than a fail. Please stop pushing this.

To the chairs, I ask that pushing a deprecated approach which has
previously been shown to be hopelessly broken (even Microoft stopped
pushing it) be ruled off topic and out of scope.

>
> In the context of a mailing list, using a SUBMITTER in the
> distribution can prove useful. For instance, a list might not need to
> rewrite if it identifies an auth=spf for the domain, allowing it to
> function as a resigner although the original domain integrity was
> broken.   There might be a  auth=arc which ARC is needed for pass
> broken 1st party signature.
>

How does one differentiate between a random mail list and other possibly
malicious intermediaries? Is there a list of "acceptable" mailing lists? If
a list isn't implementing email authentication practices itself, how does
one trust any given list to be acting "on behalf" of a sending domain that
has published p=reject? Why is your proposal better than rewriting or lists
deciding not to accept mail from domains publishing p=reject?

>
> I know this is out of scope, but legacy scenarios may included
> checking for the 'atps=y' tag and check for an ATPS DNS authorization
> record for the resigner domain. There still many domains who don't use
> DMARC but instead still have ADSP dkim=all to expose a mail policy -
> "Expect all my mail to be signed."
>

You acknowledge that your proposals are out of scope but insist on wasting
the working group participants time by repeatedly bringing them up.

I again call on the Chairs to shut down out of scope discussions.

Michael Hammer







> However, at present, the most plausible use-case appears to be the
> addition of delayed SPF rejection scenarios through DMARC evaluation.
> Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to
> soften the impact of SPF -ALL policies.
>
> The approach might work as follows:
>
> - If SPF fails and the Submitter indicates p=reject, then reject
> (comes with its acceptable problems)
>
> - If SPF fails, the Submitter specifies p=reject and auth=dkim, then
> proceed to transfer the payload and evaluate DKIM
>
> - If SPF fails and the Submitter signifies p=none, then continue with
> payload transfer
>
> - If SPF fails and the Submitter designates p=quarantine, then proceed
> with payload transfer
>
> SUBMITTER may help align SPF with its original DMARC purpose—combining
> SPF+DKIM results while keeping with some level of optimization.
>
> --
> Hector Santos,
> https://santronics.com

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Murray S. Kucherawy]

On Thu, Aug 3, 2023 at 10:39 AM Hector Santos  wrote:

> [...]
>
> However, at present, the most plausible use-case appears to be the
> addition of delayed SPF rejection scenarios through DMARC evaluation.
> Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to
> soften the impact of SPF -ALL policies.
>
> The approach might work as follows:
>
> - If SPF fails and the Submitter indicates p=reject, then reject
> (comes with its acceptable problems)
>
> - If SPF fails, the Submitter specifies p=reject and auth=dkim, then
> proceed to transfer the payload and evaluate DKIM
>
> - If SPF fails and the Submitter signifies p=none, then continue with
> payload transfer
>
> - If SPF fails and the Submitter designates p=quarantine, then proceed
> with payload transfer
>
> SUBMITTER may help align SPF with its original DMARC purpose—combining
> SPF+DKIM results while keeping with some level of optimization.
>

Ah, interesting.

I don't think this should go in the base document, since the research we
did for RFC 6686 suggests that deployment of SUBMITTER, at least as of that
document's publication, wasn't very broad.  However, if the size of the
problem is substantial, and this solution turns out to be potentially
effective, this might be fodder for the applicability statement or usage
guidelines document that this WG has discussed producing in the past as a
possible enhancement.

Collecting some data and doing some experimentation would be really helpful
toward determining the right path here, if any.

-MSK, just participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Barry Leiba]

I don't agree.  An allow list bypasses something -- whatever
processing the list allows something past -- but not everything.

In this case, we might be talking about a list that means "If we are
sufficiently certain that a message same from the entity on the list,
we will not reject it even if the 'From' domain publishes p=reject."

First, what that sufficient certainly means will be a matter of
policy, and could well require that the message be authenticated as
coming from the listed entity (via SPF or DKIM, or perhaps through
some private arrangement).

Second, the message might still go through other evaluation, such as
normal spam filtering, and could be discarded, rejected, or
quarantined on that basis.

I see no reason to avoid talking about using such allow lists, and I
see it as beyond our scope to say how a receiving domain decides what
to put on such lists or how it assures itself that a message qualifies
for the special handling the list provides (apart from saying
something like the "sufficiently certain" above).

Barry

On Wed, Aug 2, 2023 at 9:46 PM Douglas Foster
 wrote:
>
> A nit on whitelisting.
>
> I suggest that we use the term "Alternate Authentication" rather than 
> "Whitelisting".   In my experience, whitelisting often implies exemption from 
> both authentication checks and content checks.When an administrator 
> simultaneous disables both types of defenses, his environment depends 
> entirely on the hope that malicious impersonators will not stumble on the 
> vulnerability.   The correct solution for failed authentication (on wanted 
> messages) is to provide an alternate authentication implemented as local 
> policy.  Our document should make this clear.
>
> Doug
>
>
> On Wed, Aug 2, 2023 at 6:34 AM Alessandro Vesely  wrote:
>>
>> On Mon 31/Jul/2023 16:47:15 + Hector Santos wrote:
>> > - I highlighted that "SPF Comes First" before DMARC or DKIM is known. It is
>> > entirely possible that an SPF restrictive policy (-ALL, Hard Fail) can
>> > preempt the payload transfer, causing a rejection before the DATA is
>> > reached. DMARCbis does acknowledge this possibility, mentioning that
>> > receivers might process SPF rejects before DMARC is known.
>>
>>
>> Rejecting before DATA is mentioned in Section 5.8, Policy Enforcement
>> Considerations, as well as in Section 8.1, Issues Specific to SPF.  I
>> suggest the former succinctly reference the latter.
>>
>>
>> >- I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407)
>> > protocols as an implementation detail to access the author's DMARC policy
>> > at the SMTP "MAIL FROM" stage. Wei expressed interest in this idea. This
>> > could also enhance the "auth=" idea to help manage local policy SPF -ALL
>> > handling. Should SMTP immediately reject? The PRA at SMTP could aid this
>> > decision for SPF -ALL policies. Based on many years of implementation, it's
>> > evident that many mailers are either identical or are using the same
>> > software that supports SUBMITTER/PRA, possibly due to ongoing support for
>> > the deprecated SenderID (RFC4406) protocol.   Here is a small snippet of
>> > this morning transaction using submitter:
>>
>>
>> Appendix D of RFC 7208 suggests to use whitelisting as a general mitigation
>> for forwarding.  To delay rejection until after DKIM verification would be
>> an even softer mitigation.  Can this be mentioned in Section 8.1?
>>
>> Of course, a sender doesn't know what SPF mitigations the receivers apply.
>> Still, whitelisting oils the wheels.
>>
>>
>> Best
>> Ale
>> --
>>
>>
>>
>>
>>
>>
>> ___
>> 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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Barry Leiba]

The IETF's policy is to consider replacing these obsolete terms; there
is no mandate.

That said, I will push us strongly to do so: there is no harm in using
"block list" and "allow list" instead, and we should.

Barry

On Thu, Aug 3, 2023 at 1:53 PM Steven M Jones  wrote:
>
> On 8/3/23 12:50 AM, Alessandro Vesely wrote:
> >
> > There is a push to avoid names that might recall racial prejudice, so
> > blacklists are sometimes called blocklists...  The mentioned Appendix
> > D talks about "whitelists of generally recognized forwarding
> > services".  I support sticking to classic names, since any racial
> > prejudice is only in the ears of the listeners, and not implied by
> > those terms.  Don't let political correctness make us color-blind.
>
>
> Many organizations now have policies relating to these language choices,
> often under more programs like "diversity, equity, and inclusion" or
> similar. We may have no choice but to conform if such a policy has been
> published for the IETF as a whole.
>
> A quick check of https://www.ietf.org/diversity/ seems to mostly focus
> on gender, families (childcare) and the English language. A skim of
> 2015's RFC 7704 (https://datatracker.ietf.org/doc/html/rfc7704) seems to
> focus more on participants and behavior. Anybody know if the language
> choices have been addressed elsewhere?
>
> --S.
>
>
> ___
> 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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Steven M Jones]

On 8/3/23 12:50 AM, Alessandro Vesely wrote:


There is a push to avoid names that might recall racial prejudice, so 
blacklists are sometimes called blocklists...  The mentioned Appendix 
D talks about "whitelists of generally recognized forwarding 
services".  I support sticking to classic names, since any racial 
prejudice is only in the ears of the listeners, and not implied by 
those terms.  Don't let political correctness make us color-blind.



Many organizations now have policies relating to these language choices, 
often under more programs like "diversity, equity, and inclusion" or 
similar. We may have no choice but to conform if such a policy has been 
published for the IETF as a whole.


A quick check of https://www.ietf.org/diversity/ seems to mostly focus 
on gender, families (childcare) and the English language. A skim of 
2015's RFC 7704 (https://datatracker.ietf.org/doc/html/rfc7704) seems to 
focus more on participants and behavior. Anybody know if the language 
choices have been addressed elsewhere?


--S.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Hector Santos]

On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote:
On Mon, Jul 31, 2023 at 9:47 AM Hector Santos 
> wrote:


   - I mentioned using the deprecated SUBMITTER/PRA
(RFC4405/RFC4407)
protocols as an implementation detail to access the author's DMARC
policy at the SMTP "MAIL FROM" stage. Wei expressed interest in
this
idea. This could also enhance the "auth=" idea to help manage local
policy SPF -ALL handling. Should SMTP immediately reject? The
PRA at
SMTP could aid this decision for SPF -ALL policies. Based on many
years of implementation, it's evident that many mailers are either
identical or are using the same software that supports
SUBMITTER/PRA,
possibly due to ongoing support for the deprecated SenderID
(RFC4406)
protocol.  [...]


Can you or Wei spell this out a little more?  What could a list 
subscriber do with this algorithm that we don't have today?


The issue we're facing in a DMARC world isn't determining who the 
original sender is, but rather that with broken signatures, we can't 
prove it to DMARC's satisfaction.  I'm not clear on how your idea 
fixes that.




The utilization of SUBMITTER/PRA protocols possibly can help manage 
situations where SPF fails before any DKIM information is accessible. 
This strategy provides SPF processors with preliminary DMARC policy 
data, potentially mitigating the impact of SPF hard-fail situations. 
The advantages of this approach are especially clear when SPF fails, 
but DMARC can help to temper the initial rejection.


Through the SUBMITTER/PRA, it's possible to ascertain the presence of 
a DMARC p=none or an auth=dkim, giving operators the choice to delay 
immediate rejection and verify DKIM instead.


In the context of a mailing list, using a SUBMITTER in the 
distribution can prove useful. For instance, a list might not need to 
rewrite if it identifies an auth=spf for the domain, allowing it to 
function as a resigner although the original domain integrity was 
broken.   There might be a  auth=arc which ARC is needed for pass 
broken 1st party signature.


I know this is out of scope, but legacy scenarios may included 
checking for the 'atps=y' tag and check for an ATPS DNS authorization 
record for the resigner domain. There still many domains who don't use 
DMARC but instead still have ADSP dkim=all to expose a mail policy - 
"Expect all my mail to be signed."


However, at present, the most plausible use-case appears to be the 
addition of delayed SPF rejection scenarios through DMARC evaluation. 
Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to 
soften the impact of SPF -ALL policies.


The approach might work as follows:

- If SPF fails and the Submitter indicates p=reject, then reject 
(comes with its acceptable problems)


- If SPF fails, the Submitter specifies p=reject and auth=dkim, then 
proceed to transfer the payload and evaluate DKIM


- If SPF fails and the Submitter signifies p=none, then continue with 
payload transfer


- If SPF fails and the Submitter designates p=quarantine, then proceed 
with payload transfer


SUBMITTER may help align SPF with its original DMARC purpose—combining 
SPF+DKIM results while keeping with some level of optimization.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

[Alessandro Vesely]

On Thu 03/Aug/2023 01:45:44 + Douglas Foster wrote:

A nit on whitelisting.

I suggest that we use the term "Alternate Authentication" rather than 
"Whitelisting".   In my experience, whitelisting often implies exemption 
from both authentication checks and content checks.



IME, whitelist means exemption from whatever penalizing process.  Exemption 
from immediate rejection is the softest exemption I can think of about 
SMTP, as it is still possible to reject after DATA.


There is a push to avoid names that might recall racial prejudice, so 
blacklists are sometimes called blocklists...  The mentioned Appendix D 
talks about "whitelists of generally recognized forwarding services".  I 
support sticking to classic names, since any racial prejudice is only in 
the ears of the listeners, and not implied by those terms.  Don't let 
political correctness make us color-blind.



Best
Ale
--







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc