[dmarc-ietf] Re: Reporting Period is undefined

[Steven M Jones]

On 12/1/24 12:00 PM, Daniel K. wrote:

I'm going through the drafts with a finer comb looking for things that
stand out, in order for us to produce as good a specification as possible.

Not all of what I find is an actual problem. I've not been involved in
this effort for several years, and I hope I can provide a new look at
some of it, and asking or pointing out things I react to as I read through.


We do have to keep in mind there may be people reading these documents 
without a dozen years of history filling in the gaps. Thank you for 
taking the time to try and provide feedback with that perspective.




Here I wanted to flag the discrepancy between my perception of the
importance we give to the reporting period ... nor even giving any
guidance on how to choose an appropriate reporting period.


There is a DMARC Usage document as a Phase II/III work item in the 
charter, but it doesn't seem likely that we'll create such a thing from 
scratch in the time remaining. And while it might have been nice for the 
WG to produce such a doc, there have been *mountains* of guidance 
published since 2015, and I'm sure more will be published no matter what 
the WG does.


--S.

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

[dmarc-ietf] Re: Reporting Period is undefined

[Steven M Jones]

On 11/28/24 10:05 AM, Daniel K. wrote:

The "ri" tag was removed, and as a result the default interval, or
reporting period is no longer mentioned any place.


Not exactly. DMARCbis, section 5.3.8: "Mail ReceiversSHOULDgenerate and 
send aggregate reports with a frequency of at least once every 24 hours."


If that isn't clear enough, I would think the addition of something like 
", covering the period since the last report was sent." would be sufficient.


--S.

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

[dmarc-ietf] failure-reporting: Bringing Verifying External Destinations inline with aggregate-reporting

[Steven M Jones]

I opened a GitHub issue 
(https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/issues/6) 
for the text in this section and am proposing the following change.


This brings the language inline with what appears in 
aggregate-reporting, and fleshes out the reason for the requirement.



Current text:

|If the target domain of a mailto address of a ruf= tag is not the same 
as the DMARC record domain where the tag was found, the report generator 
MUST verify that the target domain acknowledges sending those reports; 
the procedure is described in Section 3 of 
[I-D.ietf-dmarc-aggregate-reporting]. |



Proposed text:

|It is possible to specify destinations for failure reports that are 
outside of the domain requesting the reports. These destinations are 
commonly referred to as "external destinations" and may represent a 
different domain controlled by the same organization, a contracted 
report processing service, or some other arrangement. Without this 
check, a bad actor could publish a DMARC policy record that requests 
that failure reports be sent to an external destination, then 
deliberately send messages that will generate failure reports as a form 
of abuse. Or, a domain owner could incorrectly publish a DMARC policy 
with an external destination for failure reports, forcing the external 
destination to deal with unwanted messages and potential privacy issues. 
Therefore a Mail Receiver who generates failure reports MUST use the 
Verifying External Destinations procedure described in Section 3 of 
[I-D.ietf-dmarc-aggregate-reporting], substituting the "ruf=" tag where 
the "rua=" tag appears in that procedure.`|



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

[dmarc-ietf] Re: Publication has been requested for draft-ietf-dmarc-aggregate-reporting-21

[Steven M Jones]

On 11/21/24 12:41, Murray S. Kucherawy wrote:


On Wed, Nov 20, 2024 at 6:48 PM Brotman, Alex 
 wrote:


* Section 2.6.2 requires gzip.  What about other methods like zstd
which can provide better compression?

This is the first time that has been asked.  I suppose it could be
changed, though, it seems as though it would break existing report
ingestion.   Are zipped reports large enough to benefit?


The reason I bring it up is because compression mechanisms more modern 
than gzip, such as Brotli and zstd, have been published as RFCs since 
RFC 7489, so I wonder if there would be any advantage to allowing 
those.  If there's never been any need and we're satisfied with gzip, 
that's fine.  I just figured I'd ask the question.



I'd be happy not to lock everything into gzip for the next X years, but 
can we allow flexibility without creating an issue for existing code? We 
could add something like (completely off-the-cuff) "+zstd" or "+brotli" 
at the end of the "rua=" value, and if neither of those are present you 
stick to gzip?


That'd have to go into the DMARCbis draft with the notation, allowed 
values, and RFC references... Worth the effort?


--S.


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

[dmarc-ietf] Re: Discussion Thread for Issue 157

[Steven M Jones]

On 11/18/24 03:38, Murray S. Kucherawy wrote:
On Mon, Oct 21, 2024 at 8:51 AM Todd Herr 
 wrote:


Issue is here -
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/157


As I read the github discussion, and to bring it back to the list as 
Barry requested, it looks like John proposed no action here and I took 
the replies to be in concurrence.  Is that the consensus response?



I've chased my tail around this one for a bit today, and I think it's 
okay as is. So, +1.


There are some reasons for limitations on failure reporting from RFC9091 
that should perhaps be carried into the failure reporting document, but 
that's nothing to do with this Issue. (And more on it later in a 
separate thread.)



--S.

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

[dmarc-ietf] Re: Citation where a Proposed Standard cannot rely on an Experimental document

[Steven M Jones]

On 11/3/24 3:45 AM, Alessandro Vesely wrote:

On Sun 03/Nov/2024 04:22:39 +0100 Steven M Jones wrote:
I've been looking for documented requirements around whether a 
Proposed Standard can reference an Experimental document. I reviewed 
RFC 2026 and ...


If such a restriction existed it would only be about normative 
references.  And we don't want to cite ARC as normative at this stage, 
methinks.



Thanks. My motivation was to make sure we are clear about any explicit 
requirements, and can reference the appropriate text, as we try to 
anticipate/address objections to the current text.


I meant to leave consideration of specific objections and responses for 
other threads, so I won't go any further with that here.


--S.


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

[dmarc-ietf] Citation where a Proposed Standard cannot rely on an Experimental document

[Steven M Jones]

I've been looking for documented requirements around whether a Proposed 
Standard can reference an Experimental document. I reviewed RFC 2026 and 
tried to scan the 15 RFCs that update it that seemed relevant (e.g. I 
skipped the IPR ones).


For example, RFC 2026 Section 2.2 describes how an I-D has no formal 
status, but if it's expected to be published on the standards track it 
may be referenced as a "Work in Progress" in a standards track document.


I found requirements for Applicability Statements in RFC 2026 Section 
3.2 where the AS could not have a higher maturity level than any 
standards track Technical Specification it references. So, a Draft 
Standard AS cannot reference a Proposed Standard TS.


But I couldn't find such a prohibition for a Proposed Standard 
referencing an Experimental document. I probably just failed with my 
search terms and skimming... Maybe there's text that says it can't 
reference anything but standards track documents, which I missed?


Is anybody familiar with a document where this kind of requirement is 
spelled out?


Thanks,
--Steve.


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

[dmarc-ietf] Re: Discussion Thread for Issue 155

[Steven M Jones]

On 10/24/24 8:16 PM, Tero Kivinen wrote:

Murray S. Kucherawy writes:

 And whatever deficiencies people see in ARC, it is a protocol-based
 response.

We have made no statement that ARC even works, much less that it solves the

stated problem.  Our story is incomplete.

I think ARC works, but what is missing from the RFC is the description
how...


Arguably the specification RFC isn't the right place to go into depth on 
how the ecosystem would use the protocol. But it's common to have 
companion Informational documents that go into considerable detail.


In fact we had developed an ARC usage guide as a WG document. The focus 
up to that point was on providing information and guidance for 
organizations implementing or deploying ARC, not really what might be 
done at the MUA level.


The ARC usage guide was officially Parked based on a discussion the 
chairs held in Prague in early 2019, so that the WG would focus on 
completing the PSD work as Experimental (RFC9091) and then get started 
on DMARCbis. At that point I believe the ARC specification had been sent 
to the RFC Editor for publication, which would happen a few months later.


Minor updates were made to ARC Usage to keep it current, because when it 
was parked we were told we could resume work after DMARCbis was done. 
That continued until the editors were directed to "let this draft 
expire" by a chair in November 2020.


cf. https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/

--S.


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

[dmarc-ietf] Re: Discussion Thread for Issue 155

[Steven M Jones]

On 10/23/24 4:35 PM, Murray S. Kucherawy wrote:
On Wed, Oct 23, 2024 at 11:55 AM Jim Fenton  
wrote:


It hardly seems like the agreement was tacit when it’s quite
explicit in the WG charter.


The charter is explicit (twice, by my count) that addressing the 
problems with indirect mail flows is in scope for the working group.  
What it doesn't make clear (hence "tacit") is the understanding, at 
least at the time of chartering, that it's not only in scope, it's 
required.


"Tacit" is tricky, and we tend to avoid that when writing documents for 
a reason.


The way I read Track 1 of the charter, the WG was to "reduc[e] or 
eliminat[e]" effects on indirect mail flows, but it doesn't state that 
the DMARCbis spec itself has to be what does it. And I don't see where 
in Track 2, "Reviewing and improving the base DMARC spec," that it says 
DMARCbis revisions themselves must remediate impacts on indirect mail flows.


But then those "tacit expectations" come back to haunt us. However...

ARC was published, and support has been baked into Mailman and Sympa for 
a good while now. I think the stumbling block in citing it in a response 
to this point, is that RFC8617 is Experimental. Given the timing now, 
leaving ARC in Experimental status - and not actually running it as an 
experiment - may have left us between a rock and a hard place. This is 
reflected in comments from Ale V and John L on the GitHub thread.


The problem with DKIM2 (another point from the GitHub thread) is that it 
would be a forward reference. I know a great deal of thought has gone 
into the "design outline," but I don't think there's a specification so 
that's at least one step behind ARC in terms of this thread, and I 
imagine it doesn't have experimental data either.



DMARCbis appears to address this via the text of Section 7.4, which in 
essence tells senders to ...  The completion of WGLC with no further 
discussion suggests that the WG believes that this is satisfactory.  
That's fine if so, but I claim it falls short of what I imagine was 
anticipated, that being a protocol solution, and I'm suggesting we 
should say something in the document that reconciles or explains this.


There is a problem inherent in trying to address implicit, undocumented 
expectations that weren't written into the charter. I don't say that to 
be a jerk but to ask, How are we supposed to know where the bar is if it 
was never written down? You can talk yourself into or out of anything 
depending on what you imagine those expectations were, or have become since.


And whatever deficiencies people see in ARC, it is a protocol-based 
response.



To reiterate something I said earlier: I'm not obstructing the 
progress of the document even though I disagree with a couple of the 
decisions made, but I think those decisions -- especially this one -- 
need to be explained or face scrutiny and delay during Last Call 
and/or IESG Evaluation.


Anticipating objections so we can address them in advance is not 
obstructive, but constructive. Thank you for taking the time to 
carefully consider the situation and kick us in the collective behind.



--S.

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

[dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33

[Steven M Jones]

> On Oct 11, 2024, at 11:15 AM, Murray S. Kucherawy  wrote:
> 
> Or have we given up?

Not yet! Pushing back from an airport terminal gate, however… More later!
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33

[Steven M Jones]

On 9/30/24 10:53, Alessandro Vesely wrote:

On Sun 29/Sep/2024 23:16:46 +0200 Murray S. Kucherawy wrote:
In Section 4.7, just out of curiosity, how much have we observed use 
of the

"fo" tag in the wild?

...

In fact, RFCs 6651/2 provide their own ra= tags to specify a reporting 
address, so if fo= only uses "d" and "s" values, it would make sense 
to set fo= without ruf=.


Requiring ruf= makes sense only if the only reports considered are 
those described in dmarc-failure-reporting. 



The following figures are for validly-formatted DMARC policies observed 
in DNS before and after June 2024*, that included the "fo=" tag with a 
value specified in RFC7489.


"fo=" Tag
Total Records
Records w/o "ruf" tag
fo=1
6,753,358   442,976
fo=0
563,852 347,126
fo=s
17,787  3,237
fo=d
5,885   691


The total (7,340,882) is a bit less than one third of all 
validly-formatted DMARC policies observed in DNS before and after June 2024.


 --S.


* In other words, any policies published for the first time after June 
2024 would not be included. Any policies published before June 2024 that 
were not still returned by a DNS query after June would not be included.


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

[dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33

[Steven M Jones]

On 10/7/24 14:26, Murray S. Kucherawy wrote:
On Mon, Oct 7, 2024 at 2:20 PM Barry Leiba  
wrote:


> In my review [1] I did ask authors to change all references to
> "[RFC]" to "Title [RFCxxx]" because that is easier for
people who
> do not have all 9000 RFC numbers to title mapping in their head

For what it's worth, I agree with this custom and have always wished
the RPC would change the citations to look like that when it makes
sense


I don't mind either form.  I just think we should use one form 
consistently throughout the document.


It would be awesome if xml2rfc did this automatically.


+1

This seems like something that should be select-able at document 
rendering time. Could turn it on when you visit rfc-editor.org to read a 
new (to you) RFC, leave it off when you're checking something you're 
familiar with.


Wrong forum, sorry...

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

[dmarc-ietf] Re: Dmarcbis.org

[Steven M Jones]

On 10/2/24 7:27 AM, Neil Anuskiewicz wrote:

I registered it defensively a while back but would happily turn it over to, 
say, dmarc.org or whomever.


Thanks for taking the thought to defensively register the domain.

And apologies to you, and to the several people who contacted me about 
this -- I'm the person responsible for the DMARC.org site. I've been 
under the weather the past few days due to a Covid+flu vaccination, but 
finally seem to be back on my feet.


As John mentioned, I'm not sure there's enough value or a great enough 
threat to continue the registration.


--S.


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

[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing

[Steven M Jones]

On 9/12/24 10:27, Alessandro Vesely wrote:



To me not much.  "provided the rfc5321.MailFrom was not altered" 
selects a part of forwarding.  What if it was altered?  If we want to 
be more explicit than implicit, we have to explain why the check 
likely fails in each case. 



Okay, so it seems like you would prefer either Option A, no mention:


As an example of this, a bank might send only targeted messages to

account holders. Those account holders might have given their bank

addresses such as jo...@alumni.example.edu (an address that relays

the messages to another address with a real mailbox) or

finance@association.example (a role-based address that does similar

relaying for the current head of finance at the association).When

such mail is delivered to the actual recipient mailbox, it will

necessarily fail SPF checks.DKIM signatures will generally remain valid

in these relay situations.



Or Option B, have some external reference. Do you have a candidate in mind?


--S.

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

[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing

[Steven M Jones]

On 9/10/24 5:06 AM, Scott Kitterman wrote:

On September 10, 2024 10:20:59 AM UTC, Alessandro Vesely  wrote:

Hmm...  there are relays that don't change the bounce address.  For such cases, the 
explanation of why SPF checks fail would be different...  I'd suggest removing the 
explanation (that is ", as the incoming ... the sending domain"). It should be 
well known by now that SPF breaks forwarding.


I don't think it's safe to assume people know this.  I  do think the point is 
worth addressing.  Perhaps adding (if the Mail From address is not rewritten by 
the relay) after necessarily fail SPF checks would address the point.



I agree that generally, if there's anyplace we should favor being more 
explicit than implicit, it's an IETF specification document.


Is a parenthetical like this too disruptive to the flow of the text?

When such mail is delivered to the actual recipient mailbox it will 
fail SPF checks (provided the rfc5321.MailFrom was not altered), as 
the sending IP address will be that of example.edu or 
association.example, and not an address authorized for the sending domain.


--S.

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

[dmarc-ietf] Re: Review of the dmarc draft documents

[Steven M Jones]

On 9/5/24 10:09 AM, Alessandro Vesely wrote:

On 04/09/2024 20:41, Daniel K. wrote:

On 7/30/24 17:18, Alessandro Vesely wrote:

On Mon 29/Jul/2024 23:46:15 +0200 Daniel K. wrote:

5) Overlap in the examples of dmarcbis and failure-reporting

With some wording differences that seem to stem from text being 
copied,

the worked on in one draft only.

Entire Domain, Monitoring Mode  vs.
Entire Domain, Monitoring Only, Per-Message Reports



They're both copied from rfc 7489.  They've been added in 
dmarcbis-31.  Should

we just remove them from one of the I-Ds?  Which one?


I suggest to keep all examples in dmarcbis. The companion documents can
then define their respective formats without carrying their own DMARC
Policy Record examples.



When we originally split the documents it wasn't clear to me just how 
much of the failure reporting content would be removed from the main 
specification, so I copied broadly. But it makes sense to have all the 
policy expression content in the main specification.



Daniel's pull request for the failure-reporting I-D removes a couple 
of appendixes:


...

Save for objections, I'm gonna merge it on the next occasion.



No objections here.


--S.


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

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Steven M Jones]

On 1/17/24 2:56 AM, Alessandro Vesely wrote:

[ Discussion of  what to do with multi-valued From: in messages ]

However, since DMARC bears the blame of banning multi-valued From:, it 
is appropriate for it to say something about the consequences and 
possible workarounds.


DMARC doesn't ban multi-valued From:, but the language of section 6.6.1 
is confusing because we were documenting the practice of implementers up 
to that time as much as being prescriptive. If anything, it highlights 
the need for the clearer language that Todd quoted earlier in this thread.


Has a measurable volume of legitimate messages with multi-valued From: 
headers been reported in the wild? Is there a real-world problem that 
needs to be solved?


--Steve.


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

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Steven M Jones]

On 1/11/24 10:46 AM, Murray S. Kucherawy wrote:


What I recall from when we wrote that was that the first paragraph 
really means "Most MTAs reject this anyway so it shouldn't even get to 
your DMARC filter" and the second means "If it does get to you, here's 
how you should probably react."



+1, matches my recollection.

--S.

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

Re: [dmarc-ietf] DMARCbis rev 29

[Steven M Jones]

On 12/1/23 11:14 AM, Dotzero wrote:


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



I further think that the best way to produce the next rev of
DMARCbis is for the chairs and the editors (and perhaps the ADs)
to huddle together and create/update issues in the Github
repository for the sections of text for which changes have been
proposed. At a minimum, the outcome of this meeting would be
several bullet points all following this pattern:

  * Create/update GitHub issue with $TITLE using text from
$MAILING_LIST_THREAD

Todd, as editor whose mail client isn't one that lends itself well
to piecing together multiple threads into a coherent list...


I never saw a response to this post to the list by Todd. As we reach 
the end of 2023 and the start of 2024, I agree that the chairs, AD and 
editors should address what issues are left to be addressed and/or 
need to be added to the list of on-topic open issues.



I think this would be helpful. 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?


Tracker link: 
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues


--Steve.

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

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

[Steven M Jones]

On 11/15/23 02:12, OLIVIER HUREAU wrote:


As mentioned here: 
https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/ 

I have found out that the current reporting ecosystem uses two types 
of XML Schema Definitions.


...

Upon investigation, I found that the XSD present in RFC 7489 Appendix 
C (https://datatracker.ietf.org/doc/html/rfc7489#appendix-C) contains 
a targetNamespace with the URI http://dmarc.org/dmarc-xml/0.1.
However, the website offers a different XSD. It seems plausible that 
implementers may have downloaded the version from dmarc.org, which 
lacks certain elements like /record/auth_result/spf/scope, 
/policy_published/fo, /record/identifiers/envelope_from, and /version, 
in contrast to the RFC version.



I can put an updated version on dmarc.org, but right now I'm trying to 
get out of a hotel room. probably 48 hours minimum before I can get to 
this, if somebody would be so kind as to identify the replacement.


--S.

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

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

[Steven M Jones]

On Nov 12, 2023, at 1:02 PM, Neil Anuskiewicz 
 wrote:
> 
> Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering 
> them worthless as nobody you’ve heard of will send them.

Even if that were to happen, the standardized format may continue in use / 
continue to be useful. And if I can scrape together enough spare minutes, I’ll 
get a reflector running again so that people implementing DMARC can send to an 
address that will definitely send failure reports when there’s a problem.

—S.


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

Re: [dmarc-ietf] Dmarcbis way forward

[Steven M Jones]

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.


--S.


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

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

[Steven M Jones]

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

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

[Steven M Jones]

On 10/25/23 4:25 AM, Matthäus Wander wrote:

Olivier Hureau wrote on 2023-10-25 12:56:
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.


As error reports have never gotten any traction, it would be a big 
effort to make this work. Reusing the existing ecosystem of aggregate 
reports is a lower hanging fruit.


Failure reports were actually sent for many years, and not just by small 
operators - NetEase and Hotmail were sending them between 2013 and 2018. 
And the reports had real value, even when heavily redacted.


GDPR and similar regulations are generally cited as causing the decline 
five years ago. There are still senders out there, but they tend to be 
small domains.


--S.

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

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

[Steven M Jones]

On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
(1) As written, the text says (to me) that the handling of a message 
might change depending on this mapping of a broken value to "none", 
but only if "rua" is present; absent "rua", the record is treated as 
junk and DMARC doesn't apply.


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.


Olivier's language comes close to this. But then Matt and Ale have 
continued with reporting...



Matt Wander wrote:

In the above case, the already existing (but not prominently known) 
optional  field in the  section can be used to 
include an error message, e.g., "syntax error in sp tag".


Text suggestion:
The Mail Receiver MAY utilize the optional "error" field in aggregate 
reports to announce syntax errors identified in the DMARC policy record.


+1


So then, maybe we wind up with something like this:

PROPOSED versus draft 28 section 4.7:


   If a retrieved policy record does not contain a valid "p" tag, or
   contains an "sp" or "np" tag that is not valid, then:

   *  The Mail Receiver MUST act as if a record containing "p=none" was
  retrieved and continue processing;

   *  The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
  in the optional "error" field of the informative section of the
  DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
 
   *  If there is no "rua" tag, or if it does not contain at least one

  syntactically valid reporting URI, the Mail Receiver effectively
  applies no DMARC processing to this message.


And if somebody wants to argue against including the third point, I 
would offer that it may be better to be explicit that to repeat this 
exercise in a future WG.



--S.

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

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

[Steven M Jones]

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


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



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


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


--S.


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

Re: [dmarc-ietf] Signaling MLMs

[Steven M Jones]

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:


The MLM can then decide if it is willing to pass the message 
unmodified to the list, or reject it with an error like "The policies 
of this list require modification of your message, which violates your 
domain's apparent policy.  Your submission therefore cannot be 
accepted.  Please contact your support organization for further 
assistance."  There's never an opportunity for the collateral bounce 
to occur if the message is never distributed, and the author domain 
has to either soften its policy or separate its regular users from its 
transactional stuff somehow.


This puts me in mind of Section 8.5, which calls out some potential 
impacts of blocking policies to "Mediators," which role doesn't 
otherwise appear very often in this document. Is there any need to add 
Mediator Actions/Considerations under section 5? Or does this belong in 
a separate document?


ISTR there were some vocal and visible mailing list operators that were 
rejecting messages from domains that published "p=reject" policies, 
maybe around 2014-15? I also thought they did this by checking the 
sending domain's published policy in DNS, to your point about 
implementation.


In which case I think this approach was tried, and I don't recall it 
persisting as a pain point for terribly long - perhaps they moved on to 
"unsavory mutations..."


In any case, are we really going to start suggesting that list operators 
start rejecting messages sent from domains that publish a blocking 
policy, as official guidance? (Now I'm looking ever so forward to 
catching up on these other threads - what the heck are people seeing out 
there??)



On 4/12/23 11:41 AM, Todd Herr wrote:

My preference here would be to add text for Domain Owners to make them 
understand the ways that p=reject might cause some mail using their 
domain to not make it to its destination, with "mailing lists might 
reject your mail" being one such example.
Yes, it seems like we'd either add something short to domain owner 
considerations per Todd, or we'd need to add considerably more to cover 
list operators and/or other Mediators.


--S.

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

Re: [dmarc-ietf] ARC Dependency?

[Steven M Jones]

On 3/24/23 3:48 AM, Douglas Foster wrote:


Do we know if any entity other than Google is successfully using ARC 
as an evaluation tool?



FWIW: In late 2021 a "German company" reported that it was able to 
"recover" about 10% of messages that had failed other authentication 
checks by validating ARC.


--S.


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

Re: [dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

[Steven M Jones]

On 3/14/23 13:18, Scott Kitterman wrote:

My expectation is that if you were able to contact the people who made that 
decision, they'd say they did it because they want information on DMARC 
failures, which is not what DMARC failure reports give you.  They provide 
details on messages which fail DMARC, not particularly about the DMARC failure.

The naming is a bit misleading, but I don't propose we change it.



Granted that you aren't proposing a change, I'm very curious as to what 
name you feel would be more accurate...


--S.


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

Re: [dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

[Steven M Jones]

On 3/12/23 07:50, John Levine wrote:


It also occurs to me that anyone who sends failure reports also sends
aggregate reports, so if you care, you have a way to find out.



This made me wonder if everybody requesting failure reports also 
requests aggregate reports, so I took a look at the data DomainTools 
shares with DMARC.org.


DMARC records that have RUF w/o RUA: 72,400+
  - 50k+ are two-component, e.g. example.org; 11k+ three-component
  - 28k are .com, 4.5 are .co, 4k are .nl, and 4.5k are .org or .net, etc

This is from all observed, valid DMARC records still available from DNS 
at the end of CY2022.


While this is a small percentage of all valid DMARC records observed at 
that point in time (about 0.1%), it is a much larger number than I would 
have expected before I checked.


--S.


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

[dmarc-ietf] PSL vs. Tree Walk and Failure Reports, was Re: DMARC agenda for IETF 116 -- and do we need one?

[Steven M Jones]

On 3/10/23 3:08 AM, Alessandro Vesely wrote:


although I'm back as an editor of the failure reporting I-D, that file 
is almost final and I can't think of anything to be discussed live 
about it.  I haven't registered for 116.



Off the top of my head, and in light of the aggregate reports getting a 
field for the method of determining the Organizational Domain -- should 
there be an optional field or provision for including this in a failure 
report?


Since it seems likely there are receivers who may reach different 
dispositions based on this change, I think we might want to consider a 
way to convey this for those who choose to send failure reports.


--S.


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

Re: [dmarc-ietf] Version in aggregate report

[Steven M Jones]

On 3/9/23 11:45, Tomki Camp wrote:
I think that's a good idea. Mike Jones from Fortra (ne Agari) also 
expressed concern during M3AAWG 57 about problems for data analysis to 
be able to determine how a specific receiver's result was achieved, 
with the discovery methodology doubling.
An XML indication specifying the approach that the receiver used 
should help allay that concern.



+1, including John's point about accommodating existing implementations.

--S.

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

Re: [dmarc-ietf] Missing participation from big tech members

[Steven M Jones]

On 11/19/22 19:13, Douglas Foster wrote:
> I note that I have no feedback reports from:

The best view of who participates in DMARC feedback reporting probably
lies with the report processors. Some of them will tell you who they are
getting reports from:

    https://dmarcian.com/dmarc-data-providers/

Outlook.com certainly appears to be providing aggregate reports, though
I haven't personally received one since September...

--S.


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

Re: [dmarc-ietf] Weak signatures

[Steven M Jones]

On 10/27/22 16:04, John Levine wrote:

It appears that Brotman, Alex  said:

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

...
There is no reason for DMARC to say anything at all about either
flavor of weak signature.



+1.

I was concerned we might be heading toward our own definition of "weak" 
when I replied. Doug seems to have clarified that it's (still) a purely 
receiver-side determination.


We should have language about keeping current with future updates to the 
DKIM base like RFC8301, but more than that and we'll be on an update 
treadmill.


--S.


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

Re: [dmarc-ietf] Weak signatures

[Steven M Jones]

On 10/26/22 16:45, Neil Anuskiewicz wrote:

On Oct 26, 2022, at 3:48 AM, Douglas Foster 
 wrote:


Murray first raised the issue of weak signatures.
...

Weak results need to be part of the aggregate report so that domain owners 
understand the importance of moving from weak to strong signatures.
...

- DAMRC Evaluation does not exit upon finding an aligned and verified weak 
signature.   Instead, the result is noted but the evaluation continues in hopes 
of finding an aligned and verified strong signature.

Strong defined as the strength of the encryption algorithm (i.e., key size).



And to be clear(er), any language talking about "strength" in terms of 
key size has to account for algorithm + key size, or you can get some 
incorrect treatment of e.g. elliptical curve signatures.



--S.


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

Re: [dmarc-ietf] Priming the Pump for Discussion - Ratchets

[Steven M Jones]

On 7/6/21 05:45, Todd Herr wrote:
>
> The theoretical goal of any domain owner that publishes a DMARC record
> is to transition from an initial policy of p=none to a final one of
> p=reject, because it is only at p=reject that DMARC's intended purpose
> of preventing same-domain spoofing can be fully realized.

While preventing impersonation of "high value" domains was the original
impetus for DMARC, and preventing same-domain spoofing is a/the core
benefit, it provides value for other use cases as well. For example, a
domain that doesn't currently see much abuse and has several indirect
mailflows (so "p=none"), but wants reporting as an "early warning
system" in case they're targeted later.

Broad applicability helps justify putting DMARC on the Standards Track,
so IMO we should be careful not to preclude other use cases, or give the
impression they aren't seen as valid.

--S.


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

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Steven M Jones]

On 6/14/21 10:09, Brotman, Alex wrote:
> Does this make everyone cringe, or perhaps worth a larger discussion?


This was considered (repeatedly) during the original DMARC work, and I
believe again while it was being put into RFC7489 form.

It was rejected because it increased the likelihood of broken/invalid
records for the overwhelming majority, while providing complexity that
relatively few senders wanted. And they could usually get what they
wanted by other means.

I would not be in favor of adding more complex policy expressions.

--S.



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

Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

[Steven M Jones]

On 5/31/21 15:49, Steven M Jones wrote:
> I think we can get the input needed to resolve this by Todd's requested
> deadline, and be able to show we did the due diligence to back up the
> decision.


I got three responses - unfortunately I discovered I don't have as many
of these contacts as I used to. So it's still anecdotal, but it includes
two of the (I don't know) dozen top mailbox providers in the world - for
whatever positive or negative weighting that may carry with you.

I'm about to add the following comment to the TRAC ticket:



I offered to try and get information on the frequency of use of this
feature from mailbox providers/report generators. I received three
responses, which I will rephrase to protect the sources. They can speak
up if they wish to go on the record.

1. Global mailbox provider A: Our code doesn't handle the syntax, and
will try to send to the address including the size specification. So if
you use that in your domain's RUA tag, our reports to you are probably
bouncing. There's a bug filed to fix it, but no commitment to do so.

2. Global mailbox provider B: We had the same bug, but fixed it - so
reports will be sent to the correct address. But regarding the limit, we
checked to see if anybody who specified a limit was receiving reports
large enough to trigger it, and nobody was. Large operators who might
actually trigger it, didn't specify a size. So we never implemented it.

3. National mailbox provider: I wrote code to implement it, but to my
knowledge it has never been triggered. Maybe our operation isn't big
enough. But implementing it was painful - guessing what the compressed
size would be, how to trim or truncate the report to fit the limit, who
to notify in the event of truncation and how... I would prefer removal,
but failing that please simplify it. [I can share the suggestions if we
go that way. --S.]



--Steve.


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

Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

[Steven M Jones]

I'm not philosophically or religiously opposed to removing the size
limit but I would like to have some data, or at least informed feedback,
to justify the decision.

This feature was not in the original December 2011 specification, but
was added in the March 2012 revision (both were pre-IETF). I'm betting
that was done because of first-hand operational issues, though of course
things have changed in ~10 years and it may no longer be necessary.

I appreciate Ale's anecdote that his size-limit code has never been
triggered, that kind of information is useful. I think the larger report
generators are the best place available to get this information, and I
will try to chase down people who can provide it this week.

I think we can get the input needed to resolve this by Todd's requested
deadline, and be able to show we did the due diligence to back up the
decision.

Thanks,
--S.

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

Re: [dmarc-ietf] Consensus Sought - Ticket #54 (Limits on recipients per report) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:46, Todd Herr wrote:
>
> Consensus on Ticket #54 
> (Remove or expand limits on number of recipients per report) was
> reached during the May 27 DMARC Interim to update the text in the
> DMARC URIs section to read:
>
> The place such URIs are specified (see Section 6.3
> 
> )
> allows a list of these to be provided. The list of URIs is
> separated by commas (ASCII 0x2c). A report SHOULD be sent to each
> listed URI provided in the DMARC record.
>
> This proposed change will be made in the next version of dmarcbis,
> scheduled for release in the next few weeks.


I support the change.

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

Re: [dmarc-ietf] Consensus Sought - Ticket #82 (Deprecate rf= and maybe fo= tag) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:47, Todd Herr wrote:
>
> Consensus on Ticket #82 
> (Deprecate rf= and maybe fo= tag) was reached during the May 27 DMARC
> Interim to remove the "rf" tag from the core spec and allow for the
> possibility that it could potentially be reintroduced, if needed, in
> the separate failure reporting spec. (The fo tag was not discussed
> during this part of the Interim).


I support moving the tag to either of the associated reporting
documents, if it is included anywhere.

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

Re: [dmarc-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:46, Todd Herr wrote:
>
> Consensus on Ticket #53 
> (Remove reporting message size chunking) was reached during the May 27
> DMARC Interim to remove the feature and update the IANA registry and
> ABNF grammar as necessary.


I support the removal, unless a report generator speaks up by June 11th
saying they support the feature.


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

Re: [dmarc-ietf] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:43, Todd Herr wrote:
>
> Consensus on Ticket #50 
> (Remove ri= tag) was reached during the May 27 DMARC Interim to remove
> the tag and update the IANA registry to reflect its removal.


I support removing the tag from the specification, but following TIm
Wisnewski suggestion to mark the tag as "historic" in the IANA registry.


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

Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:43, Todd Herr wrote:
>
> Consensus on Ticket #47 
> (Removal of "pct" tag) was reached during the May 27 DMARC Interim to
> keep the tag, but to rewrite its definition in whole or in part to
> make its usage better understood.


I support keeping the "pct=" tag in the specification.

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

Re: [dmarc-ietf] Consensus Sought - Ticket #4 (Definition of "fo" parameter) - With Interim Notes

[Steven M Jones]

On 5/28/21 08:43, Todd Herr wrote:
>
> Consensus on Ticket #4
> (Definition of "fo"
> parameter) was reached during the May 27 DMARC Interim to update the
> definition of the "fo" parameter with the following sentence, as shown
> in dmarcbis-01:
>
> The value of this tag is either "0", "1", or a colon-separated
> list of the options represented by alphabetic characters.
>
>
> It is understood from the discussion that ABNF for the "fo" tag will
> have to be updated, and this update will happen in the next version of
> dmarcbis, scheduled for release in the next few weeks.


I support the proposed change.

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Steven M Jones]

On 5/5/21 21:26, Seth Blank wrote:
>
> The Chairs ask group participants to explicitly speak up if:
> 1) they intend to participate in the interim
> or 2) they wish to participate in the interim, but the timing does not
> work


1) Intend to participate


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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Steven M Jones]

On 2/21/21 08:49, Chudow, Eric B CIV NSA DSAW (USA) wrote:
> I think it's getting better, but I wouldn't call them Internet Naming 
> Authorities. Should we just call them higher-level entities?

There are proper names for these actors - there's no need to be even
more vague ...


> Also, while the biggest help that PSD DMARC would make is for non-existent 
> organizational domains, it can also help with other domains that haven't 
> expressed a DMARC policy, so the abstract shouldn't only discuss unregistered 
> domains.

Except for the few cases where the registrar for a given TLD mandates
DMARC participation and/or certain policies, there should be no language
that sounds like /imposing/ DMARC on domains where the domain
owner/operator has not elected to do so. Loose language here will not be
received well.


--S.

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

Re: [dmarc-ietf] Forensic report loops are a problem

[Steven M Jones]

On 1/27/21 19:08, John R Levine wrote:
> On Wed, 27 Jan 2021, Murray S. Kucherawy wrote:
>>> I still don't understand why failure reports about messages that
>>> happen to be failure reports are in any way special.
>>
>> Loop detection in RFC 5321 is a normative MUST because of the obvious
>> operational problems it creates.  Maybe I'm being thick, but right now I
>> don't see how this is different, apart from the fact that each
>> message is
>> distinct; ...
>
> Here's perhaps another way to look at it.
>
> ...
>
> B) Someone slaps me upside the head and I fix my SPF record so my
> reports are sent correctly.
>
> This does not strike me as a hard problem.


It's not a hard problem. I see the last sentence in Section 3.3 as
reserving the right to deliver that slap...

--S.


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

Re: [dmarc-ietf] Forensic report loops are a problem

[Steven M Jones]

On 1/27/21 12:47, Murray S. Kucherawy wrote:
> On Wed, Jan 27, 2021 at 12:37 PM John Levine  > wrote:
>
> I still don't understand why failure reports about messages that
> happen to be failure reports are in any way special.
>
>
> Loop detection in RFC 5321 is a normative MUST because of the obvious
> operational problems it creates.  Maybe I'm being thick, but right now
> I don't see how this is different, apart from the fact that each
> message is distinct; you're still causing a problem by turning this on
> without a care in the world about whether two verifiers start spamming
> each other.


There's coverage in 7489 Section 7.2 that a domain owner can
inadvertently DDoS themselves via failure reports. And that still
surprised many implementers, even though it seemed obvious to them in
retrospect.

This case is even less obvious, and we still have questions coming in
about it from new implementers.

I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:


3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken for authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be mitigated
   by sending reports from a domain or subdomain that doesn't request
   reports, or by performing rate limiting for report receiving mailboxes.


--S.


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

Re: [dmarc-ietf] attack on reports

[Steven M Jones]

On 1/26/21 11:24, Michael Thomas wrote:
>
> Here's a very basic question: if I do not know all of the IP addresses
> that send on my behalf, are DMARC reports of any value?
>
No, an organization is not assumed to have perfect knowledge of all
their authorized sending sources. If that were common, there would have
been much less need for DMARC in the first place.

One of the primary goals of DMARC (IMO) is to help organizations
identify sending sources that have to be /investigated/. Some may be
vendors who were engaged outside the normal email operational processes,
most are likely just transient spam sources. But you won't know which is
which until you at least take a cursory look.

All of which requires those DMARC aggregate reports, and benefits from
failure reports if you can get them -- and that the domain owner, or
somebody acting on their behalf, *examines* those reports.

Organizations using email should have at least some policies and
procedures that cover all these things - and that is a very large topic
that this isn't the right place to explore. 


> Enterprises farm out email all of the time and it could be difficult
> to know when they change their server addresses, etc.
>
Yes, which is part of why even organizations that have gone through a
long deployment process and arrived at their desired "end state" find
value in continuing to receive and monitor reports. As you touch on,
vendors don't always tell you about such changes in advance.

You have to examine reports and, from time to time, take some action.

--S.


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

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

[Steven M Jones]

On 1/25/21 12:18 PM, Michael Thomas wrote:


On 1/25/21 12:08 PM, Todd Herr wrote:
On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote:



Sounds like a bug to me and an issue should be opened. Just
because it's
a 10 year old bug doesn't mean it's not a bug.


I disagree.

Authentication results should not differ at a given provider based 
solely on the destination domain, so there is no reason to report 
results separately for each destination domain. Further, there's no 
value to the report generators, especially at large sites like 
Google, to expend the resources necessary to generate and send X 
reports when one will do.


So you're saying I should be free to spoof any domain I want because 
Google might be inconvenienced?




If the language in 7.2.1.1 that Seth cited is "working," then report 
generators are sending reports that pass DMARC and the report receivers 
are validating that before ingesting the attached reports. However this 
only provides some degree of attribution for the report itself...


We can certainly check with report receivers to confirm that they are 
doing that validation, and perhaps get some measure of how often they 
see reports that don't pass. What does that leave us with?


Assuming 7.2.1.1 "works," reports that don't pass DMARC won't be 
processed, and won't cause the confusion and/or delayed implementation 
you cited as the potential harm.


That leaves reports that pass DMARC, sent from domains that haven't 
actually handled the sending domain's email. This sounds to me like 
reports that contain false data. Reports containing false data are 
identified as a security consideration in RFC7489 Section 12.2, without 
a reference to 7.2.1.1 as the suggested mitigation.


I don't see where additional authentication of the report itself can 
address this concern, given the availability of disposable domains. That 
leaves report receivers with the need to track report senders' 
reputation, which might warrant a mention in the revised spec.


What did I miss?

--S.


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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Steven M Jones]

On 1/20/21 15:10, Steven M Jones wrote:
>
> Duplicate reports to the same destination are not
> the base case


I may be an idiot, or at least too quick to hit Send. Since nobody
implements https:// yet, what does the transition look like? Likely two
URIs to the same report processor, using each method.

But I suspect the specification can deal with preferring one method over
the other when both are present and the report generator supports both.

--S.


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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Steven M Jones]

On 1/19/21 06:02, Todd Herr wrote:
> Picking up the thread on a ticket that was brought before the group
> pre-holidays and has lain fallow since the end of 2020...

Prompted me to read from the start of the thread through:

On 1/20/21 11:19, John R Levine wrote:
> On Wed, 20 Jan 2021, Alessandro Vesely wrote:
>> John's record looks more workable, but it's still fluffy:
>>
>> "v=DMARC1; p=none; rf=afrf;
>> rua=mailto:dmar...@abuse.net,https://dmreport.abuse.net/dmreport/;
>> ruf=mailto:dmar...@abuse.net";
>
> Whaddaya mean fluffy?  Try a PUT or POST to that URI and it'll work.


I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be
specified/permitted.

However I don't yet see a compelling case for the OR- syntax or a
separate "ruap" tag. Duplicate reports to the same destination are not
the base case, and the bandwidth for unintended duplicates will likely
be much smaller than, say, per-message DNS tree walks being discussed
elsewhere. Report processors annoyed by receiving duplicates can work
with the domain owners in question, and if that doesn't work they can
withdraw their report authorization record.

--S.


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

Re: [dmarc-ietf] Forensic report loops

[Steven M Jones]

On 1/13/21 20:29, Murray S. Kucherawy wrote:
>
> How are implementers dealing with forensic report loops?

The question of whether such a thing is actually ever seen in the wild
should be asked, if only to document that it was asked and answered. See
prior "this is a vanishingly small number who cares" discussions.

Channeling Dave, is it fair to just say the objective is: To ensure that
forensic reports do not ever cause the recipient of a forensic report to
generate another forensic report in response? Is that overly broad? Are
there other goals or conditions?


> Say I send a message from X to Y, whose DKIM signature fails.  Y sends
> me back a forensic report, whose DKIM signature also fails.  X sends a
> forensic report to Y, whose report fails, etc.  We need a way to break
> the loop.

Is there a functional or operational difference between aggregate and
forensic reports I'm not thinking of that would cause the solution for
one case to be unsuitable for the other? Or can we hope for a mechanism
that applies to all DMARC reports?


> Off the top of my head, a few options:
>
> 1) a new header field indicating "This is a forensic report, don't
> generate a forensic report about it."

Is there a reason somebody might use this new header in an abusive way?
Or include it in a forged forensic report to avoid exposure? Cue a 0.1%
of 0.1% sidebar...

Jumping ahead of those questions, would the new header have to be DKIM
signed by the report generator, and the entity /doing final delivery of
that report/ required to validate the DKIM signature(s) from the report
generator, and only generate a forensic report in response if this new
header is not present? Or if the signature didn't cover the new header?
Or if the signature couldn't be validated?

"Doing final delivery of that report" -- is that sufficient? Or, "any
entity processing the report and potentially generating a report in
response?"


> 2) some kind of token that's always in the Subject field of a DMARC
> forensic report.
DMARC forensic report Subject: lines aren't uniform, but the last time I
looked there was an awful lot of similarity. If that were tightened up a
little more, would an explicit token really be necessary?


> 3) always generate forensic reports as the null sender, and specify
> that forensic reports should never be generated in response to the
> null sender

I suppose that would meet the goal, but what would be lost along the
way? What keeps coming to mind is the advice I've seen to have your
bounce messages authenticate with DMARC - if a sender does that or is in
the process of implementing it, they might want whatever forensic
reports they could potentially get...

cf.
https://www.validity.com/how-to-authenticate-your-bounce-messages-with-dmarc/


--S.


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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Steven M Jones]

On 12/1/20 7:41 PM, Dave Crocker wrote:

On 12/1/2020 7:03 PM, Steven M Jones wrote:
Rather that the Domain Owner is *requesting* whatever the Receiver 
implements between rejecting the message and putting it in the inbox, 
and is willing to apply. 


Yes, but...

The premise that an author domain owner can, in any way, direct the 
message disposition decisions of a receiving system is simply false. 
It's false to a level of silliness, if one adequately considers the 
complete independence of the receiver from the domain owner.


Yes, you are absolutely right. But this is why I wrote "requesting" 
rather than "commanding (with all the guarantees King Canute had when he 
commanded the tide to halt)" -- the latter phrasing is just /slightly/ 
too ponderous even for me... Does "requesting" really imply control over 
the outcome, rather than the expression of a desire?



I'd frankly recommend changing the labels for these expressions, but 
expect folk to argue that there is too much installed base and 
operational history.


Ah, now maybe we're getting somewhere. But if you toss that notion out, 
you have to follow up with an example or two. Which labels, and changing 
them in what way?


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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Steven M Jones]

On 12/1/20 6:16 PM, John Levine wrote:

In article  you write:

On 12/1/20 4:16 PM, Douglas Foster wrote:

I have always assumed that p=quarantine and pct<>100 were included to
provide political cover for "Nervous Nellies" who were afraid to
enable p=reject.

p=none, p=quarantine, and the pct= option were all included so that
organizations could set policies according to their own risk/reward
evaluation, including changes to those evaluations over time.

Do you think there was a shared understanding of how p=quarantine
would be implemented? Put the mail in a spam folder? Put it in some
separate place that you can check? (Mimecast does that with some
dubious mail) Put it in the inbox with a warning label?


Not in the sense of, "All Receivers should do at least X for 
quarantine." Rather that the Domain Owner is requesting whatever the 
Receiver implements between rejecting the message and putting it in the 
inbox, and is willing to apply. Discussions of this nature usually 
included a recognition - if not a blunt statement - that the Receiver 
will do whatever they deem best in whatever situation was under 
consideration.


So even if the use case of a small Receiver without a quarantine 
function wasn't explicitly mentioned on this or that occasion, they 
would be covered under the, uhm, /force majeure/ clause of Receiver agency.


That "clause" came up a _lot_ ...

--S.


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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Steven M Jones]

On 12/1/20 4:16 PM, Douglas Foster wrote:


I have always assumed that p=quarantine and pct<>100 were included to 
provide political cover for "Nervous Nellies" who were afraid to 
enable p=reject.


p=none, p=quarantine, and the pct= option were all included so that 
organizations could set policies according to their own risk/reward 
evaluation, including changes to those evaluations over time.



Pct<>100 is pretty much similar.   A sender can specify pct=20, but 
that does not mean that I am going to allow spam into my system 80% of 
the time simply to make the sender happy.


I really hope no casual readers get the impression that DMARC bypasses 
spam filtering. DMARC evaluations are expected to be independent of spam 
evaluations. If there's any overlap here, perhaps it would be for DMARC 
(and/or underlying protocols) to provide reliable domain attribution to 
drive a local policy decision about filtering.



Leaving it deployed is a useful ruse to promote deployment.   I favor 
leaving both mechanisms in place.


While I deplore characterizing these policy elements as a "ruse," I 
agree that p=quarantine should be kept.


--S.


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

Re: [dmarc-ietf] Optional p= makes no sense

[Steven M Jones]

On 11/9/20 4:15 AM, Alessandro Vesely wrote:

On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote:


I'm pretty sure both cases would be invalid as DMARC policy records, 
in which case they should be ignored.



I don't think so.  The current draft says:

[...]



Oops - thank you for the gentle correction about absent "p=" tags in 
policy records, Ale.




On 11/9/20 6:05 AM, Dave Crocker wrote:

On 11/9/2020 4:15 AM, Alessandro Vesely wrote:
Invalid or repeated p= tags are a problem, but possibly they don't 
completely disqualify a record.



The concept of 'partial' disqualification points to the problem of 
trying to be subtle in specifications.


A specification should provide and demand simple details and simple 
handling of problems.



At least "clear and unambiguous" if we can't quite reach "simple."





[...]

Here, the simple rule should be:

 An invalid DMARC record MUST be treated as if no DMARC record is 
present. 



+1


--S.


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

Re: [dmarc-ietf] Announcing DMARCbis Editors

[Steven M Jones]

On 11/7/20 8:20 PM, Dave Crocker wrote:

On 11/7/2020 8:12 PM, Steven M Jones wrote:
that's why the policy option of "p=none" exists. Perhaps the use of 
the string "none," meaning "no change in handling," is too readily 
confused with "none" meaning "no policy?" Which is indeed an odd 
duck, a policy saying there is no policy...



Although the DMARC spec defines p=none as:


  none:  The Domain Owner requests no specific action be taken
 regarding delivery of messages.


This is rather tortured language that invites confusion.  Forgive me, 
but "requests no specific action" is a request that isn't a request.  
It has no real meaning.


What is actually intended is:

  "The Domain Owner is expressing no policy for action to be taken
   regarding delivery of the message."

d/



Fair point, the language could be improved - and by a lovely 
coincidence, I understand there's a group tasked with revising the spec. ;^)


Though I'm not convinced that it seems confusing when you read it in the 
context of the "quarantine" and "reject" options right below it...


--S.


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

Re: [dmarc-ietf] Announcing DMARCbis Editors

[Steven M Jones]

On 11/7/20 5:00 PM, Dave Crocker wrote:

On 11/7/2020 4:50 PM, Jim Fenton wrote:
If that last sentence is the consensus of the working group (and I 
see that the charter could be interpreted that policy is required), 
then fine. But I consider the reporting aspect to be useful even in 
the absence of policy assertion or enforcement, allow a domain owner 
to obtain information about recipients’ receipt of unauthenticated 
email from that domain.



DMARC can do 3 things:

   1. Define alignment and how to effect it

   2. Request receive-side disposition of non-aligned mail

   3. Request reporting.

DMARC does not have to do 2 or 3.  It can refrain from making a 
handling request and it can refrain from requesting reporting.


A claim that DMARC isn't DMARC unless there is policy seems an odd 
view, given p=none.



"p=none" is the defined _policy_ to get 1 and 3 without 2. That's how 
you set a _policy_ that allows you to request reporting without enforcement.


"p=none" allows Jim's desired use case to have reporting without a 
change in handling. Since it _is_ a policy, what Seth wrote ("DMARC does 
not function without policy.") is not in conflict with that use case.


Maybe changing that option to "none" from "monitoring" wasn't actually 
the best choice? But I'm not sure it would be wise to change it now, in 
light of the installed base...


--S.

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

Re: [dmarc-ietf] Announcing DMARCbis Editors

[Steven M Jones]

On 11/7/20 4:50 PM, Jim Fenton wrote:

On 5 Nov 2020, at 9:45, Seth Blank wrote:

[...]

To Todd's point, DMARC is a means of communicating policy between domain
owner and mail receiver regarding how to handle unauthenticated mail. 
DMARC

does not function without policy.


[...] But I consider the reporting aspect to be useful even in the 
absence of policy assertion or enforcement, allow a domain owner to 
obtain information about recipients’ receipt of unauthenticated email 
from that domain. I realize that RFC 7489 treats policy as the primary 
function and reporting as secondary, but this WG is about improving 
that specification, and I consider this to be an improvement.



I agree there is a great deal of value in reporting without 
"enforcement" -- that's why the policy option of "p=none" exists. 
Perhaps the use of the string "none," meaning "no change in handling," 
is too readily confused with "none" meaning "no policy?" Which is indeed 
an odd duck, a policy saying there is no policy...


Is there a problem with using the "p=" tag to signal the desire for 
reports without requesting a change in the processing of messages that 
don't get a DMARC "pass?"





[ Quoting Seth again: ]

If someone believes policy can be spun out into a separate draft, please
upload your suggestion as an I-D and we will discuss it.


That’s quite a bit of work for something that might very well be dead 
on arrival. I have outlined the portions of the specification that 
would go in the base specification and the portions that go into the 
policy document, and that should be sufficient to make this decision.



Okay, but what is the expected payoff from splitting it out? Does it 
make it easier to process and approve updates of the policy content 
separately from, say, the description of record discovery or Alignment 
concepts? Easier to pass muster for Standards Track? Are implementers 
currently confused and dissuaded by having policy details mixed with the 
other content?


If the benefits seem worthwhile, I could get behind the split - but 
there ought to be a clear benefit.



--S.


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

[dmarc-ietf] Separate policy spec, was Re: Optional p= makes no sense

[Steven M Jones]

I wanted to bring this topic into a visibly different thread, as it's 
really about further splitting up of the base DMARC document.



In digging through recent messages, I think I see what Ale meant. The 
topic was Jim Fenton's suggestion of splitting the policy section out 
into a separate document. This would be the relevant reference from 
Ale's message on Nov 5th, subject "Announcing DMARCbis Editors" - Ale is 
responding to Todd Herr in this snippet:



Moving discussion of policy to a second specification would render 
any base
specification to be no more than effectively a table of contents 
pointing
to other documents, which seems to me to be a pointless document to 
produce.



Operators who don't need policy, for example external report receivers 
who just want to publish verification records, would find the relevant 
info in the base spec.


A good point of Jim's proposal is that having policy in a separate 
spec, in the same manner as reports, avoids the unintended effect of 
classifying reports as a 2nd class, generally-not-used feature.


Alessandro: Correct me if I'm wrong, but it seems from this quotation 
that you were just constructing a case were a valid DMARC role (third 
party report receiver) would need to use the "base" spec (without policy 
content), and the reporting specs, without direct need for a 
separate/split-out "policy" spec.


While you have a point, I would think that any report receiver would 
need to reference that policy spec as soon as they receive a report and 
need to interpret it. In which case, I would need a more compelling 
reason or benefit to split the policy section out into a separate document.



With regard to the "Optional p= makes no sense" thread, I think the 
quotation with too-little context gave the impression of a different or 
larger issue.


--Steve.


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

Re: [dmarc-ietf] Optional p= makes no sense

[Steven M Jones]

On 11/7/20 5:09 AM, Douglas E. Foster wrote:
The report receiver verification step was referenced in the response. 
  This was the pointer:


https://tools.ietf.org/html/rfc7489#section-7.1.

It requires a DNS entry at: . 
_report._dmarc., type TXT, value "v=DMARC1"  (No other 
content is specified.)



Thank you Doug, I'm familiar with section 7.1.

I think the question of whether the "p=" tag is optional has been 
adequately addressed.



I'll respond to the other topic in this thread separately, with a 
subject line that reflects the topic.


--S.


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

Re: [dmarc-ietf] Optional p= makes no sense

[Steven M Jones]

On 11/7/20 1:11 AM, Alessandro Vesely wrote:

On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote:

On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote:

It makes no sense to allow "p=" missing.   Why would we suggest that 
all

existing implementations alter their code to tolerate additional
unnecessary complexity, rather than requiring domain administrators 
to key

a few more characters so that code changes will not be necessary?



Are there really implementations that choke on missing p=?

How about "v=DMARC1; p=none; p=quarantine;"?



I'm pretty sure both cases would be invalid as DMARC policy records, in 
which case they should be ignored. If an implementation is trying to do 
something with invalid records like these, particularly one with 
multiple "p=" tags, then that would be a problem.








I also don't understand this comment from Alessandro :

"Operators who don't need policy, for example external report 
receivers who just want to publish verification records, would find 
the relevant

info in the base spec." >>
There is only one policy record, published by the domain owner.  The 
DNS
record either suggests enforcement (p=quarantine, p=reject) or it 
does not

(p=none, p=missing, no DMARC record).


I can't speak for him, but I believe he's referring to the records 
that a
report consumer outside the authority of the domain at issue might 
publish,
as documented currently in 
https://tools.ietf.org/html/rfc7489#section-7.1.
In those cases where, for example, foo.com publishes a DMARC policy 
record
with a rua= value of say "repo...@bar.org", there must exist a TXT 
record

of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that
bar.org is consenting to receive these reports.



Exactly!  Dropping the requirement allows the definition of DMARC 
record to be unique.  Not a terrific gain, just a little simplification.



I'm not aware of any requirement for third party report receivers to 
publish a DMARC policy record for their domain, in order to operate as 
report receivers. If that's what you meant, Ale, can you tell us where 
it appears in RFC7489 or the -bis spec?



--S.


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

Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis

[Steven M Jones]

On 10/26/20 14:58, Tim Wicinski wrote:
>
> This starts a Call for Adoption for: DMARC-bis


I support adoption of the DMARCbis draft as a working group document.

(I realize you asked for objections, but you need some record of support
to proceed, don't you?)

--S.


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

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66

[Steven M Jones]

On 9/23/20 2:49 PM, Seth Blank wrote:


... the Chairs strongly believe that having rough consensus on clear 
definitions is key to progressing the bis effort effectively. We 
strongly agree with Dave Crocker's position here: 
https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/



Role definitions are useful, and indeed several appear in RFC7489 
section 3. (I'm surprised that Report Generator isn't there...)


I think that expanding those definitions _in the RFC_ would be useful to 
provide a stable reference and avoid confusion in related and subsequent 
documents, not to mention our discussions.




Should the spec be clear about ... what it means for each to 
participate partially and completely?


This sounds like, "You haven't really implemented DMARC unless you do 
all of X, Y, and Z and do them this way."


We should keep in mind that DMARC is a _cooperative_ endeavor outside 
the protocol evaluation - the Domain Owner _requests_ a particular 
treatment, they cannot coerce it. A Mail Receiver / mailbox provider may 
send reports to enable the Domain Owner to correct authentication 
issues, but they cannot compel it.*


Yet many of the discussions related to ticket 66 on- and off-list appear 
to arise from people thinking that they are entitled to dictate how 
other entities implement and/or use DMARC outside the protocol 
evaluation, and that is a recipe for disappointment. Guidance is 
perfectly reasonable, probably even helpful, but we aren't going to get 
very far with commandments and proscriptions unless the goal is to have 
them ignored.


 -1 to normative language in this sense
 +1 to guidance/suggestions, probably moreso in a BCP


 --S.


* Obviously certain parties _can_ compel behavior (AOL/VZN/Yahoo, 
Google, etc). But that ability wasn't created by DMARC, and such a 
capability will not be conferred in the other direction by DMARC.





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

Re: [dmarc-ietf] Meetecho at IETF 108

[Steven M Jones]

On 7/28/20 7:07 AM, Murray S. Kucherawy wrote:
If any of those of you who participated in today's working group 
session via the Meetecho interface have any thoughts ...  You can 
email the list, the chairs, or me with your thoughts.



Having to flip back and forth between the chat column and the 
queue/participant column was awkward. Assuming I didn't miss a setting: 
Why can't we have both shown? At least as an option on larger 
screens/windows/devices.


--S.


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

[dmarc-ietf] MUAs showing From: address field, was Re: DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

[Steven M Jones]

On 6/2/20 5:45 PM, Douglas E. Foster wrote:


As to visibility: The business world still runs on Microsoft Outlook, 
and **Outlook presents the From Address** when a message is read. So 
it is odd to assert that no one ever sees that data.


[Emphasis added]

Regarding this and a subsequent message in this thread from Ale, that 
may be true in the message body display, but usually not in folder 
views. Once the message is opened the body pane may show the full fields 
or not, but often a hasty or preoccupied user is busy reading and 
engaging with the content, and it's too late.


Also, I believe this is relatively recent behavior for Outlook. My 
recollection is that for many years Outlook was notorious for only 
showing the display name (or perhaps in some cases certain Active 
Directory fields it looked up) even in the body view. This has changed 
at some point but I believe it was true during the original DMARC 
effort, and I believe it was still true while this WG was working on the 
drafts that led to RFC7489.


However, the versions of Outlook I just checked (Outlook/macOS and 
Outlook Web Access) do show both rfc5322.From display name and address 
field in the body view  some of the time, perhaps most of the time -- 
but not all of the time. Viewing two messages from the same mailing list 
in OWA, one showed both fields and one only showed the display name. 
Window size did not appear to be a factor. The same applied for a 
periodic message sent from a vendor - both fields displayed in 
Outlook/macOS, only the display name in OWA.


And consider the fact that today mobile devices are the MUA of choice 
for many/most end users. Mobile MUAs are much less likely to show an 
rfc5322.From address field even in the message body view.


--S.



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

Re: [dmarc-ietf] More redacted RUF reports better than no RUF reports

[Steven M Jones]

On 6/11/20 5:22 PM, Scott Kitterman wrote:

On June 11, 2020 6:28:13 PM UTC, Steven M Jones  wrote:
... I also suggested that perhaps potential failure report generators
would be encouraged if they could see examples of reports with
different levels of redaction.


I think it's entirely sensible to assess demand before investing a lot of time 
in this.  ...  I think the real question on this issue is for receivers.  Is 
there anyone working that side of the equation that would be inspired to send 
some kind of limited feedback report where they send none now is they had 
clearer examples to work from.



I should have said "I speculated," I suppose... While listening to 
Autumn I couldn't recall having seen such examples, so I threw the idea 
out there.


Anyway yes, we should be guided by data where we can get it. But if 
we're looking for something better than "anecdata," at the moment I can 
only imagine getting that through a careful survey of a large number of 
non-reporting receivers. And I don't see that happening unless it covers 
a lot more questions than just whether examples of redacted failure 
reports would have changed the decision not to send failure reports...


If there's no sense that it would be useful, no need for further discussion.

--S.


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

[dmarc-ietf] More redacted RUF reports better than no RUF reports

[Steven M Jones]

In the WG Interim Session, I had given a "+1" to Autumn Tyr-Salvia's 
comment about redacted failure reports being better than no failure reports.


I also suggested that perhaps potential failure report generators would 
be encouraged if they could see examples of reports with different 
levels of redaction. This would be as opposed to only seeing "reports 
SHOULD include as much of the message and message header as is 
reasonable" in RFC7489 section 7.3, and deciding to avoid a potential 
headache.


Whether these examples would best be delivered through the DMARCbis 
appendix, the DMARC Usage draft (currently "parked"), or an effort more 
aligned with the ARF family of specs, I am not sure.


If there's a desire to see this, I'm willing to try to put something 
together.


--S.


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

Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement

[Steven M Jones]

On 05/21/2020 14:11, Scott Kitterman wrote:

Also, I don't see a problem with making the p= tag optional (with an inferred
value of None if not present).  This is consistent with an existing SHOULD in
RFC 7489 and appears to be broadly supported in existing implementations.


Wow, did I miss/forget this proposal earlier in this thread? IMO this 
change should not be buried as a side-discussion, it should have it's 
own ticket (assuming it doesn't already) to raise visibility and record 
a proper discussion/decision.


--S.

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

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

[Steven M Jones]

On 05/15/2020 13:16, Scott Kitterman wrote:


When there is only one report format, there's no need to discover a common
format between report senders and report receivers.  As soon as there are two,
then to be interoperable, then either both report formats are required or
there has to be some kind of discovery mechanism, because we don't want report
senders sending reports in a format the receiver can't parse.


And every time we add another flag or k/v pair we're adding another way 
for the domain owner/manager to screw up and invalidate their published 
policy.


Something to bear in mind throughout these deliberations.

--S.

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

Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?

[Steven M Jones]

On 05/15/2020 11:26, Seth Blank wrote:

https://trac.ietf.org/trac/dmarc/ticket/69

Aggregate reports are only sent in XML format. There's been some 
discussion (that's also related to 
https://trac.ietf.org/trac/dmarc/ticket/42 about expanding reporting 
functionality beyond mailto:), of adding additional reporting formats, 
specifically JSON.


Should we consider adding JSON formatting to DMARC?


I don't see the benefit. Can anybody make that case?

More overhead to maintain, more opportunity for errors. Does adding JSON 
somehow eliminate the anecdotes about report generators who have issues 
with their XML output? Any reason to think that wouldn't also happen 
with JSON?


Does adding JSON reporting solve one of the other open tickets?

--S.

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

[dmarc-ietf] draft-ietf-dmarc-arc-usage-08 published

[Steven M Jones]

This document is officially in "Parked WG Document" state while we focus 
on other matters, but it seemed worthwhile to keep it from expiring.


One typo noticed after the last update in April was corrected.

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

Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

[Steven M Jones]

On 11/07/2018 11:41 PM, Scott Kitterman wrote:

I'd suggest we adopt the draft/work item and then try to figure it out.


+1. We should see where we can get with this topic.

--S.



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

[dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted

[Steven M Jones]

Greetings,

I've submitted the changes to the "ARC Usage" I-D that I had on-hand, 
primarily because the previous version was going to expire on October 
25th, and the I-D freeze for IETF103 was going to occur this evening. 
That deadline was extended by 24 hours, but I opted not to push it 
(further)...


Consider this a reminder that your questions and suggestions are welcome.

New version: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-06
Diff from -05 to -06: 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-06.txt


Yes, I know I missed updating a couple things. Yes, some formatting is 
off because I uploaded the XML instead of the TXT version. We'll fix 'em 
in the next rev.


Thanks,
--Steve.


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

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16

[Steven M Jones]

It's been quite a while since my last full read-through of the spec, so 
apologies if I blunder into anything long-settled. And apologies if I'm 
repeating something from earlier commentary, I'm trying to get in under 
a very liberal interpretation of the deadline as is... ;)




Love the way Section 2 introduces and describes the basics.


Section 3.1 - I would suggest "the three header fields /from a 
particular Internet Mail Handler/ compose a single ARC Set." (Addition 
in /slashes/.) Best to be explicit that ARC sets are organized by 
(outdated term) ARC Intermediary. Or "Sealer," but that would be a 
forward reference...  But without this, the reader might be left 
scratching their head until Section 5.1 makes it clear that an ARC Set 
is created by a single entity.



Section 4.2 - I would suggest "An `ARC Set` is a single collection of 
three ARC Headers (AAR, AMS, and AS) /from a single ARC Sealer/." Same 
reasoning as previous.



Section 4.3 - Typo, "AS header fields allow messages handlers" - 
"messages" should lose the trailing "s" (or I suppose it could be 
modified to "allow a message's handlers" if that's what was intended...)



Section 5.2 Step 1 -- Because of the preceding reference to maximum 
number of ARC Sets, rephrase for clarity at the end, "In the following 
algorithm, the /highest instance value ("i=") present in the ARC being 
processed is referred to as `N.`/"




That's it. Great work -- what a long way this has come since oar-dev 
started up in 2014!

--Steve.




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

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Steven M Jones]

On 3/19/18 2:02 PM, Yasutaka, Genki | Dkim | OPS wrote:
>
>
> You can download from the following link.
>
> https://datatracker.ietf.org/meeting/agenda.html
>
> - Virtual DMARC: DMARC verification without record definitions
>
> I will send you directly just in case.
>

Thank you, I found it -- I had used the "download meeting materials as
PDF" link, which didn't include either slide deck, but I found the
slides under the "Show meeting materials" link.

To the list, in the (unlikely?) event I'm not the only one...

--S.

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

Re: [dmarc-ietf] [Request] Presentation in IETF101

[Steven M Jones]

I want to thank Yasutaka san for presenting the Virtual DMARC proposal. 
I believe the situation he and his colleagues are addressing would 
benefit from more attention.


The meeting materials at IETF do not seem to include Yasutaka san's 
slides. If I didn't just miss it, would it be possible to share that 
presentation?


Aside from changes to the "dmarc=" allowed values in 
Authentication-Results: - and I think this echos a point made during the 
session - the underlying issue seems to be the use of DMARC-style 
alignment checks in the absence of a DMARC policy record.


That practice may be useful to the receiver's evaluation of SPF and DKIM 
results. Perhaps that should be explored as a receiver/authenticator 
best practice. It may be _very_ useful to capture these statistics to 
make it clearer to domain-owners/senders that more current email traffic 
would pass DMARC checks than they may presently realize. I would 
definitely like to explore that further.


But DMARC is based on cooperation between domain-owner/sender and 
authenticator/receiver. And it depends on the explicit 
opt-in/request-for-treatment from the domain-owner, signaled by a public 
DNS record, and the reporting mechanisms so that the domain-owner/sender 
can correct errors in implementation of authentication measures.


Virtual DMARC seems to be discussing only what happens within the 
authenticator/receiver, but perhaps I have missed this part. I look 
forward to re-reading the proposal and slides with this in mind.


--Steve.

Steve Jones
DMARC.org, LinkedIn, crash.com, etc.

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

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

[Steven M Jones]

On 3/15/18 10:19 AM, Kurt Andersen (b) wrote:
> Two more items for discussion (coming from a chat that I had with some
> of the NCSC folks today):

Thanks for sharing their input.


>   * Creating a diagnostic report that would have some additional
> information (such as sending address) and URLs without going quite
> as far as a forensic report - so something between the aggregate
> and forensic levels
>

I'm probably missing something, but -- aren't email addresses usually
classed as PII in the EU, whether they're sending or receiving at the
moment? Seems to me it would run afoul of the privacy regs that tend to
rule out forensic reports in certain jurisdictions...

Maybe there's a batch/aggregate angle vs.  per-message that helps avoid
that concern? Would time and URLs alone be useful enough to warrant the
effort and expense?

--S.

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

Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains

[Steven M Jones]

Hullo Ian, good to hear from you.

Interesting observations with gov.uk. I confess I'm unclear on expected 
behavior for DMARC policies published at a label listed in the PSL 
itself, but this is certainly the right place to ask. And maybe there 
are some heuristics operating in the local policy space at receivers 
that need to be updated in light of last year's UK policy announcements...


--Steve.

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

Re: [dmarc-ietf] ARC Experimental goals

[Steven M Jones]

On 07/22/2017 12:36 AM, Tim Draegen wrote:
> Why not pipe what is learned directly into a BCP.. you know.. in real time?

Hmm, perhaps some kind of "feedback report" could be used... ;)

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

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

[Steven M Jones]

On 07/18/2017 01:00 PM, Kurt Andersen wrote:
>
> We've suggested (during M3AAWG sessions) that smaller recipients can
> build out a whitelist of "commonly seen" mediators, but might there be
> value in having a mediator publish some sort of DNS record that would
> indicate that they ARC seal mediated traffic?

That whitelist - if I'm not confused - is used by the small/medium
receiver to identify ARC intermediaries whose ARC-sealed authentication
information they can take as accurate. In other words, that they can
_trust_ ARC information from those intermediaries... It's the stand-in
for the sophisticated reputation systems that the large receivers
already have.

The problems with self-identifying oneself as trustworthy are pretty
clear...


I'm missing what the other use for this information would be. What's the
result of plugging this information into the small/medium receiver's
filters?

--S.

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

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

[Steven M Jones]

On 07/18/2017 01:00 PM, Kurt Andersen wrote:
>
> We've suggested (during M3AAWG sessions) that smaller recipients can
> build out a whitelist of "commonly seen" mediators, but might there be
> value in having a mediator publish some sort of DNS record that would
> indicate that they ARC seal mediated traffic?

That whitelist - if I'm not confused - is used by the small/medium
receiver to identify ARC intermediaries whose ARC-sealed authentication
information they can take as accurate. In other words, that they can
_trust_ ARC information from those intermediaries... It's the stand-in
for the sophisticated reputation systems that the large receivers
already have.

The problems with self-identifying oneself as trustworthy are pretty
clear...


I'm missing what the other use for this information would be. What's the
result of plugging this information into the small/medium receiver's
filters?

--S.

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

Re: [dmarc-ietf] ARC RFC status to target

[Steven M Jones]

On 07/07/2017 12:12, Andrew Sullivan wrote:
> On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote:
>> Would there be a proposed schedule for that evaluation to take place?
> It's a good question, but I have two responses:
>
> 1.  IETF timelines are worth approximately what one pays for them :)

:D


> 2.  The lack of criteria by which to evaluate the experiment was
> itself one of the reasons offered for not undertaking a move from
> experimental sooner.  So not having the criteria will do nothing to
> prevent the dragging on.  (Of course, not classifying as experimental
> _will_ prevent that dragging on, but comes with the downsides that
> Dave was suggesting.)

I may be misreading your response, but I wasn't suggesting a timeline
without criteria. I would hope to see criteria and a provisional
timeline for when to apply them. "A, B, and C will be tracked and
evaluated at IETF 101, next move to be decided then" or something
vaguely similar.

Perhaps the criteria would be included in the RFC, and the review would
be added to the WG's work items? I'm not sure how it's usually done...
Do Experimental RFCs ever get expiration dates as a forcing function,
the way Internet Drafts do?

--S.

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

Re: [dmarc-ietf] ARC RFC status to target

[Steven M Jones]

On 7/7/17 11:29 AM, Andrew Sullivan wrote:
> On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote:
>> Experimental status is exactly for this purpose.
> I always feel like experimental status ought to come with some
> description of what success or failure would mean and how that would
> be determined.

Would there be a proposed schedule for that evaluation to take place? I
don't so much disagree with the description of how Experimental status
/should/ work, and including evaluation criteria would make sense. But
I'm not thrilled with the idea of ARC being left on the Experimental
track for umpteen years...

--S.

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

[dmarc-ietf] Anybody new for a possible interop in Lisbon, week of M3AAWG?

[Steven M Jones]

>From time to time we've organized interoperability testing sessions for
ARC implementers. We have the opportunity to hold one the week of the
M3AAWG meeting in Lisbon, Portugal in June.

Is there anybody who hadn't previously raised their hand as an
implementer, who has or is developing an implementation and would want
to participate in such a test? We haven't had one in Europe before, and
it's not clear when such an opportunity might arise again. So if it's
something you wish to see happen, please speak up.

Thanks,
--Steve.


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

Re: [dmarc-ietf] ARC-Authentication-Results

[Steven M Jones]

On 04/03/2017 19:04, Steven M Jones wrote:
>
> Results/claims by prior ARC participants in a given message are
> recorded in their own ARC set ("i=N"), which they signed. Those are
> verified and signed by subsequent ARC participants.

Excuse me, too imprecise. "Those signatures are verified and all prior
ARC sets are signed by subsequent ARC participants."The subsequent ARC
participants cannot verify prior ARC participants' results/claims.

--S.

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

Re: [dmarc-ietf] ARC-Authentication-Results

[Steven M Jones]

On 04/03/2017 17:42, Murray S. Kucherawy wrote:
> On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones  <mailto:s...@crash.com>> wrote:
>
> My POV, there is a strong 1:1 correlation between a set of ARC
> headers and a given ADMD. In this world view, the A-A-R would
> *not* collect all A-R values from all preceding ADMDs.
>
>
> It depends on what the goal is.  If you only want to record what the
> ADMD itself directly evaluated, your proposal is fine.  If you want to
> record what the ADMD thinks prior ADMDs claimed (e.g., GMail saying
> "Yahoo! claims this was fine when they got it"), then we must go deeper.

Results/claims by prior ARC participants in a given message are recorded
in their own ARC set ("i=N"), which they signed. Those are verified and
signed by subsequent ARC participants. This is how an intact ARC chain
provides the authentication results as observed by all/prior ARC
participants. The 2nd/3rd/Nth ARC participant is not saying "I believe
and trust the prior participants," just that "the signature(s) verified,
and I can tell you what I saw re: authentication when I was receiving
the message from hop N-1."

By contrast (and referring back to the start of the thread) I think it
would be unwise to include random A-R payloads one extracts from inbound
messages. Anybody handling the message can inject a random A-R. Trying
to extract only DKIM signed A-R headers from those messages can be
difficult - for example, because the correct inbound authserv-id for an
ADMD may not be clear to subsequent ADMDs, and where alterations may
have subsequently occurred in transit that break the signatures or
remove an A-R.


--S.

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

Re: [dmarc-ietf] ARC-Authentication-Results

[Steven M Jones]

On 04/03/2017 16:49, Murray S. Kucherawy wrote:
> The latest ARC base document says this about the
> ARC-Authentication-Results field:
>
>ARC-Authentication-Results is a direct copy of the Authentication-
>Results header field [RFC7601 ] 
> created for archival purposes by the
>each MTA outside of the trust boundary of the originating system
>which is contributing to the chain of ARC header fields.  The
>corresponding instance ("i=") tag value MUST be prefixed to the
>Authentication-Results.
>
> Apart from the grammatical glitch ("the each"), this appears to me to
> be saying:  "Collect the contents of the A-R fields that already exist
> and re-record those results into a new A-A-R field."
>
> Should that include the results computed by the ADMD that's doing this
> work?

My POV, there is a strong 1:1 correlation between a set of ARC headers
and a given ADMD. In this world view, the A-A-R would *not* collect all
A-R values from all preceding ADMDs.

The A-A-R attached by a given ADMD is meant to include the A-R value
computed by that ADMD during receipt/validation of the message in
question. So I would suggest language more like the following for
5.1.3's first paragraph:

"ARC-Authentication-Results is a copy of the Authentication-Results
header field [RFC7601] created during the receipt/validation of the
message by an ADMD from a source external to that ADMD. In other
words, a message is received by an ADMD and has an A-R computed and
attached to the message. When an ADMD is creating an A-A-R, it takes
the contents of the A-R header created by the same ADMD, prefixes it
with the appropriate instance ("i=") tag value, and records it in
the A-A-R."


This probably needs language to handle the case where a given ADMD
creates multiple A-R headers, at minimum. But before tackling that,
let's have any objections to the general sense of the above paragraph,
or the assertions before it?

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

Re: [dmarc-ietf] Section [5.2.1] of the ARC draft

[Steven M Jones]

On 01/20/2017 11:23, Scott Kitterman wrote:
>
> I'm not on the ARC list, so I'll pile on this thread here...

This is the right place for anything constructive regarding the
specification, so no problem regarding any other lists.


> I understand the minimum key size in the draft is 512 bits.  I'm not planning 
> on releasing any software that supports key sizes less than 1024, so I 
> guarantee you interoperability problems for small keys.

+1 -- no need for weak keys.

1) Do we have a normative reference within the RFC framework for key
lengths for different crypto systems, and can we simply invoke that
reference rather than including a hard figure in this spec?

2) Does such a reference still consider 1k keys as acceptable at this
time? Is there a schedule for periodic review?

--S.


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

Re: [dmarc-ietf] ARC Interoperability testing Friday, Dec 16th

[Steven M Jones]

On 12/29/2016 15:15, Barry Leiba wrote:
> Steve, can you give us a brief report on how this went?

A very brief report, yes - because it turned out that three of four
implementations would have no representatives available at that time, so
the testing did not in fact happen. My apologies for not reporting that
at the time, but I was busy coming down with the flu.

Speaking for myself, I didn't think it would take this long to pull the
implementations together - which is unfair given that I'm not writing
one... We had originally thought to collect a test corpus as an output
of the live test sessions, because we thought this would all be pretty
easy. But while some sample messages were shared from session to
session, nobody produced a comprehensive set as implementations were
found to be incomplete, or buggy, etc..

In the most recent conversation I had with Murray Kucherawy, around the
14th, we discussed just picking an implementation and producing such a
corpus. Publish the keys, the input and output messages, and maybe the
intermediate stages like canonicalized hashes, and allow the various
implementers to run that against their code off-line. They could then
take a stab at determining if there was a bug (and on which side), or a
vague point in the spec, without having to coordinate schedules.

Where is said corpus? See previous comment about flu, and the holidays.

That's the current status. Thanks for reminding me about this open work
item.

--Steve.


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

[dmarc-ietf] Changes to ARC specification re: A-A-R header

[Steven M Jones]

An ARC implementer recently pointed out that the rationale for capturing
the contents of the Authentication-Results: header in the
ARC-Authentication-Results: header wasn't clear from reading the
specification. So I'd like to propose some changes to the draft
specification to address this point.

Apologies if my method of suggesting/describing changes is out of order
- redirects welcomed.


Section 1 "Introduction" --

First paragraph, first sentence, change "non-compliant messages" to
"handling messages that fail to authenticate."

Split the existing first paragraph; make the last three sentences a
separate paragraph, starting with "This specification defines..."

Modify the second sentence of the new second paragraph to append, ", and
preserve the contents of the Authentication-Results: header created by
ARC-aware intermediaries."

Replace the last paragraph of the section with the following:

> Another goal is to capture and convey the contents of the
> Authentication-Results (A-R) mechanism [RFC7601] as seen by
> intermediaries in indirect mailflows. Normally A-R permits the results
> of an email authentication evaluation process to be transmitted from
> the evaluating agent (e.g. an MTA) to a consumer that makes use of the
> information (e.g. a filtering mechanism or MUA). A-R is usually only
> used this way within a given ADMD, but ARC can reliably convey the
> contents of the A-R header that each ARC-aware intermediary generates
> between ADMDs. The final message receiver may choose to use this
> information from valid ARC chains - particularly the A-R contents
> recorded by the first ARC-aware intermediary - in evaluating messages
> that fail to authenticate through direct checks of protocols like
> DKIM, DMARC, or SPF.
>
> For more detailed examples of when and how A-A-R contents might be
> used by message receivers, please refer to [ARC-USAGE].
>


Section 2.3 "Utility" --

Append the following to the first sentence: "..., including the
authentication results observed by each ARC-aware intermediary."


Section 4 "Overview" --

Append the following to the first sentence of the second paragraph: "...
and any authentication results they evaluated when receiving the message."


Section 5.1.3's first paragraph is a bit awkward. I'd like to propose
the following replacement text for changes:

> ARC-Authentication-Results (AAR) is a copy of the contents of the
> Authentication-Results: header [RFC7601] as generated by the ADMD
> creating this set of ARC headers. That is, it captures the
> authentication results that the reporting ADMD observed when it
> received the message from another ADMD. 

I recommend striking the second paragraph (sentence) in this section
about the "i=" tag -- the same exact text appears in the following
5.1.3.1 "`i' Tag Value"



