[dmarc-ietf] Re: New attack leveraging DMARC None

[Dotzero]

On Tue, May 7, 2024 at 9:27 PM Scott Kitterman  wrote:

> On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote:
> > On 5/7/2024 7:00 PM, Dotzero wrote:
> > > https://www.ic3.gov/Media/News/2024/240502.pdf
> > >
> > > This was released this past week by the FBI. Although we are in last
> > > call, I have to wonder if a) the attack itself, and/or b) the
> > > government recommendations regarding policy might impact DMARCbis in
> > > any manner. I've only just started thinking about the attack itself
> > > and potential implications.
> > >
> > > Michael Hammer
> >
> > While the subject is interesting, in my eyes, Business Email Compromise
> > (BEC), and a non-preferential DMARC policy disposition published by the
> > spoofed domain owner aren't an issue with the DMARC mechanism itself.
> > The receiving mail system did exactly what the domain owner requested
> > with p=none, no disposition was taken on email(s) failing DMARC.
> >
> >  From an alternate point of view, one might consider how this policy
> > could be more broadly "exploitable" as a side effect now that the
> > internet email ecosystem is inundated with p=none DMARC records by
> > domain owners just doing the bare minimum to meet ESP sender
> > requirements, but that's still not a problem with DMARC itself.
> >
> > Addressing this issue - perusing Section 5.5.6, is there anything else
> > we could add that would be acceptable language in an Standards track
> > document to encourage urgency behind a transitory state of p=none use by
> > domain owners? Would that even make sense to do? (Legitimate question
> > for the WG)
>
> I don't think the claim that p=none is "transitory" is at all generally
> correct.  It will be in some cases and not others.
>
> Scott K
>

This reflects one concern that came to mind fairly quickly. When we
originally came up with DMARC it was intended for use by domains sending
transactional mail and which did not have individual users or very limited
individual users. There has been a certain amount of coercion by some large
mailbox providers to incentivize email authentication, including DMARC.
Publishing P=none is one way of meeting those requirements. These attacks
and the recommended response by the FBI put domains with individual users
in a difficult position.

One might say this is an operational issue and leave it at that. This
doesn't strike me as right but I'm not sure what the working group might
reasonably do/say in DMARCbis about an operational issue..

Michael Hammer
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] New attack leveraging DMARC None

[Dotzero]

https://www.ic3.gov/Media/News/2024/240502.pdf

This was released this past week by the FBI. Although we are in last call,
I have to wonder if a) the attack itself, and/or b) the government
recommendations regarding policy might impact DMARCbis in any manner. I've
only just started thinking about the attack itself and potential
implications.

Michael Hammer
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Re: [dmarc-ietf] Overall last-call comments on DMARC

[Dotzero]

On Thu, Apr 4, 2024 at 1:42 PM Murray S. Kucherawy 
wrote:

> On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Murray, I was hoping your proposal to advance ARC was serious.
>>
>
> If people think (and have evidence that) ARC is ready, then why would I
> not be serious?
>
> The WG needs to resolve that "if" though.
>

A while back in the working group I asked people to provide data showing
the efficacy of ARC. The response was crickets. What I see now is a bunch
of hand waving but again, no data that can be evaluated. I am not against
ARC but it needs to be evaluated on its own merits. It is a separate
document and should not be conflated with DMARC. I'll also point out that
WGLC is the inappropriate time to throw something new in the hopper, "just
because".


>
>
>> To Ale's concerns, I think a registration process would help mailing
>> lists, but there are many options, and we do not need to define one single
>> solution.   Most of the mailbox providers already have a registration
>> process for bulk senders, with a feedback loop for problem situations.  I
>> see plenty of opportunity for them to build on that.
>>
>
> This also needs to be described if we think that's a part of the solution.
>

Again, WGLC is not the appropriate time to start throwing out new and
undocumented proposals.

>
> My overall point is that this thread makes it seem like we're not putting
> forward a complete solution.  It feels a lot more like a proposed standard
> that for its clear success depends on a bunch of other things that range
> from experimental to abstract to undefined.  And if that's a correct
> summary, I'm asking if that's what we really want to do.  It seems a little
> haphazard, like we're scrambling to tie together the loose ends of a movie
> plot.  We need to do a good job of bringing our audience to as solid a
> conclusion as possible, or the critics' reviews might not come out well.
>

My response to your statement "... this thread makes it seem like we're not
putting forward a complete solution." is a complete solution to what? It
seems like people are trying to throw in everything but the kitchen sink,
including new proposals and rehashing old issues that were supposedly
settled, as we go through last call.

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

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Dotzero]

On Wed, Apr 3, 2024 at 5:21 AM Laura Atkins  wrote:

>
> On 1 Apr 2024, at 13:18, Brotman, Alex  40comcast@dmarc.ietf.org> wrote:
>
> One item left out of Seth’s text is that due to MBPs who act in this
> fashion, these SPF evaluation failures will (understandably) not show up in
> DMARC reports, and the domain owner may not have visibility for these
> failures.  However, the text also puts the onus on the domain owner instead
> of the MBP.  The text could be altered to instead suggest that MBPs who
> deploy DMARC should not utilize the outcome of SPF in this fashion.  If the
> domain owner wants to protect their domain, and has no idea if the MBP
> supports DMARC properly (presuming they also have an enforcing policy), is
> it more or less advisable to use “-all” with your SPF record?
>
>
> Is that true, though?
>
> I just saw a report yesterday that someone had temp failures at Gmail (73
> to be exact) and Gmail sent 73 DMARC reports for that sender / IP combo.
>
> So that’s one bit of evidence that even if the message is not accepted,
> DMARC reports are sent.
>
> laura
>
> --
> The Delivery Expert
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Delivery hints and commentary: http://wordtothewise.com/blog
>


This implies that the messages were not rejected at SPF (connection but
before "DATA" command) but instead the connection was held open in order to
evaluate SPF as part of DMARC. This is a different scenario than a MBP
rejecting on the basis of SPF before DMARC evaluation.

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

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Dotzero]

On Mon, Apr 1, 2024 at 8:18 AM Brotman, Alex  wrote:

> One item left out of Seth’s text is that due to MBPs who act in this
> fashion, these SPF evaluation failures will (understandably) not show up in
> DMARC reports, and the domain owner may not have visibility for these
> failures.  However, the text also puts the onus on the domain owner instead
> of the MBP.  The text could be altered to instead suggest that MBPs who
> deploy DMARC should not utilize the outcome of SPF in this fashion.  If the
> domain owner wants to protect their domain, and has no idea if the MBP
> supports DMARC properly (presuming they also have an enforcing policy), is
> it more or less advisable to use “-all” with your SPF record?
>
>
>
> I’d be curious to see the Venn diagram of MBPs who implement SPF in this
> fashion, and also fully support DMARC.  I feel like the MBPs who I’ve
> encountered deploying an SPF check in this way had not at the time
> supported DMARC.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
I was just thinking along these lines and was going to post but you beat me
to the punch.

+1

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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[Dotzero]

On Mon, Mar 18, 2024 at 2:38 AM John R Levine  wrote:

> On Sun, 17 Mar 2024, Dotzero wrote:
> >> Whenever mail is sent, there is a risk that an overly permissive source
> >> may send mail which will receive a DMARC pass result that was not, in
> >> fact, authorized by the Domain Owner. These false positives may lead
> >> to issues when systems interpret DMARC pass results to indicate
> >> a message is in some way authentic. They also allow such unauthorized
> >> senders to evade the Domain Owner's requested message handling for
> >> authentication failures.
>
> > I have a problem with this 2nd paragraph and believe it is factually
> > incorrect. The Domain Owner has in fact authorized the message(s) as a
> > result of an overly permissive approach. I would suggest that in fact any
> > resulting DMARC pass is technically NOT a false positive because it is
> > authorized by the overly permissive approach..
>
> Seems to me we it depends on what you think "authorized" means.  My sense
> is I told you it's OK to send the message, yours seme to be that any host
> on an IP in the SPF record or anyone who steals your DKIM key is
> authorized by definition.
>
> Is there some other wording that can make the difference clear?
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly



Here's a quick stab at some modified wording for the second paragraph:

Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, intended by the Domain Owner. These results may lead
to issues when systems interpret DMARC pass results to indicate
a message is in some way authentic. They also allow such unauthorized
senders to evade the Domain Owner's intended message handling for
authentication failures.

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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[Dotzero]

On Sun, Mar 17, 2024 at 9:36 PM John Levine  wrote:

> Tightened up a little, reworded in view of the fact that your own
> mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
> >11.X  External Mail Sender Cross-Domain Forgery
>
> Add this to 11.1 Authentication Methods
>
>
> Both of the email authentication methods that underlie DMARC provide
> some assurance that an email was transmitted by an MTA which is
> authorized to do so. SPF policies map domain names to sets of
> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM
> signatures indicate that an email was transmitted by an MTA with
> access to a private key that matches the published DKIM key record.
>
> Whenever mail is sent, there is a risk that an overly permissive source
> may send mail which will receive a DMARC pass result that was not, in
> fact, authorized by the Domain Owner. These false positives may lead
> to issues when systems interpret DMARC pass results to indicate
> a message is in some way authentic. They also allow such unauthorized
> senders to evade the Domain Owner's requested message handling for
> authentication failures.
>

I have a problem with this 2nd paragraph and believe it is factually
incorrect. The Domain Owner has in fact authorized the message(s) as a
result of an overly permissive approach. I would suggest that in fact any
resulting DMARC pass is technically NOT a false positive because it is
authorized by the overly permissive approach..

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

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

[Dotzero]

Neil, SPF essentially deals with hosts and IP address ranges. Your
suggested solution does not address the main problem(s) raised in the
research.

One approach that potentially addresses the SPF problem of shared hosting
would be for ESPs to use IPv6 address space for sending. Each customer can
then be assigned unique IP addresses. An approach like this causes other
potential operational problems, for example infrequent senders (think of a
monthly newsletter sent at the beginning of each month). The issues
presented by Chuhan Wang have actually been known and understood for quite
sometime even if not well documented for a wider audience.

I do agree that the title is misleading.

Michael Hammer

On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz  wrote:

> The solution to that vulnerability is in part use a subdomain and, when
> possible, narrow the scope of what you permit. Better yet, choose a vendor
> that’s known for tight security. A quick Look at the the security headlines
> will show you some vendor red flags. But the sad state of spf is a
> misleading title at best,
>
> On Mar 4, 2024, at 8:37 PM, Chuhan Wang 
> wrote:
>
> 
>
> Hi Everyone,
> I am Chuhan Wang from Tsinghua University, the author of paper *BreakSPF:
> How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet.*
>
> Thanks Barry for sharing our paper presented at NDSS regarding the
> vulnerabilities of SPF in this work group. I'm glad to see that our
> research on BreakSPF is being discussed in the IETF work group. It's
> encouraging to know that our work is contributing to important
> conversations about email security.
>
> I am willing to discuss any questions or concerns that may arise from our
> paper. Please feel free to reach out to me, and I'll be more than happy to
> discuss our findings and insights with the group.
> Chuhan Wang
> Tsinghua University
>
> Begin forwarded message:
>
> *From: *Barry Leiba 
> *Subject: **[dmarc-ietf] The sad state of SPF: research just presented at
> NDSS*
> *Date: *February 28, 2024 at 17:33:41 CST
> *To: *IETF DMARC WG 
>
> A paper was presented this morning at NDSS about the state of SPF, which
> is worth a read by this group:
>
>
> https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
>
> Barry
> ___
> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Dotzero]

I agree that the rough consensus landed on "SHOULD NOT" even though there
were some who felt "MUST NOT" was "purer". I was one of those who
(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
consistency within the document to match the outcome that there was rough
agreement on. That is the new issue he is opening and not rehashing the
previously closed issue.

Hopefully the chairs will rule on this so we don't have a previous issue
reopened during last call.

Michael Hammer

On Thu, Feb 29, 2024 at 2:53 PM Seth Blank  wrote:

> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
>
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
> wrote:
>
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
>> right?
>>
>> Scott K
>>
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>> oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to
>> death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no
>> doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>> first
>> >> >set of minor edits and I came across a sentence that I believe goes
>> beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
>> "It
>> >> is
>> >> >therefore critical that domains that host users who might post
>> messages to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
>> yes?
>> >> >
>> >>
>> >> ___
>> >> 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
>>
>
>
> --
>
> *Seth Blank * | Chief Technology Officer
> *e:* s...@valimail.com
> *p:*
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> 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] DMARC with multi-valued RFC5322.From

[Dotzero]

On Fri, Jan 19, 2024 at 10:20 AM Todd Herr  wrote:

> On Thu, Jan 18, 2024 at 9:28 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> As a long time implementer and integrator of IETF protocols, my mail
>> engineering view ….
>>
>> The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header
>> to have multiple addresses:
>>
>> from = "From:" mailbox-list CRLF
>> mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
>>
>
> True, but in such cases, it requires that there be a Sender: header with
> exactly one mailbox as a value -
> https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2
>
>
> [snip]
>>
>
>
>>
>> However, if I have been following this thread, DMARCBis was updated to
>> ignore these multi-from messages for DMARC purposes because they
>> (erroneously) presumed they should be rejected, i.e. never make it to a
>> signer or verifier.
>>
>> I am not sure that is correct.
>>
>
> Perhaps the way forward for DMARC is to look for a Sender header when
> there is more than one RFC5322.From domain and use that for DMARC
> processing, with the stipulation that messages that don't contain such a
> Sender header are invalid and should be rejected?
>

The problem with relying on the Sender header is that unless a Sender
header matches the right hand side (domain) of the email address in the
>From field, you can't tell if there is a legitimate relationship between
Sender and From.

I think the correct approach is for DMARC to recognize this is a very tiny
corner case that very rarely shows up in the real world and ignore it.

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

Re: [dmarc-ietf] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)

[Dotzero]

On Wed, Oct 25, 2023 at 10:04 AM Todd Herr  wrote:

> On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba 
> wrote:
>
>> Now that we have a consensus call on the main issue that has remained
>> open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else) further?
>>
>> ...or...
>>
>> 2. Do we have what we need to finish up the DMARCbis document, and
>> should the chairs cancel the session at 118?
>>
>> Oh, and...
>>
>> 3. Is there something else (such as the reporting documents) that we
>> should use the time at 118 to discuss?  Or can we continue with those
>> on the mailing list for now?  My sense is that aggregate reporting, at
>> least, is just about ready to go and doesn't need the face-to-face
>> time.
>>
>>
> I think canceling the session at 118 is the way to go.
>
> I further think that the best way to produce the next rev of DMARCbis is
> for the chairs and the editors (and perhaps the ADs) to huddle together and
> create/update issues in the Github repository for the sections of text for
> which changes have been proposed. At a minimum, the outcome of this meeting
> would be several bullet points all following this pattern:
>
>- Create/update GitHub issue with $TITLE using text from
>$MAILING_LIST_THREAD
>
> Todd, as editor whose mail client isn't one that lends itself well to
> piecing together multiple threads into a coherent list...
>
> --
>
> *Todd Herr * | Technical Director, Standards & Ecosystem
> *e:* todd.h...@valimail.com
> *p:* 703-220-4153
> *m:* 703.220.4153
>
>

I never saw a response to this post to the list by Todd. As we reach the
end of 2023 and the start of 2024, I agree that the chairs, AD and editors
should address what issues are left to be addressed and/or need to be added
to the list of on-topic open issues. In the interest of completing the
working groups objectives, off-topic posts/threads should be shut down
quickly so that we can focus on resolving open on-topic issues.

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

Re: [dmarc-ietf] DMARC marketing on NPR

[Dotzero]

On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> The gap between what is being attempted and what is needed is a huge
> personal disappointment.
>
> The DMARC goal should be to block malicious impersonation without blocking
> wanted messages, where "wanted" is in the eyes of the evaluator and his end
> user.That puts the onus on the evaluator.   RFC 7960 said that
> evaluators need to be aware of problems, but gave no solutions.   DMARCbis
> replaces the evaluator with a mindless automaton, repeating all the worst
> mistakes of RFC 7489.
>
> This is from a real-world conversation with a product support tech:
>Me:  I cannot use your DMARC implementation because it does not have an
> exception mechanism.
>Him:   Why would you need exceptions?
> I blame his ignorance, and his product's inadequacies, on RFC 7489, which
> defined no exceptions.
>
> RFC 7489 falsely divides the mail stream into four groups:
>
>- Authenticated / Pass,
>- Unauthenticated without Prejudice (None),
>- Unauthenticated with Prejudice (Quarantine/Reject), and
>- No Result.
>
> In reality, there are only two possible states:  Authenticated and Not
> Authenticated.
>
>- The Mailing List problem proves that the distinction between None
>and Reject is a fiction.  At best, Fail with Reject justifies a slightly
>higher risk weight for environments that depend on weighting.
>- "No Result" is an error in RFC 7489.The PSL and default
>alignment rules allowed a result to be calculated on any domain.   An
>evaluator cannot excuse a decision to allow malware infestation by saying,
>"the domain owner did not give me permission to check for malicious
>impersonation."   "No Result" is another way of saying, "I did not do my
>job."
>- Any unauthenticated message is a potential impersonation.  It is the
>evaluator's job to figure out whether malicious impersonation actually
>occurred or not.
>
> Authentication failure provides a starting point, not an end point.  The
> risk of malicious impersonation applies to every unauthenticated message.
>
> Correct evaluation fixes the mailing list problem and fixes a lot of other
> false blocks, while blocking the malicious traffic that RFC 7489 leaves
> unmolested.
>
> We need a document that is targeted at evaluators, to help them make
> correct disposition decisions for their organizations.   The current
> document blames the charter as the reason that it does not even try.
>
> Doug Foster
>

You are absolutely incorrect when you state that there are no exceptions
provided. "Local policy"  enables an evaluator to implement any
exception(s) they wish.

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz 
wrote:

> Michael, I’m realizing I started this discussion thinking we were talking
> about failure reports and a bit about aggregate reports when I think we
> might have pivoted to Feedback Loops and I was so focused on reports, I
> failed to register the change. Or just as likely it was FBL’s the whole
> time. Either way I apologize for the back and forth. I see what you were
> saying when I notice the word FBL that I somehow missed.
>
>
> Neil
>

These reports are a type of FBL (feedback loop).

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz 
wrote:

>
> The fact that you aren't seeing failure reports doesn't mean they aren't
> being generated. My experience has been that they are being made available
> through 3rd parties where there is a contractual relationship.
> >
> > Michael Hammer
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> Michael, then if you say that’s how it works via third parties then I
> believe you. I’m surprised I never knew that somehow. I always thought that
> the major MBPs sent their own aggregate and failure reports. I do learn
> something new every day but this one caught me off guard. What I have heard
> of is companies you could hire to manage your feedbacks for you as a
> service. The part I missed was these companies actually generating and
> sending failure reports receivers. I’ve not found a company with a quick
> web search but I’ll try again later. They don’t also send the agg reports
> for their clients to only failure reports? I will do a deeper web search
> later as now I’m feeling a bit of cognitive dissonance and so want to read
> up on how this service works.


