from:"Neil"

> On May 8, 2024, at 12:59 PM, John Levine  wrote:
> 
> According to Mark Alley  :
>> -=-=-=-=-=-
>> 
>> p=none is one solution, the other ( interoperable method) is to exempt the
>> traffic from whatever process is breaking DKIM (i.e. external subject/body
>> warning tags, URL rewriting, etc.). But that's a per-customer fix.
> 
> That would require getting the customer to understand that they're causing the
> problem and to spend money fixing it, rather than saying "your mail is 
> broken."
> 
> Good luck with that. Also remember that until DMARC came along, this
> all worked just fine.

That’s the easy part in my experience. A good conversation addressing concerns 
and getting buy in from previously skeptical people is easy in conversation. In 
my experience the misconceptions are often there yet shallow. They’re easily 
fixed misconceptions from the whirlwind of information, hype, and I’ve even 
seen panic. I’m not wise enough to know how to counter that chaotic noise 
machine at scale.
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

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



> On May 7, 2024, at 6:09 PM, 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)
> 
> 
> 
> - Mark Alley
> 
Yes,my side effect of the rush to p=none or bust to check some boxes comes from 
an incentive just as incentives brought us DMARC snake oil. I’ve noticed that 
friends of mine much smarter than me don’t know anything about email 
authentication. Even people who work in email often seem to avoid it. So the 
incentive to jump through hoops was kind of unfortunate but I suspect that the 
half backed incentives toward p=none as a copy and paste are part of a longer 
term plan. The next set of incentives seem likely to encourage enforcement at a 
pace that doesn’t turn the apple cart over on small businesses and the like.

There kind of needs to be a lot of clear communication which is relatively easy 
as it doesn’t take long to grok the basics if you’re interested at all. ___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

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

> On May 7, 2024, at 7:19 PM, John Levine  wrote:
> 
> It appears that Scott Kitterman   said:
>>> 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.
> 
> I have to agree.  I still have no plans to use anything other than p=none
> on most of my domains.
> 
> Also, it's not like p=reject is a magic bullet. It makes some kinds of
> mail forgery harder, but it does nothing about lookalike domains or
> attacks that use the fact that most mail programs don't even show the
> author's address.
> 
> Please, let's not get distracted and let's finish up.

Dmarc is the best tool for the job. There are other tools to fight lookalike 
spoofing. I haven’t heard a serious claim that dmarc is the miracle cure. You 
might say it kind of fits the Unix philosophy of a tool that does one thing 
well. I think there’s been hype. But the good news is it’s easy to explain to 
someone the limits of DMARC as once you get it it makes intuitive sense. The 
issue isn’t with DMARC’s excessive claims. It’s some of DMARC’s advocates. I 
think of DMARC as a key puzzle piece. I feel we have a tendency to think less 
of DMARC, even undervalue it, because of the behavior of a few overzealous 
advocates.
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

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



> On May 8, 2024, at 3:48 AM, Laura Atkins  wrote:
> 
> 
> 
>> On 8 May 2024, at 02:25, 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.
> 
> I’m currently dealing with a client that sends notification emails to their 
> customer businesses. Those businesses forward the messages out to their 
> employees. DMARC breaks during the forwarding process - my guess is that it’s 
> due to the business filtering appliances modifying the body of the message on 
> inbound - adding “external” or modifying links. 
> 
> The mail is all isolated on a subdomain that’s only used for these 
> notifications. The domain had p=reject but a lot of the notifications were 
> being rejected due to that policy.
> 
> I’m not sure what the actual solution is here, but for the short term I told 
> the client to move to p=none because they are being paid to send these 
> notifications and the notifications are failing. These kinds of indirect 
> corporate mail flows seem to be an increasing problem  - I saw another report 
> of the same issue. I’m interested in hearing what the practical and 
> implementable solutions are here. I brought it up on one forum and the only 
> suggestion I got was to “add the forwarding systems to SPF.” I said no, 
> because that’s unworkable. 
> 
> It seems to me that until ARC is in widespread use, there will be mail that 
> is too important to use p=reject for. 

Yes, in fact, if I’m not mistaken the concept of the “general purpose” domain 
that’s perpetually p=none came about because of these kind of scenarios. One or 
more subdomains set aside for such use cases. It might be just a necessity as 
an intermediate step along this journey.

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

Re: [dmarc-ietf] Thoughts on choosing N

2024-05-05 Thread Neil Anuskiewicz



> On Apr 17, 2024, at 6:20 PM, John Levine  wrote:
> 
> It appears that Todd Herr   said:
>> When DMARC was first developed, there was concern about DNS load and
>> needing to minimize DNS lookups. Operational expertise now shows that this
>> is no longer cause for concern.
>> 
>> Short circuiting a tree walk has led to many issues, like a reliance on the
>> PSL, complicated algorithms for Org Domain discovery, ...
> 
> I have to say I have some sympathy for just taking out the limit and
> if you sometimes need to walk umpteen levels on stupid domains, so be
> it.
> 
> Or I suppose say if there's more than 8 components in the name, just stop 
> because no domain
> actually used for mail is that deep.  Take out the skip stuff.

Yeah, you aren’t designing for the perfect storm edge case.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Thoughts on choosing N

2024-04-17 Thread Neil Anuskiewicz



> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely  wrote:
> 
> On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote:
>>> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman  
>>> wrote:
>>> I am confused.
>>> 
>>> Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be 
>>> found either in this case.  Why do we need to support something that is 
>>> currently unsupported? >>
>>> We picked n=5 to allow the current org level record to be detected by the 
>>> tree walk.  It's true that the tree walk provides some additional 
>>> flexibility for subordinate organizations within what we would call a DMARC 
>>> org domain based on RFC 7489, but that was by no means anything we ever 
>>> described as a feature or a goal. >
>> I don't share your understanding here. I interpret some of the text of 
>> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do 
>> away with the PSL and Org Domain entirely; just walk the tree" to at least 
>> imply that the tree walk was designed to provide this flexibility [...]
> 
> 
> If we wanted to provide high flexibility, then we'd have designed an 
> inheritance system whereby, for example, policy or rua address can be 
> inherited from parent domains.  John would 've called it mission gallop.
> 
> 
>>> Even if some organizations have very deep DNS trees, the fact that some 
>>> entity uses a.b.c.d.e.f.tld doesn't affect DMARC.  The record for the top 
>>> level of their organization will still be found. >>
>>> In any case, any domain, at any depth in the tree can publish their own 
>>> DMARC record if they need some special thing.  The value of N does not 
>>> affect that at all >
>> Fair enough. You're correct that a DMARC policy can be published for any
>> specific domain used as the RFC5322.From domain, so perhaps a bit of text
>> in the Tree Walk section describing the really deep use case and
>> the solution for it might be a compromise.
> 
> 
> We may say the system is harsh by design.  You can rely on the org domain 
> settings or define your own in the From: domain.  Flexibility to fetch values 
> from intermediate domains is not provided.

I’m imagining a little chaos if such flexibility were shoe horned in. Rare, 
sure, but frantic, baffled stress for a few unlucky souls.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-17 Thread Neil Anuskiewicz

On Apr 17, 2024, at 6:33 AM, Todd Herr  wrote:On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:Colleagues,DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy record as follows:The DMARC policy record is published for a PSD, but it is not the Organizational Domain for itself and its subdomain. There is no need to put psd=n in a DMARC record, except in the very unusual case of a parent PSD publishing a DMARC record without the requisite psd=y tag.I don't think this is entirely accurate, especially the second sentence ("no need ... except in the very unusual case"), and here's why. Either that, or the description of the Tree Walk needs to be changed.The Tree Walk is intended for both DMARC Policy discovery and Organizational Domain discovery, and section 4.7 (DMARC Policy Discovery) says the policy to be applied will be the DMARC record found at one of these three locations:The RFC5322.From domainThe Organizational Domain of the RFC5322.From domainThe Public Suffix Domain of the RFC5322.From domainMeanwhile, section 4.8, Organizational Domain Discovery, gives the following three options for where the Organizational Domain is:DMARC record with psd=nThe domain one level below the domain with a DMARC record with the tag psd=yThe record for the domain with the fewest number of labels.The Tree Walk, as described in section 4.6, defines two explicit places to stop, both of which rely on discovery of a DMARC policy record with a psd tag defined.One of your concerns is that without a PSD tag, but I think the default is PSD=n. Does,that address that concern or did I misunderstand the concern?The default for the psd tag is 'u', not 'n'.See https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-formatThank you and I’m not sure why I was thinking n. I guess I figured if it’s not a PSD which should publish an explicit y. My logic just looking at the tree walk makes no sense.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-16 Thread Neil Anuskiewicz



> On Apr 16, 2024, at 2:18 PM, Todd Herr 
>  wrote:
> 
> 
> Colleagues,
> 
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy 
> record as follows:
> 
> The DMARC policy record is published for a PSD, but it is not the 
> Organizational Domain for itself and its subdomain. There is no need to put 
> psd=n in a DMARC record, except in the very unusual case of a parent PSD 
> publishing a DMARC record without the requisite psd=y tag.
> 
> I don't think this is entirely accurate, especially the second sentence ("no 
> need ... except in the very unusual case"), and here's why. Either that, or 
> the description of the Tree Walk needs to be changed.
> 
> The Tree Walk is intended for both DMARC Policy discovery and Organizational 
> Domain discovery, and section 4.7 (DMARC Policy Discovery) says the policy to 
> be applied will be the DMARC record found at one of these three locations:
> The RFC5322.From domain
> The Organizational Domain of the RFC5322.From domain
> The Public Suffix Domain of the RFC5322.From domain
> Meanwhile, section 4.8, Organizational Domain Discovery, gives the following 
> three options for where the Organizational Domain is:
> DMARC record with psd=n
> The domain one level below the domain with a DMARC record with the tag psd=y
> The record for the domain with the fewest number of labels.
> The Tree Walk, as described in section 4.6, defines two explicit places to 
> stop, both of which rely on discovery of a DMARC policy record with a psd tag 
> defined.

One of your concerns is that without a PSD tag, but I think the default is 
PSD=n. Does,that address that concern or did I misunderstand the concern?

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

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

2024-04-08 Thread Neil Anuskiewicz



> On Apr 1, 2024, at 2:43 PM, John R. Levine  wrote:
> 
> On Sun, 31 Mar 2024, Jim Fenton wrote:
>> Based on the above problems, I do not think DMARC-bis should be published as 
>> a standards track document by IETF.
> 
> This reminds me of the NAT wars in the 1990s.  We all understand that DMARC 
> has a lot of problems, but it's far more widely used than many of the IETF's 
> published standards.  It just makes us look insular and out of touch to 
> pretend that it doesn't exist, or if we shut our eyes it will go away.

I’d be hugely dissapointed if this does not go into the standards track.

N
___
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

2024-04-08 Thread Neil Anuskiewicz

On Mar 31, 2024, at 12:45 PM, Seth Blank  wrote:On Sun, Mar 31, 2024 at 2:00 PM John Levine  wrote:It appears that Mark Alley   said:
>>   People who publish -all know what they do.
>
>I posit that there is a non-insignificant amount of domain owners that 
>don't know what the consequences of -all are other than that they've 
>been instructed to use "-all" by a guide online, ...

I'm with you.  I have had too many arguments with people whose SPF records
end with -all and insist it is everyone's fault but theirs that their mail
doesn't get delivered.

The special case of a record only containing -all, meaning they send no
mail whatsoever, is different and I don't think it's contentious.

But I still am reluctant to give people a lot of advice about how to
sent up their SPF records. This is dmarc-bis, not spf-bis.I concur, and do not want to accidentally make normative updates to SPF.SPF hard fails in a DMARC context is a constant point of confusion and bad operational practice. I do think the spec should cover it in a concise and mostly informational way.My proposed text was:Some Mail Receiver architectures implement SPF in advance of any DMARC operations. This means that an SPF hard fail ("-") prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place, and DKIM has a chance to validate the message instead of SPF. Operators choosing to use "-all" to terminate SPF records should be aware of this. Since DMARC only relies on an SPF pass, all failures are treated equally. Therefore, it is considered best practice when using SPF in a DMARC context for domains that send email to end records with a soft fail ("~" / "~all").---Could this work with simply the removal of the last sentence covering best practice? 

R's,
JohnJohn’s treatment of this topic is as clear and concise as I’ve seen. Excellent.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all



> On Apr 7, 2024, at 6:20 PM, Scott Kitterman  wrote:
> 
> 
> 
>> On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz 
>>  wrote:
>> 
>> 
>>>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz  wrote:
>>> 
>>> 
>>> 
>>>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen  wrote:
>>>> 
>>>> Scott Kitterman writes:
>>>>> I hear you. Your operational issue is my system working as designed.
>>>>> DMARC works on top of SPF, it doesn't change it.
>>>> 
>>>> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
>>>> are trying to change the fact that people rely purely on SPF, and try
>>>> to get them moved to use DMARC istead, and we are trying to explain
>>>> that if you do SPF inside the DMARC context, you get exactly same
>>>> policy results you get as when you do SPF before, except you get it
>>>> better, as you have more data available. Using -all would be
>>>> completely ok if everybody would be doing DMARC, but as there are some
>>>> systems which do SPF outside DMARC, and there having -all might
>>>> shortcircuit DMARC out from the equation, we should provide guidance
>>>> to those people how they can get best results in current environment.
>>>> Thus the best current practice should be use to use ~all instead of
>>>> -all if you are trying to use DMARC, and want other systems to
>>>> actually act based on your DMARC policy.
>> 
>> The problem I see is that some receivers never got the memo and still 
>> enforce just on an SPF hard fail which only creates fear, uncertainty, 
>> doubt, and annoyance.
> 
> 
> If there's FUD, it's due to claiming it is a significant problem for DMARC.  
> Everyone has a different mail stream, so YMMV, but in my experience this is 
> approximately never an issue.  This is only even potentially an issue when 
> Mail From aligned and SPF is fail.  I don't recall the last time I saw that 
> happen for a message that also passed DKIM (and d= was aligned).
> 
> What is the overwhelming case for me is Mail From is not aligned (like this 
> mailing list) and SPF is pass, none, neutral, etc.  Even if the receiver 
> rejects SPF fail, it almost never comes up.  Then the DMARC result is a 
> function of the DKIM signature verifying and being aligned.  The fact that my 
> domain has a -all SPF record virtually never matters for DMARC.
> 
> So let's move on...

Let’s move on.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-10.txt



> On Mar 17, 2024, at 9:12 AM, Alessandro Vesely  wrote:
> 
> On Sun 17/Mar/2024 16:50:40 +0100 internet-drafts wrote:
>> Internet-Draft draft-ietf-dmarc-failure-reporting-10.txt is now available. It
>> is a work item of the Domain-based Message Authentication, Reporting &
>> Conformance (DMARC) WG of the IETF.
>>Title:   Domain-based Message Authentication, Reporting, and Conformance 
>> (DMARC) Failure Reporting
>>Authors: Steven M Jones
>> Alessandro Vesely
>>Name:draft-ietf-dmarc-failure-reporting-10.txt
>>Pages:   16
>>Dates:   2024-03-17
> 
> 
> However we close the fifth point of issue 133[*], I added a new paragraph to 
> delimit failure reporting scope:
> 
> 3. Other Failure Reports
> 
>This document only describes DMARC failure reports. DKIM failure reports
>[RFC6651] and SPF failure reports [RFC6652] are described in their own
>documents. A Report Generator issuing a DMARC failure report may or may not
>simultaneously issue also a failure report specific to the failed
>authentication mechanism, according to its policy.
> 
> It adds RFC665{1,2} as Informative References.
> 
> Keep it?  Change it, but how?  Strike it?
> 
> 
> Best
> Ale
> 
Do you all think we should mention the decline and fall of the failure report? 
I think that Yahoo! is the only major MBP that still sends failure reports. I 
think the others may have stopped over PII concerns.

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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all



> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz  wrote:
> 
> 
> 
>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen  wrote:
>> 
>> Scott Kitterman writes:
>>> I hear you. Your operational issue is my system working as designed.
>>> DMARC works on top of SPF, it doesn't change it.
>> 
>> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
>> are trying to change the fact that people rely purely on SPF, and try
>> to get them moved to use DMARC istead, and we are trying to explain
>> that if you do SPF inside the DMARC context, you get exactly same
>> policy results you get as when you do SPF before, except you get it
>> better, as you have more data available. Using -all would be
>> completely ok if everybody would be doing DMARC, but as there are some
>> systems which do SPF outside DMARC, and there having -all might
>> shortcircuit DMARC out from the equation, we should provide guidance
>> to those people how they can get best results in current environment.
>> Thus the best current practice should be use to use ~all instead of
>> -all if you are trying to use DMARC, and want other systems to
>> actually act based on your DMARC policy.

The problem I see is that some receivers never got the memo and still enforce 
just on an SPF hard fail which only creates fear, uncertainty, doubt, and 
annoyance.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 7, 2024, at 9:27 AM, John R Levine  wrote:
> 
> On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
>> I think clear statement and supporting text explaining clearly that SPF is 
>> no longer the policy layer would be a good idea. While it might be slightly 
>> out of scope, I have encountered people who think best practice is to 
>> enforce with -ALL.
> 
> We had a long discussion about that which you can read in the list archive at 
> https://mailarchive.ietf.org/arch/browse/dmarc/
> 
> Nobody is crazy about SPF but removing it completely is too much of a change. 
> As Ale pointed out, if you don't want people to use SPF for your DMARC 
> validation, make all your SPF entries ? or ~ rather than +.
> 
> This WG should have finished a year ago.  Unless you think something is so 
> broken that it's worth more months of delay, forget it.

To be clear I was suggesting considering deprecating the hardfail modifier only 
as it’s archaic. I was not saying deprecate SPF.  That said, i don’t know what 
the unexpected consequences of this change would be. I think SPF still has its 
place. Maybe they’ll make some adjustments over in the SPF working group. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all



> On Apr 7, 2024, at 6:54 AM, Tero Kivinen  wrote:
> 
> Scott Kitterman writes:
>> I hear you. Your operational issue is my system working as designed.
>> DMARC works on top of SPF, it doesn't change it.
> 
> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
> are trying to change the fact that people rely purely on SPF, and try
> to get them moved to use DMARC istead, and we are trying to explain
> that if you do SPF inside the DMARC context, you get exactly same
> policy results you get as when you do SPF before, except you get it
> better, as you have more data available. Using -all would be
> completely ok if everybody would be doing DMARC, but as there are some
> systems which do SPF outside DMARC, and there having -all might
> shortcircuit DMARC out from the equation, we should provide guidance
> to those people how they can get best results in current environment.
> Thus the best current practice should be use to use ~all instead of
> -all if you are trying to use DMARC, and want other systems to
> actually act based on your DMARC policy.
> 
>> Anything like this belongs in an operational guidance document, not in the
>> protocol description.  I have no problem describing the trade offs in an
>> appropriate document, but I don't think this is it.
>> 
> 
I think you’re right the core document should be kept sacred but a DMARCbis 
pointing to an operational document that discusses the trade offs and perhaps 
goes so far as to recommend best practices if that seems appropriate.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

Forgive me if this a dumb idea but, Scott and others, any discussion of just 
deprecating SPF hardfail at some point?

> On Apr 6, 2024, at 1:40 PM, John Levine  wrote:
> 
> It appears that Scott Kitterman   said:
>> I hear you.  Your operational issue is my system working as designed.  DMARC
>> works on top of SPF, it doesn't change it.  
>> 
>> Anything like this belongs in an operational guidance document, not in the
>> protocol description.  I have no problem describing the trade offs in an
>> appropriate document, but I don't think this is it.
> 
> I agree.  "Don't do stupid stuff" goes in an A/S, not in the spec.
> 
> I entirely believe people are confused about SPF, but they're confused
> about everything. A few days ago on the generally clueful NANOG list
> we had to explain to someone that rejecting mail if DKIM signatures
> don't verify is not a good idea.
> 
> 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] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all



> On Apr 6, 2024, at 1:40 PM, John Levine  wrote:
> 
> It appears that Scott Kitterman   said:
>> I hear you.  Your operational issue is my system working as designed.  DMARC
>> works on top of SPF, it doesn't change it.  
>> 
>> Anything like this belongs in an operational guidance document, not in the
>> protocol description.  I have no problem describing the trade offs in an
>> appropriate document, but I don't think this is it.
> 
> I agree.  "Don't do stupid stuff" goes in an A/S, not in the spec.
> 
> I entirely believe people are confused about SPF, but they're confused
> about everything. A few days ago on the generally clueful NANOG list
> we had to explain to someone that rejecting mail if DKIM signatures
> don't verify is not a good idea.
> 
> R's,
> John
> 

I think clear statement and supporting text explaining clearly that SPF is no 
longer the policy layer would be a good idea. While it might be slightly out of 
scope, I have encountered people who think best practice is to enforce with 
-ALL.

It’s not that it’s stupid to do that, it’s just that email auth is still kind 
of obscure knowledge for some reason I don’t quite understand since it’s been a 
while.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] General Purpose Domain

2024-03-16 Thread Neil Anuskiewicz

Unless I’m misunderstanding, a General Purpose Domain is a separate domain or 
at least subdomain:

*   You’d use a General Purpose Domain (GPD) exclusively for Mailing Lists
*  You would designate either a subdomain or a less critical org domain as your 
GPD. 
* The GPD MUST NOT have an enforcing policy of reject. That is, the policy of a 
GPD must remain p=none.

The heading is Interoperability considerations which is a section mostly 
talking about indirect mail flows. The explanation’s cursory for such a common 
and challenging problem. 

I’d say start with defining the problem and solution in more depth, giving 
Mailing Lists its own heading under Indirect mail flows with a clearly 
delineated problem and solution even at the risk of some redundancy.

Otherwise, I think there will be a lot of busy people who will miss the 
indirect mail bit entirely and many who do read it won’t grok what exactly 
they’re supposed to do and why.

 Neil


 




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

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

2024-03-16 Thread Neil Anuskiewicz

> On Mar 16, 2024, at 9:38 AM, Scott Kitterman  wrote:
> 
> On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote:
>> John Levine writes:
>>> It appears that Todd Herr   said:
>>>> I agree that clarifying it can't hurt, obviously, ...
>>> 
>>> I disagree, it does hurt.
>>> 
>>> If we say you're allowed to use CNAMEs to point to DMARC records,
>>> people are to say uh oh, is there something special here? What about
>>> DKIM records? what about SPF records? how about SPF includes? or SPF
>>> redirects?
>>> 
>>> Really, there is nothing to say here, so let's not say it.
>> 
>> We could add an example Appendix B that uses CNAME, so that would give
>> indication, yes of course you can use CNAMEs, without explicitly
>> adding text that might cause confusion.
> 
> I think we have more important things to spend our time on.
> 
> Scott K
> 

I agree that CNAMES isn’t worth time or effort. From what I’ve seen it’s the 
larger ESP’s do this and they document it and they provide records to copy and 
paste from the auth settings into DNS. Then you go back and click a button and 
it lights up green. The sort of person who’s confused by the CNAME is the same 
person confused by a TXT record. I’m reading DMARCbis 30  now and things are 
looking good to me.

My only quibble is, so far, I’ve not seen a clear,  concise explanation of the 
general purpose domain. It’s not complicated but I think the idea is going to 
be new for a lot of people. Some people might misunderstand in less than useful 
ways as well.

Neil

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

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

2024-03-15 Thread Neil Anuskiewicz



> On Mar 15, 2024, at 9:40 AM, Alessandro Vesely  wrote:
> 
> On Fri 15/Mar/2024 02:34:15 +0100 Murray S. Kucherawy wrote:
>>> On Fri, Mar 15, 2024 at 9:11 AM John Levine  wrote:
>>> It appears that Todd Herr   said:
>>> >I agree that clarifying it can't hurt, obviously, ...
>>> 
>>> I disagree, it does hurt.
>>> 
>>> If we say you're allowed to use CNAMEs to point to DMARC records,
>>> people are to say uh oh, is there something special here? What about
>>> DKIM records? what about SPF records? how about SPF includes? or SPF
>>> redirects?
>>> 
>>> Really, there is nothing to say here, so let's not say it.
>>> 
>> +1, I don't understand what needs to be clarified here.  If I ask for a TXT
>> record at a given name, I expect to get one back (or a non-success code).
>> It really doesn't matter to DMARC whether that process traversed a CNAME
>> record in the process.  (Or if it does matter, I've yet to see a reason
>> why.)
> 
> 
> +1, people who know DNS can derive the possibility to use CNAME on their own. 
> Those who don't are better off not trying it.

It’s mostly ESP’s with large customer bases that ask for CNAMES, providing them 
with scalability, and the ability to rotate keys. It’s the appropriate choice 
in some contexts. Why is this a concern of the WG?

Neil
___
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



> On Mar 11, 2024, at 10:38 PM, 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
>> 
>>> Could infrastructure, in theory, be divided into the most restrictive scope 
>>> possible with walls between?

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

Re: [dmarc-ietf] Fwd: Break SPF response: DKIM Only



> On Mar 4, 2024, at 11:07 PM, Chuhan Wang  wrote:
> 
> 
> Hi Douglas,
> 
> Thank you for your insightful summary of our paper. I'd like to share some of 
> my opinions.
> 
> You mentioned clients lose control of their SPF integrity. It's one of the 
> key problems exactly. Clients host their email services on email providers. 
> They are required to include email providers' SPF records in their SPF 
> records. However, the centralization of SPF deployment magnifies SPF 
> vulnerabilities. Our results show that when the email provider is vulnerable, 
> a single vulnerable SPF record can influence more than 10,000 domains, which 
> actually violates the assumption of SPF that domains can be distinguished by 
> IP addresses.
> 
> The reliance on IP addresses for sender authentication, a model that might 
> have seemed reasonable 20 years ago, has now proven to be inadequate in 
> today's situation. The centralized deployment of SPF, driven by centralized 
> email services, has only exacerbated the vulnerabilities inherent in this 
> trust model. The cascading effects of a single vulnerable SPF record 
> affecting thousands of domains highlight the fragility of our current email 
> authentication chain.
> 
> It's also worth noting that a similar centralization phenomenon also exists 
> in the deployment of DKIM (e.g., shared DKIM keys), based on our previous 
> research published in the USENIX Security 2022. 
> https://www.usenix.org/conference/usenixsecurity22/presentation/wang-chuhan
> 
> Based on the current status of SPF deployment, maybe it's time for us to 
> shift the trust model and explore better approaches to address email 
> authentication issues.
> 
> Chuhan Wang
> Tsinghua University

Sir, I was wondering if you could provide a short, concise proposal to mitigate 
this problem? Perhaps how you might introduce a student to a new concept.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Don't trivialize psd=n

Is there any reason to lead with don’t worry about the tag but there is one 
critical use case. I think a more declarative statement in favor of the tag for 
those who will be stressed and skimming. Sure they might add a psd where it’s 
not needed but that’s better than not know the important part: the exception. 
So the strong statement should be the lead and the exception, btw, only really 
need it when… comes next. That would lead to some extraneous tags but less 
likely missing when it counts, rare.

> On Mar 10, 2024, at 12:14 PM, Douglas Foster 
>  wrote:
> 
> 
> Both of these statements seem unnecessarily weak, bordering on apologetic.
> 
> 5.3.General Record Format
> PSD ("n")
> ."... There is no need to put psd=n in a DMARC record, except in the very 
> unusual case of a parent PSD publishing a DMARC record without the requisite 
> psd=y tag."
> 
> 11.8 Determination of the Organizational Domain For Relaxed Alignment
> "For cases where strict alignment is not appropriate, this issue can be 
> mitigated by periodically checking the DMARC records, if any, of PSDs above 
> the organization's domains in the DNS tree and (for legacy [RFC7489] checking 
> that appropriate PSL entries remain present). If a PSD domain publishes a 
> DMARC record without the appropriate psd=y tag, organizational domain owners 
> can add psd=n to their organizational domain's DMARC record so that the PSD 
> record will not be incorrectly evaluated to be the organizational domain."
> 
> I suggest that the second sentence of 5.3 should read:
> "While the tree walk is designed to be upward-compatible with existing 
> policies that do not provide a psd tag, use of psd=n is RECOMMENDED as it 
> reduces evaluator processing effort, reduces load on the DNS, and increases 
> confidence in the evaluation results.  Use of psd=n is REQUIRED if a parent 
> domain has a DMARC policy without a psd tag."
> 
> Given the number of private registries that have embraced DMARC for PSDs 
> prior to publication of DMARCbis, it is difficult to even justify the 
> assumption that an unflagged PSD will be "very unusual"  
> Similarly, 11.8 could more usefully read:
> "For cases where strict alignment is not appropriate, this issue can be fully 
> mitigated by publishing a psd=n tag on the organizational domain."
> 
> Why would anyone "periodically check" for a problem, when the risk can be 
> completely eliminated in advance by taking a simple preventative measure?
> 
> 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] Fwd: The sad state of SPF: research just presented at NDSS

On Mar 12, 2024, at 9:05 AM, Dotzero  wrote: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 HammerI like the IPv6 idea in principle but would the MBP’s adjust as small businesses can’t operate optimally with a sender reputation that’s like the sound of one hand clapping.I think SPF isn’t the problem, it’s the overloading of includes, lax vendor security in many cases, often overloading the org domain with a few includes that are cringeworthy in their permissiveness. If there were incentives to solve this problem the ESPs would be on it. Unfortunately, security breaches tend to act as externalities not proving a direct incentive for ESP’s and others to make mitigating this issue a priority. That said, a smart sender can avoid spf problems with planning and situational awareness.I don’t blame the spf protocol I blame the pushing the envelope until threat actors started writing thank you notes.On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> 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 <wc...@mails.tsinghua.edu.cn> 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 WangTsinghua UniversityBegin forwarded message:From: Barry Leiba <barryle...@computer.org>Subject: [dmarc-ietf] The sad state of SPF: research just presented at NDSSDate: February 28, 2024 at 17:33:41 CSTTo: IETF DMARC WG <dmarc@ietf.org>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/B___
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

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 WangTsinghua UniversityBegin forwarded message:From: Barry Leiba Subject: [dmarc-ietf] The sad state of SPF: research just presented at NDSSDate: February 28, 2024 at 17:33:41 CSTTo: 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 listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags



> On Mar 1, 2024, at 5:39 PM, John R Levine  wrote:
> 
> On Fri, 1 Mar 2024, Seth Blank wrote:
>>> It seems OK but I would say that at this point that mailto: URI are the
>>> only ones currently defined.
>>> 
>> 
>> Participating, to this point. Throwing out an idea, that may be
>> spectacularly bad:
>> 
>> mailto: is the only function that's ever been used. We even discussed
>> exploring other mechanisms, and consensus was to drop that exploration. I
>> can't find the ticket quickly, but I know it was covered early on during
>> the bis work.
>> 
>> Do we just want to dramatically simplify this, and throw the "mailto:; into
>> the reporting ABNF and call it a day? It would dramatically streamline the
>> text.
> 
> That would be fine with me.  I proposed an http method similar to the one for 
> mta-sts and everyone said no need, mail is plenty fast.  I have mta-sts https 
> set up and indeed, basically nobody uses it.