--Steve.

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

[dmarc-ietf] ARC Interoperability testing Friday, Dec 16th

[Steven M Jones]

Do you have an ARC implementation? Have you tried testing it against
somebody else's implementation? If not, you should join our testing
event Friday of this week! No travel required, we'll be sending messages
between implementations while on a conference bridge. Video optional.

If you have an implementation of ARC in your product or service, contact
me off-list. I'll add you to the list of interop participants, and
you'll receive details for this and future testing events.

Thanks,
--Steve.

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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

[Steven M Jones]

Hello Marco,

Interesting proposal, from a five minute skim via cell phone. Have any mailbox 
providers or report generators shared their views on the incremental overhead 
of having to track this kind if interval timer for each sending domain that 
experiences an authentication failure, versus what may currently be a "fire and 
forget" arrangement now?

I look forward to a longer review on a larger screen. :)

--Steve. 



Sent from my iPhone

> On Nov 24, 2016, at 18:51, Marco Davids (IETF IMAP)  
> wrote:
> 
> Dear community,
> 
> I hereby request feedback and support for draft-davids-dmarc-fi-tag.
> 
> Problem:
> 
> Per-message failure reports as requested by the "ruf" tag are a useful
> source of information when debugging deployments or in analyzing attacks.
> 
> However, under certain circumstances this property can potentially lead
> to an undesirably high volume of reports.  Especially when a Domain
> Owner's name is spoofed and abused in a large-scale phishing or other
> impersonation attack.
> 
> RFC7489 offers only a very limited solution to this problem (in section
> 7.3).
> 
> The lack of a mechanism for a Domain Owner to influence the volume of
> reports constitutes an obstacle to deployment of the "ruf" tag feature.
> 
> Solution:
> 
> In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It
> provides a Domain Owner with a simple way of requesting limitation of
> the rate at which such reports are sent.
> 
> Please let me know what you think of it. I'm looking forward to a
> fruitful discussion on the design choices I made and I also hope for
> support of the idea.
> 
> Thanks.
> 
> The draft can be found here:
> 
> https://datatracker.ietf.org/doc/draft-davids-dmarc-fi-tag/
> 
> -- 
> Marco Davids
> SIDN Labs
> 
> ___
> 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] draft-kucherawy-dmarc-rcpts