Our original intent (I'm one of the folks behind DMARC) was that failure
reports would be provided to senders just like aggregate reports. This was
before GDPR and privacy concerns did a number on the practice. The
companies that provide the service of managing these FBLs for you typically
allow you to view and/or download the reports.

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Sat, Nov 11, 2023 at 9:17 AM Neil Anuskiewicz  wrote:

>
>
> On Oct 25, 2023, at 3:57 AM, Olivier Hureau <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
> 
> On 25/10/2023 08:10, Steven M Jones wrote:
>
> It's not so much changing the handling as changing the reporting.
>
> * The policy to apply is "none," because the p/sp/np value was faulty.
> Done.
> * Next step, if there's no "rua" target you can't report - which is now
> equivalent to bailing out of DMARC processing for this message.
>
> I am not fan of this exceptions, it breaks the ABNF ... 'A DMARC policy
> record MUST comply with the formal specification found in Section 5.4
> 
> '
> The record 'v=DMARC1; p=foobar; rua=mailto:r...@example.com
> ' does not comply with the formal specification (ABNF
> rule dmarc-request)
> Furthemore, 'mailto://example.com ' is a valid URI
> according to RFC3986. If we take into consideration the record 'v=DMARC1;
> p=foobar; rua=mailto://example.com ' : a 'rua' tag is
> present and contains at least one syntactically valid reporting URI (no
> need to have a mailto). Who are we going to send the reports specifying the
> errors?
>
> What about using the error report of RFC 7489 for this purpose instead of
> aggregate report? (
> https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 )
>
> I have never seen any error report but I think that error reports were a
> great ideas because they can advertise the domain owner (through the valid
> URI) for any failing external destination verification
> We could also use the error reports for  to reports any syntactic errors
> in the record could be also useful, in my opinion.
>
> Email is not dead! Now the bad news: error reports (commonly called
> failure or forensic reports are not long for this world. The only major MBP
> that I see failure reports from is Yahoo. I’m not advocating eliminating
> failure reports altogether as when one of these mythical creatures appears
> they can be very useful. But I wonder if Yahoo discusses stopping failure
> reports then failure reports would be far less useful. I do understand the
> PII concerns.
>
> My point is that the concept of failure reports sounds good in theory but
> I’d say we are in irons now with a decent chance of running aground. It
> might be an opportune time to rethink the failure report. I don’t know.
>

The fact that you aren't seeing failure reports doesn't mean they aren't
being generated. My experience has been that they are being made available
through 3rd parties where there is a contractual relationship.

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

Re: [dmarc-ietf] DMARC session at IETF 118

[Dotzero]

On Sat, Oct 28, 2023 at 1:38 PM Barry Leiba  wrote:

> I'm starting this in a separate thread that I want to keep for ONLY
> the following question:
>
> Do we want to use the session we have scheduled at IETF 118 to talk
> about the issue that clearly is still in discussion about adding a tag
> to specify which authentication mechanism(s) to use when evaluating
> DMARC?
>
> Or shall I cancel the 118 session and just let the discussion continue
> on the mailing list?
>
> And being clear here: the "eliminate SPF entirely" suggestion is
> definitely out, failing rough consensus.  We're *only* talking about
> the suggestion to add a tag to specify what the sender wants.
>
> Barry
>

Let the discussion continue on the list. Personally I think there has been
enough discussion that there can be a call for consensus.

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Thu, Oct 26, 2023 at 8:25 PM Scott Kitterman 
wrote:

>
>
>
> I propose that we not repeat this discussion and instead, try to focus on
> finishing.
>
> Scott K
>


Agreed.  +1

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman 
wrote:

>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely 
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
>  * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the Domain Owner wants Receivers to
> use?  If so, it doesn't seem to be in the document yet.
> >>>
> >>> My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge cases of domains with over-wide SPF policies, since they proved to
> be vulnerable to false DMARC pass.  The WG discussed the possibility to
> also require both methods to limit replay, and concluded that the idea was
> a foot gun.  Hence the WG agreed on the comma syntax.
> >>
> >> My reading of the discussion is:
> >>
> >> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> >
> >
> >Yes.
> >
> >
> >> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
> >
> >
> >One thread started here:
> >https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
> >
> >It ends up with Wei recapitulating the thread and summarizing the changes
> to the draft.  No objections.  I expected those changes to be carried out.
> >
> >
> >> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
> >
> >
> >I had only seen Scott's reading, which surprised me.  After you and
> Michael hold that no agreement was reached, I begin to doubt of my reading
> myself.
> >
> >In particular, since there is a paper[*] showing how a "spoofed email
> >purporting to be b...@state.gov is delivered to a Gmail user’s inbox
> with no warning indicators", Wei's argument seemed to be fully reasonable.
> >
> >What outstanding objections were there?
>
> The purported use case is "my SPF is so awful you can't trust it and at
> the same time, so critical I still have to publish the record".  I don't
> think that's a real thing.
>
> If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
>

+1

We need to stop confusing operational/implementation issues on the part of
some with issues that reflect poor logic in a standard.

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba  wrote:

> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge
> > cases of domains with over-wide SPF policies, since they proved to be
> > vulnerable to false DMARC pass.  The WG discussed the possibility to also
> > require both methods to limit replay, and concluded that the idea was a
> foot
> > gun.  Hence the WG agreed on the comma syntax.
>
> My reading of the discussion is:
>
> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>

+1


> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
>

+1


> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
>
>
Mi chael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Additional Document, was Re: Dmarcbis way forward

[Dotzero]

I changed the subject line to differentiate the discussion regarding an
additional document from the consensus thread.

On Tue, Oct 24, 2023 at 1:15 PM Murray S. Kucherawy 
wrote:

> [trimming redundant Ccs]
>
> On Tue, Oct 24, 2023 at 9:41 AM Dotzero  wrote:
>
>> I'd like to first thank Francesca for taking the time to review where the
>> working group is as far as consensus.
>>
>
> +1, that was a lot to sift through.
>
> The short version of the non-normative language should be in the document
>> itself but I believe the issues resulting from deviating from the normative
>> "SHOULD NOT" deserve a fuller discussion in a separate document.
>>
>
> What's the likelihood that a separate document would be consulted if it
> existed?
>

Some would consult it and many would not. This is no different than some
will read the RFC and many will not. Notice that  did not specify that the
additional document should be an IETF document. I'm flexible in that
respect.

>
> I think I'd prefer to see exposition on this topic in an appendix of the
> -bis document.  I'm not convinced the WG has the energy to produce another
> Informational just about this, covering the stuff you listed.
>

 I'm not against this but it would certainly hold up completion of the -bis
document.

>
> I'm also wondering whether documents like RFCs 6377 and 7960 already
> sufficiently cover the issues we're talking about here.  I suppose we
> haven't discussed the mitigations that are in play already (even though
> people don't like them).
>

I envision a document discussing the considerations and issues surrounding
the specific choice of implementing a p=reject policy. This was part of the
email authentication training I and a few others used to give in the
2010-2012 timeframe through the Online Trust Alliance (now part of the
Internet Society).

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

Re: [dmarc-ietf] Dmarcbis way forward

[Dotzero]

I'd like to first thank Francesca for taking the time to review where the
working group is as far as consensus.

I fall into the "SHOULD NOT" consensus group with additional non-normative
language.

The short version of the non-normative language should be in the document
itself but I believe the issues resulting from deviating from the normative
"SHOULD NOT" deserve a fuller discussion in a separate document.

Much of the discussion has been focused on the impact to mailing lists but
the impacts can involve a wider range of issues depending on the nature of
the domain/organization and users involved. A discussion of those wider
impacts in the context of a "SHOULD NOT" would be useful in educating
domain owners, administrators and (even) users. There are differences in
control and impacts between a corporate/organizational domain, government
domains, domains which offer free or paid accounts to the public and
personal domains for example. Advice to one of these groupings may not
reasonably address the concerns and impacts for domains or constituencies
in other groupings.

Michael Hammer




On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini  wrote:

> I have been asked by Murray to assist with a consensus evaluation on the
> discussion that has been going on for a while about the dmarcbis document
> and how to move forward.
>
>
>
> I have made an attempt to evaluate consensus on the topic, trying to look
> at it from a complete outsider’s point of view and trying not to let my
> personal opinion bias my assessment. This is a summary of that evaluation.
> It is based on several threads in the mailing list: [1], [2], [3] and
> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
> chronology of comments, because some people have expressed different
> support for different proposals, in which case I consider the latest
> email I can find as the person’s latest opinion.
>
> Although that was mentioned, I believe there is no consensus to move the
> document status to Informational. I believe there is a rough consensus that
> a change needs to be made in the text to include stronger requirements
> admonishing operators against deploying DMARC in a way that causes
> disruption. The mails go in many directions, but the most contentious point
> I could identify is if there ought to be some normative MUST NOT or SHOULD
> NOT text. Many people have suggested text (thank you!). I believe the ones
> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD
> NOT proposal [3]. I believe most people who’d prefer just descriptive text
> have stated that they can live with the SHOULD NOT text, but they have
> stronger objections towards the MUST NOT text. There also a number of
> people who strongly believe MUST NOT is the way to go, but these people
> have not objected strongly to Barry’s latest proposed text in the mailing
> list (although they have made their preference clear during the meeting
> [4]). As a consequence, I believe there is a stronger (very rough)
> consensus for going with Barry’s SHOULD NOT text. I also believe there is
> consensus to add some non-normative explanatory text (be it in the
> interoperability or security consideration sections, or both) around it.
>
> I suggest the authors and the working group start with Berry’s text and
> fine-tune the details around it.
>
> In particular, as another AD that might have to ballot on this document, I
> suggest that you pay particular attention to the text around the SHOULD
> NOT, as also Murray suggested in [5]. I have often blocked documents with
> the following text: “If SHOULD is used, then it must be accompanied by at
> least one of: (1) A general description of the character of the exceptions
> and/or in what areas exceptions are likely to arise.  Examples are fine
> but, except in plausible and rare cases, not enumerated lists. (2) A
> statement about what should be done, or what the considerations are, if the
> "SHOULD" requirement is not met. (3) A statement about why it is not a
> MUST.”.
>
> I appreciate everybody’s patience and constructive discussion.
>
> Francesca, ART AD
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>
> [2]:
> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>
> [3]:
> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>
> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>
> [5]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
> ___
> 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] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Fri, Oct 20, 2023 at 11:14 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> Hi,
>
> > The correct solution is that the person responsible for creating the
> problem record should fix the problem record they created.
>
> How does downgrading p=reject to p=none help the person responsible for
> creating the problem record to fix it?
>
> If it is by looking at the aggregate report, sp and np DispositionType is
> enough, no need to change p
>
> Olivier
>

There is no "p" if the syntax is incorrect. It really is as simple as that.
"p" isn't changed because there was no valid "p" in the first place. I'm
surprised you aren't asking for any string including a "q" to be considered
valid.

Michael Hammer

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Fri, Oct 20, 2023 at 10:39 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> Hi,
>
> > Why would we even consider going down this path?
> I am considering this pass in order to fix any miscomprehension in the RFC.
>
> > Why do you only consider "fixing" quarantine with a dropped "e"? Why
> don't you want to fix all the other potential mispellings of quarantine?
> > Should quarntine be a candidate   for "fixing"? If not, why not?
>
> I think I wasn't clear enough.
> I am not concerned about fixing misspelled tags, I am only concerned about
> the possible "downgrade" of p=reject to p=none if sp/np tag is not valid
> (and rua is present)
>
>
>
> Regards,
> Olivier
>
>
The correct solution is that the person responsible for creating the
problem record should fix the problem record they created.

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Dotzero]

On Fri, Oct 20, 2023 at 9:51 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> Hi,
>
> Assuming that the comma is an Oxford comma, I do interpret the sentence
> with the following boolean:
>
> ( 'retrieved policy record does not contain a valid "p" tag'  || contains
> an "sp" or "np" tag that is not valid ) && ( a "rua" tag is present and
> contains at least one syntactically valid reporting URI )
>
> Nevertheless, I forgot to add the "rua" tag in the previous email:
>
> > 'v=DMARC1; p=reject; sp=quarantin;'  (an 'e' is missing at 'quarantine')
> MUST
> > be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid.
>
> Should be  :
>
>  'v=DMARC1; p=reject; sp=quarantin; rua=mailto:r...@example.com'  (an 'e'
> is missing at 'quarantine') MUST
>  be interpreted as 'v=DMARC1; p=none;' because the "sp" tag is not valid.
>
> Regards,
> Olivier
>  
>

Why would we even consider going down this path? Why do you only consider
"fixing" quarantine with a dropped "e"? Why don't you want to fix all the
other potential mispellings of quarantine? Should quarntine be a candidate
for "fixing"? If not, why not? What if someone includes "policy=q"in their
DMARC record?

If someone is getting RUA reports, monitoring logs, etc., spelling and/or
syntax mistakes should be identified fairly easily. Even something basic
like sending test emails to freemail providers and looking at headers on
the receiver side will quickly identify problems.

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

Re: [dmarc-ietf] Getting the word out and educating

[Dotzero]

On Mon, Oct 16, 2023 at 7:14 PM Neil Anuskiewicz  wrote:

> Outside of the official business of the WG, is there a mechanism for
> educating people about DMARCbis. Why is it important? What problems does it
> solve? What’s different? I think some of it might even surprise some
> people: You mean we have been relying on files of public suffix domains all
> this time? How exactly does the tree walk work?
>
> The RFC is great but won’t be enough for quite a few people. To get
> adoption we need content for different audiences, I think.
>
> So my thought is it would be useful to have content such as articles,
> videos, even a website that explains why the changes are important and how
> they work. I realize the RFC does explain things but I think more will be
> needed.
>
>  Is that something people just would do on their own or is this more of a
> coordinated process?
>
> I realize there’s dmarc.org but I think there will be a need for more
> explanatory material through multiple mediums. I think good articles and
> videos will be key.
>
> Neil
>

https://www.m3aawg.org/ had sessions on DMARCbis, DKIM replay, etc. at
their meeting in Brooklyn last week. I did not attend. A number of ISPs,
mailbox providers, ESPs, etc. participate. I don't see it as something IETF
organizes.

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

Re: [dmarc-ietf] Policy Enforcement Considerations

[Dotzero]

On Tue, Sep 19, 2023 at 8:20 AM Scott Kitterman 
wrote:

>
>
> On September 19, 2023 8:50:02 AM UTC, Alessandro Vesely 
> wrote:
> >Hi all,
> >
> >the second sentence of the second paragraph of Section 5.8:
> >
> >OLD
> > In particular, because of the considerations discussed
> >   in [RFC7960] and in Section 8.6 of this document, it is important
> >   that Mail Receivers not reject messages solely because of a published
> >   policy of "reject", but that they apply other knowledge and analysis
> >   to avoid situations such as rejection of legitimate messages sent in
> >   ways that DMARC cannot describe, harm to the operation of mailing
> >   lists, and similar.
> >
> >I have the feeling that most readers understand that allusion to /other
> knowledge and analysis/ to mean content filtering.  Thence the lemma that
> if we can relay on content filtering then we don't need strong
> authentication. Instead, referenced Section 8.6 presents forwarding as
> /the/ scenario where DMARC fails.  Accordingly, this section could be more
> precise on the kind of semantically acceptable enforcement exceptions.  Let
> me try a wording:
> >
> >NEW
> > In particular, because of the considerations discussed
> >   in [RFC7960] and in Section 8.6 of this document, it is important
> >   that Mail Receivers seek additional knowledge and mechanisms whereby
> >   published policies of "reject" and "quarantine" can be safely
> overridden.
> >   Mailing lists, and forwarding in general present cases where messages
> are
> >   legitimately sent beyond the author domain's reach, breaking SPF and
> >   possibly also DKIM.  The combined effort of Mail Receivers and
> Forwarders
> >   can lead to establishing a strong recognition of such mail flows,
> warranting
> >   discharge from DMARC policy enforcement while still respecting the
> >   semantics of the author domain policy, thus avoiding the harm that
> >   otherwise DMARC causes to the operation of mailing lists.
> >
> >
> >Is that cool?
>
> No.  I think this section is currently, correctly, focused on what to do
> with only references to why. I don't think we should change that.  If the
> current references are inadequate, then we should improve them, not attempt
> to restate them.
>
> I don't think "other knowledge" is limited to content filtering and your
> attempt to be more precise is problematic because it doesn't actually
> achieve the goal.
>
> "The combined effort of Mail Receivers and Forwarders ...", for example,
> leaves out mailing lists, which is one of the things you said you were
> trying to solve.
>
> Scott K
>

I agree with Scott.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Wed, Sep 13, 2023 at 9:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC 7489.   In particular, this means that:
> - when p=none, unauthenticated messages are never obstructed, for fear of
> hindering a wanted message
>

I do not see the word "fear" anywhere in the specification.  When p=none,
the sending domain is not asking the receiving domain to do anything but
report the observed results of validation, assuming that a report receiving
address(s) is provided.

- when p=reject, unauthenticated messages are never allowed, in the blind
> faith that such messages are always unwanted
> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
>
> This raises a coverage problem.
>

Not really.


> A huge volume of traffic will not be protected by Sender Authentication,
> so the evaluator becomes entierly dependent upon content filtering to
> protect himself from attacks that impersonate unprotected domains.
>

By your logic, all sending domains should be forced to implement DMARC
p=reject. Nothing is further from the truth. A domain may choose to only
publish only an SPF record. A domain may choose to only use DKIM. A domain
may choose to implement DMARC. A domain may choose to implement none of
these. A domain may choose to only emit PGP signed messages. A domain may
choose to use S/MIME signing. Note that NONE OF THESE approaches offers
universal or even majority coverage of the global messaging corpus.

In the unlikely case that a content filtering implementation is sufficient
> for non-DMARC domains, it is likely to be sufficient for DMARC domains
> also, making DMARC unnecessary.
>

One need only look at spam folders to see that content filtering to see
that it does not provide a comprehensive solution. By your logic above,
perhaps we should jettison content filtering as a tool.

>
> The coverage problem is aggravated if we assume rational attackers.   With
> a plethora of domains available for impersonation, attackers are least
> likely to use domains that are protected with p=reject.  Therefore the
> reference model implementation protects an evaluator where attacks are
> least likely, and fails to protect an evaluator where attacks are most
> likely.
>

Again, you are asserting a "coverage problem" when none exists. If a
sending domain chooses not to participate in DMARC, that is a choice on
their part, not a problem. If a receiving domain chooses not to validate,
that is a choice, not a problem. Again, applying your logic as expressed
above, should we discard SMTP based messaging because organizations choose
to use other forms of messaging for their communications?


>
> Now consider the mailing list problem.
>
> The mailing list owner should assume that all evaluators will enforce
> DMARC according to the reference model, regardless of the receiving
> domain's published DMARC policy.   This means that every subscribing domain
> SHOULD create a DMARC exception for traffic coming from the list's MAILFROM
> address.
>

This does NOT mean that every subscribing domain should create an exception
for traffic coming from the list's MAILFROM address.


> However, we assume that this does not happen for one of these reasons:
> (a) the list owner does not ask for the exception,
> (b) the subscriber fails to forward the exception request,
> (c) the email system administrator refuses the request, or
> (d) the email filtering system provides no mechanism to implement the
> request.
>
> Then subscribers join from one or more domains with p=reject policy, and
> the problems start.   When a subscriber gets disenrolled because his domain
> enforces DMARC without exceptions, he screams at the mailing list operator,
> who then points his finger at the p=reject domain.  Alternatively, the
> domain gets munged and the subscribers fuss for that reason instead.  Faced
> with this peer pressure, the p=reject subscriber complains loudly to his
> mail system administrator.   In the hoped-for-case, the domain owner caves
> under this internal pressure and changes his DMARC policy to p=none.  One
> of the odd things about this result is that the characteristics of the
> incoming messages remain unchanged.  Instead, it is the risk tolerance that
> has been increased.
>

A list owner may choose not to accept subscriptions/messages from a domain
participating in DMARC and publishing p=reject.

>
> In the simpler solution, subscribers would accept impersonation from one
> account in one domain, so that both subscriber and non-subscriber domains
> are protected from impersonation attacks using the p=reject domain from any
> other source.   In the hoped-for solution, all Internet participants become
> vulnerable to impersonation attacks using the no-longer-reject 

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  wrote:

>
> All the best,
> Hector Santos
>
>
>
> On Sep 13, 2023, at 8:51 PM, Dotzero  wrote:
>
>
>
> On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  wrote:
>
>> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
>> Douglas Foster
>>
>> Absolutely incorrect. DMARC is a deterministic pass|fail approach based
>> on validation through DKIM or SPF pass (or if both pass). It says nothing
>> about the acceptability/goodness/badness of a source.
>>
>>
>> So why are we here?
>>
>
> Because you care?
>
>
> I do.
>
>
>> Correct or incorrect, a published p=reject has to mean something to the
>> verifier who is doing the domain a favor by a) implementing the protocol
>> and b) the goal of eliminating junk.   If there are false negatives, whose
>> fault is that?  The Domain, The Verifier or the Protocol?
>>
>
> DMARC does one thing and one thing only. It mitigates against direct
> domain abuse in a deterministic manner, nothing else. It doesn't stop spam
> and it doesn't depend on or involve reputation. It is but one tool among a
> number of tools that various parties can choose from. A message passing
> DMARC validation does not mean the message is "good". There is no question
> of fault. Perhaps you should recommend changes to incorporate a blame game
> if your goal is to determine fault.
>
>
> Deterministic means there is no question -  you follow the protocol. Your
> (speaking in general) opinions don’t matter.
>

It means that the output of the algorithm is deterministic. It does not
mean that the receiver blindly act on that output. As has been stated many
times by many people, a policy assertion is a request by the sending domain
administrator/owner, not a mandate. That is why local policy on the part of
the receiver overrides a sender policy assertion.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  wrote:

> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
> Douglas Foster
>
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
> validation through DKIM or SPF pass (or if both pass). It says nothing
> about the acceptability/goodness/badness of a source.
>
>
> So why are we here?
>

Because you care?

>
> Correct or incorrect, a published p=reject has to mean something to the
> verifier who is doing the domain a favor by a) implementing the protocol
> and b) the goal of eliminating junk.   If there are false negatives, whose
> fault is that?  The Domain, The Verifier or the Protocol?
>

DMARC does one thing and one thing only. It mitigates against direct domain
abuse in a deterministic manner, nothing else. It doesn't stop spam and it
doesn't depend on or involve reputation. It is but one tool among a number
of tools that various parties can choose from. A message passing DMARC
validation does not mean the message is "good". There is no question of
fault. Perhaps you should recommend changes to incorporate a blame game if
your goal is to determine fault.

>
> I think it’s the protocol but thats my opinion as one of early DKIM POLICY
> adopters and an advanced and costly implementation. If policy does not help
> protect a domain and also the receiver with failure hints or better said
> negative classification of a source per the domain policy, then what is the
> point of the work here or lack of there?
>

False negatives are generally the result of implementation choices of
senders. That's not an interoperability problem. It's a case of "Doctor, it
hurts when I do that". The correct response is "Don't do that."

Receivers are free to assign reputation, apply local policy as they see fit
but that all falls outside of DMARC.

>
> Same is true with SPF.
>
> Please try to be more civil with people’s views or position with this
> problematic protocol.
>

Thank you for sharing your opinion. I'm truly and deeply sorrowful if I
have offended your sensibilities. I will consider including trigger
warnings on future posts.

>
> Thanks
>

You are welcome.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Mon, Sep 11, 2023 at 6:36 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are still trying to fix an evaluator problem by changing domain
> owner behavior.  No harm in giving domain owners the warning, but changing
> evaluator behavior would be much better.   Presumably, the evaluator
> behavior that we have today is the result of RFC 7489 wording, so we may be
> able to change future evaluator behavior by strategizing the language of
> DMARCbis.
>

IETF is not the behavior police.


>
> Compare email authentication to a controlled-access building.   On any
> given day, some employees will arrive at work to discover that their badge
> is back at home.   How is it handled?   By sending the employee to the
> physical equivalent of quarantine:  the pass office.Most employees can
> be validated by another method, such as driver's license or biometrics.
>  An employee who forgot his wallet and cannot be verified by biometrics
> will lose a day's work.   However, a person who is identified as using a
> fake ID will be led away by police.
>
> Email authentication is not much different.   We are judging message
> source acceptability, not individual messages.
>

Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
validation through DKIM or SPF pass (or if both pass). It says nothing
about the acceptability/goodness/badness of a source.

100% email authentication is possible and should be the goal.   Quarantine
> is the preferred place to send unauthenticated mail, regardless of sender
> policy (or lack of policy).In quarantine, acceptable messages are given
> alternate authentication and released, just as the secure-building employee
> is given a temporary badge or replacement badge.   If lack of authenticated
> is discovered to be a fraudulent attacker, then all messages from the
> attacker should be blocked, not just the impersonation messages.
>
> When it seems impossible to quarantine and review every unauthenticated
> message, triage becomes necessary.  The messages with highest perceived
> risk are sent to quarantine and the lower-risk messages are released and
> reviewed as time permits after the fact.
>

This is the dumbest approach possible. Think about it. What you are saying
is "With all our expertise, technology and automation, we are going to hand
the messages we think are the riskiest to you, the end user, who has no
expertise to figure out whether this message is safe". What is wrong with
this picture?


> Either way, the workload steadily decreases as message sources become
> permanently authenticated or permanently blocked.
>

Maybe the workload decreases and maybe it doesn't. You are making a huge
assumption that an authenticated message source will permanently be
authenticated and a blocked message source will permanently be "bad". This
approach creates real problems. In any event, this isn't how DMARC works.
DMARC validates each message on its own. DMARC does not involve reputation.
Please stop trying to conflate things outside of DMARC with DMARC.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton  wrote:

> On 7 Sep 2023, at 9:28, Wei Chuang wrote:
>
> Many enterprises already have "p=reject" policies. Presumably those
> domains were subject to some sort of spoofing which is why they went to
> such a strict policy.
>
> This is not necessarily the case. For example, DHS has directed
> 
> all Executive Branch federal agencies to publish a policy of reject,
> regardless of whether they were subject to spoofing (and with no mention of
> the problems with doing so. Others have published “Email Security Best
> Practices” advocating the use of p=reject. For example, one well-known
> email vendor has a tool that generates a warning if p=quarantine or
> p=reject isn’t configured, and says on their website, “We recommend reject,
> for reasons we’ll touch on later.”
>

The Federal government is not a very good example to make your point. In
the 2010-2011 time frame there were a number of high profile cases where
government email WAS spoofed with various negative outcomes. Two examples
come to mind. The first was an email purporting to be from Senate staff
(Sergeant at Arms) to various news agencies/publications that several high
profile Senators were killed. There were news reports of this as a result
that briefly moved financial markets. The other involved fake online
Christmas cards (email notifications) to various government contractors and
purporting to be from the White House (POTUS) even though at the time the
White House was still only sending printed Christmas cards. This resulted
in compromises at more than one defense contractor. As a result of these
sorts of incidents, Pat Peterson (Agari) and I were asked by EOP (Executive
Office of the President) to put together and give training on email
authentication that was turned into a virtual training environment for
government employees (excluding contractors). Since that time there have
been various efforts by the Federal government to implement stronger email
authentication practices, both at agencies and government contractors. This
ultimately led to the DHS directive. Yes it's a blunt instrument but it is
the culmination of a process triggered by cases of malicious "spoofing".

> I agree that the SHOULD language is not very useful because it’s likely to
> be interpreted as only advice. Instead, I think we need a stronger
> statement about the consequences of this policy. For example, “Domains
> publishing p=reject MUST NOT expect mail to mailing lists and similar
> forwarders to be delivered reliably.”
>

The "MUST NOT you suggest is normative language that many will ignore with
no particular incremental negative impact to them beyond the current
situation. I'm not thrilled with the proposed SHOULD NOT language but it
makes much more sense to me than your proposal.

Michael Hammer
___
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,
> 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Dotzero]