Now. But do you think it has ponptential to catch on? 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-30.txt

Well done! This was a technical and quasi political journey and I felt I had 
front row seats.

Neil

> On Feb 28, 2024, at 3:05 PM, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-dmarc-dmarcbis-30.txt is now available. It is a 
> work
> item of the Domain-based Message Authentication, Reporting & Conformance
> (DMARC) WG of the IETF.
> 
>   Title:   Domain-based Message Authentication, Reporting, and Conformance 
> (DMARC)
>   Authors: Todd M. Herr
>John Levine
>   Name:draft-ietf-dmarc-dmarcbis-30.txt
>   Pages:   72
>   Dates:   2024-02-28
> 
> Abstract:
> 
>   This document describes the Domain-based Message Authentication,
>   Reporting, and Conformance (DMARC) protocol.
> 
>   DMARC permits the owner of an email author's domain name to enable
>   verification of the domain's use, to indicate the Domain Owner's or
>   Public Suffix Operator's message handling preference regarding failed
>   verification, and to request reports about the use of the domain
>   name.  Mail receiving organizations can use this information when
>   evaluating handling choices for incoming mail.
> 
>   This document obsoletes RFCs 7489 and 9091.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-30
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> 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] Inconsistencies in DMARC Aggregate Report XML Schema

I’d say extend your thinking on why beyond the format itself. What else could be the cause? On Mar 11, 2024, at 7:33 PM, Neil Anuskiewicz  wrote:Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU  wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and only refer to the [I-D.ietf-dmarc-aggregate-reporting] I've strayed a bit from DMARC, but occasionally I think about the aggregate reporting analysis problems a domain owner may encounter. In earlier emails, I mentioned using a JSON format for reports. Although the format change has been discussed in the past and the working group agreed not to switch to JSON, I'm not sure that providing a new XSD file will solve the problem of the multiple XSDs we already have.In my opinion, players who have already implemented the reporting system may not be inclined to update to the new format, and we'll then have 3 different definitions of XML.The question of JSON then arises, to start afresh on a sound footing. While this may require considerable effort in terms of RFC writing and code implementation, I think it will provide greater clarity and access for newcomers. As part of my research, I've written a paper on DMARC that will be published soon (mid-March). Even though DMARC adoption increases (4.5% in 2022 to 5.4% in 2023), the proportion of p=none handling policies also decreases (67.7% to 55.5%). One of my first hypotheses is that domain owners were using the reporting system to enhance their infrastructure and then adopted more restrictive policies.The figure below (Fig.7) illustrates the differences in reporting policies between the two years and that the adoption of more restrictive policies can be attributed tothe new DMARC domain names.However, the increase in the "restrictive" handling policy does not seem correlated with the use of the reporting system.I have compared the handling policies and content of RUA tags during the period (see graph below, Fig.8).To summarize my analysis: 54.7% of the domain name that had p=none and moved to p=reject, did not have rua tags ( 5) and 48.2% of all domain names displayed unexpected behavior: they removed the rua tag without adopting more restrictive policies or have adopted more strict policies without having rua tagsIn conclusion, I feel that there is something behind the difficulty of analyzing aggregate reports, and it is related to the current XML format...Nevertheless, this is only a feeling and not tangible proof (yet), so it doesn't constitute a reasonable technical argument to justify my remarks about a new JSON format.The current version of Dmarcbis does not leave room for a possible new aggregate report format in section 5.3.3. Shouldn't this section be less specific about the XML format, while still referring to [I-D.ietf-dmarc-aggregate-reporting], which could be updated in the future?If the working group is interested in the idea of a new (or alternative) JSON format, I can try my hand at writing a draft (if I'm accompanied by an IETF's experience writer).Regards,Olivier Hureau--PS: I can send interested readers a pre-printed version of my work.___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU  wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and only refer to the [I-D.ietf-dmarc-aggregate-reporting] I've strayed a bit from DMARC, but occasionally I think about the aggregate reporting analysis problems a domain owner may encounter. In earlier emails, I mentioned using a JSON format for reports. Although the format change has been discussed in the past and the working group agreed not to switch to JSON, I'm not sure that providing a new XSD file will solve the problem of the multiple XSDs we already have.In my opinion, players who have already implemented the reporting system may not be inclined to update to the new format, and we'll then have 3 different definitions of XML.The question of JSON then arises, to start afresh on a sound footing. While this may require considerable effort in terms of RFC writing and code implementation, I think it will provide greater clarity and access for newcomers. As part of my research, I've written a paper on DMARC that will be published soon (mid-March). Even though DMARC adoption increases (4.5% in 2022 to 5.4% in 2023), the proportion of p=none handling policies also decreases (67.7% to 55.5%). One of my first hypotheses is that domain owners were using the reporting system to enhance their infrastructure and then adopted more restrictive policies.The figure below (Fig.7) illustrates the differences in reporting policies between the two years and that the adoption of more restrictive policies can be attributed tothe new DMARC domain names.However, the increase in the "restrictive" handling policy does not seem correlated with the use of the reporting system.I have compared the handling policies and content of RUA tags during the period (see graph below, Fig.8).To summarize my analysis: 54.7% of the domain name that had p=none and moved to p=reject, did not have rua tags ( 5) and 48.2% of all domain names displayed unexpected behavior: they removed the rua tag without adopting more restrictive policies or have adopted more strict policies without having rua tagsIn conclusion, I feel that there is something behind the difficulty of analyzing aggregate reports, and it is related to the current XML format...Nevertheless, this is only a feeling and not tangible proof (yet), so it doesn't constitute a reasonable technical argument to justify my remarks about a new JSON format.The current version of Dmarcbis does not leave room for a possible new aggregate report format in section 5.3.3. Shouldn't this section be less specific about the XML format, while still referring to [I-D.ietf-dmarc-aggregate-reporting], which could be updated in the future?If the working group is interested in the idea of a new (or alternative) JSON format, I can try my hand at writing a draft (if I'm accompanied by an IETF's experience writer).Regards,Olivier Hureau--PS: I can send interested readers a pre-printed version of my work.___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 4.1 DMARC Basics



> On Mar 3, 2024, at 1:41 AM, ves...@tana.it wrote:
> 
> Hi,
> 
> the last two paragraphs of section 4.1 also show a neat asymmetry between rua 
> and ruf.  The first sounds like the notification that feedback exists rather 
> than something a mail receiver should do.  The second is good, but not 
> normative.
> 
> 
> OLD
>   DMARC's feedback component involves the collection of information
>   about received messages claiming to be from the Author Domain for
>   periodic aggregate reports to the Domain Owner or PSO.  The
>   parameters and format for such reports are discussed in
>   [I-D.ietf-dmarc-aggregate-reporting]
> 
>   A DMARC-enabled Mail Receiver might also generate per-message reports
>   that contain information related to individual messages that fail
>   authentication checks.  Per-message failure reports are a useful
>   source of information when debugging deployments (if messages can be
>   determined to be legitimate even though failing authentication) or in
>   analyzing attacks.  The capability for such services is enabled by
>   DMARC but defined in other referenced material such as [RFC6591] and
>   [I-D.ietf-dmarc-failure-reporting]
> 
> 
> NEW
>   A DMARC-enabled Mail Receiver SHOULD collect authentication results
>   and generate aggregate reports that contain information about
>   received messages claiming to be from the Author Domain for periodic
>   aggregate reports to the Domain Owner or PSO.  The parameters and
>   format for such reports are discussed in
>   [I-D.ietf-dmarc-aggregate-reporting]
> 
>   A DMARC-enabled Mail Receiver MAY also generate per-message reports
>   that contain information related to individual messages that fail
>   authentication checks.  Per-message failure reports are a useful
>   source of information when debugging deployments (if messages can be
>   determined to be legitimate even though failing authentication) or in
>   analyzing attacks.  The capability for such services is enabled by
>   DMARC but defined in other referenced material such as [RFC6591] and
>   [I-D.ietf-dmarc-failure-reporting]
> 
> How's that?
> 
> Best
> Ale
> 
Perfect. It makes it clear what’s critical, aggregate reports, and that you may 
provide at your own volition, leaving room for PII policies and the like.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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



> On Feb 29, 2024, at 10:55 AM, Todd Herr 
>  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?
> 
Yes! Assuming general purpose is precisely, clearly defined we have a winner.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

Please remove the pct tag from the spec.

> On Mar 9, 2024, at 7:05 AM, Alessandro Vesely  wrote:
> 
> Hi,
> 
> as ADSP is historical, perhaps we can strike A5 entirely.  If not, we should 
> at least eliminate bullet 5:
> 
>   5.  ADSP has no support for a slow rollout, i.e., no way to configure
>   a percentage of email on which the Mail Receiver should apply the
>   policy.  This is important for large-volume senders.
> 
> (Alternatively, we could think back about pct=...?)
> 
> Best
> Ale
> --
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] picking nits with the ABNF



> On Mar 9, 2024, at 7:33 PM, OLIVIER HUREAU 
>  wrote:
> 
> 
> >> dmarc-version = "v" equals %s"DMARC1
> > I believe the "%s" should be dropped
> 
> 'DMARC1' is case-sensitive in 7489.
> Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41 %x52 
> %x43 %x31"
> 
> > I think it should be %x20-3A /  %x3C-7E
> Agreed.
> 
> I would also add comment about the dmarc-fo ABNF : 
> 
> dmarc-fo  = "0" / "1" / "d" / "s" / "d:s" / "s:d"
> 
> The FO paragraph 
> (https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format)
>  explicitly states that there exist 3 kinds of failure reports :
> - DMARC failure report.
> - DKIM failure report.
> - SPF failure report.
> 
> However, with the current ABNF, we could only ask for "DMARC failure report" 
> or ("DKIM failure report" and/or "SPF failure report")
> 
> Shouldn't we have an ANBF rule with all the possible permutations or a more 
> generic one such as :
> 
> dmarc-fo = dmarc-fo-value *(":" dmarc-fo-value)
> dmarc-fo-value = "0" / "1" / "d" / "s"
> 
> 
> Olivier
> 
> De: "Tim Wicinski" 
> À: "IETF DMARC WG" 
> Envoyé: Dimanche 10 Mars 2024 01:00:33
> Objet: [dmarc-ietf] picking nits with the ABNF
> 
> Just picking over the ABNF with my checks, some Qs
> 
> 
> dmarc-version = "v" equals %s"DMARC1
> 
> I believe the "%s" should be dropped
> 
>   dmarc-value   = %x20-3A |  %x3C-7E
> 
> I think it should be %x20-3A /  %x3C-7E
> 
> and now just something suggested.  The comments for URI read like this
> 
> ; "URI" is imported from [RFC3986]; commas
> ; (ASCII 0x2C) and exclamation points
> ; (ASCII 0x21) MUST be encoded
> 
> Could they be rewritten for readability
> 
> ; "URI" is imported from [RFC3986];  
> ; (ASCII 0x2C) commas and  
> ; (ASCII 0x21) exclamation points
> ; MUST be encoded
> 
> gladly tell me i'm too obsessive
> 
> 
> 
Yes, since most people are used to the FO tag but would happily embrace this 
upgrade.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis rev 29

2023-12-13 Thread Neil Anuskiewicz

Well done! I feel that rough consensus must be close.

> On Dec 2, 2023, at 5:10 AM, Alessandro Vesely  wrote:
> 
> On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote:
>> There are only four open items on the issue tracker - though I think the SPF 
>> question 
>> (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/116) was 
>> resolved. But is that really all there is to do?
> 
> 
> I'd hope most of the other questions are solved as well.  Aren't they?
> 
> *auth* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/118
> This was rehashed in the end of October, when Scott explained how the correct 
> way to fix SPF is appropriate usage of qualifiers.  There seemed to be 
> agreement that such clarification deserves its own paragraph in DMARCbis, but 
> it never made it to rev 29.
> 
> *reject* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/115
> This was discussed ad nauseam.  My understanding is that participants 
> convinced that MUST NOT is right finally consented to accept Barry's text.
> 
> *define* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96
> To say when people can hold they implement or enforce DMARC.  Seth proposed 
> some text in the beginning of April.  Don't recall the conclusion.  Do we 
> need to add text for this?
> 
> 
> We should review *aggregate reporting*.  For one point, we should add XML 
> documents to the normative references:
> 
> Extensible Markup Language (XML) 1.0 (Fifth Edition)
> https://www.w3.org/TR/xml/
> 
> W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
> https://www.w3.org/TR/xmlschema11-1/
> 
> W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
> https://www.w3.org/TR/xmlschema11-2/
> 
> There are a few other points which deserve a review, summarized in a thread 
> started by Olivier about mid November.  Should I create a new ticket for that?
> 
> 
> Best
> Ale
> --
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Dmarcbis way forward

2023-11-16 Thread Neil Anuskiewicz



> On Nov 12, 2023, at 4:00 AM, Alessandro Vesely  wrote:
> 
> On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:
>>>> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely  wrote:
>>> My opinion is that Barry's text is good as is.  As far as delimiting a 
>>> SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me:
>>>It is therefore critical that domains that host users who might
>>>post messages to mailing lists SHOULD NOT publish p=reject. Domains
>>>that choose to publish p=reject SHOULD implement policies that
>>>their users not post to Internet mailing lists.
>>> The exceptions to the latter SHOULD are rather obvious.  Do we really need 
>>> to formally specify domain policing?
>>> My perception is that Section 8.6 puts the issue in very clear terms.  It 
>>> is even overly clearly and thoroughly explained for average readers.  Only 
>>> IETF purists longing for email as it was in the 80s consider it important 
>>> to point out how DMARC is unjustly oppressing email forwarding, including 
>>> mailing lists.  The rest of the world just use it as needed.
>> What happened to the general purpose domain, actually subdomain, which I 
>> understood to be a non enforcing subdomain just for distribution lists. That 
>> idea was far from perfect but it seemed good. To clarify were you obliquely 
>> supporting the general purpose domain idea?
>> I can think of alternatives but those alternatives clearly affect 
>> interoperability. Since. Discussion some weeks ago I learned here that we 
>> must consider interoperability at every step, which makes sense morally and 
>> practically in the face of a real interoperability issue.
>> Yeah, I lurk enough to have drunk the koolaid. That said, are there list 
>> operators who participate and cogently make their case on why there’s no 
>> viable mitigating changes they could make? It’s plausible that the answer is 
>> no but it’s not 100% clear that this is a problem that can’t be solved. It’s 
>> pretty clear there aren’t good solutions on less bad ones.
>> If this issue is already decided on and I’m beating a dead horse, I 
>> apologize. If I’m going to lurk it’s got to be every day for at least a few 
>> minutes to avoid dead horse beating that I’m sure is annoying.
> 
> 
> A taxonomy of possible mitigations was published in 2014:
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
> 
> That page distinguishes among sending side workarounds and other approaches. 
> The former can be implemented unilaterally without further discussions. 
> Discussions take decades, as we see.  It seems that mailing lists, and 
> forwarding in general constitute a minor problem for the vast majority of 
> mailbox providers.  The urgency for a better solution is only perceived by 
> mailing list users, an area where ietfers are especially active but the rest 
> of the world, on average, is not.
> 
> There are cooperative solutions, but they won't be implemented until 
> forwarding becomes a noticeable problem for large operators.