[Steven M Jones]

On 11/12/2016 22:50, Murray S. Kucherawy wrote:
> I've posted a draft that attempts to address an attack that's begun to
> appear with DKIM.  Interestingly, we called it out as a possible
> attack in RFC6376 and even RFC4871, but now it's apparently happening
> and being annoying enough that people (I believe from the MAAWG
> community) are asking if there's a protocol solution that's possible.
>
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
>
> Comments welcome.

Thanks for codifying this proposal Murray.

So per Section 5, this form of DKIM signature will fail to verify at a
receiver who doesn't implement the new feature, period. And in fact any
forwarding - whether it alters the RFC5322 message or not - would
produce a DKIM verification failure at the next/final recipient.

The language in Section 5 paragraph 3 seems to cover envelope splitting.
Should this be expanded to address origin ADMD infrastructure such as
split signer/MTA, analogous to the note about split MTA/verifier at the
receiving ADMD in paragraph 4?

Are there any usage guidelines or recommendations about how and when to
use the new signing feature that I missed? For example is there another
draft, or a thread in a different forum/list, that speaks to this? If it
doesn't exist, do we need to create one? (Ulp - did I just volunteer?)

I'd be curious to get feedback from folks who aren't enamored of ARC,
but understand the motivating abuse...

Thanks,
--Steve.


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

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