On Wed, Jul 19, 2023 at 10:42 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Can you find a commercial product that can configure a rule which says,
> "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the
> MailFrom address produces SPF PASS"?
>
> Simple enough rule.  If vendors understood what we want them to
> understand, they would allow creation of multipe-attribute rules like this,
> combining authentication results and identifier values, to provide local
> authentication overrides.   But they don't, or at least I have not found
> one after diligently searching.
>

YOU keep on substituting "we" for "I" when YOU have not gained a consensus
on what YOU want. YOU have not searched very diligently if you couldn't
find a single vendor who can do what YOU want. As Olivier pointed out,
Cisco AsyncOS can do this. I was an early customer of IronPort (when the
company was still code named "GodSpeed" and that capability existed in the
early 2000's, so even well before DMARC even existed.

Another company product that has had that capability is MessageSystems and
their Momentum servers. You'd have to write the rule in Lua. A very
flexible implementation.

The fact that YOU don't know something exists after "searching diligently"
doesn't mean it doesn't exist. Perhaps asking the community yields results
when "searching diligently" does not.


>
> On the other hand, finding products that block unconditionally on FAIL is
> pretty easy.
>
> We need to find words in our document that begin to fix this, to obtain
> the products and evaluator behavior that we both want and their users need.
>

YOU are again substituting "we" for "I". You have also wandered from
writing a protocol to telling people how they (actually YOUR preference)
should implement their operational choices for local policy. Trying to
dictate local policy choices is a losing proposition. Trying to dictate to
vendors YOUR policy choices is also a losing proposition. Local policy
choices != protocol.

Michael Hammer


> Doug
>
> On Wed, Jul 19, 2023, 8:07 PM Dotzero  wrote:
>
>>
>>
>> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> Perhaps you can clarify what you think DMARC is.
>>>
>>> Apparently a significant number of evaluators think that "DMARC Fail
>>> with p=reject always means unwanted mail".   Or to use Michael Hammer's
>>> language, "DMARC Fail with p=reject means the domain owner wants it
>>> rejected so I will reject it."These are exactly the attitudes that
>>> cause us so much trouble because (a) DMARC Fail with p=reject does not mean
>>> that rejection is always the correct response, and (b) DMARC Fail with
>>> p=none is an important piece of information.
>>>
>>
>> You are misrepresenting my position by ignoring local policy. A DMARC
>> policy of quarantine or reject is a request by the domain owner or
>> administrator. While consideration of a sending domain's request should be
>> given consideration, a receiving domain is free to do as it wishes. A
>> receiving domain may choose not to implement DMARC validation at all. A
>> sending domain may believe that the risk of some legitimate emails being
>> rejected or quarantined is an acceptable tradeoff in order to protect
>> itself and users/recipients. You appear to have a problem with these
>> choices being made by both the sending domain and the receiving domain. Why
>> do you presume to know better than they as to what they should do?
>> Certainly, if I publish a policy of p=reject and a receiver allows an email
>> that should have been rejected to reach their user/customer and that person
>> contacts me because that message caused them a problem, I'm going to tell
>> them they need to speak with their mail administrator, mailbox provider,
>> etc. I've done that in the past and I'll do it in the future. What others
>> choose to do is their choice. While I may have an opinion, I recognize that
>> it is their choice.
>>
>>>
>>> We have only two ways to block unwanted messages:   Identify unwanted
>>> and malicious messages based on the sender, or based on the content.
>>>  Impersonation interferes with the sender reputation assessment, so we know
>>> that attackers have an incentive to impersonate.   Sender Authentication
>>> provides information about messages that MIGHT be impersonations
>>> because they are not authenticated.   Fortunately, most messages can be
>>> authenticated.
>>>
>>
>> You a

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Dotzero]

On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Perhaps you can clarify what you think DMARC is.
>
> Apparently a significant number of evaluators think that "DMARC Fail with
> p=reject always means unwanted mail".   Or to use Michael Hammer's
> language, "DMARC Fail with p=reject means the domain owner wants it
> rejected so I will reject it."These are exactly the attitudes that
> cause us so much trouble because (a) DMARC Fail with p=reject does not mean
> that rejection is always the correct response, and (b) DMARC Fail with
> p=none is an important piece of information.
>

You are misrepresenting my position by ignoring local policy. A DMARC
policy of quarantine or reject is a request by the domain owner or
administrator. While consideration of a sending domain's request should be
given consideration, a receiving domain is free to do as it wishes. A
receiving domain may choose not to implement DMARC validation at all. A
sending domain may believe that the risk of some legitimate emails being
rejected or quarantined is an acceptable tradeoff in order to protect
itself and users/recipients. You appear to have a problem with these
choices being made by both the sending domain and the receiving domain. Why
do you presume to know better than they as to what they should do?
Certainly, if I publish a policy of p=reject and a receiver allows an email
that should have been rejected to reach their user/customer and that person
contacts me because that message caused them a problem, I'm going to tell
them they need to speak with their mail administrator, mailbox provider,
etc. I've done that in the past and I'll do it in the future. What others
choose to do is their choice. While I may have an opinion, I recognize that
it is their choice.

>
> We have only two ways to block unwanted messages:   Identify unwanted and
> malicious messages based on the sender, or based on the content.
>  Impersonation interferes with the sender reputation assessment, so we know
> that attackers have an incentive to impersonate.   Sender Authentication
> provides information about messages that MIGHT be impersonations
> because they are not authenticated.   Fortunately, most messages can be
> authenticated.
>

You are again misrepresenting what DMARC is and does. It is NOT a guessing
game about whether a recipient might want a given email. It is a simple
pass/fail that should be automated before a message ever (potentially) gets
to a recipient. It may be as simple as the message took an unintended or
unexpected path which potentially creates risks from the perspective of the
sending domain. DMARC knows nothing about whether email is wanted or
unwanted on the receiving side of the mailstream. It knows nothing about
reputation. DMARC is not a substitute for other filtering or reputation
systems. DMARC is not a Swiss Army knife, was never intended to be one, nor
is it appropriate to pretend you can contort it into one.

I absolutely agree with John regarding his comments and agree with his
sentiment of " I am so tired of people imagining that DMARC is more than it
is."

Michael Hammer


>
> Doug
>
>
>
>
> On Wed, Jul 19, 2023 at 5:32 PM John Levine  wrote:
>
>> It appears that Barry Leiba   said:
>> >> - An attacker sends 10 messages that maliciously impersonates a
>> >> big bank.  With help from DMARC p=reject, the evaluator blocks
>> >> them all.  The attacker follows up with 10 messages that
>> >> maliciously impersonate a major university.   The stupid
>> >> evaluator says, "p=none means no problem here".   The message is
>> >> accepted and the user is harmed because the evaluator learned
>> >> nothing from blocking the successful attack.
>> >
>> >This is a useful point, and I think we should do something with it.
>>
>> Sorry, but I completely disagree.
>>
>> The interesting filtering data is that a bunch of unauthenticated mail
>> arrived from some source. As we have learned over and over, someone's
>> DMARC policy tells you nothing about the threat level or whether the
>> failure is an attack or a mailing list, only that someone decided for
>> whatever reason to publish p=reject.
>>
>> If a source sends a burst of unauthenticated mail, it could often be a
>> good idea to give that source a poor reputation. Or maybe you have a
>> reason to believe otherwise, e.g., it's been sending bursts of
>> unauthenticated mail for years, nobody's ever marked it as spam,
>> because it's some kind of courtesy forward.
>>
>> Note that you would do exactly the same thing if the burst of
>> unauthenticated university mail preceded the burst of bank mail. It's
>> the authentication failure that tells you that there may be a problem,
>> not the DMARC policy.
>>
>> Mail filtering is complicated, so much so that handling the signals is
>> more than a full time job at many mail systems. I expect that large
>> mail systems have their own ideas abou who's a bank, who's a
>> university, who's a public 

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Dotzero]

On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman 
wrote:

> It's not news that there's a risk for SPF associated with shared IP
> addresses.
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
>

+1


>
> I understand your view and agree on the problem.  I also sympathize with
> the
> need to technically address conditions as they exist in operations.  I'm
> not
> convinced that we should bake the solutions into protocol, however.
>
> As I've said before, I think this is primarily and economics/incentives
> problem, not a technical problem.  If you increase the incentives for
> third
> party providers to support DKIM in place of SPF, I don't think you've
> actually
> solved anything.
>

The reality is that many ESPs have asked "how does DMARC fit into my
business model?". My response has always been that it is not up to the
community to figure out your business model.


> As fas as I've seen, the low cost (for a third party to sign using their
> customer's domain name) approach is for the third party provider to
> publish
> DKIM key records based on their own private keys and then tell their
> customer
> to put a CNAME in their DNS that points to it.  In the case of a shared
> server, the third party provider then needs to keep track of which
> customer is
> authorized to sign for which d= domain, but they can use their own keys/
> infrastructure for doing so.
>

That is one approach. We used to delegate subdomains and contractually
require key rotation, etc. We did that after 2007 (due to Storm Worm), well
before DMARC was published. There were ESPs that balked at signing with our
keys and they were not considered as potential vendors. There were others
that worked with us and also provided dedicated IPs that were shared among
our various brands (for SPF). Many folks lag behind because they perceive
the "cost" of security as higher than the cost(s) associated with the
consequences of poor practices.

A slightly more complicated approach would be for the domain to provide
private signing keys to the 3rd party.


>
> The internal management function of keeping track of which customers can
> use
> which signing domains is essentially the same as the internal management
> function of keeping track of which customers can use which Mail From
> addresses
> with SPF.
>
> My speculation (and it is that), is that the most cost sensitive third
> party
> providers currently use SPF only and are less likely to keep effective
> control
> of which customer can send from which identity precisely because it's less
> expensive.  If you change the deployment incentives so that DKIM is now
> more
> necessary for some of their customers, they'll no doubt deploy it, but
> without
> better internal controls, you'll end up with the same problems with these
> providers expressed through a different technology.
>

In some ways, receivers/mailbox providers enable the bad practices by
accepting problematic email because that requires less work in dealing with
the ISP Relations people from those mailers. As a sidenote, one need only
look at the ratio of deliverability people to compliance people at some of
these organizations to understand priorities. A harder line would force
those mailers to reevaluate their practices and offerings. This is an
operations/implementation problem and not so much a protocol/standards
problem. Just saying.

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Dotzero]

On Fri, Jun 30, 2023 at 2:31 PM Murray S. Kucherawy 
wrote:

> On Fri, Jun 30, 2023 at 11:22 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> Why is the mechanism called "Domain-based Message Authentication,
>> Reporting, and Conformance" and not "Domain-based Message Authentication,
>> Reporting, and Disposition"? Perhaps a better question, why is
>> "conformance" in the name of the mechanism?
>>
>
> Two reasons I can think of:
>
> 1) "Conformance" describes the test as to whether a message meets the
> required authentication test(s).  And one can reasonably infer from
> "Conformance" that a message which doesn't conform to the published
> authentication policy will be dealt with accordingly.
>
> 2) DMARC's antecedents (e.g., ADSP) were still part of what we considered
> email authentication, which is covered by the "A".
>
> -MSK
>

"Conformance"  was about conformance to the requested policy disposition.
We (dmarc.org participants) tossed around various acronyms as we discussed
the name. I'll also point out that the immediate antecedent to DMARC was
MOOCOW. ADSP was not a consideration other than problems to avoid.
"Authentication" referenced authenticating the domain associated with the
RFC822 From email address.

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

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Dotzero]

On Thu, Jun 22, 2023 at 8:59 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Right, but the messages often get sent anyway.   So the evaluator who
> blocks the message as malicious impersonation is blocking incorrectly
> because the fail result is unreliable.   If it only affects nuisance
> advertising, the error may not matter to the evaluator.  But I think the
> problem affects some messages that matter to the recipient.
>
> Doug
>

Blocking a message that fails authentication does not mean that the
evaluator assumes "malicious impersonation". It simply means the sending
domain in the From address has published a p=reject policy and has
requested that messages which fail to authenticate aren't authorized by the
domain, nothing more and nothing less.

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

Re: [dmarc-ietf] DMARC and Data Hygiene

[Dotzero]

On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.
>

> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>
> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are both real problems, but only because people are
> trying
> to make DMARC pass a positive assertion.  In order to do that reliably,
> organizations need to be more like Case 1 and be very careful vetting
> third
> parties that they authorize for.  I don't think that's a protocol problem.
>

I think this is a key factor for the calculus of value in DMARC " ...but
only because people are trying to make DMARC pass a positive assertion." I
agree that it's not a protocol implementation.

It really can't/shouldn't be used to try and make positive assertions (even
though people attempt to do so). Apart from the cases Scott points out,
there is the very real situation of when good domains go bad, whether
because the good domain has been subverted, sold or for other reasons. If
we move away from attempting to use DMARC to make a positive assertion then
the issues around configurations/implementations become less problematic.
Perfection is the enemy of good.

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Dotzero]

On Thu, Jun 8, 2023 at 4:35 PM Barry Leiba  wrote:

> > A sender using both SPF and DMARC will see a slight
> > boost in validation rates due to increased resiliency when there are
> > transient DNS failures and other problems.
>
> Do you mean "both SPF and DKIM", perhaps?
>

My bad. I responded while in the middle of something else. Proof that one
should always proof read before hitting send.

>
> I don't see how that makes sense: if there's a transient DNS failure,
> then neither the SPF nor the DKIM (nor the DMARC) records can be
> retrieved.
>

One example is where there are a pool of DNS servers. One server in a pool
might have an issue while others are fine. All the lookups do not
necessarily hit the same server. You also don't factor in cached results
for SPF as well as potentially different TTLs for those results.

>
> I also don't see how using an unreliable mechanism is a benefit.  It
> demonstrably hurts validation rates related to relayed/forwarded mail,
> and can cause *false* validations in cases of overly-broad SPF
> configurations (as when a large provider that also hosts many spammers
> is used).
>

It's all in the mail flow and configurations. YMMV. I was dealing almost
overwhelmingly with transactional emails in a well configured environment
(from the day that DMARC was originally published we were at p=reject)).
Yes, we had to fix some things beforehand. I strongly believe that the 2
biggest problems with setting up email authentication as a sender is that
people don't put much thought into it and in many cases they deploy when
their hair is on fire.

Michael Hammer

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Dotzero]

On Thu, Jun 8, 2023 at 10:44 AM Barry Leiba  wrote:

> See, I don't look at it as "harmed".  Rather, I think they're using "we
> use SPF" as a *reason* not to use DKIM, and I think that *causes* harm.
>

That might be true but does not address whether or not SPF is/can be useful
in the context of DMARC validation.


>
> SPF is, as I see it, worse than useless, as it adds no value to domain
> that use DKIM -- any time DKIM fails SPF will also fail -- and actually
> impedes the adoption of DKIM.  Reliance on SPF causes DMARC failures that
> result in deliverability problems for legitimate mail.  I wholeheartedly
> support removal of SPF as an authentication mechanism that DMARC accepts.
>

I'm going to disagree with you on this, having experience with billions of
emails sent with both SPF and DKIM used in the context of DMARC validation.
A sender using both SPF and DMARC will see a slight boost in validation
rates due to increased resiliency when there are transient DNS failures and
other problems. A small percentage of a very large number is still a large
number. Let's not throw the baby out with the bath water.

>
> Barry, as participant
>

Michael Hammer


>
> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank  40valimail@dmarc.ietf.org> wrote:
>
>> Participating, I have data that I believe points to a long tail of
>> businesses who predominantly only authenticate on behalf of others using
>> SPF, and would be harmed by such a change. It will take me a little while
>> to confirm and share.
>>
>> I also know a predominant ccTLD with millions of registrations, that has
>> SPF on roughly 80% of them, but DMARC on barely 5%. I don't have data on
>> DKIM for those, but I assume it's closer to the DMARC penetration than the
>> SPF one. I'll see if I can get this data to share more publically, and also
>> get the DKIM answer.
>>
>> Of course the goal is aligned dkim with a stated policy, but I don't
>> think the data supports us being anywhere close to that realistically.
>>
>> As Chair, this is a valuable conversation to have with real data on
>> problems and opportunities at scale, and am excited to see Tobias share and
>> see what others have to say.
>>
>> Seth
>>
>> On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy 
>> wrote:
>>
>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula >> 401und1...@dmarc.ietf.org> wrote:
>>>
 My team recently concluded an extensive study on the current use and
 performance of DMARC. We analyzed a staggering 3.2 billion emails, and the
 insights drawn are quite enlightening. Of these, 2.2 billion emails
 (approximately 69%) passed the DMARC check successfully. It's quite an
 achievement, reflective of our collective hard work in fostering a safer,
 more secure email environment.



 However, upon further analysis, it's evident that a mere 1.6% (or
 thirty-six million) of these DMARC-passed emails relied exclusively on the
 Sender Policy Framework (SPF) for validation. This is a remarkably low
 volume compared to the overall DMARC-passed traffic, raising questions
 about SPF's relevancy and the load it imposes on the DNS systems.



 Given the current use case scenarios and the desire to optimize our
 resources, I propose that we explore the possibility of removing the SPF
 dependency from DMARC. This step could result in a significant reduction in
 DNS load, increased efficiency, and an accurate alignment with our
 predominant use cases.

 [...]

>>>
>>> Does anyone have consonant (or dissonant) data?
>>>
>>> -MSK, participating
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>
>>
>> --
>>
>> *Seth Blank * | Chief Technology Officer
>> *e:* s...@valimail.com
>> *p:* 415.273.8818
>>
>> This email and all data transmitted with it contains confidential and/or
>> proprietary information intended solely for the use of individual(s)
>> authorized to receive it. If you are not an intended and authorized
>> recipient you are hereby notified of any use, disclosure, copying or
>> distribution of the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> this email and then delete it from your system.
>> ___
>> 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] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Dotzero]

On Wed, Apr 26, 2023 at 8:58 AM Scott Kitterman 
wrote:

> I'd like to see the 'SHOULD employ a secure transport mechanism' section
> added back in.  As I mentioned in another message, I think IETF policy
> based on RFC 7258 supports it.  Alternately, something in privacy
> considerations might be okay.  I think it's better to have the SHOULD, but
> I could live with that.
>
> Scott K
>

+1

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Dotzero]

On Mon, Apr 24, 2023 at 10:18 PM John R. Levine  wrote:

> > I removed the small section that faced objections.
> >
> > I updated the ridtxt definition and discovered that mmark was making a
> mess of those asterisks.  When there are more than one/some on a single
> line, it believes you would like some subset to be defined as "" things.
>
> Looks pretty good.  Minor points:
>
> The first paragraph in 2.6 says:
>
>  Where the URI specified in a "rua" tag does not specify otherwise, a
>  Mail Receiver generating a feedback report SHOULD employ a secure
>  transport mechanism.
>
> Since the only mechanism is mail and nobody's going to S/MIME encrypt
> their reports, I suggest just deleting it.
>

TLS vs not TLS.

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

Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Dotzero]

On Sun, Apr 23, 2023 at 1:20 PM Hector Santos  wrote:

> On 4/23/2023 6:10 AM, Alessandro Vesely wrote:
> >
> > Meanwhile, digressions about ATPS and similar schemes can help
> > casting some light on future evolution.  From: rewriting cannot be
> > the final solution; it is a temporary hack.  Digressions don't slow
> > down the publication, as discussions about actual text quickly
> > prevail.  They are just a mean to help convergence toward a common
> > vision of the future.
>
> With each year, that "temporary hack" becomes the new normal and it
> will be harder to clean up. It is not the right way and I don't  its
> too late to reverse.  However, it has been 17 years and DMARCbis is
> not finished without some clean up in this area.
>

It HAS NOT been 17 years for either DMARC (first published in 2011  and
first submitted to IETF as informational in 2015) or DMARCbis. Let's at
least use publicly available data points for time frames rather than time
frames pulled out of thin air.

>
> First, Section 4.4.3 should have text on using extended tag methods to
> provide 3rd party authorization methods.  Just add the RFC 6541
> abstract or version of it:
>

No! Supporting and referencing an experimental specification which has
never gotten significant traction is the wrong way to go. If you believe
that ATPS is the right path then YOU should work to attract a wider range
of participants to use ATPS and then provide data back to IETF, whether
through an ATPS working group or a DKIM working group that is chartered to
undertake that work.

>
>  ATPS [RFC6541] is an experimental specification proposed which
> adds a extended tag "atps=" allowing
>  advertisement of third-party signature authorizations that are to
> be interpreted as equivalent to a signature
>  added by the administrative domain of the message's author. ATPS
> was designed for ADSP.  There is interest to
>  apply this tag to DMARC to help deal with unchecked but
> authorized resigners false positives.
>

You don't even need a working group at this point to validate that ATPS
works and that it can scale in a workable manner. It has not been shown
that ATPS scales with regard to adds and deletes of individual tags. As you
quite rightly point out, ATPS was designed for ADSP, not DMARC. I have no
problem if you and others wish to experiment but you should do your
experiment first and then seek agreement from the wider community before it
gets embedded in another specification. Why should ATPS be granted special
consideration vs other proposals out there? It shouldn't.

>
> Second, there are possible outcomes with members using restrictive
> domains:
>
> 1) Legacy MLS/MLM, unaware of protocol, unchanged author domain,
> submission mail integrity is broken due to long time practice of body
> and subject changes, can cause members of a list to be
> auto-unsubscribed when their receivers begin to honor p=reject and
> reject mail integrity DKIM failures.
>
> 2) Protocol Awareness, honoring the policy, constraining subscription
> and submissions to unsecured submissions.  Restrictive domains not
> acceptable for list submissions.  Note: It is possible to allow a
> Read-Only List Member concept.
>
> 3) Protocol Awareness, not honoring policy and tearing down the author
> security, replacing with unsecured distribution.
>
> The correct way for any protocol is to close security  loopholes. In
> this case, recommend #2 using Subscription and Submission controls.
> Let the author domain figure it out.  DMARCbis MUST recognize if the
> intent of the domain is to clean up their brand, by implementing hard
> failure rejects at both SPF and DMARC, then it should recommend
> handlers SHOULD honor the policy of the domain or be prepared for the
> possible false positives.
>
> I can understand why DMARCbis's editor does not want to document
> rewrite, but imto, can't be ignored anymore.   The details of a
> rewrite can be quickly outlined.  To help the RFC process, maybe
> DMARCbis could refer to the Functional Specifications of SSP (RFC5016)
> Section 5.3, Item 10 which basically reinforces the idea that local
> policy ALWAYS prevails and it is quite possible there will be
> undesirable tearing down of secured submissions.  One possible
> mitigation is to replaced it with a secured rewriter with a p=reject
> policy.
>