Sir, that these mitigations can be implemented without discussion, then doesn't 
that make the problem needing mitigation outside the scope of this working 
group? The difference between no discussion and a working group is like the 
ocean and a bucket of water. Don't let anything that isn't a flat out blocker 
get in the way. Encourage use of the bucket but you can lead an admin to water.

Neil
> -- 
> 
> 
> 
> 
> 

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

Re: [dmarc-ietf] Dmarcbis way forward



> On Nov 11, 2023, at 7:24 PM, Steven M Jones  wrote:
> 
> On 11/12/23 03:59, Neil Anuskiewicz wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100 
>> people voted yes and 3 voted no, the three win? Id there’s a document that 
>> states these rules I’d be happy to dig into it. If there’s a rule we should 
>> have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
>> understandable if I’m not entitled to a vote. That said, what do the rules 
>> say?
> 
> 
> Scott gave the chapter-and-verse reference:
> 
>> https://datatracker.ietf.org/doc/html/rfc7282
> 
> The problem we typically have is with the level of participation. 
> Specifically, not having enough people actively participating. (I am guilty 
> of being a "variable" participant myself.)
> 
> As I described the situation to a group last week, consensus is a very 
> different animal when you have your 100 participants, versus 6 or 8 regular 
> participants. The lower the number, the more space each question/objection 
> takes up.
> 
> That's just group dynamics; on top of that, you have questions like whether 
> the X or Y participants you have adequately represent the "Internet 
> community," or even the "IETF community," as Murray raised in San Francisco.

I volunteer to participate when I’m ready in terms of knowledge and I’ll strive 
to develop my participation savvy. Lol. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

> On Nov 11, 2023, at 7:11 PM, Steven M Jones  wrote:
> 
> 
>> On 11/12/23 04:56, Dotzero wrote:
>> 
>> 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.
> 
> +1 on the original intent - we were on the cusp of having a network of paid 
> services and bi-lateral information sharing agreements, but instead the group 
> decided an open system anybody could participate in would be better. Not that 
> it would be effortless to participate and benefit, it obviously takes a lot 
> of work, but it would be possible if one put in the effort and resources.
> 
> +1 on the general decline due to a changing PII landscape.
> 
> There are still some sources sending failure reports, but they tend to be 
> smaller operators.
> 
> And even in a world of "private failure reports," having the format 
> standardized is a useful thing.
> 
> --Steve.
> 

I have a feeling the die is cast for failure reports from MBPs. I’m curious to 
learn if they sent legit failures, which has scared off the major MBPs except 
for Yahoo.  So if others were using a third party, it’d be sort of interesting 
to know what they sent and how it assuaged those worried about the PII.

Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering them 
worthless as nobody you’ve heard of will send them. This issue isn’t a five 
alarm fire. I figure maybe adjust this next WG. I think the train has left the 
station and there’s no brake to pull.

Thanks.

Neil

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

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




> On Nov 11, 2023, at 11:56 AM, Dotzero  
> 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 

Mike, thank you for explaining that. It makes total sense now. And, on the face 
of it, it does sound like a good idea. Did this third party sanitize the data 
or send straight up failure reports?

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

Re: [dmarc-ietf] Dmarcbis way forward



> On Nov 11, 2023, at 11:06 AM, Scott Kitterman  wrote:
> 
> The short answer is it depends.  We don't vote.
> 
> Here's the longer answer:
> 
> https://datatracker.ietf.org/doc/html/rfc7282
> 
> Scott K
> 
>> On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz  
>> wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100 
>> people voted yes and 3 voted no, the three win? Id there’s a document that 
>> states these rules I’d be happy to dig into it. If there’s a rule we should 
>> have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
>> understandable if I’m not entitled to a vote. That said, what do the rules 
>> say? 
>> 
>>>> On Oct 23, 2023, at 9:07 PM, Scott Kitterman  wrote:
>>> 
>>> On Monday, October 23, 2023 4:03:36 AM EDT 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.

>>>> If I’m not mistaken Francesca has outlined an opening for a deal. 
>>>> According to the rules document, making everyone 100% happy isn’t the 
>>>> priority. If agreement can be reached that’s satisfactory to most, if not 
>>>> all parties, could get us to rough consensus.  This seems like evidence 
>>>> that the parties aren’t taking immutable stands, leaving an opening for an 
>>>> agreement. Well done, Francesca, your astute summary might possibly get us 
>>>> over the finish line avoiding a protracted stalemate.

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

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

On Nov 11, 2023, at 1:21 PM, Dotzero  wrote:On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz <n...@marmot-tech.com> 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.NeilThese reports are a type of FBL (feedback loop).
Yes sir. It’s all clear to me now.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

On Nov 11, 2023, at 11:56 AM, Dotzero  wrote:On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz <n...@marmot-tech.com> 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, 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___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

What is the definition of rough consensus. That is if you took a vote, 100 
people voted yes and 3 voted no, the three win? Id there’s a document that 
states these rules I’d be happy to dig into it. If there’s a rule we should 
have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
understandable if I’m not entitled to a vote. That said, what do the rules say? 

> On Oct 23, 2023, at 9:07 PM, Scott Kitterman  wrote:
> 
> On Monday, October 23, 2023 4:03:36 AM EDT 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/
> 
> I don't think this is consistent with the IETF's mandate to provide documents 
> which promote interoperability.  I do not, however, plan to file an appeal 
> about it.
> 
> 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] DMARC policy discovery and invalid tag exception.


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

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

On Oct 25, 2023, at 3:57 AM, Olivier Hureau 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.

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward



> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely  wrote:
> 
> My opinion is that Barry's text is good as is.  As far as delimiting a 
> SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me:
> 
> It is therefore critical that domains that host users who might
> post messages to mailing lists SHOULD NOT publish p=reject. Domains
> that choose to publish p=reject SHOULD implement policies that
> their users not post to Internet mailing lists.
> 
> The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
> formally specify domain policing?
> 
> My perception is that Section 8.6 puts the issue in very clear terms.  It is 
> even overly clearly and thoroughly explained for average readers.  Only IETF 
> purists longing for email as it was in the 80s consider it important to point 
> out how DMARC is unjustly oppressing email forwarding, including mailing 
> lists.  The rest of the world just use it as needed.

What happened to the general purpose domain, actually subdomain, which I 
understood to be a non enforcing subdomain just for distribution lists. That 
idea was far from perfect but it seemed good. To clarify were you obliquely 
supporting the general purpose domain idea? 

I can think of alternatives but those alternatives clearly affect 
interoperability. Since. Discussion some weeks ago I learned here that we must 
consider interoperability at every step, which makes sense morally and 
practically in the face of a real interoperability issue. 

Yeah, I lurk enough to have drunk the koolaid. That said, are there list 
operators who participate and cogently make their case on why there’s no viable 
mitigating changes they could make? It’s plausible that the answer is no but 
it’s not 100% clear that this is a problem that can’t be solved. It’s pretty 
clear there aren’t good solutions on less bad ones.  

If this issue is already decided on and I’m beating a dead horse, I apologize. 
If I’m going to lurk it’s got to be every day for at least a few minutes to 
avoid dead horse beating that I’m sure is annoying.

Neil
> 
> 
>> On Mon 23/Oct/2023 10:03:36 +0200 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, t

Re: [dmarc-ietf] Codifying "Apex Domain"?

On Nov 9, 2023, at 6:40 AM, Todd Herr  wrote:Colleagues,I note that lately in various email fora that the term "apex domain" has found some favor, said term being used interchangeably with "organizational domain", and having the same contextual meaning as "organizational domain".DMARCbis does not contain the word "apex", nor did RFC 7489 before it.My question here is, should DMARCbis at least mention the term "apex domain", perhaps in section 3.2.9, Organizational Domain. The entirety of that section currently reads:The Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8.Does it make sense to change that toThe Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8. The Organizational Domain is also sometimes referred to as the Apex Domain.When I first started looking at email, I found it less than useful to have multiple names for the envelope from. I saw we call it the org domain and let the chips fall where they may. If you don’t know what an org domain is I’d say it’s time to do some reading or ask a colleague. For example, I’d love it if the envelope from was just that. Define it briefly in the document itsperhaps in the footnotes. Then you can mention it’s call reefer, pot, dope, ganja and chronic but recommend envelope from as the common name. ___
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



> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely  wrote:
> 
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
> 
> 
> You're the only one strongly opposing the idea, AFAICS, and I still don't 
> know why.
> 
> 
>> Let's either focus and finish or give up and close the group.
> 
> 
> Even if we don't add the feature, we should address the vulnerability. 
> Currently there is only a bullet in Section 4.8, Organizational Domain 
> Discovery, saying:
> 
>* The domain found in the RFC5321.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
> 
> We need to add a subsection in Security Consideration, discussing an example 
> of an include mechanism with a neutral qualifier and its effect on DMARC 
> outcome; that is, how that avoids spurious authentications.
> 
> The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
> Specific to SPF.  We could add a reference to the added subsection there.
> 
If explicit language gets us a good portion of the way there. That is forward 
progress for those who support this. Alexandra there must be others not willing 
to go that direction and digging in wil just mean this same conversation 6 
months ago. To keep it neutral the hums should prevail now and those who lost 
this one, remember the battle may be winding down but you have time to provide 
tangible evidence this was a brain dead decision. I’m guess WG members are 
smart and experience quite a bit of neurogenesis (I.e., don’t hold to an idea 
for ego certitude). Even if those who don’t hum hate it, take solace that time 
will show you right if you are right and I doubt anyone humming will hum that 
dissonant song of wrong again. 

If the no hummers are right I hope they humbly re litigate this and change a 
bad policy. Let’s test drive this baby and see if it breaks down out in the 
boonies.
> 
> 
> 
> 
> ___
> 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 session at IETF 118

For routine, remote is perfect but I’d imagine hums leave no doubt in Prague and a chance for rapport to be established. As an observer this proces made me tense and annoyed at time. Myn2 cents is go to Prague. It’s a gorgeous city. This group has a gruff vibe in the tradition of Usenet but our tribe tends to forget and forgive setting the stage for you to work more smoothly together. It’s like when the godfather called in the 5 families.On Nov 1, 2023, at 3:21 PM, Barry Leiba  wrote:The sense I’m getting is to cancel the session in Prague.  I’ll do that tomorrow (Thursday) morning SFO time unless someone screams loudly with a convincing reason that we need to keep the session.BarryOn Sat, Oct 28, 2023 at 10:38 AM 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

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

On Oct 29, 2023, at 7:57 AM, Dotzero  wrote: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.

BarryLet the discussion continue on the list. Personally I think there has been enough discussion that there can be a call for consensus.Barry, you think there’s rough consensus now? If so then by all means count asap and get closure. Even those who disagree respect the process and will keep their party dry to fight another day. I don’t know exactly what rough consensus is no I know it when I see it, to paraphrase Brandeis. And we all know what it looks like. Accepting defeat even when we think we are fire right is part of what makes this country great. We concede. That’s honor.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] (no subject)

> On Nov 8, 2023, at 8:46 AM, John R. Levine  wrote:
> 
> On Mon, 6 Nov 2023, Douglas Foster wrote:
>> Since IETF cannot protect its own lists from conspicuous impersonation, it
>> seems poorly qualified to tell anyone else how to do so.
> 
> Actually, that message had nothing whatsoever to do with impersonation, and 
> everything to do with an obscure configuration error in my mail system.
> 
> Leaping to conclusions is rarely helpful.
> 
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

I’m not consistent lurking but I get the feeling there’s one more large issue 
that’s a big blocker. The only is a talk at least on zoom not email, where both 
gentlemen do the honor of earnestly steal maning the other argument then from 
there refute the best case not the straw man version that’s human nature. 
Everyone else listen with an open mind and get to rough consensus. The steal 
man method should settle this. It’s easier than dialing.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2023-10-20 Thread Neil Anuskiewicz



> On Oct 20, 2023, at 8:43 AM, Alessandro Vesely  wrote:
> 
> On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU 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 )
> 
> 
> I think it means:
>if ( retrieved policy record does not contain a valid "p" tag' ||
> (the applicable policy would be that of an "sp" or "np" tag &&
>  such tag exists but is not valid)
>   ) then:
> 
>   if a rua exists use it
>   otherwise forget that record.
> 
> The tricky point is that, although sp= or np= default to p= if they are 
> missing, if they are present but not valid a valid p doesn't help.
> 
> 
>> '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.
> 
> 
> That's the case if From: referred to a subdomain.  In that case sp= would be 
> applicable, but it is not valid, so treat is as if it had sp=none.  p= 
> doesn't play.  Would have played if sp= was missing.
> 
That’s my interpretation, too, but Olivier has a point that the wording isn’t 
as clear as it could be.

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

Re: [dmarc-ietf] Why Relaxed Alignment?

2023-10-18 Thread Neil Anuskiewicz

On Oct 18, 2023, at 7:24 AM, Todd Herr  wrote:On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster  wrote:Why do we need to support relaxed alignment at all?A common use case for relaxed alignment is when an organization (e.g., WeSellStuff) employs a third party Email Service Provider (e.g., WeSendEmail) to send mail on the organization's behalf. In that case, we might have the following:Return-Path domain: bounces.wesellstuff.comDKIM signing domain: wesendemail.wesellstuff.comRFC5322.From domain: marketing.wesellstuff.comThe above configuration allows for WeSendEmail to manage the SPF record for bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to be pointed at WeSendEmail, so that they can handle bounce processing and other Delivery Status Notifications.It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using a dedicated subdomain that is delegated to WeSendEmail, which can publish the public key in DNS and generate the private key and keep it private to use for signing mail it sends. Meanwhile, WeSellStuff only has to delegate responsibility for those parts of the DNS that are specific to WeSendEmail's sending to WeSendEmail.Yes, strict alignment would be *very* disruptive to a LOT of senders.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DBOUND

On Oct 16, 2023, at 6:48 PM, Neil Anuskiewicz  wrote:
> 
> 
>> On Oct 16, 2023, at 6:43 PM, Seth Blank  
>> wrote:
>> 
>> I'm sorry, to what are you referring? I co-chair the M3AAWG technical 
>> committee, and am unaware of any advocacy for relitigating DBOUND...

Seth, I based my statement on wording in a couple documents and I heard it from 
other sources but I think I’m just flat out wrong w3aawg is supporting DBOUND. 
I did not mean it as a pejorative, it was more interest in why they might be 
supporting it. I don’t anything about DBOUND. It looked like the project was a 
an active project, so I was curious about it and why M3AAWG might have taken an 
interest. But jumping from that to support was too big a leap.

My goal for being on this list is to learn and that’s been great. So the next 
thing would be how to use what I learn to be helpful. It’s challenging to 
figure out how to be helpful to the WG so I’ve been thinking of other ways such 
as other content to help others understand. 

The reference to DBOUND was sparked by looking around at what w3aawg was saying 
as I generally think they have some good papers and a great video series on 
email authentication. But what I found on DBOUND isn’t endorsement. They framed 
DBOUND in a positive light and encouraged people to look into the project but 
that doesn’t mean the organization endorses it. 

The last thing I wanted to do is offend anyone here. I’d like to continue to 
learn and possibly contribute to the larger DMARCbis effort. So again, I 
apologize.

Neil

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

Re: [dmarc-ietf] DBOUND

See section VOn Oct 16, 2023, at 6:43 PM, Seth Blank  wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND?

Perhaps once we prove that DMARCbis works they’ll reconsider.

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
-- Seth Blank  | Chief Technology Officere: s...@valimail.comp:  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