[Steven M Jones]

A lot of points have been raised (again) in this thread - and I was only
looking at what went to the DMARC WG list, forgetting that of course
somebody would continue/branch the conversation by only using the
ietf@ietf list...

John Klensin highlighted a fundamental issue when he mentioned "the
privacy advantages of hard-to-trace message origins." The
assumption/decision that we want to keep that feature of existing email
protocols - but still try to identify bad actors - is what started us
down the road from SPF, to DomainKeys, to DKIM/SSP/ADSP, to DMARC.

Are we going to revisit that assumption/decision? If not, we'd better
look at how to make DMARC something we can all live with...

Are we going to try and extend DMARC with something like an ATPS that
scales? Is there an intersection of ATPS and ARC that might meet the need?

--S.


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

[dmarc-ietf] ARC: Syntax for ARC-Authentication Results header

[Steven M Jones]

I've noticed that one ARC implementation in development does *not* use a
semi-colon delimiter after the prefixed "i=N" sequence tag in the
ARC-Authentication-Results: header, but does use it in the other two.
This is probably just a bug, but it prompted me to check the spec.

In section 5 of the current draft ARC spec, I couldn't find any mention
one way or another about this delimiter. (And there's no ABNF, for
whatever that's worth.) However if you check the examples in the
appendix, I think every example has this delimiter in all three ARC
headers, in each set of ARC headers for "multi-hop" examples.

The use of the semi-colon is a little different under RFC7601
(Authentication-Results:), in that the semicolon separates "clauses" or
"phrases" as opposed to the tag/value pairs within each clause. (And the
authserv-id generally isn't a tag/value pair.)  But I don't see any
problem with the ARC "i=N" sequence tag/value being treated as a
separate pre-pended clause, so long as it properly references RFC7601 in
the spec.

Any thoughts on this? Any other areas that need to be tightened up in
the ARC draft spec??

Thanks,
--Steve.

-- 
Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com


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

[dmarc-ietf] ARC Interoperability testing event this Friday, 9/23

[Steven M Jones]

Have an implementation of the ARC protocol? We will be holding an
interoperability testing event this Friday, 9/23, between 9 and 11:30AM
Pacific (Noon and 2:30PM Eastern). Several different implementations
will be available for testing with each other, and remote participation
is the norm (versus traveling).

This is an event for those implementing ARC functionality in a product
or service, free or commercial. If you have an implementation, or are
actively working on one, and are not already on our interoperability
mailing list, please contact me directly via email to be included in
these events.

Thanks,
--Steve.

 
Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com


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

[dmarc-ietf] Most common problems with DMARC records

[Steven M Jones]

 810The string "DMARC" must be upper case
DMARC1; p=...  62Missing "v="
\\226\\128\\156v=DMARC140Incorrect quoting/escaping
_dmarc v=DMARC119Extraneous text
v=DMARC;15Missing the "1" in "DMARC1"
TXT \\\"v=DMARC1 7Extraneous text and quoting
v=DMARC1/; 6Incorrect escape character
v=DMARC1: 4Use of ":" instead of ";"
v=DMARC1p= 4Using "" at all
v%253DDMARC1%253B 3Two levels of character escaping
v=DMARC1; \\226\\128 3Incorrect quoting/escaping
=DMARC1 2Missing the "v" in "v=" tag/value pair
v-DMARC1 1Missing the "=" in "v=" tag/value pair

In addition, a number of records appear with widely varying numbers
and arrangements of escape or quoting characters. It is not at all
uncommon to see constructs like the following:

\"\\\"v=DMARC1;   618 Numerous escapes/quotes
\"v=DMARC1;\" \"p 187Escapes/quotes within the record
\"v=DMARC1;\" \"p=\"4Escapes and missing "p=" value
\"\" \"v=DMARC1\"   2Escapes, quotes, and spaces...
\" \\\"v=DMARC1;1...



Incorrect Policy Values
===

The use of incorrect policy values in the "p=" tag/value pair, or of a
pre-publication tag name such as "policy" instead of "p", may be of
particular interest to the working group when refining the protocol
specification. For this reason they appear below instead of above with
the general malformed DMARC records.

p=monitor   125Incorrect "p=" value
policy=none52Incorrect/outdated tag
p=monitor; sp=monitor41Incorrect "p=" and "sp=" value
p=nonee   20Incorrect "p=" value
p=;16Missing value of "p=" tag/value pair
p=quarantaine11Incorrect "p=" value
p=quarentine 7Incorrect "p=" value
p=quarintine 7Incorrect "p=" value
p=non; 3Incorrect "p=" value
p=blocked 1Incorrect "p=" value



Summary
===

The majority of non-DMARC DNS TXT records appearing at "_dmarc" labels
in the six year Farsight dataset is most likely due to the widespread
use of wildcard SPF records. Given that, how many records from the
dataset should actually be considered as malformed or problematic
DMARC records?

Taking the records described in the last two sections, "Malformed
DMARC Records" and "Incorrect Policy Values," we can be fairly
confident we're considering records intended to be DMARC deployments.
That gives us 3,769 invalid DMARC records, recognizing there may be
some overlap of records with more than one type of flaw.

Since these are all the invalid records captured, they should be
compared to all the valid DMARC records captured (184,676). This
appears to yield an error rate of little over 2% for all DMARC records
in our dataset.

What are the most common faults observed? The most common fault in a
published DMARC record appears to be omission of the required "p="
policy tag. The second most common fault appears to be not ensuring
the string "DMARC" in the "v=" tag is in fact upper case. And the
third most common fault appears to involve using too many escape and
quoting characters in the nameserver data, resulting in extraneous
characters in the published record.

It's known that many mail receiver implementations will strip out some
quoting and escaping characters in DMARC records they retrieve, though
the details are not known. They may only strip the outermost pair,
only operate between the beginning and "v=" at the start of the
record, etc. While a given receiver's validation methods might produce
different totals, this issue is probably still a solid third place
ranking as a class of problem.




-- 
Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com

tl;dr
=

Two percent of all recognizable DMARC records published were invalid.

The three top problems with DMARC records observed over six years were:

1: Missing "p=" tag
2: The "DMARC" in "v=DMARC1" wasn't capitalized
3: Extraneous escape/quoting characters in record

There's a "Summary" at the bottom if you want it.




Introduction


Farsight Security has made over six years of DNS data related to email
authentication protocols available to DMARC.org. We recently reviewed
DMARC records across this period, which seems like it might provide
useful input for the IETF DMARC working group.

The Farsight data is captured by network probes proximate to a number
of nameservers. While this represents a