SSP is long gone and failed. Referencing something which failed to gain
support many years ago is also not a path to go down.


> I don't think the above will take long to do and I believe will help
> resolve the conflict.
>

It doesn't resolve the conflict. As I stated above, if you believe in ATPS
then you need to attract a wider range of participants for your experiment,
including sending domains, receiving domains and intermediaries (and not
just mailing lists). Repeating "this solves the problem" is not data.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Dotzero]

On Sat, Apr 22, 2023 at 2:04 PM Hector Santos  wrote:

>
> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
>
> It appears that Jesse Thompson   said:
>
> -=-=-=-=-=-
>
> A DNS-based lookup, perhaps in the style of ATSP as this thread is
> describing, to query for not just domain-level authorization, but also
> potentially user-level authorization, I think is
> compelling because it can:
>
>
> Once again, no. This is not mission creep, it is mission gallop.
>
>
> The current mission is chaos!!  I sometimes wonder If the intent is to
> keep it chaotic to show non-consensus in really the strategy.  Jesse was
> referring to user policies.  ATPS is about domain policies.  Lets not
> confuse this.
>
> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
> distraction and wheel spinning that is keeping us from finishing.
>
>
> -1
>
> First, not true, there is running code using ATPS, and you know it.
> Second, there are APIs that support it.  It may be disabled in the open
> source but it's there. Second, when an editor does not champion his own
> work, it will be much harder to sell.  There is absolute no reason why a
> receiver can not to an ATPS check if its already doing an DMARC with false
> positive results due to not doing an ATPS.
>
> What has kept us from finishing this 17+ year project was the editor of
> ADSP and now editor of DMARCbis preventing 3rd party authorization
> concepts.  He removed it from SSP when it was hijacked with ADSP.   To his
> credit, its on the record, he didn’t want people using ADSP and was
> successful to get it abandoned as a proposed standard and made it historic.
>

You are incorrect that SSP was "hijacked" by ADSP.  I was the one who
suggested the change from Sender Signing Protocol to Author Domain Signing
Protocol because the effort was about domains and NOT individuals. It was
ONLY a name change. As with many other efforts there was evolution, both
before the name change (which occurred around SSP 11 if I remember
correctly) and after. Anyone can go back to the list archives to verify
this.

>
> But DMARC snuck in via M3 as an Informational status and since he can’t
> stop domains from using DMARC, he took over the editing of DMARCbis and now
> wants a MUST NOT p=reject without explaining how to best avoid its problems
> for existing systems.
>

As one of the original organizers of the DMARC effort I object to your
characterization of DMARC as having "snuck in via M3". The DMARC effort
coalesced when an earlier effort called MOOCOW organized by JD Falk failed.
(I had declined to participate in MOOCOW because I believed early on that
it was doomed to fail.) Yes, some of the DMARC meetings took place
immediately preceding M3 meetings as a matter of convenience but many more
took place online or were hosted by participating organizations at their
offices. There were also other efforts as well. Anyone can go back to the
archives of lists like DKIM-OPS circa 2007 to see me publicly stating a
DMARC like approach in which I said that any emails being emitted by
americangreetings.com that failed to pass either DKIM signed mail with a
>From of americangreetings.com or SPF aligned with americangreetings.com
should be discarded. This differed from the effort between PayPal and Yahoo
which was based on private peering between two parties.

As I have previously stated on this list, I disagree with the MUST NOT for
p=reject but I think you casting aspersions that John is trying to kill
DMARC is baseless and unfair. He has strong opinions about interoperability
and mail lists.


>
> Yet, his answer to the DMARC problem, as a single implementation with IETF
> list, is to strip the security of a domain using a Rewrite and does not
> want to document it as a DMARCBis solution to the problem he refuses to
> help fix, nor document the subscription/submission restrictions method,
> something he could have done rather than introduce an unfortunate mail
> engineering taboo to they industry - a new security loophole with caused by
> this rewrite:
>
>  Destroyed Mail Authorship Authentication Replays
>
> I almost believe he wants DMARCBis to fail as a Proposed Standard,
> therefore refusing to also change it back to informational status as
> suggested by Barry Leibre since it would give DMARCbis a better chance of
> surviving IETF engineering scrutiny and passing last call.
>
> As a proposed standard, there will be friction when ADSP was abandoned for
> reasons DMARCBis is not resolving other than saying don’t use restrictive
> domains.   That’s what slowing this down.
>

ADSP (nee SSP) had other issues and it wasn't so much killed as failed.
There were agreed upon compromises and it failed to gain traction. That
sometimes happens.

I'll also digress and address Jim Fenton's comment about the Federal
government not understanding the difference between informational and
Standards track. DMARC wasn't submitted to IETF as informational until
2015. It was originally published 

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >IMHO at least an appendix should say that if you can't do anything better
> you
> >have to rewrite From: with examples of legitimate display-phrase,
> expanding a
> >bit the first bullet in Section 11.4.  That can also be a good place to
> explain
> >the kind of damage DMARC causes.
>
> Absolutely not. This sort of thing is utterly outside the scope of our
> job and wasting time on it just further delays our already extremely
> late work.
>
> R's,
> John
>

+1

There are many things John and I may disagree on but he clearly understands
why avoiding scope creep (and bad ideas) is important.

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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Mon, Apr 17, 2023 at 12:05 PM John Levine  wrote:

> It appears that Laura Atkins   said:
> >Is this another issue we should document and make recommendations about?
> I was thinking along the line that transactional SaaS
> >providers should fully support DMARC and should not allow companies using
> p=reject in their business mail to access the
> >service?
>
> Section 2.4 says that everything other than the From: header is out of
> scome. Section 11.4 describes display name attacks and it looks OK to
> me. I suppose we might tweak 2.4 to clarify that anything other than
> the mailbox in the RFC5322.From field is out of scope to avoid any
> implication that we're talking about the comment part.
>
> +1
>
> It's not exactly a secret that bad guys can use misleading connents as
> easily as good gyys. If we tried to enumerate all the ways that people
> might do dumb things, we would die of old age before we finished so I
> would prefer not to start.
>

+1

>
> At M3 people occasionally have talked about extending DMARC to cover
> the From comment but it's such an ill-defined problem (what's
> allowable? how could you tell?) that it has never gone anywhere.
>

There are things that can be done but to me they fall under local policy
and not interoperability. For example, if an email address is displayed but
doesn't match the From email address, don't display it. Some sites never
display the comment and only display the From email address. Things like
that.

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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins 
wrote:

> Reading through the various discussions about how to document the harm
> DMARC causes for general purpose domains, I started thinking.One way that a
> lot of major SaaS providers have chose to deal with DMARC is spoofing their
> customer’s in the 5322.from Comment string. There are numerous examples of
> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off
> the top of my head.
>
> All of these companies send out financial or business mail on behalf of
> their customers, some of whom do use p=reject on their own domains. Some of
> them also use restrictive DMARC policies for this mail, others don’t.
>
> Is this another issue we should document and make recommendations about? I
> was thinking along the line that transactional SaaS providers should fully
> support DMARC and should not allow companies using p=reject in their
> business mail to access the service?
>

Let's throw the baby out with the bath water. There are ways a
(transactional) domain owner can enable a vendor to generate/send email on
their behalf without the vendor "spoofing" the domain. A subdomain can be
delegated, private DKIM signing keys can be provided. Another approach is
routing outbound email from the vendor through the customer's mail
servers.  In addition, dedicated sending IPs can be required by the
customer. My personal favorite is delegating a subdomain because all of the
obligations can easily be specified contractually. In the past when
potential vendors have said "we don't do that" or "we can't do that" and
I've said "then we can't consider you in our vendor election process", it's
amazing how quickly they figure out how to do things if there is enough
money on the table. I speak from experience.

If enough people insist then vendors will productize these approaches into
their offerings more generally. It's a competitive differentiator until
enough vendors have offerings, at which time it will become the ante to
play in the game. So no, suggesting that the only solution is vendors
rejecting business from customers who publish p=reject is pretty much a
non-starter.


>
> I keep going back and forth that this is not an interoperability issue -
> the mail works fine even when the business is spoofed in the 5322.from
> comment string. But on a practical level it looks exactly like phishing
> mail because it’s financial (or contractual) docs from a particular company
> coming from a random domain. I keep ending up this isn’t an
> interoperability issue, it’s just an end run around DMARC and it’s not the
> IETF’s place to comment on that.
>

I could see a discussion in a BCP as to why it's a bad practice. I don't
see it having a place in a standard.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 9:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> These decisions are made in the light of ransomware attacks that have shut
> down critical social infrastructure like city governments and hospital
> systems.
>
> The proceeds from Internet-based fraud are funding groups like Boko Haram
> that kidnaps girls into sex slavery, boys into child soldiering, and then
> uses their weapons to burn Christians inside their churches.
>
> This is not about money for fat cats, it is about trying to stave off the
> darkness.
>
> Unless a mailing list has controls in place to ensure that EVERY post
> comes from the asserted participant, it is the height of hypocrisy to ask
> an evaluator to assume that the post is from the asserted participant.
>  IETF cannot do even the easiest part of that task, so I have no reason to
> expect better elsewhere.
>
> Societies depend on trust.   Impersonation in all it's forms undermines
> trust.
>
>
> Doug
>
>
>
>
> On Fri, Apr 14, 2023, 9:17 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Apr 14, 2023 at 12:37 PM Dotzero  wrote:
>>
>>> While the you part of "we" may not see any advantages, quite a few
>>> financials, greeting card sites, retailers AND many receivers have seen the
>>> advantages, including p=reject. One thing I've learned over the years is
>>> that it is presumptuous to speak on behalf of "everyone" when you don't
>>> actually have their authorization to speak on their behalf. It's kind of
>>> like sending email claiming to be from someone else's domain without their
>>> permission.
>>>
>>
>> We need to tread carefully here.  Standards are supposed to improve
>> things for everyone, not just quite a few financials, greeting card sites,
>> retailers AND many receivers.  Presented that way, it sounds a lot like
>> we're saying these decisions should be biased in favor of those with
>> money.  I know we don't mean that.
>>
>> -MSK, participating
>>
>

Seeing the advantage does not mean that it only benefits the ones I listed.
I'm aware they see the advantage because people from those types of
organizations were involved in the original creation and testing and over
the years I've seen the data on abuse reduction. Not just the DMARC numbers
but the downstream impacts on abuse. Unfortunately organizations tend not
to provide data about its efficacy publicly because it involves providing
data about their business. It works. It could have been kept a private club
of "big boys" but people involved in the effort believed there was (is) an
ecosystem benefit in it being an open standard that anyone could implement.
>From start to publication, DMARC took roughly 18 months including testing.
The participating organizations spent a lot of resources and  money during
that period writing code and testing, including various meetings and
interop events. I'm not confident it would have happened and especially in
that time frame if it were a public effort. Now that also doesn't include
the initial time and work it took for the private parties to figure out how
to interact with each other.  It's smaller organizations and the average
person who benefits from that initial effort. If it weren't a published
standard, how could they take advantage and be able to participate? It was
handed over to IETF because of a belief that IETF would be the best steward
in moving it forward.

And yes, I fully recognize that there are tradeoffs DMARC involves. If only
transactional domains publish p=reject then I'd argue the benefits far
outweigh the downsides. The calculus changes with broader implementation
for other types of domains, but as others have pointed out, no death
penalty is imposed in those circumstances.

I've seen people suggest that policy should be gotten rid of but keep
reporting. Policy was/is the incentive for receivers to do reporting. It
allows sending domains to have visibility into mail flows claiming to be
theirs, whether theirs or not, from the receiver's perspective.This
presumably enables them to take steps to correct things they perceive to be
problematic if they so choose. And yes, that can include publishing
quarantine or reject as a policy request.

If it weren't for companies like !Yahoo and AOL pulling the trigger on
p=reject, we wouldn't be having this conversation. I'm not saying this to
blame them, rather I'm just recognizing facts. But we are where we are.

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

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  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.emailstanda...@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  40isdg@dmarc.ietf.org> wrote:
>
>>
>>
>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy 
>> wrote:
>>
>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely 
>> 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> wrote:
>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
>>> 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 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba  wrote:

> > I don’t think folks are objecting to cautionary language.  I think
> > folks are objecting to a blanket MUST NOT.  If we're going to qualify
> > the MUST NOT with a bunch of language, that's a bit different.   The
> > original proposal was: "To be explicitly clear: domains used for
> > general-purpose email MUST NOT deploy a DMARC policy of p=reject."
> > I'm still fuzzy on what constitutes general purpose, or perhaps more
> > accurately when p=reject is acceptable?  Is it acceptable to use
> > p=quarantine in those cases?  If a domain (such as comcast.com)
> > decides p=reject is what they really want .. then what? (I know, we're
> > not the protocol police..)
>
> The idea is MUST NOT because it harms interop with long-standing
> deployments.  If you decide you're more important than that, you do
> what you want and there it is.  It's as simple as that.  The "then
> what" is that you don't interoperate with mailing lists (and perhaps
> other things, depending upon the exact configuration).  That's the
> definition of MUST NOT.  It doesn't mean that someone will come down
> on you if you do.  It means you will likely fail to interoperate if
> you do.
>
> As to "what constitutes general purpose", if you are providing email
> addresses to the general public, that qualifies.  If your domain is
> sending email only from employees, and you have policies about
> employees using their email addresses to conduct business, then that's
> a different issue.  Of course, if their business involves posting to
> mailing lists, you have some decisions to make.
>
> Again, none of this is on pain of death.  We're just talking about how
> to use the protocol interoperably.  If you have reasons you think are
> important to do otherwise, you can do what you want.  The protocol
> specification needs to define interoperability clearly and strictly.
>
> Barry
>

Barry wrote:

" The idea is MUST NOT because it harms interop with long-standing
deployments.  If you decide you're more important than that, you do
what you want and there it is.  It's as simple as that"

I could live with the normative MUST NOT if there were some non-normative
text recognizing that there are domains that violate the MUST NOT but not
in any way attempting to validate violating the MUST NOT. Is there any
potential that such wordsmithing could break the apparent impasse? Just
sort of noodling on this.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 4:25 PM John Levine  wrote:

> It appears that Dotzero   said:
> >While the you part of "we" may not see any advantages, quite a few
> >financials, greeting card sites, retailers AND many receivers have seen
> the
> >advantages, including p=reject. ...
>
> The advantages you see are certainly real but they're not about
> interoperability.
>
> DMARC prevents a lot of mail from being delivered, the exact opposite
> of interoperating. In your case at least, there are good reasons to
> believe that the recipients wouldn't have wanted the mail, but that's
> a separate question.
>

The vast majority of email messages emitted are prevented from being
delivered. Should the flood gates holding back those messages be opened in
the name of interoperability? My hunch is that this is not the desired
outcome by many/most people.

>
> I also think that you're kind of an edge case, with a mail stream that
> you can characterize very exactly and a clear understanding of the
> costs of the mail that gets lost.  People who know they have users
> on mailing lists and publish p=reject anyway, not so much.
>

DMARC was specifically created to address direct domain abuse with regard
to transactional mail. That hardly makes  financials, greeting card sites,
retailers AND many receivers edge cases.

>
> I'm with Scott, there's no question about the interop problem so
> document it and move on.
>

My response was orthogonal to any interop problems. Instead it was in
response to Laura claiming to speak on behalf of an all inclusive "we". It
may be that I was mistaken and it was instead an Imperial "we".

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins 
wrote:

>
>
> On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:
>
> On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
>
> On 12 Apr 2023, at 12:21, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> Any form of security creates inconvenience.
>
> Yes. And we make tradeoffs between that. In this case, the security is
> ensuring that users at specific domains can and should only send mail
> through approved channels managed by those domains. Many users have
> violated those security policies, by participating in mailing lists. This
> caused problems for other folks on the mailing lists - as they were the
> ones removed from the list due to the security policy. The lists responded
> by rewriting. This causes yet more inconvenience to other subscribers and,
> additionally, allows the users to bypass their domain security policy.
> I am not seeing how this creates an arena of security.
>
>
>
> Security is not From: munging.  That's the workaround that security
> requires.
>
>
> No security (at least in the viewpoint of some people) is using a p=reject
> for mail from their domain. In that context, From: munging is actively
> subverting the security  settings of domains.
>
>
> Based on the header rewriting done by IETF, I have a hard time seeing how
> its rewrite of Comcast addresses can cause any of the problems that you
> cite.
>
> That’s how the IETF rewrites, it’s not how everyone rewrites.
>
>
> Couldn't the IETF say how to rewrite?
>
>
> There’s currently a deployed base where there are many different ways to
> munge. "It is a _fact_.”
>
>
> But does your domain require even headers to be rewritten?Why doesn't
> IETF ask you, and omit rewrite if that is what your domain wants?
>
> Because that doesn’t scale for the IETF.
>
>
> Mailman options do scale.  From: rewriting is going to fade off by first
> allowing single subscribers to disable it, for the posts
>
> directed to them, after their MX set up some kind of agreement with the
> MLM.
>
>
> The _fact_ still remains that From: rewriting is actively subverting the
> security of domains that choose to publish p=reject.
>
> It is hard for me to cry over mailing lists when they cannot ensure that a
> post comes from the asserted poster and they cannot adapt their DMARC
> defenses to the preferences of the recipient domains.   Life is hard.   It
> only gets harder if I wait for someone else to solve problems that I can
> solve myself.
>
> I don’t understand how header rewriting ensures the authenticity of a
> poster. Given the data is being modified by the MLM, it seems to me that
> rewriting compounds the problem.
>
>
>
> It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE
> post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting
> for that, which is what they should have done.  We are suffering all the
> damage caused by DMARC but don't enjoy any of the advantages it could bring.
>
>
> I encourage you to think very hard about why, after more than a decade, we
> still don’t see any of the advantages to DMARC.
>

While the you part of "we" may not see any advantages, quite a few
financials, greeting card sites, retailers AND many receivers have seen the
advantages, including p=reject. One thing I've learned over the years is
that it is presumptuous to speak on behalf of "everyone" when you don't
actually have their authorization to speak on their behalf. It's kind of
like sending email claiming to be from someone else's domain without their
permission.

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

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Dotzero]

On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba 
wrote:

> Maybe just add a sentence to the end of the second paragraph:
>
>The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.
>
> Barry
>

I think the opposite. Something along the lines of "Sending domains SHOULD
implement both SPF and DKIM to minimize breakage and non-delivery of mail.

Michael Hammer


>
>
> On Thu, Apr 13, 2023 at 12:04 PM Todd Herr  wrote:
>
>> On Thu, Apr 13, 2023 at 11:21 AM Barry Leiba 
>> wrote:
>>
>>> > Anyone who does forwarding is damaged by DMARC because there are a lot
>>> of
>>> > people who do DMARC on the cheap with SPF only.
>>>
>>> This brings up another issue, I think: that there should also be
>>> stronger advice that using DKIM is critical to DMARC reliability, and
>>> using SPF only, without DKIM, is strongly NOT RECOMMENDED.
>>>
>>> I don't disagree.
>>
>> How do we make the following text stronger?
>> 5.5.2.
>> Configure
>> Sending System for DKIM Signing Using an Aligned Domain
>> 
>>
>> While it is possible to secure a DMARC pass verdict based on only one of
>> SPF or DKIM, it is commonly accepted best practice to ensure that both
>> authentication mechanisms are in place to guard against failure of just one
>> of them.
>>
>> This is particularly important because SPF will always fail in situations
>> where mail is sent to a forwarding address offered by a professional
>> society, school or other institution, where the address simply relays the
>> message to the recipient's current "real" address. Many recipients use such
>> addresses and with SPF alone and not DKIM, messages sent to such users will
>> always produce DMARC fail.
>> 
>>
>> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d=
>> domain in the DKIM-Signature header) that aligns with the Author Domain.
>>
>>
>> --
>>
>> *Todd Herr * | Technical Director, Standards and Ecosystem
>> *e:* todd.h...@valimail.com
>> *m:* 703.220.4153
>>
>> This email and all data transmitted with it contains confidential and/or
>> proprietary information intended solely for the use of individual(s)
>> authorized to receive it. If you are not an intended and authorized
>> recipient you are hereby notified of any use, disclosure, copying or
>> distribution of the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> this email and then delete it from your system.
>>
> ___
> 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] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Wed, Apr 12, 2023 at 9:41 AM John R Levine  wrote:

> On Tue, 11 Apr 2023, Neil Anuskiewicz wrote:
> > If DMARC can protect domains from spoofing which I believe ends up
> > costing over $14 billion per year. Forget about the $14 billion and
> > think how this crime spree affects people’s view 
>
> But it obviously can't do that, and what it does do happens at
> considerable cost.
>

The claim that DMARC protects against spoofing has never been made by the
originators of DMARC. We have always been careful that it only addresses
direct domain abuse.


>
> I don't know where that $14B number came from but I am reasonably sure
> someone pulled it out of his, er, hat.  WHen people talk abbout
> "spoofing", they might mean exact domain impersonation or they might mean
> lookalikes, or as likely as not mail where the body impersonates someone
> and the From address is totally unrelated since, as Dave Crocker often
> reminds us, most users don't look at the return address and a lot of mail
> software doesn't even show it.  DMARC only addresses one modest part of
> that.
>
> If you are someone like Paypal or a big bank, and you have full control
> over all the routes of your mail, AND IT DOES NOT MATTER IF YOUR MAIL GETS
> LOST, p=reject makes sense.  The farther from that you are, the less sense
> it makes and the higher the costs you impose on other people. People
> chronically forget the capitalized part when thinking about the tradeoffs.
>

Nobody has full control over all the routes email will take. How does the
emitting domain know that a recipient hasn't set up forwarding from one
account to another or that a recipient address isn't an exploder or alias
representing multiple recipients at multiple domains?