Re: [dmarc-ietf] DBOUND

On Oct 16, 2023, at 6:43 PM, Seth Blank  wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND?

Perhaps once we prove that DMARCbis works they’ll reconsider.

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

In this document on the site, toward the bottom they encourage support for it. I found the same thing in another similar document. https://www.m3aawg.org/sites/default/files/m3aawg_present_and_future_of_the_public_suffix_list.docx_.pdfNo offense intended, sir. I apologize if I’m wrong. It does appear they are supporting it by the wording.Neil___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DBOUND

M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a 
viable alternative? We could sure use the support of M3AAWG. How could we earn 
their support or are they committed to DBOUND?

Perhaps once we prove that DMARCbis works they’ll reconsider.

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

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



> On Oct 16, 2023, at 4:53 PM, Dotzero  wrote

> 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

That makes sense. So I could write on the topic, videos, etc., on my own 
speaking for nobody other than myself and that wouldn’t step on toes it sounds 
like. I just wanted to make sure as I’m considering creating some content meant 
to help. I could create content for technical audiences who might have basic 
knowledge of email authentication and, because of their role, they want a 
primer on what’s coming down the pike.

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

[dmarc-ietf] Getting the word out and educating

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



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

Re: [dmarc-ietf] Tree Walk impact



> On Oct 16, 2023, at 11:00 AM, Scott Kitterman  wrote:
> 
> 
> 
>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely  wrote:
>>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
>>> Thank you, sir. That’s part of the reason to cautiously transition away 
>>> from the PSL. It has the feel of a throwback to a time when people thought 
>>> the number of total users would be in the hundreds or thousands. Wouldn’t a 
>>> cautious transition alleviate your concerns? Not everyone, everywhere will 
>>> pull the switch at midnight.
>> 
>> 
>> Can we engage ICANN for sending a kind request to upgrade their DMARC 
>> records to all PSDs?  Or can we do it on their behalf?  Or on IETF behalf?  
>> Or?
>> 
>> Is that a subject for 118?
> 
> Which ICANN managed TLDs have DMARC records (PSDs which are either not TLDs 
> or not ICANN managed TLDs are not anything ICANN has anything to say about)?
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

Are TLD’s typically responsive to these sorts of requests? Do they each have to 
be sold on the idea?

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

Re: [dmarc-ietf] Tree Walk impact

2023-10-13 Thread Neil Anuskiewicz

If I read that right it gives you what you think is a desirable outcome. That is, this might be a strong sign that you’re at least considering supporting DMARCbis!Yes, we all need to be prepared for headaches no matter which direction this all goes.On Oct 13, 2023, at 3:59 AM, Douglas Foster  wrote:The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.DougOn Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely <ves...@tana.it> wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely <ves...@tana.it> wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
>>>> Both approaches have problems.   Stop-at-last enables the walk to exit the current organization and stop on a private registry, for both alignment evaluation and for aggregate report transmission.   This is not a minor problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would save a lookup.  However, it is not something that we can recommend, after we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must behave /as if/ they followed the letter of the spec, but don't have to actually do so.

Would it be possible to test these scenarios with a working prototype or some other way to provide proof. Due to other obligations I haven’t been able to lurk here much but upon coming back I think the tree walk issues touched on today are possibly the only things standing in the way of dmarcbis. Though I saw there’s a nascent save our PSL movement that I read about. I’m not sure how serious or influential this movement is and why they’d feel so strongly that they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems will be addressed, there’s going to be stress, but ultimately another hack such as the hosts file for DNS will become largely irrelevant in the big picture, taking the Internet another step out of childhood toward adulthood. That’s a good thing even if some things go wrong along the way that need to be fixed or mitigated. The Internet is a place where the perfect is often more blatantly the enemy of the good.

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

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

2023-10-13 Thread Neil Anuskiewicz

Thank you, sir. That’s part of the reason to cautiously transition away from the PSL. It has the feel of a throwback to a time when people thought the number of total users would be in the hundreds or thousands. Wouldn’t a cautious transition alleviate your concerns? Not everyone, everywhere will pull the switch at midnight.On Oct 13, 2023, at 6:50 AM, Douglas Foster  wrote:Neil, the list is attached. .I used "Z" in the PSD and NP columns to indicate "not specified".   For the other columns, defaults have been inserted.Since everybody has their own copy of the PSL, others may find minor variants of this data.Doug FosterOn Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:

> On Oct 13, 2023, at 3:59 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of us could make calls to talk to a representative sample. We’d then greatly improve our knowledge of both the concerns and wants of this set of domain operators. Then you’d be in a better position to understand what they want and that, of course, can’t help but influence your decisions. The low numbers at this stage make getting the basic data much easier. 

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

Re: [dmarc-ietf] Tree Walk impact

2023-10-13 Thread Neil Anuskiewicz

> On Oct 13, 2023, at 3:59 AM, Douglas Foster 
>  wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL 
> domains   About 400 of them have DMARC policies.  A super-majority specify 
> relaxed authentication without specifying a NP policy.   This indicates that 
> the policy was created before the PSD for DMARC spec.   I conclude that these 
> domains want to be treated as organizations, not PSOs, and tbe stop-last Tree 
> Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of 
us could make calls to talk to a representative sample. We’d then greatly 
improve our knowledge of both the concerns and wants of this set of domain 
operators. Then you’d be in a better position to understand what they want and 
that, of course, can’t help but influence your decisions. The low numbers at 
this stage make getting the basic data much easier. 

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

Re: [dmarc-ietf] Tree Walk impact

2023-10-12 Thread Neil Anuskiewicz

I’d say it’s best practice to have a separate policy subdomains. We should encourage it.foo.example.com’s spoofed by one vendor most likely, so switching vendors isn’t too big a task. No need to roll example.com back to none. Just role foo back. It’s clearly a better way to go. Set things up so when you make changes, you open up a tiny security hole for as short a time as possible. So if dmarcbis exncourages subdomain dmarc policies then let’s encourage that with clear words and clear policies.On Oct 7, 2023, at 11:44 AM, Douglas Foster  wrote:No, this is not a false positive.  The PSL put all of the identifiers in a 2LD organization, which I reviewed and judged to be correct.The problem happens when Mail From u...@bounce.example.com authenticates u...@example.com and both domains have DMARC policies.  Removing the lower policy is the only remedy.   For SPF, this pattern of child-authenticates-parent is quite common.  Hsving multipke DMARC policies is less common. Again, what previous data was presented to justify the consensus that we would see no probems? DougOn Sat, Oct 7, 2023, 1:26 PM Richard Clayton  wrote:-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message 
hgv...@mail.gmail.com>, Douglas Foster 
com> writes

>    So initially, I am asking for a compsrison between my results and 
>    the data used to justify the asserted consensus.

if you published the data (just the right hand side of relevant
addresses is needed) we could check your working ...

>    Was 2% previuosly observed and judged acceptable?  Were the 
>    previous error rates judged acceptable because they were computed 
>    using a different denominator definition?

clearly if you get 10 messages from odd-domain and 10 messages from
Google then you will see a different percentage than someone who gets 3
(or some days 0) messages from odd-domain and 100 from Google ...
but provided odd-domain isn't just sending to you then any large mailbox
provider should have seen enough mail to provide a sensible measure of
the impact by counting domains not %age of overall mail.

>    With our present design, the necessary response to these errors is 
>    for the domain owner to remove intermediate DMARC policies.

that's strange ... isn't the intent of the new scheme to encourage
subdomain owners to add them !

I do wonder if this is the PSL raising its ugly head again. A remarkable
number of the people who have added entries have not understood how they
now need to publish rather more DNS records than previously ...

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZSGUTN2nQQHFxEViEQKHpQCeP4SAEJFQbCG74hSpmKPugIWLWs0An2e5
DMtrmcDBziCPFM9PVB0Vx6dI
=aCqk
-END PGP SIGNATURE-

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

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

2023-10-12 Thread Neil Anuskiewicz

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
>>>> Both approaches have problems.   Stop-at-last enables the walk to exit the 
>>>> current organization and stop on a private registry, for both alignment 
>>>> evaluation and for aggregate report transmission.   This is not a minor 
>>>> problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would 
>>> save a lookup.  However, it is not something that we can recommend, after 
>>> we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must 
> behave /as if/ they followed the letter of the spec, but don't have to 
> actually do so.

Would it be possible to test these scenarios with a working prototype or some 
other way to provide proof. Due to other obligations I haven’t been able to 
lurk here much but upon coming back I think the tree walk issues touched on 
today are possibly the only things standing in the way of dmarcbis. Though I 
saw there’s a nascent save our PSL movement that I read about. I’m not sure how 
serious or influential this movement is and why they’d feel so strongly that 
they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems 
will be addressed, there’s going to be stress, but ultimately another hack such 
as the hosts file for DNS will become largely irrelevant in the big picture, 
taking the Internet another step out of childhood toward adulthood. That’s a 
good thing even if some things go wrong along the way that need to be fixed or 
mitigated. The Internet is a place where the perfect is often more blatantly 
the enemy of the good.

Neil
___
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?

2023-08-05 Thread Neil

From: Dave Crocker 
Date: Saturday, August 5, 2023 at 9:49 AM
To: Jesse Thompson , Neil 
Cc: Todd Herr , IETF DMARC WG 
Subject: Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

> The language used for DMARC has always been problematic. "Policy"
> implies control, but the domain owner has no control over the receiving
> platform.  Quarantine and Reject declare control that also does not exist.
Suppose you set a policy of p=reject that’s still your policy even if receivers 
aren’t obligated to honor your policy. But it’s a policy nonetheless. It’s not 
required that a policy be followed for it to be policy. That aside, there’s 
unlikely to be another word that works better than’s worth any confusion or 
disruption that could be caused by changing the jargon.

Also, we understand who our audiences are in reality. Sometimes it’ll be a 
harried admin skimming the RFC, and others will take the time to do a deep 
dive. Even the harried admin scanning today might want to dive deep when he has 
more time. So out of respect for those who want to get things done and solve 
problems quickly and those who wish to grok the new DMARC spec, I think the 
optimal solution would be to follow E.B. White, making every word count, having 
empathy for the reader, and avoiding distractions that could bog the stressed 
reader down.

Then there would be well-organized appendixes that satisfy the reader in a 
lower stress state who wants to spend some time to grok.
So I get straight to the point, postpone in-depth exploration a few pages, 
putting enough material in well-organized appendices to satisfy the desire of 
many technical people who don’t feel comfortable until they grok something. 
That can be me on the same day easily.
Thanks.
Neil

> Governance seems like the best word to me, since Governance is what
> Reporting has provided to ADs in Monitoring Mode, but I do not want to
> say DMARG out loud either :-)

Here, too, the domain owner does not govern the platform receiver.

d/

--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

2023-07-24 Thread Neil Anuskiewicz



> On Jul 19, 2023, at 3:21 PM, Douglas Foster 
>  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.   

Doug, if what you’re saying is true then the root cause might be our fault. If 
we’ve not communicated clearly enough DMARC’s purpose. A communication problem 
likely needs to be solved with more and better communication via the standards 
doc itself and other channels.

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

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

2023-07-24 Thread Neil Anuskiewicz

On Jul 23, 2023, at 9:39 PM, Douglas Foster  wrote:Neil, this is about whether to block first and ask questions later:   quarantining first is safer, but not initially feasible.My working assumption is that essentially all evaluators release unauthenticated traffic to their users every day.   To fix the mailing list problem, we are proposing to ask them to do so on a slightly greater scale.If you start on a path toward 100% authentication, the assumption is that you cannot quarantine every unauthenticated message because you will not have the staffing resources to work the quarantine queue in a timely manner.   So you have to do triage.   Authentication moves:Start by updating your configuration to authenticate based on the DMARC concept instead of RFC 7489 and the sender policy.   Don't waste precious resources checking for impersonation on messages that already have verifiable authentication.   Don't allow the absence of someone else's DMARC policy record to become a reason to put your network at risk.Also consider that authentication comes in multiple forms.   I decided that a few major ESPs could be trusted to enforce client authentication during account setup and account use, so I did not have to repeat the process on every message from them.   That does not mean that I accept every message, because I don't.   Some of them still send a lot of unwanted traffic.  But it does mean that I accept the From address as valid without requiring an aligned DKIM signature.   This move also improved my authentication percentage.Collectively, these moves will decrease the false positives in your pool of unauthenticated messages.Audit moves:Initially, you can start with after-the-fact audits on the most obvious suspects.   For example, find the messages that fail both sender authentication and content filtering.   These messages have a high probability of malice, so verify the assessment and then block the sender completely.   You can actually start anywhere, because any form of sampling will work.  You have a dual goal:   find the wanted-but-unauthenticated message senders, and give them an authentication rule, while also finding the unwanted message senders and giving them a block rule.  Every investigation moves a message source from unauthenticated to authenticated or from unauthenticated to blocked.  Since you have a finite number of message sources, you have a finite number of investigations to complete.Gradually, send an increasing volume of messages to quarantine, based on perceived probability of fraud.   Assume that this queue will still contain wanted messages, so the quarantine volume has to be throttled by your capacity to review all of its traffic.  Wanted messages still need to be released to users in something approximating a timely manner.Over time, this process is guaranteed to reduce the volume of unauthenticated traffic.   When my SPF non-PASS rate was down to a few messages per day, I decided that I could quarantine any SPF result other than PASS.   Some of my business partners had no SPF policy at all, so they were quarantined and then equipped with an alternate authentication rule.   By now, virtually all of the authentication-related quarantine is unwanted traffic.    I haven't yet enforced quarantine on From verification failure, but my FROM PASS rate is about 97%, and the remaining 3% is mostly ESPs that have not been given special treatment.   So I am focusing on content filtering.   Most of the malicious traffic comes from mailbox provider accounts used for malicious purposes, which was sort of the goal of the 100% authentication effort.   I have to depend on content filtering to flag those suspicious actors, and the confirmed attackers will be given a block rule.Doug FosterOn Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:Doug, you’ve done a fine job of explaining as I groked what you said. If I get I think most people here got it. I’ve been busy with work and personal life so haven’t had as much time to lurk here. I’m curious what sparked your concern now? Also, isn’t it best to block first and ask questions later to mitigate damage while you investigate? I guess I’m saying the two ideas aren’t mutually exclusive.

Neil

> On Jul 15, 2023, at 4:27 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
> 
> 
> Murray recently observed, correctly, that something went horribly wrong with the DMARC rollout, because it caused (continues to cause) many safe and wanted messages to be blocked.
> 
> My assessment was in a recent post:
> 
> Something about the language of RFC 7489 caused implementers to focus on blocking individual messages, when the appropriate use of DMARC is to identify and investigate potentially malicious sources.
> 
> The "message blocking" approach violates the interests of the users it is intended to protect:
> 
> - An attacker sends 10 messages that maliciously impersonates

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