It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters
but there is a calculus regarding the tradeoffs of a very small percentage
(in the case of my former a very small fraction of a percent) of email not
getting delivered vs the damage caused to recipients of malicious emails
involving direct domain abuse. In one example of direct domain abuse, the
malicious actors copied and pasted from real transactional emails and
inadvertently included tracking code.Over the course of 48 hours over
180,000 people clicked on the malicious link before the site hosting the
malicious content was shut down. And that was all from receiver domains
that were not validating DMARC. And again, the original intent of DMARC was
mitigating direct domain abuse involving transactional emails. We
recognized the tradeoffs involved but to say it didn't (and doesn't) matter
if such transactional email gets lost is a gross exaggeration.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex 
> wrote:
>
>> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and
>> the website signs records via DNSSEC.  The website I want to go to breaks
>> their DNSSEC.  My ISP cannot retrieve a record to return to my browser that
>> can be used.  A is the browser, B is the website, C is the ISP DNS platform.
>>
>>
>>
>> I understand your point, though I think mine still has reasonable merit.
>> I understand the charter is to resolve the interoperability between
>> indirect mail and p=reject.  I’m just not sure I see an intersection of
>> “fix indirect email” and “p=reject”.
>>
>
> I see what you're getting at, but I don't think they're comparable.  There
> are a few main differences:
>
> 1) DMARC is a surprise to some actors.  The intermediary in DMARC doesn't
> know that it's suddenly contributing to a problem.  In the DNSSEC example,
> the ISP DNS platform knows it's participating; it is, after all, a
> DNSSEC-aware resolver.  In DMARC, suddenly MLMs around the world have to
> change what they're doing and don't know they're part of a new problem.
>

If DMARC is a surprise to "some actors" today, they clearly haven't been
paying attention. It was first publicly published (not through IETF) in
2011. With regard to MLMs and forwarders, the wake up call would/should
have been in 2014 when AOL, !Yahoo and other domains with lots of users
started publishing p=reject policies. I'm not commenting on other aspects
of the discussion, only your belief that in this day and age, DMARC is a
surprise to anyone.

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

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones  wrote:
>
>> This puts me in mind of Section 8.5, which calls out some potential
>> impacts of blocking policies to "Mediators," which role doesn't otherwise
>> appear very often in this document. Is there any need to add Mediator
>> Actions/Considerations under section 5? Or does this belong in a separate
>> document?
>>
>
> We should probably review it and think about whether what it says is
> enough.
>

This is certainly worth a discussion.


> ISTR there were some vocal and visible mailing list operators that were
>> rejecting messages from domains that published "p=reject" policies, maybe
>> around 2014-15? I also thought they did this by checking the sending
>> domain's published policy in DNS, to your point about implementation.
>>
> This would be great [anec-]data to have.  Do you remember where you might
> have seen it?
>

My recollection is similar to Steve's except that I saw the talk but didn't
see the walking the walk.

> In any case, are we really going to start suggesting that list operators
>> start rejecting messages sent from domains that publish a blocking policy,
>> as official guidance? (Now I'm looking ever so forward to catching up on
>> these other threads - what the heck are people seeing out there??)
>>
>
> Well, this WG is chartered to come up with some kind of standards track
> solution to the problem.  I don't see one in DMARCbis at the moment.  Given
> how long this WG has existed so far, that's a fairly glaring omission.
> Doesn't seem to me this idea should be off the table just yet...
>

 I don't think it should be off the table but believe it is only one of the
options that MLMs/forwarders have.

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

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Wed, Apr 12, 2023 at 9:41 AM John R Levine  wrote:



>
> When we say that mail systems that don't fit the DMARC threat profile
> shouldn't publish DMARC policies, we have good reasons to say so, and
> that's what our standards need to say if we're serious about
> interoperating.
>
> R's,
> John
>

" ...shouldn't publish DMARC policies..."

I note that you didn't write "MUST NOT". I heartily concur with "shouldn't"
or SHOULD NOT. I still have issues with "MUST NOT".

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Sat, Apr 8, 2023 at 5:10 PM Scott Kitterman  wrote:

> Possible.  I didn't count.
>
> I didn't see any convergence towards an alternative.
>

The fact that there hasn't been convergence on an alternative doesn't mean
there has been convergence on the proposed new txt. This also doesn't mean
the proposed new text becomes the default in the event of a lack of
consensus. If anything were to be considered the default in the event of
lack of consensus it would most logically be the original text.


>
> I think adding explicitly that the MUST is related to interoperability
> reasonably addresses the concern that there are non-interoperability
> reasons people are going to publish p=reject despite the side effects.
>

I don't read it that way. We clearly see interoperability even with domains
such as AOL, Yahoo and other similar domains publishing p=reject. I
recognize there are issues but I'm not comfortable that they rise to the
level of a failure to interoperate. I'm also not comfortable publishing
"MUST NOT" for p=reject when we know that domains representing a very large
number of sending users are. To me that smacks of virtue signaling and a
failure to address a difficult problem space because, "you know". This is
why I am more comfortable with "should not". It recognizes the problems but
doesn't pretend they are going away because of a demand to conform that the
promulgators of the standard recognize won't be listened to.

>
> I don't see a stronger consensus for a specific alternative.
>
> I think we have exhausted the discussion on the topic, so, whatever the
> resolution, I'd like to see the chairs drive the question to closure.  It's
> pretty clear it's not going to naturally drift into a universal consensus.
>
> Michael Hammer
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

Going back through the thread I find more people questioning/disagreeing
with the proposed wording than agreeing with it. I don't see a rough
consensus.

Michael Hammer

On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman  wrote:

> We've gone nearly a week without any further discussion on this thread.
>
> I reviewed the thread and I think this is the closest we got to anything
> (most) people agreed on.  I know not everyone liked it, but I doubt we're
> going to get closer to a consensus on this.
>
> Can we adopt this and move forward on to the next thing?
>
> Scott K
>
> On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
> > I'm happy with that suggestion.
> >
> > Barry
> >
> > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman 
> wrote:
> > > Would you feel any better if the MUST NOT was followed by 'to preserve
> > > interoperability '?  That's implicitly there and I believe technically
> > > correct.  If you value other properties of the system higher than
> > > interoperability, then the advice may not apply, which is fine.
> > >
> > > Scott K
> > >
> > > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"
>  wrote:
> > > >I’m just not sure how we determine what is high-value.
> > > >
> > > >comcast.com: p=reject
> > > >comcast.net: p=none
> > > >xfinity.com: p=quarantine
> > > >
> > > >The top one is corporate, middle is consumer, bottom is consumer (but
> not
> > > >actually used) & customer comms (sub-domains).  They’re all used in
> > > >various ways for internal messaging.  Should I tell our corporate
> admins
> > > >that they need to no longer publish p=reject?  They’re violating the
> RFC
> > > >by doing so?  There are very few consumer-oriented messages that
> > > >originate from comcast.com.  Are we doing it right?  It makes things
> a
> > > >little harder when one of our employees wants to use a mailing list.
> > > >But that still feels like the right thing to do.
> > > >
> > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> > > >dictating to domain owners what is in their best interests, regardless
> > > >of our perceived value of their domain.
> > > >
> > > >--
> > > >Alex Brotman
> > > >Sr. Engineer, Anti-Abuse & Messaging Policy
> > > >Comcast
> > > >
> > > >From: dmarc  On Behalf Of Barry Leiba
> > > >Sent: Wednesday, March 29, 2023 10:15 AM
> > > >To: Todd Herr 
> > > >Cc: dmarc@ietf.org
> > > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> > > >flows
> > > >
> > > >I'm very much against text such as this, as I think it encourages
> > > >deployments that are contrary to interoperability and to the intent of
> > > >p=reject.
> > > >
> > > >I contend that p=reject (as with the similar construct in the older
> ADSP)
> > > >was intended for high-value domains and transactional mail, and that
> it
> > > >was never intended for use in domains where general users send general
> > > >email.
> > > >
> > > >I stand by the MUST NOT that I proposed.
> > > >
> > > >Barry
> > > >
> > > >
> > > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> > > > 40valimail@dmarc.iet
> > > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> > > >mailto:resn...@episteme.net>> wrote:
> > > >
> > > >If you agree that interoperability is increased, then I'd suggest that
> > > >you actually do agree that the proposed text is appropriate.
> > > >
> > > >
> > > >I don't know that I agree that interoperability is increased...
> > > >
> > > >I'm having trouble squaring proposed language that says "Domain owners
> > > >MUST NOT publish p=reject because it breaks interoperability" with the
> > > >following language from section 5.8:
> > > >
> > > >
> > > >Mail Receivers **MAY** choose to accept email that fails the DMARC
> > > >
> > > >mechanism check even if the published Domain Owner Assessment Policy
> > > >
> > > >is "reject". In particular, because of the considerations discussed
> > > >
> > > >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT**
> reject
> > > >
> > > >messages solely because of a published policy of "reject", but that
> > > >
> > > >they apply other knowledge and analysis to avoid situations such as
> > > >
> > > >rejection of legitimate messages sent in ways that DMARC cannot
> > > >describe, harm to the operation of mailing lists, and similar.
> > > >
> > > >It seems inconsistent to state with certainty that authorized mail
> will
> > > >be rejected due to authentication breakage when there is no
> requirement
> > > >that a reject policy be honored (and we have plenty of evidence that
> > > >Mail Receivers are following the 'SHOULD NOT reject messages'
> guidance).
> > > >
> > > >Language that would be more consistent in guidance to the domain
> owners
> > > >might look something like this:
> > > >
> > > >After careful analysis of the aggregate report data as described in
> > > >section 5.5.5 (Collect and Analyze Reports), Domain Owners **MAY**
> > > >choose to change their policy from 'none' to 'quarantine' or 'reject'.
> > 

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Thu, Apr 6, 2023 at 9:19 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hallo,
>
> Le 06/04/2023 à 01:46, Dotzero a écrit :
> >
> > Not at all. The discussion (and specific post I was responding to) was
> > about mailing lists but it also applies more generally. A number of
> > years ago I saw bounces from a Polish domain. Their policy was that if
> > the From and the Mail From didn't match they would reject the inbound
> > email. I find that absurdly limiting but they can implement whatever
> > policy they want. Maybe there are sending domains that do that for all
> > their mail. My point is that domain owners/admins, at least on certain
> > levels, get to choose how they interact with other networks/servers.
>
> Yeah, but this is where DMARC comes in, and muddies the responsibilities
> that come with those choices. Originating domains (quoting Todd Herr)
> just "use p=reject as a signal to declare that they got all outgoing
> mail authenticated". Evaluators candidly comply with the originator's
> wish to have unauthenticated mail rejected. None of them is taking
> responsibility for the breakage they collectively are causing to mailing
> list (etc…) operation.
>

Again, not at all. You are quoting Todd's opinion, which does not equal a
fact. A domain publishing a p=reject policy is only a signal that the
domain wishes email that fails to validate to be rejected, nothing more and
nothing less. When we (Yes, I was part of the original dmarc.org team)
created DMARC and published it in 2011, we were focused on a point solution
to what we perceived as a point problem. That was direct domain abuse of
transactional emails from organizational domains which had few or no end
users. We recognized that there was a risk of DMARC being implemented by
domains with many individual users but felt that the potential downsides
limited the likelihood of that happening. When Yahoo and AOL implemented
DMARC with a p=reject policy within weeks of each other in 2014, it was
because each organization was enduring major impersonation attacks against
their users. My understanding is that in both those cases the decision to
publish p=reject was made by the top business leader(s) of each
organization as a business decision, not a technical one. Since that time,
many other organizations with lots of end users have faced similar attacks.

So Baptiste, what responsibility do you expect these organizations to
undertake? I'm asking this as a serious question, not a rhetorical one. In
all seriousness they are/were focused on addressing their, potentially
existential, problems and not those of others. One might state that is a
very selfish attitude. I would agree and then suggest such a statement
changes nothing. I haven't faced that situation or choice so I'm not in a
position to answer what I would personally do if faced with those choices.
I will point out that in many cases organizations make the decision as a
result of being under attack.

Avalanches of bounces inflicted upon uninvolved third parties are a
> major interoperability problem caused by DMARC. This should not happen
> without either the originator or the evaluator breaking a MUST
> requirement. Otherwise, DMARC itself is responsible for the breakage.
>

I again invoke King Canute. There are other things which can cause
avalanches of bounces. It's a shame. The fact that it is happening suggests
that mailing list operators and others face choices. Simply wagging a
finger and shouting "YOU BROKE A MUST NOT" is hardly an effective response.


>
> > I also don't think it would  be pretty but it's within the realm of
> > options they can choose from.
>
> You talk, but you know they won't really do it. Because they're not
> trying to coerce you into changing your way of operating.
>

I personally don't know what (generic) others will or won't do. If faced
with avalanches of bounces and the risk of getting blocked overall by large
receivers, some list owners have in fact blocked inbound messages from
domains which publish p=reject. This may have been a temporary expediency
while they decided on other measures, but it has happened.


>
> BTW, From munging has not become any "neater" than it was 2 years ago.
> Or 2 years before. As long as there is no proven solution (ARC?),
> rehashing the same pseudo-moral arguments is not helpful.
>

I certainly haven't engaged in pseudo-moral arguments. I'm looking at it
from a very pragmatic perspective. Do you create or update standards based
on the reality of what is happening or do you take an Ivory tower approach
in which the standard you promulgate bears little relationship to what is
happening in the real world?

I think Ale's post to the list impersonating Alex is a perfect example of
why playing the "MUST NOT" card is insufficient and should be reconsidered.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Wed, Apr 5, 2023 at 5:41 PM Jim Fenton  wrote:

> On 1 Apr 2023, at 8:25, Dotzero wrote:
>
> >  Hmm, let's apply this to DMARC.
> >
> > " But it interoperates just fine once you make the effort."
> >
> > Nobody forces a Sender to publish a DMARC record. Nobody forces a
> receiver
> > to validate DMARC. Nobody forces mailing lists to accept mail from
> domains
> > which publish a DMARC record let alone one which publishes  p=reject
> > policy. But it interoperates just fine once you make the effort.
>
> Doesn’t this again assume that all DMARC breakage is due to mailing lists?
>

Not at all. The discussion (and specific post I was responding to) was
about mailing lists but it also applies more generally. A number of years
ago I saw bounces from a Polish domain. Their policy was that if the From
and the Mail From didn't match they would reject the inbound email. I find
that absurdly limiting but they can implement whatever policy they want.
Maybe there are sending domains that do that for all their mail. My point
is that domain owners/admins, at least on certain levels, get to choose how
they interact with other networks/servers.


>
> This got me to musing: What if IETF decided to remove its From address
> rewriting and started bouncing all incoming mail to its mailing lists from
> domains that have a p=reject (and maybe p=quarantine) policy? I don’t think
> it would be pretty.
>

I also don't think it would  be pretty but it's within the realm of options
they can choose from.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

Yours is the most reasoned argument in support of "MUST NOT" vs "SHOULD
NOT", even if I disagree with you. You recognize the issues involved with
going the "MUST NOT" path even though you ultimately support it.

Michael Hammer


On Sat, Apr 1, 2023 at 6:30 AM Scott Kitterman  wrote:

>
>
> On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
> >
> >>
> >>
> >>
> >>>
> >>>
> >>> But when you deploy DMARC and force lists to change the way they work,
> >>> the experience is altered in a way users perceive as a degradation.
> We're
> >>> taking something significant away, and the benefit is not perceived to
> be
> >>> worthwhile.
> >>>
> >>
> >> It may or may not be true for any given situation. You are assuming
> facts
> >> not in evidence. There are end users who do not subscribe to email
> lists.
> >> My wife is one such person. If users overall were truly upset as you
> >> indicated, we would have expected users to flee en masse from the large
> >> free webmail providers after they switched to p=reject. And yet they are
> >> still around providing email services to millions and millions of users.
> >>
> >
> >Oh, the facts are very much in evidence.  There's no need to assume
> >anything.
> >
> >Hang around any IETF meeting for a few hours.  It may not take even that
> >long for someone to ask when the  DMARC problem is going to be
> >fixed.
> >
> >I guess the point that I'm trying to make is that reality is nowhere near
> >> as neat and simple as some might make things out to be.
> >>
> >> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
> >> falls into the category of King Canute commanding the waters to retreat.
> >> Publishing a standard (MUST NOT) which you know  will ignore
> >> reduces the credibility of a standards organization which does so.
> SHOULD
> >> NOT with an admonishment and explanation as to potential consequences
> makes
> >> more sense to me.
> >>
> >
> >Quoting from RFC 2119 which defines the all-caps key words we've come to
> >know and love:
> >
> >4 <https://www.rfc-editor.org/rfc/rfc2119#section-4>. SHOULD NOT
> >This phrase, or the phrase "NOT RECOMMENDED" mean that
> >   there may exist valid reasons in particular circumstances when the
> >   particular behavior is acceptable or even useful, but the full
> >   implications should be understood and the case carefully weighed
> >   before implementing any behavior described with this label.
> >
> >If we use SHOULD NOT, as you suggest, there's an implication that there
> >might be a valid reason for non-transactional mail to use "p=reject".  Are
> >we okay with that?
> >
> I think that's not quite it.
>
> There is clearly a valid reason.  There are domains that value the
> security properties of p=reject more highly than the negative effects to
> interoperability.
>
> The challenge for DMARC is that the understanding the "full implications"
> of such a choice is infeasible as the implications are not limited to the
> domain in question.  The choice to deploy p=reject for domains with users
> that use email in varied ways impacts the entire email ecosystem, not just
> the domain making the decision.
>
> Technically I don't think there's any question about the negative
> interoperability implications so MUST NOT [because there will be
> interoperability problems] is clearly accurate.  It's equally true that
> approximately no one is going to change their minds about publishing
> p=reject if the IETF puts MUST NOT in the DMARCbis RFC.  If we do it there
> will be, once again, people who point and laugh about how out of touch the
> IETF is with reality.
>
> As the meme says, technically correct is the best kind of correct.  I
> think it's the IETF's job to be the pedantic nerd who won't let go of an
> issue that everyone else is sick of hearing about, so we should stick with
> MUST NOT.  I also understand why that's profoundly unsatisfying for many.
>
> Scott K
>
> ___
> 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] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba  wrote:

> > If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for
> > non-transactional mail to use "p=reject".  Are we okay with that?
>
> When do folks get to line up so they can plead the case for their reason?
>
> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
> "MUST NOT, but we know it will be widely violated so we're saying
> SHOULD NOT".  We need to stop doing that.
>

A "standard" which is widely violated is not a standard. To publish a
standard one knows is and will be widely violated is a bit of a fool's
errand, n'est-ce pas? We need to stop doing that.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Fri, Mar 31, 2023 at 8:00 AM Barry Leiba  wrote:

> > Compare that with the move to https everywhere.  Having to get
> certificates and
> > encrypting and decrypting all stuff is certainly not an interoperability
> > improvement.
>
> Say WHAT?  There's no interoperability issue there.
>
> There's some effort involved in doing it, and one has to weigh that
> effort against what one gets out of it.  But it interoperates just
> fine once you make the effort.  It's not the same thing at all.
>
> Barry
>

 Hmm, let's apply this to DMARC.

" But it interoperates just fine once you make the effort."

Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver
to validate DMARC. Nobody forces mailing lists to accept mail from domains
which publish a DMARC record let alone one which publishes  p=reject
policy. But it interoperates just fine once you make the effort.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Sat, Apr 1, 2023 at 2:53 AM Murray S. Kucherawy 
wrote:

> On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
>
>>
>>
>>
>>>
>>>
>>> But when you deploy DMARC and force lists to change the way they work,
>>> the experience is altered in a way users perceive as a degradation.  We're
>>> taking something significant away, and the benefit is not perceived to be
>>> worthwhile.
>>>
>>
You invoked "end user experience" in your post I responded to.

" When you change the URI scheme you're using from "http" to "https",
there's some complexity introduced in the implementations, but your
experience as a consumer is largely the same"

The end user experience wasn't exactly the same. In many cases end users
couldn't access websites or couldn't visit them without clicking through
warning screens that the website is insecure and/or forced to explicitly
"approve" those sites. That is hardly "largely the same" experience. Sure,
years after that time frame things have settled down. It is convenient to
ignore or minimize what end users experienced during that transition. I'm
not a fan of domains with lots of end user accounts implementing p=reject
but I also recognize that in the real world things evolve.

>
>> It may or may not be true for any given situation. You are assuming facts
>> not in evidence. There are end users who do not subscribe to email lists.
>> My wife is one such person. If users overall were truly upset as you
>> indicated, we would have expected users to flee en masse from the large
>> free webmail providers after they switched to p=reject. And yet they are
>> still around providing email services to millions and millions of users.
>>
>
> Oh, the facts are very much in evidence.  There's no need to assume
> anything.
>
> Hang around any IETF meeting for a few hours.  It may not take even that
> long for someone to ask when the  DMARC problem is going to be
> fixed.
>

And presumably you'll also find people asking when the  placing
of all that crap in TXT records is going to be fixed.


>
> I guess the point that I'm trying to make is that reality is nowhere near
>> as neat and simple as some might make things out to be.
>>
>> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
>> falls into the category of King Canute commanding the waters to retreat.
>> Publishing a standard (MUST NOT) which you know  will ignore
>> reduces the credibility of a standards organization which does so. SHOULD
>> NOT with an admonishment and explanation as to potential consequences makes
>> more sense to me.
>>
>
> Quoting from RFC 2119 which defines the all-caps key words we've come to
> know and love:
>
> 4 <https://www.rfc-editor.org/rfc/rfc2119#section-4>. SHOULD NOT   This 
> phrase, or the phrase "NOT RECOMMENDED" mean that
>there may exist valid reasons in particular circumstances when the
>particular behavior is acceptable or even useful, but the full
>implications should be understood and the case carefully weighed
>before implementing any behavior described with this label.
>
> If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for non-transactional mail to use "p=reject".  Are
> we okay with that?
>

Looking at the real world, I'm ok with that rather than splitting hairs. If
a domain sends a million transactional emails a day, has 5 end user
accounts which are subscribed to a handful of maillists which all accept
their mail and which starts experiencing significant direct domain abuse,
are you seriously suggesting they MUST NOT implement a p=reject policy?
Would you stand in front of them, wag your finger and say to their face,
"Thou must not!"? What alternate solutions would you offer them? Are you
planning on being the "standards police"? If not, whom do you propose
should be the "standards police"? Will offenders be banished from the
Internet? If there is little or no consequence for violating (a generic,
not you specifically Murray) YOUR mandate, what does it actually mean?
Perhaps maillists SHOULD reject mail from ALL domains with end users and
which publish a policy of p=reject. Why hasn't that been incorporated into
DMARCbis? If working group participants truly believe this to be anathema
to interoperability then they should be clamoring for incorporating such a
requirement.

If you feel this strongly, where is the record of your advocating for "MUST
NOT" for domains with end users implementing an SPF policy ending in
"-all"? That certainly breaks interoperability through mailing lists and
various forwarders if honored by valid

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Fri, Mar 31, 2023 at 3:05 PM Murray S. Kucherawy 
wrote:

> On Thu, Mar 30, 2023 at 8:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> The world has changed.   Insecure mailing lists did not matter in the
>> days before email became a weapon.
>>
>
> A comparison was made to the global deployment of HTTPS to replace HTTP.
> There have been other examples in my career, like replacing rsh and telnet
> with ssh.  In those instances as well, the world had changed.  There
> appears to be a claim that DMARC is another instance of the same kind of
> evolution and it ought to be embraced.
>
> The problem, I believe, is that there is not clear consensus that the
> community wants this, because the benefits are not strictly incremental.
> When you change the URI scheme you're using from "http" to "https", there's
> some complexity introduced in the implementations, but your experience as a
> consumer is largely the same yet is secured against snooping or tampering
> in transit.  It's a clear win.
>

Absolutely a false assertion. When browser providers decided to stop
supporting HTTP and only support HTTPS, there were websites not reachable
that people wanted to reach. That is the very definition of broken
interoperability. Websites that wanted to be reached (which hadn't already
switched) needed to switch to HTTPS in order to remain reachable.


> The same is true of moving to ssh.
>

Not exactly true. I'm presuming you are indirectly referring to telnet.
Surprisingly, even today it is possible to find servers that accept telnet
connections. The two parties can choose the connection protocol to use.


>
>
> But when you deploy DMARC and force lists to change the way they work, the
> experience is altered in a way users perceive as a degradation.  We're
> taking something significant away, and the benefit is not perceived to be
> worthwhile.
>

It may or may not be true for any given situation. You are assuming facts
not in evidence. There are end users who do not subscribe to email lists.
My wife is one such person. If users overall were truly upset as you
indicated, we would have expected users to flee en masse from the large
free webmail providers after they switched to p=reject. And yet they are
still around providing email services to millions and millions of users.

I guess the point that I'm trying to make is that reality is nowhere near
as neat and simple as some might make things out to be.

I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
falls into the category of King Canute commanding the waters to retreat.
Publishing a standard (MUST NOT) which you know  will ignore
reduces the credibility of a standards organization which does so. SHOULD
NOT with an admonishment and explanation as to potential consequences makes
more sense to me.

Michael Hammer


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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

Douglas Foster wrote " My point was to only restate that "signed" is the
only truth that the DMARC policy can assert."

This is not true. If a sending domain provides a p=reject policy assertion
in their DMARC record, that is truth. They are not saying that fail always
means fraud. They are saying that mail which fails to pass either SPF or
DKIM is requested to be rejected (for whatever reason). Why do people keep
on trying to overload their personal interpretations on top of something
very simple and straight forward?

Michael Hammer

On Thu, Mar 30, 2023 at 11:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My point was to only restate that "signed" is the only truth that the
> DMARC policy can assert.The new prose needs to fix the false certainty
> that the old prose created.   But until this week, the group seemed ready
> to repeat the same mistake and use language which perpetuates the myth that
> FAIL always means fraud.   Maybe, but not certainly.   The difference is
> important.
>
> DF
>
>
> On Thu, Mar 30, 2023, 8:46 PM Murray S. Kucherawy 
> wrote:
>
>> On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> I would be happy with p=signed, because that is what p=reject means, and
>>> it is our job is to ensure that people interpret the signal correctly.
>>>
>>
>> Quoting the charter:
>>
>> "The working group will seek to preserve interoperability with the
>> installed base of DMARC systems, and provide detailed justification for any
>> non-interoperability."
>>
>> Changing one of the valid "p=" values seems to me to be the opposite of
>> "preserve interoperability with the installed base", so the bar is high to
>> make this change.
>>
>> Can the problem you're trying to address be handled in any other way?
>> Say, improved informational prose?
>>
>> -MSK, participating
>>
>> ___
>> 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] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Tue, Mar 28, 2023 at 12:18 PM Scott Kitterman 
wrote:

>
>
> I don't understand the connection between DMARC policies and open signup
> domains?  What makes them in any way special relative to DMARC?
>
> Scott K
>

I agree with Scott on this.  I don't believe that "open signup" domains
deserve this special call out in this manner. For example, a domain
providing accounts to the public ( "open signup domains") may choose to
specify in its TOS that account email addresses may not be used to send
email from servers other than the domain's own servers. This is a
contractual issue, not an interoperability issue. We should be very careful
before wading into these waters. I understand the concern but I think the
concern is best handled in a separate BCP.

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

Re: [dmarc-ietf] ARC interop and abuse concerns

[Dotzero]

Let's not conflate "spaminess" with authentication (specifically DMARC and
ARC) and forwarding. DMARC deals with direct domain abuse. ARC is an
attempt to show an authenticated chain of handling outside of DMARC when
DKIM and/or SPF is broken through forwarding. Consideration of "spaminess"
is outside the scope of either DMARC or ARC.

A receiver may choose to use DMARC validation and/or ARC as an input into
their spam filters, reputation or otherwise, but again, that is outside the
scope of DMARC (or ARC) and should be a separate discussion/effort/RFC.

My comments should not be taken as opposition to Wei's proposal, only to
entangling it with discussions of "spaminess". If a forwarder (for example
a maillist recipient) attempts to forward email to a nonexistent email
address, that is well beyond the scope of DMARC or ARC.

Michael Hammer

On Sun, Mar 19, 2023 at 7:51 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's not gloss over the interaction between spaminess, forwarding, and
> authentication.
>
> A forwarded mail stream will almost always be viewed as spammy, if any
> spam exists in the source mail stream.  This is because:
>
>- The downstream evaluator will give the forwarder no credit for spam
>which is never forwarded and therefore never seen.
>- The evaluator will give the forwarder demerits for messages which
>the forwarder considered acceptable but the downstream evaluator rejected.
>- Finally, the forwarder will be blamed by the downstream recipient if
>wanted messages are blocked incorrectly as suspected spam.  This creates an
>incentive for the evaluator to error on the side of weak filtering.
>
> The problem becomes worse if the forwarder agrees to forward to a
> recipient address that does not exist or a recipient that does not want the
> forward.  I am surprised that current practice does not require forwarding
> approval, from the proposed recipient, before forwarding begins.
>
> For forwarded mail, the evaluator wants to make a reputation assessment on
> both the forwarding source that is submitting the message, and the
> originator of the message.   Without ARC, detecting a forwarded message is
> fairly tricky, and the algorithm for doing so has never been put into an
> RFC.   ARC allows forwarding to be better documented, which is valuable if
> the ARC data is actually provided and if it can be trusted.
>
> My initial assessment of Wei's DARA proposal is that it helps to assess
> whether the ARC data is sufficiently complete, which is an important step
> toward making it trusted.   Replay prevention is, of course, desirable as
> well.
>
> Doug Foster
>
>
>
>> ___
> 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] Version in aggregate report

[Dotzero]

I favor being explicit in the reporting.

Michael Hammer

On Thu, Mar 9, 2023 at 1:51 PM Trent Adams  wrote:

>
>
> Alex -
>
>
>
> I think that the difference comes down to an inference made by the report
> analyst (and assuming enough data to make an informed guess) vs. the report
> generator expressly stating the mechanism they used.
>
>
>
> IMO, it makes sense to include the signal.  I'd rather not rely on
> inference when an a priori statement can be transmitted.
>
>
>
> But yeah... what do others think?
>
>
>
> - Trent
>
>
>
> PS - I'm reminded of the scene in "Seinfeld" when Kramer is pretending to
> be Movie Phone and asks, "Why don't you just tell me the movie you want to
> see?" https://www.youtube.com/watch?v=XagGEi_n_ok=187s
>
>
>
>
>
>
>
> *From: *"Brotman, Alex" 
> *Date: *Thursday, March 9, 2023 at 11:37 AM
> *To: *Trent Adams , "dmarc@ietf.org" <
> dmarc@ietf.org>
> *Subject: *RE: [dmarc-ietf] Version in aggregate report
>
>
>
> Trent, I’m not entirely opposed to the idea, though I wonder if it’s
> necessary. It seems like if the old method is used vs the tree-walk, and if
> the results are different, then the policy domain in the report would be
> different and easily distinguishable?
>
> Trent,
>
>
>
> I’m not entirely opposed to the idea, though I wonder if it’s necessary.
> It seems like if the old method is used vs the tree-walk, and if the
> results are different, then the policy domain in the report would be
> different and easily distinguishable?  I guess if you want something in the
> report to point at, we can create a field.
>
>
>
> Thoughts from others?
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* Trent Adams 
> *Sent:* Wednesday, March 8, 2023 11:44 AM
> *To:* Brotman, Alex ; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] Version in aggregate report
>
>
>
>
>
> Alex -
>
>
>
> Good catch... and yeah, if the DMARC-bis version won't be incremented, I
> agree that the "version" field in the RUA should remain "1" for both
> RFC7489 and DMARC-bis so there's no disconnect in meaning of "version".
>
>
>
> What about adding a field that'd expressly identifies which DMARC record
> discovery mechanism was used?
>
>
>
> That way a report analyst would be able to handle differences in results
> from different evaluators (some using the RFC7489 "hop", and others using
> the -bis "tree walk") for the same set of published policies.
>
>
>
> Perhaps something like:
>
>
>
>   
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> The excepted values being the enumerated discovery mechanisms (e.g.
> something like "hop", "treewalk").
>
>
>
> Thoughts?
>
>
>
> - Trent
>
>
>
>
>
>
>
> *From: *dmarc  on behalf of "Brotman, Alex" <
> Alex_Brotman=40comcast@dmarc.ietf.org>
> *Date: *Wednesday, March 8, 2023 at 9:25 AM
> *To: *"dmarc@ietf.org" 
> *Subject: *[dmarc-ietf] Version in aggregate report
>
>
>
> While reviewing something in the aggregate doc, I came across this bit in
> the XML specification. Unless I've missed something, we're not incrementing
> the version in the DMARC DNS record. 
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> So, if we're not changing that DNS record, obviously this "version" string 
> has less meaning.  The prose describing the field says this would be "1" or 
> "2".  If we're going to stick to not incrementing the version string, I need 
> to update this to reflect that.  Not a horrible task, just wanted to be clear 
> before I make work for myself.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> ___
>
> dmarc mailing list
>
> dmarc@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$
>  
> 
>
> ___
> 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] Treewalk causing changes

[Dotzero]

On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba 
wrote:

> I think the failure of this thinking is the idea that there's any
> intent going on at cuny.edu, and we need to remind ourselves that it's
> a *hierarchy*, and that that word means something specific.  In a
> hierarchy you expect to inherit things *through* the hierarchy,
> without skipping levels.  No one expects to inherit from a grandparent
> and *not* from the parent: that's not how hierarchies work.
>
> The fact that using the PSL resulted in that is unintentional and is
> extremely unlikely to be what anyone wanted.  It's far more likely
> that it's just what happened, without intent, and that no one noticed
> nor cared.
>
> I don't think there's anything to fix here, as the tree walk has
> already fixed this anomaly.  Letting people put the anomaly back in
> with a confusing tag that no one will ever deploy doesn't seem to be a
> good approach.  The real answer for anyone who needs to jump the
> hierarchy for some reason is that they simply need to put in an
> explicit DMARC record, and they get exactly what they want, *whatever*
> that is.
>
> Now, if we can find any real-world cases where that isn't practical --
> something like a whole load of subdomains of bmcc.cuny.edu that truly
> want to skip up and inherit from cuny.edu instead and will be broken,
> rather than fixed, by tree walk -- then I really do want to hear about
> that, and then I would think we need to revisit this.  I do not think
> that now.
>
> Barry
>

Thank you.  +1

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

Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports

[Dotzero]

On Sun, Feb 19, 2023 at 1:01 PM Scott Kitterman 
wrote:

> Thanks for checking.  In that case, I particularly think we should not be
> spending time on proposals like this.  We should focus on finishing the
> work we are chartered to do.
>
> Scott K
>

+1

Focus.

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

Re: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

[Dotzero]

On Sun, Jan 8, 2023 at 2:17 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> re:  "These are not forensic reports"
> The purpose of aggregate reports is to define WHERE a problem occurs,
> while the purpose of a forensic report is to define WHY a problem occurs.
> (e.g. "Why do my DKIM signatures fail when sent to example.com on
> Thursdays?")  The problem with Source IP alone is that it does not
> adequately answer the WHERE question.   Perhaps you have never had to find
> a computer behind a many-to-one NAT, but it happens.
>

Perhaps I did architect and run a system with many thousands of server
instance on-prem, colo, cloud and 3rd party vendors, including integration
of systems from acquisitions... and all without EHLO in aggregate
reports... and all without paying a 6-figure consulting fee to find all of
our mail sources and get them configured for DKIM signing. You make it
sound as if without EHLO, all is lost. As far as finding a server in a pool
behind NAT/PAT implementations, that isn't all that difficult - more like
drudge work. I've done it on implementations that involve both local load
balancing and wide area load balancing. I'm not exactly sure what point you
are trying to make.

>
> Aggregate reports are most useful to organizations with a mail environment
> which is so complex that they can justify a 6-figure consulting engagement
> to find all of their mail sources and get them configured with DKIM
> signing.   These are the ones that are likely to need HELO information to
> complete their rollout.   I am also thinking of DMARC-participating PSOs,
> which will be interested in maximum available information about DMARC
> failures.
>

Aggregate reports are useful to ANY organization interested in implementing
email authentication to protect their sending domains. Organizations with
large complex environments are in the best position to find all their mail
sources and get them configured properly for SPF/DKIM/DMARC. Smaller
organizations tend to lack the internal resources and the knowledge to
create and maintain proper implementations.

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

Re: [dmarc-ietf] Does Aggregate Reporting meet "Internet Scale" test?

[Dotzero]

On Thu, Dec 8, 2022 at 1:59 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> 1) DMARC was a successful 2-company experiment, which was turned into a
> widely implemented informational RFP.   We are now writing the
> standards-track version of that concept.  We hope that Standards Track will
> provide the basis for significantly increased adoption.  This seems the
> appropriate time to ask whether the design can be optimized for
> efficiency.  If you were designing from scratch, would this reporting
> design be the result?   What alternatives have we considered and ruled out?
>

You clearly don't know what you are talking about. There were a number of
organizations involved in the original DMARC effort. I represented one of
the participating organizations. Participating organizations included
Senders (Financials, Social Media companies, other Brands and Publishers),
Mailbox Providers and Intermediaries. There was a predecessor effort, which
included a number of organizations, and was organized by J.D. Falk
(Yahoo!)called MOOCOW. Another predecessor effort was organized by Ironport
(Pat Peterson) and also included a number of organizations. I am arguably
the first person to publicly ask receivers to reject mail that did not pass
either DKIM or aligned SPF. That was in 2007 (more than 5 years before
DMARC was published and before the DMARC.ORG team was organized. My public
posts (using my then corporate email account) can be found on the DKIM-OPS
list and SPF related lists. At the time there were only a couple of large
mailbox providers which could do anything with those assertions and they
could only provide chunks of mail logs for us (under contractual
relationship) for us to mutually discuss and evaluate what was going on.
I'm not writing this to brag on what I was doing but to make it clear that
your assertion that DMARC " was a successful 2-company experiment" is
absolutely incorrect and inaccurate.

Please provide the source of your incorrect assertion.

>
> 2) The burden of reporting is not experienced equally by all report
> senders.   If I send a batch of messages from 1 source domain to:
> - 10 target domains at Google, I will get 1 report, because Google
> consolidates across target domains.
> - 10 target domains at Yahoo, I will get 10 reports, because Yahoo chooses
> to disaggregate by target domain.
> - 10 target domains to Ironport clients, I will get 20 or 30 reports.
> These are client-specific appliances, many clients have multiple appliances
> configured in parallel for load balancing, and each appliance produces its
> own report.
>
> Google presumably can dedicate servers to the reporting function, while
> the Ironport servers seem to generate reports in parallel with message
> processing.   Altogether, I conclude that Google can absorb an increase in
> workload much more easily than an appliance
>
> 3) The burden of reporting is not shared equally at present.
>  Substantially all of my reporting comes from the three sources just
> stated:  Google, Yahoo, and Ironport appliances.   Since these
> organizations have not been actively participating, perhaps you are right
> and they are happy with the present design.   On the other hand, perhaps
> someone with connections should ask them whether they want to see
> optimizations.
>
> I'll fix this for you. Ironport appliances are sold by Cisco. I was one of
the first customers of Ironport (before they were even called Ironport they
used the codename "Godspeed") and helped them by giving feedback on
development of their "A" series (optimized for outbound email) appliances.
Cisco bought them (to fill a gap in their product offerings) and
subsequently focused on development of their "S" (security) line of
devices. Cisco also reduced Ironport support for standards development in
this space. After that a number of key Ironport employees went on to found
companies which have been very supportive of efforts in this space. Several
of note are Pat Peterson (Founded Agari) and Tim Draegen (Founded DMARCIAN).

>
> 4) As DMARC participation grows, the growth curve is not really linear.
> Currently, 40% of my mailstream is covered by DMARC reporting because more
> than 30% of my outbound mail goes to Google servers.   Altogether, the
> number of reporting domains, from all sources, is somewhere around 40.   To
> move reporting from 40% of messages to 40% of domains, the volume of
> reports will grow by orders of magnitude.
>
> 5) Which then raises the question of, "Who do we expect to do reporting?"
>   Several participants in this group have expressed the conviction that
> everyone who benefits from DMARC should also contribute to DMARC by doing
> reporting.This seems fair, but it is probably not necessary.
>  Reporting from Google alone is probably sufficient for domain owners to
> know whether or not their servers are properly configured.But as long
> as we want everyone to participate, we cannot assume that everyone will
> 

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

[Dotzero]

On Thu, Nov 24, 2022 at 6:12 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have been tracking the discussion pretty closely for about three years,
> and I have no recollection of any discussion which established that From is
> different from Author.   On the contrary, we have said that From indicates
> the person's whose ideas are being presented, which is why authorship is
> different from MailFrom.   MailFrom is equivalent to Scribe.
>
> Jeremiah the prophet is the presumed Author of the Biblical book with his
> name (or of the material on which it is based), even though he may have
> been illiterate.  The book tells us that a guy named Baruch was his scribe,
> but Baruch is remembered only incidentally.
>
> Please clarify why you don't believe that From = Author.
>
> Doug Foster
>

Then you weren't tracking when Dave Crocker proposed the use of "Author" as
a means of enabling replies where a mail list or other intermediary
rewrites the From. Is a rewritten email address from an intermediary the
>From AND the Author? If you reply to the rewritten From do you have any
reasonable expectation that your reply will reach the purported "Author" of
the email?

You are going down the same path that Microsoft went down with SenderID
when they conflated Sender with MailFrom. I used to send emails to the
folks at Microsoft who were pushing SenderID, using their own email
addresses because you could consistently get a neutral. It drove them nuts
for months before they admitted it was a problem with PRA. From != Author.
There may be instances where it does but that is not because a standard
specifies it to be so. Merely a happy coincidence.

Michael Hammer

>
>
> On Thu, Nov 24, 2022 at 4:58 PM Dotzero  wrote:
>
>>
>>
>> On Thu, Nov 24, 2022 at 2:22 PM Neil Anuskiewicz 
>> wrote:
>>
>>>
>>>
>>> On Nov 24, 2022, at 7:10 AM, Dotzero  wrote:
>>>
>>> 
>>>
>>>
>>> On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster <
>>> dougfoster.emailstanda...@gmail.com> wrote:
>>>
>>>> Your solution is straightforward, but I am not sold.
>>>>
>>>> DMARC PASS means that the message is free of author impersonation.
>>>> This can only be true if all authors are verifiable and verified.
>>>>
>>>
>>> This is absolutely not true. An attacker can use homoglyphs, cousin
>>> domains and other means of impersonating a sender. An attacker can
>>> impersonate a sender within the same domain and DMARC will happily give a
>>> pass because the right hand side of the from address matches. Author !=
>>> sending domain. DMARC only addresses direct domain impersonation.
>>>
>>>
>>> Can we assume that in the context of DMARC, passing means passing with
>>> alignment when it stops exact domain impersonation. I think we can assume
>>> that nobody on this list thinks me using my own passing spf and dkim with
>>> sketchythreatactor.com  and spoofing your header from isn’t what anyone
>>> means by pass in this context. If the effect can stop impersonation it’s
>>> ipso facto in alignment.
>>>
>>
>> In the context of a standards working group, no, we cannot assume
>> anything. There have been plenty of misstatements and factually incorrect
>> statements in this group. This includes  "DMARC PASS means that the message
>> is free of author impersonation". DMARC pass means it passed DMARC
>> validation. If a homoglyph From email address passes DMARC validation,
>> there has indeed been impersonation of the purported From address. And for
>> purposes of DMARC, Author is not necessarily the same as From. We've had
>> that discussion multiple times before.
>>
>> Michael Hammer
>>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

[Dotzero]

On Thu, Nov 24, 2022 at 2:22 PM Neil Anuskiewicz 
wrote:

>
>
> On Nov 24, 2022, at 7:10 AM, Dotzero  wrote:
>
> 
>
>
> On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Your solution is straightforward, but I am not sold.
>>
>> DMARC PASS means that the message is free of author impersonation.  This
>> can only be true if all authors are verifiable and verified.
>>
>
> This is absolutely not true. An attacker can use homoglyphs, cousin
> domains and other means of impersonating a sender. An attacker can
> impersonate a sender within the same domain and DMARC will happily give a
> pass because the right hand side of the from address matches. Author !=
> sending domain. DMARC only addresses direct domain impersonation.
>
>
> Can we assume that in the context of DMARC, passing means passing with
> alignment when it stops exact domain impersonation. I think we can assume
> that nobody on this list thinks me using my own passing spf and dkim with
> sketchythreatactor.com  and spoofing your header from isn’t what anyone
> means by pass in this context. If the effect can stop impersonation it’s
> ipso facto in alignment.
>

In the context of a standards working group, no, we cannot assume anything.
There have been plenty of misstatements and factually incorrect statements
in this group. This includes  "DMARC PASS means that the message is free of
author impersonation". DMARC pass means it passed DMARC validation. If a
homoglyph From email address passes DMARC validation, there has indeed been
impersonation of the purported From address. And for purposes of DMARC,
Author is not necessarily the same as From. We've had that discussion
multiple times before.

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

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

[Dotzero]

On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Your solution is straightforward, but I am not sold.
>
> DMARC PASS means that the message is free of author impersonation.  This
> can only be true if all authors are verifiable and verified.
>

This is absolutely not true. An attacker can use homoglyphs, cousin domains
and other means of impersonating a sender. An attacker can impersonate a
sender within the same domain and DMARC will happily give a pass because
the right hand side of the from address matches. Author != sending domain.
DMARC only addresses direct domain impersonation.

>
> What do you dislike about PERMERROR?  My SPF algorithm continues
> evaluating on PERMERROR and returns both the error and the fallback
> result.   This is not standard but it is within my freedom of control.
>
> Similarly, an evaluator could apply a fallback DMARC solution after
> PERMERROR caused by a multi-From message, if they want.  But it is not our
> role to ensure acceptance of an identifier that cannot be verified.
>  Verification is established at the domain level.   Multi-from
> authorization is established at the individual level.   This is the mailing
> list problem redux.  The mailing list is authorized by an individual
> subscriber, but individual authorizations cannot be proven.
>
> DF
>

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

Re: [dmarc-ietf] Standardizing signature contents