> On Jun 8, 2023, at 4:25 PM, Scott Kitterman  wrote:
> 
> The data I have seen (and it sounds like Mike is saying the same thing) 
> shows DKIM verification results are less than 100%, consistently, for direct 
> connections.  It was always lower than the SPF pass rate for hosts listed in 
> a domain's SPF record.  I understand that in theory, it shouldn't matter, but 
> in practice it is.
> 
> Software engineering isn't a perfect science.  In general, a more complex 
> protocol will suffer more defects.  If you want to design things that only 
> work when software is perfect, I'm not interested.
> 
> In terms of utility for direct connections, I think having both helps and I 
> don't find claims the SPF can never pass when DKIM fails to be credible.  If 
> someone has data that shows that's true now, I'd be interested to see it (my 
> experience is a few years ago, so things may have changed).
> 
> Ultimately, I think SPF and DKIM both suffer from what I'll genetically call 
> data hygiene problems.  SPF is mostly adding third party providers who are 
> insufficiently careful (might not even care, I don't know) generating SPF 
> pass results for "bad" mail.  DKIM is mostly about replay attacks.  Neither 
> of these are protocol problems and I don't think support dumping one or the 
> other out of DMARC.
> 
> One could make the opposite argument too, and I think it would be equally 
> valid:
> 
> The only value DKIM brings for DMARC is for indirect mail flows.  For any 
> direct connections, SPF is sufficient.  All the proposed DKIM changes to 
> solve the DKIM replay problem are likely to break indirect mail flows anyway, 
> so there's no longer a point to keep DKIM.  It's much more complicated and it 
> looks like the benefit of it is going away, let's just simplify the protocol 
> and get rid of it.
> 
> Now, I think that's a bad argument, but I don't think it's any worse than the 
> argument being presented to get rid of SPF.

I’ve observed the pattern of a high dmarc pass rate on DKiM alone, over 99% in 
most cases, yet as cogently stated by others, SPF will take a 99.5% pass rate 
to a rock solid 100%.

These might be an acceptable amount of blocked mail in some situations but 
there are many other scenarios where these lost emails, which add up fast, cost 
the company money and potentially strain relationships.  Email is perhaps the 
most important tool for business communication between businesses. An account 
manager sends a contract to an important prospect who doesn’t get it. That’s 
the cost. It might not be your first day at 99.9% but that number is on a 
rendezvous with its destiny to cost the business and individuals in various 
ways.

The effects of what seem to be small but aren’t when it comes to communication 
in business. 

Sure, we narrow the scope of our spf as much as we possibly can but we don’t 
toss that 0.5% traffic away without a reasonably good reason. 

If someone can cogently explain the assumption that the costs of spf 
implantation done judiciously (You don’t put an ESPs entire include in your org 
domain’s spf but you don’t just punt, declining the benefits of well implanted 
SPF. That’s an unforced error. Sometimes you have to throw SPF overboard but 
that’s not optimal. I get the feeling some here might make spf walk the plank 
right away. I ask that you reconsider that notion.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

Michael,As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I worked for was not unusual. That tension must play out many places as the roles and wildly different incentives bake tension right into the cake.On Jul 12, 2023, at 6:33 AM, Dotzero  wrote: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 listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Another p=reject text proposal

Yes sir, I’m convinced. Some of my more conservative customers who take 
security deadly serious won’t even bounce a DMARC failure with a helpful 
message. It’s discard. I respect the person I’m thinking of who hates bouncing. 
He’s appropriately paranoid for a InfoSec manager.

> On Jul 23, 2023, at 1:13 PM, Barry Leiba  wrote:
> 
> 
>> 
>> Without bounces the sender is in the dark.
> 
> Yes, if the sender is a human.
> 
> Not so, if the sender is a mailing list and that sender will then
> unsubscribe the intended recipient.
> Also not so, if the sender is a malfeasant who may use the bounce
> message for bad purposes.
> 
> It's very clear to me that if I think a bounce message will be
> harmful, I will not send one.  I will happily prefer silent discard
> over a bounce when I think that's a better approach for that
> situation.  Bouncing a legitimate mailing list message is just bad.
> If you have reason to believe you're going to do that... don't.
> Either deliver the message or silently discard it.  But don't bounce
> it.
> 
> Barry

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

Re: [dmarc-ietf] DMARC and Data Hygiene

 At a fundamental authentication property level, there are additional differences too.  IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature.  (This is one the issues of trusting the SPF results in ARC-Authentication-Result, whereas with DKIM once can try to validate the signature yourself).  On the other hand it's only fair to make the observation that SPF is easier to set up than DKIM and we want to capture those benefits as well.Is dkim really harder than SPF? I think part of the reason some of mega ESPs only support dkim alignment is because a lot can be automated. And you’re addiding something, not changing something (I.e., the envelope from). In most cases these days implementing dkim on the user side involves copying and pasting a txt or, increasingly common, a CNAME. It’s easier for everyone.I think DKIM’s simple for the end user at the mega ESPs. The incentives push them to make it as easy possible, while punting or shoving aligned spf aside.No, SPF has its place unless I’ve been a way from this list for so long I didn’t get the memo on that. So yes not deprecated until we come up with something a bit better or it becomes more of a liability than an asset.We're definitely not saying SPF should be deprecated, and in fact we want more deployment of SPF as it's highly complementary to DKIM both from a deployment perspective but as a spam fighting signal.  We just want to prevent its use in From header spoofing.  [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf 

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.Just pointing out we're prototyping one of the drafts and there's other work behind the scene. 
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'm not sure.  Much as Case 1 provides safety, the email Internet today has a large part that's based on Case 2 and 3 and it's up to us to frame standards that provide safety for our users by solving the issues you mentioned.  (Or if those needs are ignored, then likely those users will move to walled gardens that can claim more safety)  For case 2, we (and others) put drafts that provide a technical solution.  For case 3, we posed some ideas that can hopefully help.-Wei

Scott K




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

___dmarc mailing

Re: [dmarc-ietf] DMARC and Data Hygiene

On Jun 20, 2023, at 11:42 PM, Wei Chuang  wrote:On Tue, Jun 20, 2023 at 8: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 would argue we can see a difference in the SPF and DKIM attacks with respect to spoofing and that makes a difference for phishing.  With the SPF upgrade attack, the adversary can spoof an arbitrary identity in the victim domain and have it SPF authenticated.  See [1] for examples.  With DKIM replay, the adversary needs access to an account in the victim domain to obtain a signed message, but can't arbitrarily spoof some other identity in the victim domain.  At a fundamental authentication property level, there are additional differences too.  IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature.  (This is one the issues of trusting the SPF results in ARC-Authentication-Result, whereas with DKIM once can try to validate the signature yourself).  On the other hand it's only fair to make the observation that SPF is easier to set up than DKIM and we want to capture those benefits as well.We're definitely not saying SPF should be deprecated, and in fact we want more deployment of SPF as it's highly complementary to DKIM both from a deployment perspective but as a spam fighting signal.  We just want to prevent its use in From header spoofing.  [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf 

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.Just pointing out we're prototyping one of the drafts and there's other work behind the scene. 
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

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

> On Jun 30, 2023, at 11:33 AM, Dave Crocker  wrote:
> 
> On 6/30/2023 11:22 AM, Todd Herr wrote:
>> Why is the mechanism called "Domain-based Message Authentication, Reporting, 
>> and Conformance" and not "Domain-based Message Authentication, Reporting, 
>> and Disposition"?
> 
> Say DMARC out loud.  Now say DMARD out loud.

I like the way you think, Mr. Crocker. What a difference a letter makes. Dmarc 
sounds important, serious. DMARD sounds like something a high college friend 
might have made up to describe something stupid. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-28.txt

I hated that concept until I tried it out with a client, a law firm, and they 
loved it and I saved them massive headaches. The general purpose we used was a 
subdomain just for lists and it’s worked perfectly so far.

I’m now in favor of advocating general purpose domains. Let’s get ESR to put 
that term in the Hacker’s Dictionary and we’ll be set. ☺️

> On Jul 7, 2023, at 12:18 AM, Alessandro Vesely  wrote:
> 
> On Thu 06/Jul/2023 21:01:48 +0200 internet-drafts wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the Domain-based Message
>> Authentication, Reporting & Conformance (DMARC) WG of the IETF.
>>Title   : Domain-based Message Authentication, Reporting, and 
>> Conformance (DMARC)
>>Authors : Todd M. Herr
>>  John Levine
>>Filename: draft-ietf-dmarc-dmarcbis-28.txt
>>Pages   : 72
>>Date: 2023-07-06
> 
> 
> Section 7.6, Expansion of Domain Owner Actions Section, final paragraph:
> 
>In particular, this document makes explicit that domains for general-
>purpose email MUST NOT deploy a DMARC policy of p=reject.
> 
> Wasn't this rejected already?
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
>
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

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



> On Jul 12, 2023, at 3: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.
> 
> 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.

Perhaps not but sans any additional incentives the big ESPs, especially in the 
SME niche, are already doing the CNAME efficient system and that efficiency 
creates its own incentives. SPF is hard to scale especially in the SME focused 
ESP with a massive customer base. From the ESP point of view it’s a win, I 
think, so this trend will likely continue.

Perhaps the value neutral discussion of SPF OR DKIM logic could be less 
dispassionate, remembering that the IETF WG has the technical soft leadership. 
We can see where things are going and think accordingly. I think that standards 
are your ostensible mission but really you also need to be a top shelf sales 
organization.

Maybe in some ways DKIM and SPF need to be put in different cribs so the 
emphcise isn’t on the OR. Perhaps it’s on the relative value of SPF and dkim 
even though in theory they could get you to the goal the same. It’s ok to 
decide dkim is sold and spf is a real nice to have add on like a real nice 
stereo. No need to be heavy handed if you sell effectively.  
> 
> 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.
> 
> 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.
> 
> Scott K
> 
>> On Tuesday, July 11, 2023 8:49:28 PM EDT Wei Chuang wrote:
>> The data we presented June 20th (archive
>> )
>> also suggests that it is premature to drop SPF from DMARC.  However I
>> differ in believing that we should accept the spoofing risk demonstrated
>> recently via SPF, and that we shouldn't strive to reduce it by making
>> improvements to DMARC and possibly SPF.  One approach is to enable
>> different senders to distinguish their differing levels of risk and
>> infrastructure by letting them specify an "auth=" flag proposed on the 20th
>> .
>> For example a mom-and-pop sender on their own infrastructure with their own
>> IPs will have a different profile than a risky, enterprise sender on shared
>> IPs.  The former would be reasonably safe using SPF and would benefit most
>> from using it.  The latter should use DKIM authentication only due to the
>> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
>> additional ideas about how to use "auth=" flag with different risk and
>> infrastructure stratification on the DKIM list on July 3rd (archive
>> > /> ).
>> 
>> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
>> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
>> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
>> to be running literally a "mom-and-pop" produce shop was using SPF
>> authentication and was confused as to why their logo wasn't showing.  After
>> explaining the requirement they were able to move to DKIM authentication in
>> one day.  Yes, it did take explaining twice what was happening, but they
>> were able to deploy DKIM on their own and got

Re: [dmarc-ietf] Another p=reject text proposal

> On Jul 7, 2023, at 8:48 AM, John Levine  wrote:
> 
> It appears that Barry Leiba   said:
>> I, too, prefer MUST to SHOULD there, but it was clear to me that we
>> will not reach rough consensus on MUST, but that we can reach rough
>> consensus on SHOULD.
>> 
>> I do like your suggestion of silent discard rather than bounce, and I
>> would want to see that change made -- perhaps with a note that
>> aggregate reports will still include information about those discards.
> 
> Silent discard breaks RFC 5321 and some people feel very strongly
> about it. For reasons I am sure I don't need to remind you of, don't
> go there.
> 
> If you get so many bounces that you find it annoying, that is nature's
> way of reminding you that you should do something about it.  Personally,
> I use sorting rules to put the bounces in a place where they don't
> clutter up my main inbox.

Without bounces the sender is in the dark. This is a tech ecosystem. Every such 
community I’ve been involved with in any way has had the “we are all in this 
together.” I’ve never experienced more generosity than from fellow techies. My 
second techie job I just hinted I was struggling with something and 15 minutes 
later he at my office door pointing in the direction of solutions at like 7 pm 
on a work day. No all nighter needed. He stayed to watch me take his guidance 
then we called it a day.

I help others whenever I possibly can as that’s the ethos engrained in me by 
mentors such as him. He didn’t just teach me techie stuff. He taught me the 
ethos. That ethos must continue.

We help each other in all kinds of ways including bouncing email to help the 
admin do the job. We wouldn’t be able to sleep if we made someone’s life harder 
because of a fuck up. That’s who we are.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Another p=reject text proposal

> On Jul 6, 2023, at 12:04 PM, Barry Leiba  wrote:
> 
> As I've said before, I think we should specify what we think is right,
> and allow implementers to make their decisions.  We can't and won't
> police them.

No way. It wouldn’t be possible even if we all made it our life’s work to be 
standards cops. I agree with stay on target, on scope with pointers as a 
courtesy when appropriate. I’ve not visited in a while (busy) but I feel the 
energy is more focused, with people prepared to swap away distractions, time 
sinks, and wild goose chases. You all are an impressively disciplined group.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

>> 
>> 
> 
> I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC 
> as anti-spam.  They are a component of spam mitigation, but authentication of 
> an identifier isn't a solution for spam.  Meng Wong (for those of you that 
> weren't around, he's the one that synthesized SPF out of previous proposals 
> and was the early leader of the SPF project) used to say that SPF is not 
> anti-spam in the same way that flour is not food.  I think that extends to 
> DKIM and DMARC as well.
> 
> The challenge with the argument that this is brand protection, so the brand 
> owner should decide is that it's primarily the receiver that needs to invest 
> in integrating these technologies into their systems and accept the 
> inevitable support burden that comes with them.  The brand owner wants 
> something from the receiver, so it needs to be simple and reliable enough to 
> be worthwhile.
> 
> SPF includes a policy mechanism so that receivers can reject mail that is not 
> authorized by SPF.  Outside of small sites with a lot of control over their 
> mail stream, it's almost never used .  It was tried and for large providers 
> with a heterogeneous user base it wasn't cost effective to support due to the 
> number of false positives and the associated tech support costs.
> 
> DMARC seems to be heading the same way due to domains using p=reject that (at 
> least in my opinion) shouldn't.
> 
> Since there are no internet police, deployment of these technologies is a 
> matter of incentives.  We do protocol design, not economics, so it's a tough 
> problem in the IETF context, but we need to keep it in mind.  Getting the 
> incentives right is probably the most important, but least tractable part of 
> https://www.ietf.org/mailman/listinfo/dmarc

I agree that none of this primarily anti spam. It’s pro brand rep and anti 
fraud. 

I saw what happened with SPF and how it seemed completely random who would 
decide to enforce on hardfail. I recall a client losing mail as they used a 
hard fail and suddenly one of the more well known hosting companies started 
honoring hard fails which was a fiasco for my client who had just copied and 
pasted the -all in without thought to the implications. The outcomes were bad 
in a random way. It wasn’t hard to persuade him back to soft fail.

I feel with dmarc people come to recognize dmarc as the policy layer. SPF had 
too much responsibility. When one goes to p=reject one’s palms get sweaty. It’s 
clearly the policy layer unlike -all which was a bit too subtle way to 
communicate policy intent. Dmarc has the intuitive grok advantage.

I hope you’re wrong or that there’s a way to mitigate this problem you speak 
of. As I remember that as a time of confusion. Confusion and chaos are our foes.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

Doug, you’ve done a fine job of explaining as I groked what you said. If I get 
I think most people here got it. I’ve been busy with work and personal life so 
haven’t had as much time to lurk here. I’m curious what sparked your concern 
now? Also, isn’t it best to block first and ask questions later to mitigate 
damage while you investigate? I guess I’m saying the two ideas aren’t mutually 
exclusive.

Neil

> On Jul 15, 2023, at 4:27 AM, Douglas Foster 
>  wrote:
> 
> 
> Murray recently observed, correctly, that something went horribly wrong with 
> the DMARC rollout, because it caused (continues to cause) many safe and 
> wanted messages to be blocked.
> 
> My assessment was in a recent post:
> 
> Something about the language of RFC 7489 caused implementers to focus on 
> blocking individual messages, when the appropriate use of DMARC is to 
> identify and investigate potentially malicious sources.
> 
> The "message blocking" approach violates the interests of the users it is 
> intended to protect:
> 
> - 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.
> 
> Consider a variant of the above:   The attacker never impersonates a big bank 
> with p=reject, it only impersonates big universities with p=none.   The 
> foolish evaluator blocks nothing because it only acts on domains with 
> p=reject.  Again, the user is harmed.
> 
> And we know the flip side:   Safe and wanted messages get blocked because 
> p=reject is enforced without investigation against mailing lists and other 
> traffic.
> 
> Security theory says that ANY unauthenticated message COULD be a malicious 
> impersonation, and worthy of investigation.   Experience says that malicious 
> impersonations are a small percentage of all unauthenticated messages.  As a 
> result, the appropriate response to an authentication failure is to 
> investigate, not to block.
> 
> I don't know exactly how to communicate the difference between message 
> blocking and sender investigation in DMARCbis, but I sure hope that we will 
> try.
> 
> 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] Signaling MLMs



> On Apr 15, 2023, at 6:56 AM, Jesse Thompson  wrote:
> 
> 
>> On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote:
>> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
>> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>> > > The Sender's users being denied the ability to participate in a list due
>> > > to its policies seems to me like it puts this customer service problem
>> > > where it belongs.
>> > Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
>> > well as for every other member with p=reject) and/or disables from
>> > rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue
>> > with his CISO and IT security team and biz dev team and public relations
>> > team and legal team and all of the other forces that caused his domain
>> > owner to publish p=reject. But he can argue with IETF for making the
>> > decision to make the change, because he feels like the IETF considers him
>> > an important stakeholder.
>> > 
>> > It's this list's customer service problem, like it or not.
>> > 
>> > After calling IETF customer service, Todd finds out his options are:
>> > 1. Create an email address in a domain that houses members of the general
>> > public, instead of one that represents his identity as a member of a
>> > company. 2. Don't participate in the list.
>> > 
>> > But Todd is really important to this list, and doesn't like these options.
>> > Surely something can be done for an old friend? John, having been escalated
>> > this customer service dilemma seeks DMARCbis for guidance and finds:
>> > 
>> > ...MUST NOT p=reject...
>> > (Todd's company is pretty clearly stating Todd mustn't be representing his
>> > company on any mailing list.)
>> > 
>> > ...Domain Owner MUST provide a different domain with p=none for mailing 
>> > list
>> > participants. (Maybe they do, maybe they don't, but it's worth asking.)
>> > 
>> > ...Mailbox providers MUST NOT reject or quarantine email based solely on a
>> > DMARC policy violation. (John could ask each mailbox provider to create an
>> > exception to their DMARC policy enforcement)
>> > 
>> > and he also finds something like:
>> > 
>> > ...If a mailing list would like to provide the best customer experience for
>> > authors within domains that violate the "MUST NOT p=reject" and to deliver
>> > the author's mail to mailbox providers violate their "MUST NOT solely
>> > enforce", for those authors the mailing list MUST rewrite the From header
>> > to use a different domain. This is a new mode of interoperability the
>> > mailing list may choose to adhere to.
>> > 
>> > John now knows what he MUST do to provide the best customer experience 
>> > given
>> > the reality he finds himself in with an important stakeholder. He can
>> > choose to ignore that MUST as much as the domain owners and mailbox
>> > providers will choose to ignore their MUST NOTs.
>> > 
>> > I feel like there will be very few mailing lists that will ever stop
>> > rewriting (among those who are doing it), especially if DMARC adoption
>> > (publishing and enforcement) continues to rise. This is the new way of
>> > interoperating, in reality.
>> > 
>> > Throw them a bone so that they have a MUST to justify the things they had 
>> > to
>> > do to interoperate all this time. It's not as easy for them to justify
>> > their reality with only this page
>> > 
>> > to lean on.
>> 
>> Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
>> windmills.
> 
> That was the first option in the customer service dilemma, and it is the 
> option I have chosen for now. I do not carry my company's brand in anything I 
> say here. All opinions expressed are my own, [but maybe my opinions carry 
> less weight as a result?]
> 
> Why not turn off rewriting on this list, as an experiment? The hypothesis is 
> that everyone will switch to Gmail and not tilt at IETF, but instead they 
> will tilt at their domain owners.
> 
> Earlier it was accused that no one is offering alternative language 
> proposals.  
> 
> I feel like "Domain Owner MUST provide a domain with p=none for mailing list 
> participants" was a reasonable suggestion, and isn't incompatible with "MUST 
> NOT p=reject for domains with members of the general public". A couple of 
> people found it acceptable when I suggested it before, and no one else 
> rejected it (or read it). That kind of language makes it more clear that the 
> domain owner must work to sort out their mixed-use domains (by adopting all 
> of the great subdomain/treewalk/psd additions in DMARCbis).
> 
> And the "If a mailing list would like to provide the best customer 
> experience...MUST rewrite" suggestion seems like a reasonable way out of this 
> "interoperability vs reality" standoff.  How about if I soften it up further: 
> 
> "Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked to 
> send

Re: [dmarc-ietf] Signaling MLMs

> On Apr 15, 2023, at 7:29 AM, Scott Kitterman  wrote:
> 
> 
>> On April 15, 2023 12:26:16 PM UTC, Laura Atkins  
>> wrote:
>> On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
> ...
>>> Or [person] gets a Gmail account for his IETF work and doesn't bother 
>>> tilting at
>>> windmills.
>> 
>> That solution only works until gmail publishes p=reject. At one point they 
>> said they were going to do that. 
>> 
>> It seems to me that there is zero harm in actively documenting the problems 
>> with DMARC and making interoperability recommendations about who should and 
>> should not be publishing restrictive policies.
> 
> I agree on documenting the issues with DMARC and making recommendations to 
> improve interoperability.  There are issues and they're significant, but we 
> shouldn't catastrophize them either.
> 
> To your other point, if that happens then people will move to another 
> provider if it affects them negatively.  If free email providers that don't 
> have p=reject get hard to find, then that probably creates a demand signal 
> and some entrepreneur will fill the void.

Does anyone know if there are promising paths that these market signals could 
impel?

I don’t like dealing with mailing list issues either and I have to do so 
regularly. If there were some avenues of r that looked promising then that 
would mean the market signals would likely make it worth the hassle of 
implementing a solution. 

I agree there’s a problem. There was that one that gave me headaches and stress 
as recently as a couple weeks ago. It’s not that I don’t think there’s a 
problem but I do think there’s some catastrophising. I think this is a solvable 
problem.

If we write a solid appendix that explains the problems and the options for 
addressing it as I think was proposed, that would provide the information 
needed, while making it clear the IETF isn’t the internet regulatory agency. 

I think if someone came up with a viable solution their ML software would do 
well. Problems are the markets way of facilitating the solving of difficult 
problems. I’m not a market purist but the market is very good at certain 
things. Market signals are the bat signal for entrepreneurs to leverage gaps in 
the market. It could be one of the established players that gets there first or 
it could be an upstart. I think the odds favor one of the better established 
players.

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

Re: [dmarc-ietf] Signaling MLMs

> On Apr 15, 2023, at 7:29 AM, Scott Kitterman  wrote:
> 
> 
> 
>> On April 15, 2023 12:26:16 PM UTC, Laura Atkins  
>> wrote:
>> On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
> ...
>>> Or [person] gets a Gmail account for his IETF work and doesn't bother 
>>> tilting at 
>>> windmills.
>> 
>> That solution only works until gmail publishes p=reject. At one point they 
>> said they were going to do that. 
>> 
>> It seems to me that there is zero harm in actively documenting the problems 
>> with DMARC and making interoperability recommendations about who should and 
>> should not be publishing restrictive policies. 
> 
> I agree on documenting the issues with DMARC and making recommendations to 
> improve interoperability.  There are issues and they're significant, but we 
> shouldn't catastrophize them either.
> 
> To your other point, if that happens then people will move to another 
> provider if it affects them negatively.  If free email providers that don't 
> have p=reject get hard to find, then that probably creates a demand signal 
> and some entrepreneur will fill the void.

Does anyone know if there are promising paths that these market signals could 
impel?

I don’t like dealing with mailing list issues either and I have to do so 
regularly. If there were some avenues of r that looked promising then that 
would mean the market signals would likely make it worth the hassle of 
implementing a solution. 

I agree there’s a problem. There was that one that gave me headaches and stress 
as recently as a couple weeks ago. It’s not that I don’t think there’s a 
problem but I do think there’s some catastrophising. I think this is a solvable 
problem.

If we write a solid appendix that explains the problems and the options for 
addressing it as I think was proposed, that would provide the information 
needed, while making it clear the IETF isn’t the internet regulatory agency. 

I think if someone came up with a viable solution their ML software would do 
well. Problems are the markets way of facilitating the solving of difficult 
problems. I’m not a market purist but the market is very good at certain 
things. Market signals are the bat signal for entrepreneurs to leverage gaps in 
the market. It could be one of the established players that gets there first or 
it could be an upstart. I think the odds favor one of the better established 
players.

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

Re: [dmarc-ietf] Signaling MLMs

On Apr 15, 2023, at 7:52 AM, Hector Santos wrote:On Apr 14, 2023, at 7:31 PM, Dotzero wrote:On Fri, Apr 14, 2023 at 5:55 PM Hector Santos isdg.net> 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.Hi Mike, Appreciate your comment. This OR gate logic will short-circuit DKIM with SPF validating. Optimizing means not processing the payload and just issue a 250 which is ‘absolutely' not what we want. In fact, DMARC logic is an AND gate of two protocols; one standard, one informational with some controversial constraints (alignment). I think you maybe meant:SPF predates ADSP/DMARC. It is a 5321 level technology. It is not a payload 5322 technology. Interestingly, you might be thinking in terms of SenderID which was a 5322 technology which offers SPF with the PRA (5322.From) as a new identity to evaluate. I know it’s hard to believe for many but there is still a good percentage of domains that do not do ADSP or DMARC and maybe not even DKIM. Just consider platforms using Integrated Mail Bots to automate things and they who don’t need the overhead. SPF is good enough.Using Pareto, SPF is the only thing needed for hard reject policy (-ALL). DMARC is useless at this point unless you want it to override SPF hardfail rejects and record and send reports, That would be a local policy. An implementation detail.Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also fail. So the payoff is high to short-circuit and lowered when you needless transfer a potential large and harmful payload.But for SPF soft failures (~ALL), that is when the interest of coupling SPF soft fail results with ADSP results got traction. SPF verifiers will pass SPF weaker policy results in meta-header data and that meant the payload protocol can help here. Microsoft explored this method and had a secret source to determine how soft failures can be coupled with ADSP results. DMARC never considered partial results. DMARC see SPF as a pass not soft-fail. So if DKIM passes and all four (4) domain identities are aligned, the transaction passes. That’s an AND gate and you don’t need to even to process SPF or do DKIM validation if the domains do not align. Hector, respecfully, I disagree with several of your points.* You seemes to be saying that when spf fails then usually dkim fails, too. I’ve seen first hand that’s nit true.* you seemed to be placing too much weight on the value of spf hardfail. Even 10 years ago, few receivers rejected on an spf hardfail. Some do but it’s not at all reliable. DMARC is accepted by most as the new policy layer. It’s where policy should be handled. The OR logic is in part to get away from the policy layer that breaks fairly easily (e.g., forwarding). SPF is important but given a choice between authenticating with just aligned SPF or just aligned DKIM, I’d choose DKIM. Could you provide a citation for the following claim: “Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also fail. So the payoff is high to short-circuit and lowered when you needless transfer a potential large and harmful payload.”I’m skeptical and I’d imagine some others are too so a cite would go a long way. Thanks.Neil___
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?

2023-04-15 Thread Neil Anuskiewicz



> On Apr 14, 2023, at 7:43 PM, Mark Alley 
>  wrote:
> 
> 
> Its not ideal, but I could live with that. That's somewhat less ambiguous 
> than [general purpose] domains, but still ambiguous; the Appendix or the same 
> section could easily clarify "unrestrictive usage policies",  and then maybe 
> the appendix, as you say, could cover the known issues and workarounds. 
> 
> If I'm being honest, given the different versions put forth so far, it seems 
> like this type of language is closer to the compromise on the 
> interoperability statement. The other versions say relatively the same thing. 
> 
> - Mark Alley

I think what Mark’s saying isn’t perfect for but I think it can get the rough 
consensus we’re seeking. That’s my humble opinion.

Neil
___
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?

2023-04-15 Thread Neil Anuskiewicz



> On Apr 15, 2023, at 4:21 PM, Scott Kitterman  wrote:
> 
> 
> 
>> On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz 
>>  wrote:
>> 
>> 
>>>> On Apr 14, 2023, at 8:26 PM, Scott Kitterman  wrote:
>>> 
>>> Perfect.  The goal is working towards consensus is to find something we 
>>> can 
>>> live with, so that's exactly what I was hoping for.  I don't think it's 
>>> ideal 
>>> either, but I can live with it.
>>> 
>>> Scott K
>> 
>> Yes sir, that’s it. However, I’d like to see less of some narratives in the 
>> discussion especially around costs and benefits. It’s not you, Scott, but 
>> your post seems apropos.
>> 
>> 1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to 
>> stop spoofing of exact domains. There are other technologies and methods 
>> whose responsibility it is to track down and take down fraudsters.
>> 
>> 2. I would like to know if general purpose domain == org domain in most 
>> cases. Someone suggested the registration of a separate domain for general 
>> purposes. That sounds reasonable as long as the advice is clear that this 
>> isn’t advocating cousin domains.
>> 
>> 3. Dmarc should be made to work is as well as possibility to prevent exact 
>> domain spoofing. I’ve seen spoofing of org domains of companies that you 
>> wouldn’t think of as a high priority impact. It can cause catastrophic 
>> consequences to the organization so spoofed. I don’t have to say more here 
>> as presumably everyone here knows. If you don’t I think it’s critical to 
>> understand that. If you can’t feel it emotionally then you’ve not explored 
>> the consequences of spoofing.
>> 
>> So I humbly request a practice of steal manning and dispense with the straw 
>> men and especially the red herrings.
>> 
> What color herrings would you prefer?
> 
> I really have no idea what that last paragraph means.
> 
> If we can stick to trying to get some consensus on the MUSTard in the main 
> part of the document, I think we can (and should) address details in the 
> appendix the proposed language suggests we point to.
> 
> Dude, I have literally worked on email authentication for 20 years.  Do you 
> think I did that without understanding it's a problem?
> 

Scott, I said it wasn’t your posts that had those problems. See above. I 
responded to you with this as I see you as the person who is going to actually 
write the compromise text in the actual document. I meant no disrespect, Scott. 
I know who you are from SPF fame on.

I was just seeing arguments that not much benefit has been seen from enforcing 
policies not to mention cousin domains and so on. I get the feeling that 
position is from someone who’s never witnessed the consequences of malicious 
spoofing.

So I apologize, Scott, I neglected to explain my concerns.

Neil
___
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?

2023-04-15 Thread Neil Anuskiewicz

> On Apr 14, 2023, at 8:26 PM, Scott Kitterman  wrote:
> 
> Perfect.  The goal is working towards consensus is to find something we can 
> live with, so that's exactly what I was hoping for.  I don't think it's ideal 
> either, but I can live with it.
> 
> Scott K