[Dotzero]

On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz 
wrote:



>
> DMARC’s job is to flat out prevent unauthorized spoofing.  It’s not a
> stretch to imagine some higher signature standard without feeling like
> you’re on DKIM’s turf.
>

The above statement is so incorrect. DMARC's "job" is to mitigate direct
domain abuse, nothing more and nothing less.

The use of homoglyphs is a form of "spoofing". DMARC does nothing to
prevent this.

The use of cousin domains is a form of "spoofing". DMARC does nothing to
prevent this.

DMARC is very useful for what it does, but that's it. DMARC does not " flat
out prevent unauthorized spoofing ".

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

Re: [dmarc-ietf] Weak signatures

[Dotzero]

On Thu, Oct 27, 2022 at 10:33 AM Brotman, Alex  wrote:

> How will we handle the ever-changing definition of "weak"?
>

> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
>
This is why I don't believe "weak" should be included in any normative
manner. I'm not sure that it should be defined for reporting. I think a
better approach is some verbiage about weak signatures as a problem.
Perhaps for reporting something like "Local Policy: weak signature" but
leave it up to the validator to deal with the weak signature decision
outside of DMARC. It's really a DKIM issue.

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

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely  wrote:

> On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote:
> > On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely 
> wrote:
> >> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote:
> >>> Unaligned signatures are orthogonal/irrelevant to DMARC. They may be
> useful in
> >>> other contexts. In the DKIM standard, signatures mean that the signer
> is
> >>> asserting some (unspecified) responsibility for the signed message.
> That may be
> >>> useful for some reputation systems.
> >>
> >> Somewhat skewed w.r.t. orthogonality, actually.  Indirect flows are
> >> explicitly mentioned in the I-D as a reason to override DMARC
> dispositions:
> >
> > DMARC only gives a pass if either SPF or DKIM passes. Unaligned DKIM
> > signatures will NEVER give a DMARC pass.
>
>
> How about dmarc=redeemed?
>
>
> >> There MAY be an element for reason, meant to include any notes the
> >> reporter might want to include as to why the disposition policy does
> >> not match the policy_published, such as a Local Policy override
> >> (possible values listed in Appendix A).
> >
> > Local Policy is just that. When a Receiver invokes Local Policy it is
> > saying "I don't care what DMARC says, I'm choosing to ignore DMARC
> Policy
> > and do something else".
>
>
> It is a local decision to trust an ARC seal or an unaligned signature,
> depending on the signing domains.  Yet, the decision can be made by the
> same
> filter which looked up the From: domain policy.
>
>
It may or may not be performed by the same filter which looked up the From:
domain policy. So what? That same filter may also consider reputation while
the SMTP session is held open. That doesn't make reputation part of DMARC.

>
>
> >> ARC too is a kind of unaligned signature, albeit with a bunch of
> >> additions. The extra information it carries, designed to bestow enough
> >> trust in the chain of custody to outweigh the self-referential reliance
> of
> >> aligned From:, doesn't substantially change the semantic of DKIM
> >> signatures.  And we should say how to report it, sooner or later.
> > > ARC != DMARC. It is a separate RFC that gives participants an
> alternative
> > means of evaluating mail flows when DKIM signatures are broken. Nothing
> > more and nothing less.
>

ARC is a different signature not an "unaligned signature".


>
>
> Conflicting protocols?  ARC was devised by the DMARC WG, during the phase
> of
> "improving the identification of legitimate sources that do not currently
> conform to DMARC requirements."  So, yes, on the one hand, since unaligned
> signatures don't conform to DMARC requirements, they're not DMARC.  On the
> other hand, as a fusion of deterministic authentication techniques and
> domain
> policies, DMARC is intrinsically extensible.  For aggregate reporting in
> particular, we explicitly provide for extensions.
>

Splitting out reporting is a good thing. Perhaps it should be renamed so
that it is not DMARC centric. I would suggest the fact that something (ARC)
which is not DMARC is included in the reporting that was developed as an
integral part of DMARC is a matter of convenience more than anything else.

>
>
> >> I'm not proposing to mandate the evaluation of any evaluable item.
> >> However, I'd neither discourage it.  Perhaps technology will provide us
> >> with ecological sources of energy.
> >
> > There is nothing wrong with using whatever data points you have
> available.
> > That doesn't necessarily mean that such evaluations and choices are
> DMARC.
>
>
> If ARC were a separate thing, it'd make no sense to include its data in
> DMARC
> aggregate reports.
>

As I wrote above, it is more a matter of convenience than anything else.
Generating separate ARC reports is duplicative effort from both a report
generating perspective as well as consumption of those reports.

>
> I think what we could do is to identify some criteria that a report
> generator
> may follow, such as doing everything, reporting up to X signatures, or
> doing
> SPF only.  Such meta data could be useful to report consumers, along with
> the
> generator's software/version.
>
>
> Best
> Ale
> --
>

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

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely  wrote:

> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote:
> > Unaligned signatures are orthogonal/irrelevant to DMARC. They may be
> useful in
> > other contexts. In the DKIM standard, signatures mean that the signer is
> > asserting some (unspecified) responsibility for the signed message. That
> may be
> > useful for some reputation systems.
>
>
> Somewhat skewed w.r.t. orthogonality, actually.  Indirect flows are
> explicitly
> mentioned in the I-D as a reason to override DMARC dispositions:
>

DMARC only gives a pass if either SPF or DKIM passes. Unaligned DKIM
signatures will NEVER give a DMARC pass.

>
> There MAY be an element for reason, meant to include any notes the
> reporter might want to include as to why the disposition policy does
> not match the policy_published, such as a Local Policy override
> (possible values listed in Appendix A).
>

Local Policy is just that. When a Receiver invokes Local Policy it is
saying "I don't care what DMARC says, I'm choosing to ignore DMARC Policy
and do something else".

>
> ARC too is a kind of unaligned signature, albeit with a bunch of
> additions.
> The extra information it carries, designed to bestow enough trust in the
> chain
> of custody to outweigh the self-referential reliance of aligned From:,
> doesn't
> substantially change the semantic of DKIM signatures.  And we should say
> how to
> report it, sooner or later.
>
> ARC != DMARC. It is a seperate RFC that gives participants an alternative
> means of evaluating mail flows when DKIM signatures are broken. Nothing
> more and nothing less.
>
> I'm not proposing to mandate the evaluation of any evaluable item.
> However,
> I'd neither discourage it.  Perhaps technology will provide us with
> ecological
> sources of energy.
>

There is nothing wrong with using whatever data points you have available.
That doesn't necessarily mean that such evaluations and choices are DMARC.

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

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

Unaligned signatures are orthogonal/irrelevant to DMARC. They may be useful
in other contexts. In the DKIM standard, signatures mean that the signer is
asserting some (unspecified) responsibility for the signed message. That
may be useful for some reputation systems.

Michael Hammer

On Sat, Oct 22, 2022 at 9:50 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Yes, it could have multiple causes.
>
>   I was just trying to elucidate a reason why unaligned signatures are
> needed.
>
> Instead I conclude that one best aligned signature is all that is needed
> for reporting.  Not 100, not 10, just 1.
>
> Doug
>
> On Sat, Oct 22, 2022, 7:43 AM Dotzero  wrote:
>
>> " 3) A signature has been compromised and an unauthorized source is
>> sending authenticated mail.  SPF FAIL with DMARC PASS provides the alarm
>> trigger."
>>
>> This is incorrect. SPF FAIL with DMARC PASS can simply be an indirect
>> mail flow. It might also be an incorrectly configured SPF record.
>>
>> Michael Hammer
>>
>> On Fri, Oct 21, 2022 at 5:57 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> I remain unconvinced.   Mail is nearly free to the sender, but expensive
>>> and risky for the recipient and his organization.   Anything unwanted
>>> message that gets through the spam filter consumes a person's time, which
>>> is a non-trivial opportunity cost.   Asking me to accept extra cost to
>>> provide "nice to have" data is too much.
>>>
>>> Your first scenario is mostly about what an evaluator can do.  I think
>>> there is an opportunity and need to discuss all the ways that an evaluator
>>> can obtain acceptable authentication on a message that fails SPF or DKIM,
>>> but the chairs have been clear that doing so is "not DMARC" and out of
>>> scope.I don't see is how the aggregate report contents facilitate or
>>> hinder your un-munging algorithm.
>>>
>>> I am not a mass mailer with a complicated identity structure, so I am
>>> willing to be educated about the wonderful things that can be learned from
>>> aggregate reports.   Based on my current knowledge, the use cases seem few,
>>> and do not need unaligned results.
>>>
>>> 1) A server is sending legitimate mail and is correctly configured with
>>> both SPF and DKIM.   The feedback from non-forwarded recipients confirms
>>> this fact.
>>>
>>> 2) A server is sending legitimate mail on behalf of the domain owner,
>>> but has a configuration error:  no signature, invalid signature, or using a
>>> server not in SPF record.SPF results from non-forwarded recipients will
>>> identify the problem so that it can be corrected.
>>>
>>> 3) A signature has been compromised and an unauthorized source is
>>> sending authenticated mail.  SPF FAIL with DMARC PASS provides the alarm
>>> trigger.
>>>
>>> 4) A server is using a delegated signature for an unauthorized purpose.
>>>  Nothing in the reports is likely to indicate this problem.   If it is
>>> detected from other sources, the correction involves revoking the public
>>> key and terminating the offending organization.
>>>
>>> 5) Some mail is failing authentication after forwarding without MailFrom
>>> rewrite or forwarding with changes.The IP address and MailFrom address
>>> help to identify the problem but the domain owner has no ability to correct
>>> the problem.   He can use p=none to limit the consequences.
>>>
>>> 6) Some mail is failing authentication because it originates from an
>>> illegitimate source.  The IP address and MailFrom address help to
>>> identify the problem but the domain owner has no ability to correct the
>>> problem.   He can use p=reject to limit the consequences.
>>>
>>> Case 5 and Case 6 are distinguishable only by the reputation of the
>>> server or Mail>From address.   Malicious senders are unlikely to add a
>>> signature to prove their identity, so perhaps a signature suggests case 5
>>> rather than case 6.   But a competent forwarder will be doing MailFrom
>>> rewrite, so the forwarder identity will be present whether a signature is
>>> added or not.
>>>
>>> These use cases do not deal with authentication failures after multiple
>>> forwards.   An abundance of signature data might allow the domain owner to
>>> reconstruct the forwarding path, but is that something he needs to do,?   I
>>> don't think so.

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

" 3) A signature has been compromised and an unauthorized source is sending
authenticated mail.  SPF FAIL with DMARC PASS provides the alarm trigger."

This is incorrect. SPF FAIL with DMARC PASS can simply be an indirect mail
flow. It might also be an incorrectly configured SPF record.

Michael Hammer

On Fri, Oct 21, 2022 at 5:57 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I remain unconvinced.   Mail is nearly free to the sender, but expensive
> and risky for the recipient and his organization.   Anything unwanted
> message that gets through the spam filter consumes a person's time, which
> is a non-trivial opportunity cost.   Asking me to accept extra cost to
> provide "nice to have" data is too much.
>
> Your first scenario is mostly about what an evaluator can do.  I think
> there is an opportunity and need to discuss all the ways that an evaluator
> can obtain acceptable authentication on a message that fails SPF or DKIM,
> but the chairs have been clear that doing so is "not DMARC" and out of
> scope.I don't see is how the aggregate report contents facilitate or
> hinder your un-munging algorithm.
>
> I am not a mass mailer with a complicated identity structure, so I am
> willing to be educated about the wonderful things that can be learned from
> aggregate reports.   Based on my current knowledge, the use cases seem few,
> and do not need unaligned results.
>
> 1) A server is sending legitimate mail and is correctly configured with
> both SPF and DKIM.   The feedback from non-forwarded recipients confirms
> this fact.
>
> 2) A server is sending legitimate mail on behalf of the domain owner, but
> has a configuration error:  no signature, invalid signature, or using a
> server not in SPF record.SPF results from non-forwarded recipients will
> identify the problem so that it can be corrected.
>
> 3) A signature has been compromised and an unauthorized source is sending
> authenticated mail.  SPF FAIL with DMARC PASS provides the alarm trigger.
>
> 4) A server is using a delegated signature for an unauthorized purpose.
>  Nothing in the reports is likely to indicate this problem.   If it is
> detected from other sources, the correction involves revoking the public
> key and terminating the offending organization.
>
> 5) Some mail is failing authentication after forwarding without MailFrom
> rewrite or forwarding with changes.The IP address and MailFrom address
> help to identify the problem but the domain owner has no ability to correct
> the problem.   He can use p=none to limit the consequences.
>
> 6) Some mail is failing authentication because it originates from an
> illegitimate source.  The IP address and MailFrom address help to
> identify the problem but the domain owner has no ability to correct the
> problem.   He can use p=reject to limit the consequences.
>
> Case 5 and Case 6 are distinguishable only by the reputation of the server
> or MailFrom address.   Malicious senders are unlikely to add a signature to
> prove their identity, so perhaps a signature suggests case 5 rather than
> case 6.   But a competent forwarder will be doing MailFrom rewrite, so the
> forwarder identity will be present whether a signature is added or not.
>
> These use cases do not deal with authentication failures after multiple
> forwards.   An abundance of signature data might allow the domain owner to
> reconstruct the forwarding path, but is that something he needs to do,?   I
> don't think so.
>
> As for the duplicate signature issue, my rule would detect support for the
> new signature algorithm if it appears first.
>
> I would be happy to hear a case summary which indicates how a real problem
> was solved, and was only solvable using non-aligned results.
>
> Doug Foster
>
>
>
> On Fri, Oct 21, 2022 at 4:11 AM Alessandro Vesely  wrote:
>
>> On Fri 21/Oct/2022 00:53:56 +0200 Douglas Foster wrote:
>> >
>> > Aligned DKIM PASS
>> > When an aligned DKIM result is PASS, I don't see that the domain owner
>> needs
>> > any more data collection performed.   The verifiable DKIM scope ID
>> should tell
>> > him where the message originated, and the source IP and HELO name tell
>> the last
>> > place it landed before delivery.I cannot see why a domain owner
>> would spend
>> > a lot of time trying to analyze success results, unless his interests
>> have
>> > transitioned from assuring identity to analyzing marketing impacts.
>>  We are
>> > not trying to provide marketing data, and any successful use of DMARC
>> for that
>> > purpose seems like an encroachment on the privacy concerns that we want
>> to
>> > minimize.
>>
>>
>> Non-aligned signatures can be meaningful for various reasons.  In that
>> case,
>> the result of their evaluation is also meaningful.  For an example, the
>> original author's domain signature, before From: was munged, is
>> meaningful.  If
>> it fails, it can be retried after undoing MLM transformation, possibly
>> leading
>> to secure recognition of 

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

On Tue, Oct 18, 2022 at 11:18 PM Scott Kitterman 
wrote:

>
>
> On October 18, 2022 10:16:44 PM UTC, Neil Anuskiewicz <
> n...@marmot-tech.com> wrote:
> >
> >
> >> On Oct 2, 2022, at 11:01 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >>
> >> 
> >> In many cases, an evaluator can determine a DMARC PASS result without
> evaluating every available identifier.
> >> If a message has SPF PASS with acceptable alignment, the evaluator has
> no need to evaluate any DKIM signatures to know that the message produces
> DMARC PASS.
> >I think it’s critical to DMARC that receivers do things like evaluate and
> report on DKIM whether or not SPF passes and is alignment. Without this, it
> would make it harder for senders to notice and remediate gaps in their
> authentication. Since there’s not a downside (that I know of), I’d say this
> should be a MUST if at all possible.
>
>
> What is the interoperability problem that happens if evaluators don't do
> that?
>
> Scott K
>

Scott, What is the interoperability problem is evaluators didn't provide
reports at all? Reporting isn't a "must" for interoperability but it
certainly helps improve outcomes instead of senders flying blind.

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

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero]

On Sun, Oct 2, 2022 at 2:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> In many cases, an evaluator can determine a DMARC PASS result
> without evaluating every available identifier.
>
>- If a message has SPF PASS with acceptable alignment, the evaluator
>has no need to evaluate any DKIM signatures to know that the message
>produces DMARC PASS.
>- Some identifiers are easily excluded by simple inspection:   A "
>sendgrid.net" identifier cannot authenticate "example.com"
>
> When the evaluator has an identifier which is known but not evaluated, he
> does not have a way to document this outcome in the aggregate reports.   To
> fix this hole, we should add an authentication result of "not evaluated"
>
> Doug Foster
>

It is absolutely a wrong thing to suggest not evaluating DKIM if there is
an SPF pass. One of the purposes of aggregated reporting is to help sending
domains to understand the what is breaking in their mail streams. SPF
PASS/DKIM PASS is totally different than SPF PASS/DKIM FAIL. The overhead
cost to perform the DKIM check is relatively low. Why wouldn't you do this.

Do you believe that preventing a sender from getting this additional piece
of information is a good thing?

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

Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5

[Dotzero]

+1 to Scott's suggestion.

Michael Hammer

On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba  wrote:

> I’m happy with Scott’s suggestion.
>
> Barry
>
> On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman 
> wrote:
>
>> On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote:
>> > > On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote:
>> > > > I think “SHOULD do what the domain owner says” is too strong, and
>> > > > propose to change it.  By making it that strong we vary from the
>> > > > policy that recipients use all the input they have to make their
>> > > > handling decision, and we tell them that using this input alone is
>> > > > normatively required for interoperability/security.  I think that’s
>> > > > wrong.
>> > > >
>> > > > I suggest this alternative text:
>> > > >
>> > > > NEW
>> > > >
>> > > > A Mail Receiver implementing the DMARC mechanism gets the Domain
>> > > > Owner’s or PSO's published DMARC Domain Owner Assessment Policy
>> > > > when a message fails the DMARC test, and uses it as an important
>> > > > factor in deciding how to handle the message.
>> > >
>> > > I agree that blindly following the remote policy is a hazard.
>> > > (Personally,
>> > > I enable that on a restricted set of domains only.)  However, the
>> above
>> > > text is too generic and slightly inexact.  You actually get the policy
>> > > /before/ concluding the evaluation.  DMARC result is an important
>> factor
>> > > also if it is a pass or a none.
>> > >
>> > > The above snippet can be skipped.
>> >
>> > The above snippet is just a slight change to what was already there,
>> > and I think it's useful to keep it... but I think I did change the
>> > sense of it when I rephrased it.  In the original, "when a message
>> > fails the DMARC test" was attached to the action that the receiver
>> > should take.  In mine, that attachment is lost.
>> >
>> > Maybe this rewording works better?:
>> >
>> > NEW-2
>> >A Mail Receiver implementing the DMARC mechanism gets the
>> >Domain Owner’s or PSO's published DMARC Domain Owner Assessment
>> >Policy and uses it as an important factor in deciding how to
>> >handle the message. When a message fails the DMARC test, Mail
>> >Receivers should make a best-effort attempt to comply with the
>> >published policy, but email streams can be complicated (due to
>> >forwarding, existing RFC5322.From domain-spoofing services,
>> >etc.) and Mail Receivers may have other information that can
>> >inform their decisions.
>> >
>> >When Mail Receivers deviate from a published Domain Owner
>> >Assessment Policy during message processing they SHOULD make
>> >available the fact of and reason for the deviation to the Domain
>> >Owner via feedback reporting, specifically using the
>> >"PolicyOverride" feature of the aggregate report defined in
>> >[DMARC-Aggregate-Reporting].
>> > END
>> >
>> > I think that retains the connection that I lost in the first attempt.
>>
>> In this part of the document, I think the phrase "best-effort" is a
>> problem.
>> A "best-effort" to comply with the policy is pretty trivial to do: if it
>> fails
>> and the policy is reject, then reject.  That's not actually what we
>> want.
>> This section is a non-normative paraphrase of part of Section 5.8.  I
>> think it
>> would be better to shorten it and reference Section 5.8.  Also, this says
>> SHOULD use PolicyOverride.  Section 5.8 currently discourages it.
>>
>> We ought to decide if we want to discourage or encourage reporting of
>> policy
>> overrides.  I think encourage is the right answer.  Based on that
>> approach,
>> I'd suggest the following changes:
>>
>> In place of the above:
>>
>> > NEW-3
>> >A Mail Receiver implementing the DMARC mechanism gets the
>> >Domain Owner’s or PSO's published DMARC Domain Owner Assessment
>> >Policy and uses it as an important factor in deciding how to
>> >handle the message. Mail handling considerations based on DMARC
>> >policy enforcement are discussed below in [section-5.8].
>>
>> > END
>>
>> And this additional change in Section 5.8:
>>
>> Replace:
>>
>> >Mail Receivers should only report reject or quarantine policy actions
>> >in aggregate feedback reports that are due to published DMARC Domain
>> >Owner Assessment Policy.  They need not report reject or quarantine
>> >actions that are the result of local policy.  If local policy
>> >information is exposed, abusers can gain insight into the
>> >effectiveness and delivery rates of spam campaigns.
>>
>> with:
>>
>> >When Mail Receivers deviate from a published Domain Owner
>> >Assessment Policy during message processing they SHOULD make
>> >available the fact of and reason for the deviation to the Domain
>> >Owner via feedback reporting, specifically using the
>> >"PolicyOverride" feature of the aggregate report defined in
>> >[DMARC-Aggregate-Reporting].
>>
>> I think this reduces 

Re: [dmarc-ietf] Issue opened: Use a four-valued token for the four roles of a DMARC policy

[Dotzero]

+1 to Scott and John's comments. I read it and do not find a compelling
value equation for including.

Michael Hammer

On Sat, Aug 27, 2022 at 10:41 PM John Levine  wrote:

> It appears that Scott Kitterman   said:
> >> - If you disagree with Doug's proposal, please clearly and concisely
> >> explain why the benefit he is proposing is not useful enough to
> >> introduce the incompatibility.
> >
> >I did read it.  I see zero benefit to it.
>
> I also looked at it and find extra complication with no benefit.
>
> R's,
> John
>
> ___
> 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] Mailing List message authentication

[Dotzero]

I agree with Scott. We do need to be that blunt given what people have
thrown out there because DMARC doesn't say it's not ok. One thing we have
been firm about is that if there isn't a DMARC record it isn't DMARC. For
"other things", people are free to go off and experiment with consenting
parties. If their experiment is interesting and potentially beneficial they
are free to submit an RFC. Running code and rough consensus.

For example, I accept the group consensus regarding sister domains. Once
the group publishes the final document I will publish my statement of the
problem and what I perceive as the fix. I will include specific examples of
how such attacks, using real domains, can be performed. Mail receiving
domains have one approach to mitigation. Affected sending domains have
another path. Concerned parties will take steps outside DMARC as local
policy. Those who are unconcerned will not. At some later point it may get
folded into DMARC, or it may not.

Michael Hammer

On Sat, Aug 27, 2022 at 6:30 PM Scott Kitterman 
wrote:

> I do.  Maybe I'm wrong and I've just read far to many crazy ideas preceded
> by
> "It doesn't actually say you CAN'T do that".  I would strongly prefer we
> be as
> direct and blunt about this as possible, even though that's probably
> insufficient to the task in at least some cases.
>
> I know Ale liked your change because it was 'nicer'.  I guess I dislike it
> for
> roughly the same reason.
>
> Scott K
>
> On Saturday, August 27, 2022 5:50:10 PM EDT Barry Leiba wrote:
> > You really think it needs to be BCP 14 key words, rather than saying in
> > plain English that if there’s no DMARC record we are outside the realm of
> > DMARC?
> >
> > Barry
> >
> > On Sat, Aug 27, 2022 at 5:15 PM Scott Kitterman 
> >
> > wrote:
> > > On Friday, August 26, 2022 11:51:51 AM EDT Alessandro Vesely wrote:
> > > > On Fri 26/Aug/2022 17:21:09 +0200 Barry Leiba wrote:
> > > > > Personally, I'm fine with the text here, but I would also be happy
> > > > > with removal of the BCP 14 key words here, like this:
> > > > >
> > > > > NEW
> > > > > If the set produced by the DNS Tree Walk contains no DMARC policy
> > >
> > > record
> > >
> > > > > (i.e., any indication that there is no such record as opposed to a
> > > > > transient DNS error), then the DMARC mechanism does not apply to
> this
> > > > > message and Mail Receivers need to use other means to decide how to
> > > > > handle the message.
> > > > > END
> > > >
> > > > This is nicer than MUST NOT.  It makes more sense, since we also
> removed
> > > > the SHOULD when the record is found and the test fails.
> > >
> > > I very much disagree.  If there's no DMARC record, whatever you do
> after
> > > that
> > > is not DMARC and we should say so.  Softening this language opens the
> door
> > > for
> > > all kinds of nonsense.  People can and will do nonsensical things, but
> we
> > > need
> > > to make it very clear that this isn't what this document is about.
> > > Tampering
> > > with the opt-in nature of DMARC is a recipe for interoperability
> problems.
> > >
> > > Scott K
>
>
>
> ___
> 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] Girl Scout troops vs MLM problems (#70)

[Dotzero]

On Fri, Aug 12, 2022 at 12:28 PM John R Levine  wrote:

> On Fri, 12 Aug 2022, Alessandro Vesely wrote:
> >> When Dave proposed the Author header, part of the idea was that DMARC
> could
> >> use it rather than From.
> >
> > IIRC that was the Sender: field.
>
> No, DMARC decided not to use Sender back when DMARC was new.  Dave
> suggested using Author to work around the From hacking.  I still think
> this is completely out of scope and not worth any more argument.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>

+1

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

Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting

[Dotzero]

On Mon, Aug 8, 2022 at 4:14 AM Alessandro Vesely  wrote:

> On Sun 07/Aug/2022 19:20:12 +0200 John Levine wrote:
> >>> By remembering failure reports issued in the past, new failures having
> >>> already reported characteristics (e.g. same forwarder) can be silently
> >>> ignored.  That would greatly reduce noise.
> >>
> >> This is a horrible idea. It presupposes that failures from the same
> origin
> >> (e.g. same forwarder) at different points in time are the result of the
> >> same underlying cause. This may be true in some cases but not true in
> other
> >> cases. Operational environments are not static. Even for short time
> frames
> >> this is a bad approach.
> >
> > It also misses the fact that "already reported characteristics" is
> > undefined.
>
>
> Right, that's to be defined.  Clearly, the criteria differ between SPF and
> DKIM.  We could also define fuzzy criteria.
>
>
> > We have plenty of work already without inventing more.  Let's agree not
> to
> > do this and get back to work on what we've already agreed to do.
>
>
> Does "not to do this" refer to failure reporting as a whole?
>
> As is, it is a noise generator that the majority of users decided not to
> implement.
>

When "we" (dmarc.org team) originally came up with DMARC, the goal was to
take what was in essence a private club to an open standard that anyone
could benefit from. My personal take is that validators choose not to
provide failure reporting for various reasons other than "it's a noise
generator". It requires extra effort and resources that some validators
choose not to undertake because it doesn't benefit them (from their
perspective). Another reason some validators don't implement is fear of
potential liability under GDPR or similar regimes. There are a number of
validators that provide failure reports through private channels but only
where a direct or indirect contractual relationship exists. This seems to
primarily through intermediaries that provide email authentication services.

Michael Hammer


>
>
> Best
> Ale
> --
>
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)

[Dotzero]

On Sun, Aug 7, 2022 at 6:41 PM John R Levine  wrote:

> Moving this back to the main list:
>
> I said:
> Even if I agreed that it would be a good idea for every mailing list in the
> world to rewrite From lines so it's harder to tell who the messages are
> from and
> you can't reply reliably, there's no way that would survive last call.
> Remember that a few large mail providers abused DMARC to outsource the
> cost of
> leaking their user address books to crooks, and screwed up every mailing
> list in
> the world as a side effect.
> Blaming the victim is not the answer. Unfortunately, there is no good
> answer.
>
> Scott said:
> Agreed. On my phone I use an MUA which will display either the friendly
> name or
> the address, not both. I routinely get messages that I can't tell who they
> are
> from without reading the raw header if someone forgets to put their name
> at the
> end of the mail because I no longer get their address in the normal display
> thanks to rewriting. I think, as was discussed at the meeting, what types
> of
> domains DMARC is suitable for needs to have some kind of MUST or MUST NOT
> depending on how it's worded then with some non-normative words in an
> appendix
> which discuss options for damage containment when the MUST is ignored.
>

I'm surprised that John did not invoke King Canute at this comment. That
ship has sailed. The horse bolted the barn and closing the barn door won't
put the horse back in. Domain administrators will implement DMARC policy or
not as they choose.


>
> On Sun, 7 Aug 2022, Alessandro Vesely wrote:
> > Saying that domains with human users MUST NOT use DMARC is not a solution
> > either.  The wording has to express the explanation Pete gave at the
> > meeting, which sounds very close to RFC 6919.
> >
> > Letting the victim die is not the solution either.  Among the solutions
> > that MLMs adopt, some allow to undo From: rewriting at the MDA level.
> ARC
> > doesn't preclude From munging.  ARC verifiers can restore the original
> > From: at rMDA level too.  Actually, small receivers can simply trust
> > selected, DMARC-aligned mailing lists and restore the original From: in
> the
> > cases where MLM saved it (w/o ARC).  This kind of hack could be set up
> > really quick.
>
> Please please can we stop doing this.  Trying to unmunge rewritten From:
> headers is totally out of scope for this group, and even if it weren't it
> does not scale and has terrible security problems.  (If good guys can put
> in real rewrites, bad guys can put in fake rewrites, and if a recipient
> can tell whose rewrites are good enough to unmunge, it can equally well
> ignore whatever problem the rewrite was supposed to fix.)
>

+1

>
> I will try and write something similar to what Scott suggests, describing
> the problems without making us look foolish, and mentioning that there are
> workarounds if you insist on sending p=reject messages on paths that DMARC
> cannot describe.
>

I look forward to seeing this.

>
> R's,
> John
>
> ___
> 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] Collecting message metadata, was Time to work on failure reporting

[Dotzero]

On Sun, Aug 7, 2022 at 6:04 AM Alessandro Vesely  wrote:

> On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote:
> >>> I don't understand what you mean by "no data collection."  It is true
> that
> >>> you can send a failure report immediately without saving anything for
> >>> later.
> >>
> >> “Those who cannot remember the past are condemned to repeat it.” –
> George
> >> Santayana, The Life of Reason, 1905.
> >
> > Perhaps I'm unusually dense today but I still don't understand what any
> of
> > this has to do with DMARC failure reports.
>
>
> By remembering failure reports issued in the past, new failures having
> already reported characteristics (e.g. same forwarder) can be silently
> ignored.  That would greatly reduce noise.
>
>
> Best
> Ale
> --
>

This is a horrible idea. It presupposes that failures from the same origin
(e.g. same forwarder) at different points in time are the result of the
same underlying cause. This may be true in some cases but not true in other
cases. Operational environments are not static. Even for short time frames
this is a bad approach.

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

Re: [dmarc-ietf] what to document about the tree walk

[Dotzero]

On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy 
wrote:

> On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman 
> wrote:
>
>> >> I think a choice within DMARCbis is a bad idea.  Effectively the
>> choice exists.  Evaluators will have the choice to stay with an RFC 7489
>> design or to upgrade to DMARCbis.
>> >
>> >The incentive to upgrade is not clear.  DMARC filters can run based on
>> an obsolete version of the PSL with no inconvenience, for a different
>> flavor of "upgrade".  Indeed, according to John's figures, we could have
>> done without any psd= tag.
>> >
>> Using obsolete data is a bug, not a feature.
>>
>
> Or using data that is accidentally correct most of the time, where
> alternatives are available.  Either way, +1.
>
> >Doug's idea of checking the results is a means to draw the attention of
>> operators on both the PSL version they use and its agreement with the DNS
>> at large.  New implementations could be encouraged to track the differences
>> and produce some kind of report about them.  IME, although running a very
>> small mail site, it does happen to hit some PSL entry, a fact which I
>> realized by chance —browsing the logs— so I cannot tell figures.
>>
>
>> What would operators do with such a report?  Receivers tracking sender
>> configuration issues and reporting issues back to them is a very 1990s
>> approach to making the Internet work. I don't think it's relevant to
>> anything useful these days.
>>
>
> If we think this is important data to put in front of people, this WG
> could do that sort of survey once there are implementations and include the
> result in an appendix, or put it in the WG's wiki or in the IETF's
> collection of implementation reports:
> https://www.ietf.org/how/runningcode/implementation-reports/
>
> It sounds like we're mostly there already given the analysis John did
> previously.
>
> >> We can't get rid of the PSL without getting rid of the PSL.
>> >>
>> >> There's no way to constrain it within the document.  If we have a
>> 'choice', we are essentially signing up the IETF to a future effort to
>> produce an update to actually get rid of it.
>> >
>> >Right, that would be the Internet Standard.
>>
>> Not really.  To drop functionality going to Internet Standard, don't you
>> have to show it's not used?  How would that even work?
>>
>
> RFC 2026 lays out the criteria for progressing a Proposed Standard to a
> Draft Standard and then to Internet Standard, and RFC 6410 later
> consolidated the latter two.  The criterion to which I think you're
> referring asserts that any unused features need to be removed before a
> protocol can advance.  However, RFC 7489 is not a Proposed Standard, so
> we're not constrained by that here.
>
> In any case, I agree that the longer the PSL remains in the equation, the
> longer we have to keep it, due to both inertia and growth of the deployed
> base.
>
> My understanding is that the IETF, based on past experiences, doesn't do
>> flag days where everyone has to switch to some new thing by a specific date.
>>
>
> I think that's right, though Barry's memory on this might be better than
> mine.  At a minimum, they're exceedingly rare.  A working group or other
> community pushing for a flag day needs to have quite a bit of momentum to
> make it work.
>
>
>> Currently we don't have any procedural requirement for backward
>> compatibility, since RFC 7489 isn't an IETF document.  Based on the working
>> group charter and good engineering practice we should limit changes that
>> affect existing deployments, but we have more flexibility now than we will
>> ever have again.
>>
>> In my view, standardizing two ways to do policy discovery and alignment
>> would be a substantial danger to interoperability and we'd be stuck with it
>> approximately forever.
>>
>
> +1 to this, for the reasons John gave in the email right below this one
> that just came in.
>
> Bite the bullet and mark use of the PSL historical for DMARC. As has been
pointed out, there will always be a long tail but we are talking rare
corner cases where the results from the two approaches diverge.

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

Re: [dmarc-ietf] Bridging the gap

[Dotzero]

On Sat, Jun 18, 2022 at 11:45 AM Barry Leiba 
wrote:

> I don't know... I would say that if the working group has rough
> consensus to reach out and asks someone(s) to do it, they could then
> say that they're calling on behalf of the working group.  No?
>
> Barry
>

Personally, if this is implemented, I think it would be better if a group
like M3AAWG were to volunteer or take on such a role. Murray has pointed
out some of the issues with someone reaching out on behalf of the working
group. The only people I can think of who could remotely claim to represent
the working group would be the chairs. Do we  really want to go there?

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

Re: [dmarc-ietf] SPF doesn't accommodate third level .name domains?

[Dotzero]

On Tue, May 31, 2022 at 1:14 PM David Bustos  wrote:

> John wrote:
> > It appears that Scott Kitterman   said:
> > >On May 30, 2022 9:50:05 PM UTC, David Bustos  wrote:
> > >>Since I own david.bustos.name, someone forwards da...@bustos.name for
> me; I presume Verisign does.
> > >>
> > >>Lately I think email receivers have been quarantining my messages and
> I suspect the reason is SPF.
> >
> > Forwarding is pretty broken these days.  Even if you had perfect SPF, a
> lot of your incoming
> > mail would fail DMARC because a lot of DMARC policies depend on SPF and
> SPF can't deal with forwarded mail.
>
> I'm talking about outgoing mail, not incoming mail.
>

I believe John uses "incoming" in referring to receivers.

>
> > > Specifically, no SPF record is
> > >published for bustos.name .  I asked Verisign to publish one and they
> declined.
> >
> > I'm not surprised.  The registry contract with ICANN forbids it.
>
> Is the contract available for me to read?
>
> You would need to ask ICANN or the registry. This is the IETF working
> group for DMARC.
>
> > In any event, I agree with Scott, your special case is not special to
> everyone else.  How about using
> > the address da...@david.bustos.name and getting your hosting provider
> to manage your mail?
>
> This special case was committed to by TLD regulators back in 2002 and it
> is a problem for everyone with a third level .name domain.  That's probably
> not many people, but the current situation is inconsistent so I am trying
> to figure out if any increases in consistency are possible.
>

It sounds like your beef is with the registry and ICANN. Nothing to do with
IETF and this working group.

>
> Yes, if no changes are possible then I may need to abandon
> da...@bustos.name .
>

If you want changes to that agreement you will not find satisfaction in
this working group.

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

[dmarc-ietf] DMARCbis and Standard Track

[Dotzero]

My understanding when the DMARCbis effort was spun up was that we were
trying to move it to Standard Track. Is this still the goal? A number of
experimental things are currently being included. This would seem to
preclude DMARC being on Standard Track.

If the experimental items being discussed were removed from the current
draft(s) and moved to separate documents, there would still be an issue if
there was a DMRC dependency rather than the experiment(s) being layered on
top of DMARC.

I'm not giving any proposed answers. I'm simply asking the question. Chairs?

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

Re: [dmarc-ietf] Figuring out the tree walk

[Dotzero]

On Mon, Feb 14, 2022 at 10:46 AM Todd Herr  wrote:

> On Sun, Feb 13, 2022 at 5:16 PM Dotzero  wrote:
>
>>
>>
>> On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman 
>> wrote:
>>
>>
>>>
>>> I think "a" would be cleanest, but I think it would cause too much
>>> backward
>>> compatibility trouble and should not be further considered.  In previous
>>> working group discussions on this I recall specific suggestions that
>>> this would
>>> be problematic and this is supported by the short survey that Elizabeth
>>> Zwicky
>>> reported on.
>>>
>>
>> The problem with what Elizabeth shared, and I do appreciate her sharing
>> it, is that what she shared doesn't show the extent of the variety of
>> behaviors in those "sibling" relationships. Because those are undocumented
>> and not understood AND it isn't even clear that those relationships and
>> behaviors are what is intended by the "standard", serious questions are
>> raised.  Can a "standard" that allows a variety of undocumented
>> non-standard behaviors (and outcomes) be considered a standard? The details
>> behind some of the examples given by Elizabeth indicate potential abuse
>> vectors beyond my original concerns. Unfortunately, the receiving
>> organizations most able to provide detailed examples are unlikely to
>> provide them publicly due to privacy concerns, embarrassing customers, etc.
>> It might be useful if an organization like M3AAWG could process detailed
>> examples from members,obfuscate the organizational information and share it
>> publicly as an aggregation of examples to inform a better standards
>> creation process.
>>
>>
>>
> I'm not understanding what you mean when you state that "it isn't even
> clear that those relationships and behaviors are what is intended by the
> 'standard'"
>

The heart and core of DMARC policy is about intent. That is, an
organization is expressing which messages are authorized are sent on behalf
of that organization through the use of either aligned DKIM signing or
aligned SPF records. Elizabeth provided more details of the high level
examples provided to this group but in a private conversation among parties
that are contractually bound, including a confidentiality clause. Among
those examples, there were cases of what can only be called
misconfigurations (flip flopping of from, mail from, DKIM signing, etc.
within the same organizational domain) and other irregularities.

>
> RFC 7489 seems to be clear in its definition of alignment.
>
> In section 3.1.1 DKIM-Authenticated Identifiers, the text reads, in part:
>
>In relaxed mode, the Organizational Domains of both the [DKIM 
> <https://datatracker.ietf.org/doc/html/rfc7489#ref-DKIM>]-
>authenticated signing domain (taken from the value of the "d=" tag in
>the signature) and that of the RFC5322 
> <https://datatracker.ietf.org/doc/html/rfc5322>.From domain must be equal if
>the identifiers are to be considered aligned.  In strict mode, only
>an exact match between both of the Fully Qualified Domain Names
>(FQDNs) is considered to produce Identifier Alignment.
>
>
> and in section 3.1.2, SPF-Authenticated Identifiers, the text reads, in part:
>
>
>In relaxed mode, the [SPF 
> <https://datatracker.ietf.org/doc/html/rfc7489#ref-SPF>]-authenticated domain 
> and RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From
>domain must have the same Organizational Domain.  In strict mode,
>only an exact DNS domain match is considered to produce Identifier
>Alignment.
>
>
> Both define relaxed alignment as "same Organizational Domain", with no 
> caveats on any other relationship between the two domains being compared.
>
>
> How do we determine intent, especially if the claim is that intent is 
> different from what was written in the RFC?
>
>
> We're fortunate, I guess, that we know how to contact most if not all of the 
> people named in the
>
> Acknowledgements section of the RFC, along with the two named authors, but 
> there is literature to suggest
>
> that eyewitness testimony is not 100% reliable.
>
> Are there notes from the time of writing RFC 7489 to confirm that the intent 
> of the group was to not allow alignment
>
> among domains without a direct hierarchical relationship?
>
>
Todd, you are well aware that meeting notes of DMARC.ORG are kept and in
fact, those notes have been kept going back well before the date on  RFC
7489. Unfortunately, those notes are subject to contractual obligations,
including a confidentiality clause,

Re: [dmarc-ietf] Figuring out the tree walk

[Dotzero]

On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman 
wrote:


>
> I think "a" would be cleanest, but I think it would cause too much
> backward
> compatibility trouble and should not be further considered.  In previous
> working group discussions on this I recall specific suggestions that this
> would
> be problematic and this is supported by the short survey that Elizabeth
> Zwicky
> reported on.
>

The problem with what Elizabeth shared, and I do appreciate her sharing it,
is that what she shared doesn't show the extent of the variety of behaviors
in those "sibling" relationships. Because those are undocumented and not
understood AND it isn't even clear that those relationships and behaviors
are what is intended by the "standard", serious questions are raised.  Can
a "standard" that allows a variety of undocumented non-standard behaviors
(and outcomes) be considered a standard? The details behind some of the
examples given by Elizabeth indicate potential abuse vectors beyond my
original concerns. Unfortunately, the receiving organizations most able to
provide detailed examples are unlikely to provide them publicly due to
privacy concerns, embarrassing customers, etc. It might be useful if an
organization like M3AAWG could process detailed examples from
members,obfuscate the organizational information and share it publicly as
an aggregation of examples to inform a better standards creation process.

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

Re: [dmarc-ietf] (7.1?) DKIM-only authentication

[Dotzero]

On Fri, Feb 11, 2022 at 3:14 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I know that we took out the reference to default policy at my request, and
> I think it was in section 7.1.   But subsequent discussion helped me to
> understand objectives that were not clear to me in the previous text.   I
> think we need to re-insert something specific about domain owners that want
> DKIM-only authentication.   Proposed language:
>
> “Some domain owners want DMARC authentication to use DKIM signatures
> only.   This requires ensuring an SPF result other than PASS.  An SPF
> result of FAIL or SOFTFAIL is likely to produce unwanted rejects by
> non-DMARC evaluators.   An SPF result of NONE may be ineffective if
> an evaluator responds to NONE by applying a locally-defined default SPF
> policy that produces an unintended SPF PASS.   Domain owners who desired
> DKIM-only authentication are RECOMMENDED to publish a policy of “?ALL”,
> which ensures an SPF result of NEUTRAL, neither PASS nor FAIL.
> Similarly, DMARC evaluators SHOULD treat SPF NONE as equivalent to NEUTRAL
> when the RFC5322.From domain has an applicable DMARC policy record.”
>
>
> Doug Foster
>
> -1 on the proposed language. A Sending domain may choose not to publish an
> SPF record. That is their perogative. The only appropriate warning is that
> if a message passes through a 3rd party where the DKIM signature might be
> broken, AND a DMARC policy other than NONE is published, the message may be
> quarantined or rejected depending on the published policy.
>

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

Re: [dmarc-ietf] 7.1 SPF -ALL

[Dotzero]

On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely  wrote:

> On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote:
> > This section implies that publishing SPF -ALL is a risky move, which is
> made
> > worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded
> > without MAILFROM rewrite and (b) the evaluator does not implement DMARC.
>
>
> My reading of Section 7.1 differs.  I see no risks implied in its wording.
>
>
> > Proposed language for the second paragraph:
> >
> > “By design, DMARC allows a verified and aligned DKIM signature to
> override
> > an unfavorable SPF result, including FAIL.However, the full
> message,
> > including the DATA section, must be accepted before DMARC
> participation can
> > be determined and DKIM signatures can be evaluated. Consequently,
> DMARC
> > evaluators SHOULD NOT use SPF results to reject a message prior to
> receipt
> > of the entire DATA section.”
>
>
> I like better the current wording.
>
>
> > When this was previously proposed, it was noted that some DMARC
> evaluators
> > consider the combination of SPF FAIL with a policy containing only
> "-ALL" to be
> > a special case which justifies early reject.  I think it is obvious that
> if an
> > evaluator does not wish to allow a DKIM override for that situation,
> then the
> > SHOULD NOT can be ignored.
>
>
> SPF clearly suggests that receivers apply whitelisting broadly.  In
> addition,
> publishers can explicitly include ?exists:%{ir}.list.dnswl.org or similar
> reference to public whitelists.  Whitelisted is neither pass nor fail.
>
> Of course, messages rejected before any DMARC processing takes place will
> not
> contribute to feedback reports.  Operators just have to be aware of it.
>
>
> Best
> Ale
> --
>
> I agree with Ale. Further, it is not as if we are considering this in a
vacuum. Since originally being made public, DMARC has been widely
implemented and it has not been identified that this (early reject on SPF
-all) has been a significant or even an insignificant problem based on data.

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