Yes sir, that’s it. However, I’d like to see less of some narratives in the 
discussion especially around costs and benefits. It’s not you, Scott, but your 
post seems apropos.

1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to stop 
spoofing of exact domains. There are other technologies and methods whose 
responsibility it is to track down and take down fraudsters.

2. I would like to know if general purpose domain == org domain in most cases. 
Someone suggested the registration of a separate domain for general purposes. 
That sounds reasonable as long as the advice is clear that this isn’t 
advocating cousin domains.

3. Dmarc should be made to work is as well as possibility to prevent exact 
domain spoofing. I’ve seen spoofing of org domains of companies that you 
wouldn’t think of as a high priority impact. It can cause catastrophic 
consequences to the organization so spoofed. I don’t have to say more here as 
presumably everyone here knows. If you don’t I think it’s critical to 
understand that. If you can’t feel it emotionally then you’ve not explored the 
consequences of spoofing.

So I humbly request a practice of steal manning and dispense with the straw men 
and especially the red herrings.

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

Re: [dmarc-ietf] Author vs Signer Domains

2023-04-14 Thread Neil Anuskiewicz

> On Apr 14, 2023, at 6:42 PM, Hector Santos 
>  wrote:
> 
> On 4/14/2023 7:31 PM, Dotzero wrote:
>> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos 
>> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>>Yes, it is simple DeMorgan’s Theorem where you use
>>short-circuiting logic.
>> 
>>DMARC says that any FAIL calculated via SPF or DKIM is an
>>overall DMARC failure.  In standard boolean logic is it an OR
>>condition:
>> 
>>IF SPF FAILS or DKIM FAILS Then Reject.
>> 
>> 
>> You have it absolutely backwards.
>> 
>> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it 
>> passes.
> I don't follow you, so NO
> 
> a fail of either is a failure as a whole.
> 
> That is how the major EPS of late are applying it - per specs.

Hector, you’re wrong on this one. Check out 
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.2. How would you 
interpret the following (follow link above for more context):
DMARC evaluation can only yield a "pass" result after one of the underlying 
authentication mechanisms passes for an aligned identifier.
Neil___
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?

2023-04-14 Thread Neil Anuskiewicz

On Apr 14, 2023, at 2:54 PM, Dotzero  wrote: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.

BarryBarry 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.I really like the way this is headed.Neil___
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?

On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy  wrote:On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The standard and the document should reflect that it’s already making a massive difference and could do even more. I don’t think it’s unreasonable to expect ml managers to adapt. If cyber crime was street crime people would be panicking in the streets. The IETF is a consensus-based organization.  I suggest that if we're going to claim DMARC as-is has the consensus of the community, that community needs to be representative of the interests of the MLM developers and operators.  Since we keep talking about "them", I don't think it is.Expecting them to adapt (or perhaps "comply" is the better word) merely because we say so feels a lot like pushing on a string.Fair enough. You’re saying this is a political process with stakeholders whose interests must be accounted for. I get that. Is there really going to be language in the new standard saying general purpose domains must be p=none type of language? That’s quite a compromise if it’s the case. Like all of us I’m busy and tired so maybe didn’t read everything including nuance. I thought the jist of one bit was that “general purpose” domains must have a p=none. What is a general purpose domain? Like could the org domain of some organization be called general purpose?N___
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?

> On Apr 8, 2023, at 6:56 AM, John Levine  wrote:
> 
> We're never going to persuade DMARC absolutists that the damage is real,
> nor the rest of us that we can wave our hands and ignore the damage.

John, the damage is real. There’s no doubt about that. Trade offs, painful 
trade offs, have to be made and I’m sure this isn’t the first WG to face trade 
offs and have to make hard decisions or not. 

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 of one of the last remnants of the free internet. 
It’s a fiasco on so many levels. If you have the tools to make a real 
difference and I can say from first hand experience DMARC has helped people’s 
financial and mental health.

The standard and the document should reflect that it’s already making a massive 
difference and could do even more. I don’t think it’s unreasonable to expect ml 
managers to adapt. If cyber crime was street crime people would be panicking in 
the streets. 

N

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

Re: [dmarc-ietf] Weakening of enforcement concern

On Apr 11, 2023, at 1:06 PM, Douglas Foster  wrote:Yes, I am talking about inbound policies.  Mailing list damage happens when inbound filters block a harmless message that the user wants.    So the best fix is for the inbound filters to acknowledge that they live in an environment with imperfect information.The Sender can only ensure that all of his mail is signed.  He cannot ensure that no other legitimate source will impersonate on behalf of a single user, or that no legitimate  intermediary will alter content during forwarding.  The recipient evaluator has the job of delivering what its users need and blocking what can harm them or don't want.  Senders cannot fix evaluators that do that poorly.  Google says they cannot do conditional processing of p=reject, but they don't block on DMARC fail at all.  They make up for that limitation by having other spam filtering logic that is pretty impressive.   My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked.I don't have the same content filtering sophistication, so I have ramped up my sender filtering.Doug FosterOn Tue, Apr 11, 2023, 11:15 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:

> On Apr 11, 2023, at 4:29 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
> 
> 
> Neil, I am slowly embracing the position of the Mailing List advocates.
> 
> If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject".   Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures.  Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process.   This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options.    I am content with language that documents this conundrum.
> 
> The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions.   Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement.    Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous.   It is my job to replace guesswork with certainty based on research.  As indicated earlier, this can be done.  Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From.   Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none
It’s perfectly acceptable to create bypasses and whatever else you want. The local is the sacrosanct domain of the admin. I don’t see how this relates the standard. It should be as robust as possible. I’m likely missing something.I’ve dealt with convoluted mailing lists that couldn’t hold a candle to mailman. There’s always a solution. The reality of workarounds shouldn’t touch the standard.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 11, 2023, at 2:45 PM, Neil Anuskiewicz  wrote:
> 
> 
> 
>> On Apr 11, 2023, at 2:29 PM, John Levine  wrote:
>> 
>> It appears that Neil Anuskiewicz   said:
>>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be 
>>> thought of by most technical people as focused on security.
>> 
>> I can believe that's the case for people you know, but none of us know "most 
>> technical people".
>> 
>> It's more likely that most actual technical people don't understand
>> what DMARC does and doubly don't understand the tradeoffs between
>> blocking malicious mail and losing legit mail that DMARC can't
>> describe.
>> 
>>> On the marketing side, authentication’s priority benefit is deliverability, 
>>> ...
>> 
>> I hope I don't have to explain how deeply the IETF does not care about 
>> deliverability.
> 
John, what does the IETF care about? I thought I knew but clearly I don’t.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 11, 2023, at 2:29 PM, John Levine  wrote:
> 
> It appears that Neil Anuskiewicz   said:
>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be 
>> thought of by most technical people as focused on security.
> 
> I can believe that's the case for people you know, but none of us know "most 
> technical people".
> 
> It's more likely that most actual technical people don't understand
> what DMARC does and doubly don't understand the tradeoffs between
> blocking malicious mail and losing legit mail that DMARC can't
> describe.
> 
>> On the marketing side, authentication’s priority benefit is deliverability, 
>> ...
> 
> I hope I don't have to explain how deeply the IETF does not care about 
> deliverability.

I don’t work in deliverability but I do care about it. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 11, 2023, at 9:14 AM, Mark Alley 
>  wrote:
> 
> 
> I agree with where you're coming from, as these were my same concerns as 
> well. That's why I also tried to say a couple of times that I feel if we make 
> an effort to make clear the interoperability expectations, but also have 
> accompanying language that those specific expectations do not make a 
> statement about perceived security benefits of strict DMARC policies... - My 
> hope is that should be sufficient enough of a compromise to address 
> everyone's concerns.
> 
Thanks. Even if it hasn’t always been the case, DMARC has evolved to be thought 
of by most technical people as focused on security. I bet a poll would reveal 
this to be the case. On the marketing side, authentication’s priority benefit 
is deliverability, though I realize that dmarc can’t make up for sins such as 
bad list hygiene.

the motivation of almost all tech people, including security folks, for 
implementing DMARC is for security and to protect their brand reputation. I 
know I don’t have much influence here so I’ll just say it one more time: people 
are motivated by security and would not want to compromise that for mailing 
lists.

I think we should focus on security. It’s what most people want from dmarc. Of 
course it only protects exact domain phishing but there are other services that 
address other threats.

this is our chance to really be in synch with why people want dmarc, which will 
open up more opportunities to do interesting things than a standard with a sort 
of ambiguous purpose. Ambiguity doesn’t lead down a good road.

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

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 11, 2023, at 4:29 AM, Douglas Foster 
>  wrote:
> 
> 
> Neil, I am slowly embracing the position of the Mailing List advocates.
> 
> If mailing lists and all other exceptional situations could be eliminated, 
> evaluators could mindlessly apply a rule to "block on fail when p=reject".   
> Similarly, if all evaluators would implement reliable mechanisms for domain 
> members to request and obtain exceptions for mailing lists and other 
> exceptional traffic, then domain owners could publish p=reject as soon as all 
> of their traffic had signatures.  Unfortunately, we have a reality that some 
> highly valued traffic arrives without authentication, and some evaluators do 
> not provide an effective exception process.   This conundrum is aggravated by 
> filtering products that do not provide administrators with sufficient 
> exception configuration options.I am content with language that documents 
> this conundrum.
> 
> The Internet will always be an environment of imperfect information, so the 
> only viable filtering scheme is one which expects and allows for exceptions.  
>  Additionally, my defenses against impersonation should not be dependent on 
> the domain owner's policy statement.Any allowed message is implicitly 
> assumed to be free of impersonation, but assumptions are dangerous.   It is 
> my job to replace guesswork with certainty based on research.  As indicated 
> earlier, this can be done.  Using DMARC, SPF, and local policy, I am at 100% 
> verified for MailFrom, and 97% verified for From.   Mailing lists have 
> nothing to fear from my filtering and I have nothing to fear from p=none.
> 
> In short, we need smarter filtering.
> 
> Doug Foster

Mr. Foster, you seem (though I could be wrong) to be talking about inbound 
where you have complete control but for policies set in domains sending 
outbound, how would filters resolve the problem? We have little control over 
outbound. Threat actors will Phish wherever the phishing is good.

I guess I was hoping that security could be the top priority but it’s likely 
naïveté. I can see the I trade offs. You piss off too many people and you end 
up with a standard nobody wants to use.

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

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz  wrote:
> 
> 
> 
>>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman  wrote:
>>> 
>>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
>>> I’m a bit concerned that the document will discourage domain owners from
>>> working toward an enforcing policy. I’ve seen at least one person say that
>>> most domains don’t need to go to p=reject. I’ve seen all sorts of domains
>>> attacked? Granted, high profile domains or perceived lucrative targets will
>>> receive the most attention but threat actors absolutely do attack all sorts
>>> of organizations all the time.
>>> 
>>> Maybe I’ve misunderstood but I hope that no langue that could be construed
>>> as discouraging domain owners from moving toward an enforcing policy would
>>> be a mistake.
>> 
>> It all depends on the user base of the domain and the tradeoff between the 
>> benefits of having such a policy against the interoperability risks of 
>> having 
>> such a policy.
>> 
>> We absolutely should be discouraging blind adoption of policies that result 
>> in 
>> reduced utility for email.  For any domain that has non-transactional users, 
>> that takes work to assess the completeness of email authentication 
>> deployment, 
>> assess aggregate reporting to understand the likely effects of either 
>> p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs 
>> associated with such policies.  That's a non-trivial set of work to do and 
>> it's not cost effective for all domains to do it.
>> 
>> Early in the deployment of SPF there was a similar push to deploy SPF 
>> records 
>> with -all (the SPF rough equivalent of p=reject).  A lot of people did it 
>> without thinking it through and there were significant side effects.  The 
>> community concluded that SPF Fail (due to the -all in the record matching) 
>> was 
>> not a sufficiently reliable indicator that mail should be rejected and 
>> largely 
>> stopped doing it.

Scott, I’m also aware of what happened to SPF’s run as a policy layer. There’s 
a big difference between SPF and DMARC. People deploy DMARC with the knowledge 
that it is the policy layer. Many soon learn that SPF hard fail isn’t honored 
much. 

There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes for 
a more robust system that you can get your legit mail passing DMARC 
consistently. SPF does was it does well but it with things like forwarding 
breaking it, the presence of DKIM made up for some of SPF’s shortcomings and 
vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a good place 
to set policy.

DMARC is a much stronger policy layer so I hope you are thinking that the 
policy setting aspect will go the way of SPF? It won’t.

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

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 10, 2023, at 9:24 PM, Scott Kitterman  wrote:
> 
> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
>> I’m a bit concerned that the document will discourage domain owners from
>> working toward an enforcing policy. I’ve seen at least one person say that
>> most domains don’t need to go to p=reject. I’ve seen all sorts of domains
>> attacked? Granted, high profile domains or perceived lucrative targets will
>> receive the most attention but threat actors absolutely do attack all sorts
>> of organizations all the time.
>> 
>> Maybe I’ve misunderstood but I hope that no langue that could be construed
>> as discouraging domain owners from moving toward an enforcing policy would
>> be a mistake.
> 
> It all depends on the user base of the domain and the tradeoff between the 
> benefits of having such a policy against the interoperability risks of having 
> such a policy.
> 
> We absolutely should be discouraging blind adoption of policies that result 
> in 
> reduced utility for email.  For any domain that has non-transactional users, 
> that takes work to assess the completeness of email authentication 
> deployment, 
> assess aggregate reporting to understand the likely effects of either 
> p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs 
> associated with such policies.  That's a non-trivial set of work to do and 
> it's not cost effective for all domains to do it.
> 
> Early in the deployment of SPF there was a similar push to deploy SPF records 
> with -all (the SPF rough equivalent of p=reject).  A lot of people did it 
> without thinking it through and there were significant side effects.  The 
> community concluded that SPF Fail (due to the -all in the record matching) 
> was 
> not a sufficiently reliable indicator that mail should be rejected and 
> largely 
> stopped doing it.
> 
> Aggressively pushing DMARC p=reject on domains that aren't ready for it may 
> well lead to a similar result. Let’s not.

I’m not for aggressively advocation for p=reject. Before my current job I 
worked as a one person business with mostly small businesses. My contracts 
weren’t just about authentication but when it became clear that a company 
didn’t have the bandwidth to get to and maintain an enforcing policy, I didn’t 
push it. It likely would have done more harm than good.

The document should make it clear that you have to know what you’re doing to 
get to an enforcing policy. 

So I’m not advocating boosterism for enforcing policies for everyone. But 
medium to large businesses I think should move toward an enforcing policy.  We 
shouldn’t make it sound easy because it is not!

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

Re: [dmarc-ietf] Weakening of enforcement concern



> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz  wrote:
> 
> I’m a bit concerned that the document will discourage domain owners from 
> working toward an enforcing policy. I’ve seen at least one person say that 
> most domains don’t need to go to p=reject. I’ve seen all sorts of domains 
> attacked? Granted, high profile domains or perceived lucrative targets will 
> receive the most attention but threat actors absolutely do attack all sorts 
> of organizations all the time. 
> 
> Maybe I’ve misunderstood but I hope that no language that could be construed 
> as discouraging domain owners from moving toward an enforcing policy would be 
> added to the document. 

I meant to say that I’ve seen all sorts of domains attacked. The goal should be 
to get to an enforcing policy. It makes sense for very small businesses to be 
very reluctant to enforce unless they have the access to the expertise. But any 
domain owner that can should protect their domains.

Neil

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

[dmarc-ietf] Weakening of enforcement concern