Re: [dmarc-ietf] "psd=" tag early assignment

[Murray S. Kucherawy]

On Mon, Jul 11, 2022 at 5:57 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We should talk about "correct results".
>
> The PSL gets the correct results in 99-dot-something percent of messages,
> but we are proposing a new algorithm because it is wrong on some fraction
> of a percent.   The size of the fraction is not a reason to ignore a
> problem.   I support a change.  But is the proposed change an improvement?
>

You had me up until "because".  I don't think the fact that the PSL is
wrong in some cases is the single impetus to replace it.  I mentioned in
another message just now what I think the reasons are for pursuing a DNS
solution.


> We also think the proposed tree walk will also return a correct result in
> 99-dot-something percent.  But are they better answers?  On what basis
> would we answer that question?
>

I think it's hard to measure that until it's fully deployed, but I'm more
drawn to the solution whose engineering and operation is easier to describe
and justify, even if it's occasionally wrong (because it's easier to fix).

What matters is whether the new algorithm produces correct answers when the
> PSL produces wrong ones, and whether it does this without introducing new
> errors that are not present in the PSL solution.  On that question, the
> answer is at best uncertain.   When the PSL and Tree Walk produce different
> results, we simply have no basis for choosing between the two, because the
> proposed Tree Walk is sourced on no new information.
>

Suppose they do give different answers.  Irrespective of which one is
actually right, I think it's easier for me to explain the DNS answer and
why it might be wrong than have to explain in full why the PSL got it
wrong, or why fixing it is not a matter of editing my own DNS records.


> However, when the Tree Walk result is based on explicit tagging
> provided by the domain owner, then we do have a better answer than the PSL,
> because the domain owner knows more about his organizational structure than
> the PSL volunteers, and we have every reason to trust the domain
> owner's assertions.
>
> [...]
>

Right.

Note this, too, from the PSL's own web site, emphasis theirs:

-- snip --

Some use the PSL to determine what is a valid domain name and what isn't. *This
is dangerous*. gTLDs and ccTLDs are constantly updating, coming and going -
and certainly not static. If the PSL is incorporated in a static manner,
and your software does not regularly receive PSL updates, it will
erroneously think that valid TLDs are not valid, or conversely treat
decommissioned TLDs that should be invalid as valid. The DNS should be the
proper source for this information, despite the performance benefits of
some local source to pre-empt network latency. If you must use the PSL for
this purpose, please do not bake static copies of the PSL into your
software without update mechanisms that are frequently checking for its
frequent updates and incorporating them.

-- snip --

If I'm a serious email receiver (and currently I am not employed by one),
this would scare me off of using the PSL completely, and I would seek to
develop or subscribe to some kind of DNS solution.

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

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

[Murray S. Kucherawy]

Hatless once again.

On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> The tree walk solves the problem IF the policy has boundary information
> provided by the domain owner.   Without that, aren't we substituting one
> insufficiently  reliable solution for another insufficiently reliable one?
>

Another way to look at it: The PSL was never designed to provide the
information for which DMARC has been using it.  Hanging DMARC on it was a
reasonable thing for a proof of concept, which is what RFC 7489 really was;
it happens to give the right answer most of the time, but that's something
of a coincidence.  Here we're taking control over the input to the
Organizational Domain and Policy Discovery algorithms, which is a more
defensible way to do things if you're heading for the Standards Track.

The tree walk also eliminates any concern that two compliant operators are
using different versions of the input data.  There is no guarantee that my
copy of the PSL is any more or less up to date than yours is, leading us
both to different determinations about the very same message.  But once
we're using the DNS for this, then, other than staleness caused by
short-term caching, we're all talking about the same thing.

There is indeed more of a burden on sending domains and registry operators
to publish the needed markers in the DNS before this will all work the way
we want it to.  My view is that the working group perceives the risk of
continued use of the PSL to be less favorable than taking on that burden.
The tree walk has been a goal for years.

Changes to nodes in the DNS tree are visible immediately; changes to the
PSL take an unknown amount of time to be published and deployed globally.

Changes to the DNS are made by the operator in charge of the name(s) being
updated; as far as I'm aware, changes to the PSL are made by a limited
community not involved in (or perhaps even interested in, or cognizant of)
DMARC.

If we want a migration period, some kind of hybrid model might work: Do the
DNS tree walk, but at each step, if you find you've hit a name that's
present in the PSL, you can stop and pretend you found a marker you're
looking for.  When those markers are all (or mostly) actually published,
then stop doing that.  For bonus points, find some non-DoS way to notify
those operators that they really should be publishing the missing markers.
(The 1990s DNS "lame delegation" stuff comes to mind.)  We just need to
remember that SPF had a not-so-great transition plan, so we need to be
careful how we craft this one.

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

Re: [dmarc-ietf] "psd=" tag early assignment

[Murray S. Kucherawy]

Speaking only as a participant:

On Thu, Jul 7, 2022 at 4:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> So John has confirmed that it is his intent to hide any information about
> private registries, because the private registries create complexity for
> his algorithm which he does not wish exposed.
>

I submit that equating "this is not worth explaining as it's a corner case"
to "we should hide this detail because I don't want anyone to know about
it" is logically absurd as well as baldly antagonistic.

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

Re: [dmarc-ietf] moving past pad=y?

[Murray S. Kucherawy]

On Wed, Jun 29, 2022 at 7:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Based on our psl information, a private registry will be at DNS segment 3
> or 4.  If the PSO registration is at DNS segment 2, the private registry
> could be either one or two segments thick.
>

What is a "DNS segment"?

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

Re: [dmarc-ietf] Draft 10 notes: NXDOMAIN

[Murray S. Kucherawy]

(as participant)

Yes, that's clearly a broken implementation.

I imagine the DMARC document could say it relies on proper implementations
of 8020, but improper ones are known to be in the wild, and results are
unpredictable when these are encountered.  Given the IETF is a standards
organization, one could also argue that this is redundant or superfluous,
but it's probably also harmless.

-MSK

On Mon, Jun 27, 2022 at 2:37 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My testing was done more than a year ago.   My recollection is that I
> discovered it based on something in the wild, and then confirmed it with a
> locally-configured experiment.   This time I am having trouble finding
> examples.
>
> The only one I can verify is from a previous email exchange on this forum:
>
> mail.foodnetwork.com
> returns NXDOMAIN
>
> but
> _dmarc.mail.foodnetwork.com
> returns DATA for type=TXT
>
> On Mon, Jun 27, 2022 at 9:52 AM Todd Herr  wrote:
>
>> On Sun, Jun 26, 2022 at 1:27 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> Our draft references and repeats RFC 8020, which asserts that
>>>
>>> "when a DNS resolver receives a response with a response code of
>>> NXDOMAIN, it means that the domain name which is thus denied AND ALL THE
>>> NAMES UNDER IT do not exist."
>>>
>>> My testing indicates that this is not correct.   NXDOMAIN means that no
>>> resource records exist for the specified domain name.  The domain may
>>> contain subdomain nodes which may contain resource records.
>>>
>>> My testing performed on Windows.
>>>
>>> Can someone else test this and report your results?
>>>
>>>
>> It might help further the discussion if you were to favor the rest of us
>> with the examples you used.
>>
>> Specifically, for which domain name did you query and received an
>> NXDOMAIN response, and for which subdomain node of that domain did you
>> query and receive resource record(s) in return?
>> --
>>
>> *Todd Herr * | Technical Director, Standards and Ecosystem
>> *e:* todd.h...@valimail.com
>> *m:* 703.220.4153
>>
>> This email and all data transmitted with it contains confidential and/or
>> proprietary information intended solely for the use of individual(s)
>> authorized to receive it. If you are not an intended and authorized
>> recipient you are hereby notified of any use, disclosure, copying or
>> distribution of the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> this email and then delete it from your system.
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

[Murray S. Kucherawy]

On Sat, Jun 18, 2022 at 11:10 AM John Levine  wrote:

> That seems like a pessimal way to make things interoperate: use one of
> an unknown set of algorithms and the other party can't tell which one
> you're going to use. If we can't agree that the tree walk is better
> than piggybacking on the PSL, I don't see any of the other changes
> we're proposing to be worth the effort to republish so we should stop
> now and not waste more time.
>

Given that we're already working in an environment where it's unlikely that
everyone's working from a common version of the PSL, I don't think this is
such a scary idea.

I didn't actually make the claim that the tree walk is better or worse, by
the way.  There are ways to say things like "you could use the PSL, but
it's deprecated for X reasons" in the model I proposed.

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

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

[Murray S. Kucherawy]

On Sat, Jun 18, 2022 at 7:49 AM Scott Kitterman 
wrote:

> Given that the mechanism we've defined uses DMARC records to make the
> determination, I don't think it would be useful to separate it into a
> different document.  If we ever get an approach that's not DMARC specific,
> then I think it would make sense to document it independently.
>

The tree walk might be the DBOUND solution, for all we know.  Having it in
a separate, generic-as-possible, document might make the technique usable
by other applications as well.

I rather liked the idea of DMARCbis saying "You need some way to determine
the Organizational Domain.  One way is with the PSL as described in X, or
you could do a tree walk as described in Y."  It also means if we ever want
to introduce some third mechanism, we don't need to do a DMARCbisbis (which
I think is DMARCter).

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

[dmarc-ietf] DBOUND

[Murray S. Kucherawy]

Some time back there was an attempt to solve the PSL problem in DNS via a
Domain Boundaries (DBOUND) working group.  It was not successful, unable to
develop consensus among several options, and the working group closed
having not produced anything.

The WG page: https://www.ietf.org/mailman/listinfo/dbound

There is now some interest in seeing if a new run at that work would
succeed.  This might be of significant interest to DMARC if it were to work
out this time.  There may be a side meeting to discuss it at IETF 114.  If
you might be interested in participating or supporting that work, feel free
to subscribe to their list.

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

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

[Murray S. Kucherawy]

On Sat, Jun 18, 2022 at 6:48 AM Scott Kitterman 
wrote:

> On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
> > Let's talk through the selling process for the Tree Walk algorithm.
> ...
> > In sum, why should an Evaluator make the switch?
>
> I think there are some good points in here.  Fundamentally, I agree that
> there
> needs to be a value proposition associated with investing the resources
> required to update a DMARC implementation from RFC 7489 to DMARCbis.
>

+1.

1.  Does not use the PSL for something it was not intended for.  As has
> been
> mentioned many times, the PSL is designed for browser use cases, not
> email.
> In their words:
> [...]
>

This has been the biggest motivator for me.  Today we're relying on
something not intended for the purpose for which we are using it, with
maintenance practices that make us nervous.  Whatever delta may exist
between the PSL and tree walk approaches, I'd be willing to accept some of
that conversion cost in the name of a more solid and defensible engineering
and operational choice.

I also still like the notion of decoupling the mechanism of identifying the
OD from DMARC itself, which I think Dave suggested.  Have we fully
dismissed that idea?

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

Re: [dmarc-ietf] Bridging the gap

[Murray S. Kucherawy]

On Sat, Jun 18, 2022 at 4:26 AM Alessandro Vesely  wrote:

> Actually sending those messages would sound more credible if done From:
> some...@ietf.org.  Does such a role exist?
>

No.  We participate here as individuals, so whoever does this will be doing
it as herself or himself.  You probably can't claim to represent the
working group either, though you could say you're a participant in it.

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

Re: [dmarc-ietf] Next draft concerns

[Murray S. Kucherawy]

On Mon, Jun 13, 2022 at 3:22 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Because I want this document to succeed and actually reduce email-borne
> attacks.
>

I believe we're all wearing the same team jersey here.  Please let's try to
keep that in mind.


> Because stifling of discussion does not lead to consensus.   It does,
> however, drag out the process.   For those who do not want this process to
> succeed, accumulated delay may be almost as good as a win.
>

Please don't conflate being challenged on your assertions with an attempt
to silence you.  If you make a claim and someone challenges it (as I have
done, most commonly because I simply don't understand the claim you're
making), then the document will be stronger either because your assertion
was correct and you've successfully swung consensus to your position, or
because your position is untenable and we decided, as a group all wearing
the same jersey, to omit it from the final product because it wasn't a well
supported position.

Because I don't know your agenda.   I am here to voice the evaluator
> perspective.   What interest group do you represent?
>

I bristle at this sort of approach.  If we're all playing closely held
poker hands here, rather than coming with an intent to collaborate openly,
then things are in pretty bad shape.

As a participant, my "agenda" is to drive DMARC toward something that's as
close to universally positive as is practicable.  I don't represent my
employer or any particular constituency other than, I suppose, my own use
of DMARC and perhaps the IETF itself which suffered substantial negative
impacts when DMARC was first deployed into the wild in a substantial way.


> Because a good security policy does not defend against what has happened,
> it defends against what could happen.
>

I would claim it takes both as input.


> Because  a new idea like Tree Walk does not get adopted unless people
> believe the pain of transition is less than the benefit, so it needs to be
> "sold".Currently, the tree walk risk seems greater than the PSL risk,
> and you don't know how to sell past that objection.   Muzzling me will not
> cause millions of system administrators to do something stupid simply
> because you put it into print.
>

I fail to see how asking you for supporting evidence of your claims --
which, to me, is a perfectly reasonable aspect of debate -- constitutes
"muzzling".

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

Re: [dmarc-ietf] Updating ABNF for Next Rev?

[Murray S. Kucherawy]

On Mon, Jun 6, 2022 at 1:40 PM Les Barstow  wrote:

> As Barry pointed out, RFC7405 does provide the %s notation. But since your
> voice was added on top of mine, I might point out that 7405 is only
> proposed, not accepted.
>

No, it's an RFC that had IETF consensus to publish, and it shows as
updating RFC 5234, so it's effective.

That said, somehow I wasn't aware of this, so it looks like what Alessandro
proposed would work and I withdraw my suggestion.  Please remember, though,
to include RFC 7405 as a new normative reference.

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

Re: [dmarc-ietf] Updating ABNF for Next Rev?

[Murray S. Kucherawy]

Speaking as a participant:

On Mon, Jun 6, 2022 at 10:12 AM Alessandro Vesely  wrote:

> >   dmarc-version   = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
>
>
> Can we use RFC 7405?  It is more readable:
>
>  dmarc-version   = "v" *WSP "=" *WSP %s"DMARC1" ; case sensitive
>

+1 to what Les said about this particular ABNF.  RFC5234 (STD 68) says
string literals are not case sensitive; we can't just override that here
with a comment.

I would prefer this, if the goal is to make it readable:

dmarc-version = %x76 *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
; e.g., "v=DMARC1"

Note that the "v" up front in what we have now allows either case as well,
so that has to change to the hex notation to lock it down.

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

Re: [dmarc-ietf] What bad stuff can a broken DMARC record cause?

[Murray S. Kucherawy]

On Sun, Apr 24, 2022 at 11:38 AM John R Levine  wrote:

> Someone I know asked me what sort of bad things could happen if one
> published a broken DMARC record.  Obviously, if your record is bad people
> won't follow your policies and you won't get your reports, but anything
> else?  Have you ever heard of MTAs burping on a bad DMARC record?
>
> I've looked at the C OpenDMARC and perl Mail::DMARC libraries and they
> both seem pretty sturdy: fetch a TXT record and if they find one, look for
> the tags they want and ignore everything else.
>

The Open* projects always aim for a soft or "least disruption" failure
mode, at least by default.  I could see being strict with (i.e., bounce on)
malformed DMARC records at some point, but nobody asked for it so I never
added it.

For DKIM, a malformed record effectively results in an invalid signature,
which is supposed to be harmless, so that's as far as I ever went there.

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

Re: [dmarc-ietf] BATV

[Murray S. Kucherawy]

On Sat, Apr 16, 2022 at 5:35 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I would like to see John Levine's BATV document revived from expired draft
> status
> https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv
>
> BATV is in use within the current mail stream, and one commercial product
> has cloned it to make a proprietary version of the same idea, so it is time
> to declare it a success.  More importantly, it provides a general
> technique, based on signature and timestamp, which permits private
> communication between MTAs using insecure RFC5322 header fields.  That
> technique has other uses.
>

Who's using it?  Which commercial product are you talking about?

I wrote and released an open source BATV filter for use with postfix and
sendmail back when it was a new idea.  The interest in the filter or in the
specification was negligible, as there were legitimate use cases with which
it interfered, such as these:

https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation#Problems

For example, A-R does not include a signature security mechanism, so
> implementers must be concerned about injection of spoofed A-R records.
>  Because ARC is dependent on the secure transmission of A-R within one
> organization, weak A-R also weakens ARC.  Both problems would have been
> avoided by using the BATV signature system, but expired drafts make poor
> reference documents for other RFCs
>

If you're following the A-R specification, you only trust your own A-R
fields (unless you really know what you're doing), and your border MTAs are
supposed to strip anything it identifies as spoofed.  In theory, you can
trust anything you see beyond that point that's bearing your own
authserv-id.  If you think that's not enough, you could DKIM sign the
message on ingress, including the A-R field you're adding on the way in, so
that it can be proven legitimate.

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

Re: [dmarc-ietf] Exception management

[Murray S. Kucherawy]

On Fri, Mar 25, 2022 at 3:51 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Exception management is straightforward when using the PSL.   The system
> administrator simply maintains an errata file that is used to add entries
> to, or remove entries from the downloaded PSL file.   If the PSL does not
> list "onmicrosoft.com", but I want it treated as a registrar, I simply
> insert that name into the local data structure which represents my copy of
> the PSL.
>
> But how does the system administrator apply corrections to the Tree Walk?
>  I am having trouble envisioning any suitable solution.   The partial ideas
> in my head seem unsustainably complex to develop, administer, and query.
>

Were I implementing such a thing, I'd probably have a list of overrides
that map names to DMARC records.  For every name in the tree walk I'm going
to try, I'd check that list first for an override, and use that if one is
found.

Such a list would not be likely to change often, if I even need it, so I
would not need to load it from disk very often, and could just keep it
cached.

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

Re: [dmarc-ietf] Tree walk in -06

[Murray S. Kucherawy]

On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll  wrote:

> Having different behaviour for the absence of the tag and the default
> value will be unnecessarily confusing and not intuitive.
>

I'm confused.  In the absence of the tag, don't you apply the default?
That is, aren't these necessarily the same thing?

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

Re: [dmarc-ietf] DMARCbis and Standard Track

[Murray S. Kucherawy]

Sigh...

On Thu, Mar 17, 2022 at 2:50 PM Murray S. Kucherawy 
wrote:

> The status we're going for is "Proposed Standard".  Note the word
> "Proposed"; a document seeking this status doesn't need to be bulletproof
> out the door, as some evolution based on experience is required.  The
> standard for publication is higher than Experimental or Informational, to
> be sure, but it's not so high that leaving room for development isn't
> permitted.  If the things you're calling "experimental" here are based on
> consensus after the working group is clearly making informed decisions, I
> think we're good to go.  We're not trying to leap directly to "Internet
> Standard".
>

Make that:

"... as some evolution based on experience is anticipated."

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

Re: [dmarc-ietf] DMARCbis and Standard Track

[Murray S. Kucherawy]

On Thu, Mar 17, 2022 at 1:13 PM Dotzero  wrote:

> My understanding when the DMARCbis effort was spun up was that we were
> trying to move it to Standard Track. Is this still the goal? A number of
> experimental things are currently being included. This would seem to
> preclude DMARC being on Standard Track.
>
> If the experimental items being discussed were removed from the current
> draft(s) and moved to separate documents, there would still be an issue if
> there was a DMRC dependency rather than the experiment(s) being layered on
> top of DMARC.
>
> I'm not giving any proposed answers. I'm simply asking the question.
> Chairs?
>

Not a chair, but I have played one on TV.

The status we're going for is "Proposed Standard".  Note the word
"Proposed"; a document seeking this status doesn't need to be bulletproof
out the door, as some evolution based on experience is required.  The
standard for publication is higher than Experimental or Informational, to
be sure, but it's not so high that leaving room for development isn't
permitted.  If the things you're calling "experimental" here are based on
consensus after the working group is clearly making informed decisions, I
think we're good to go.  We're not trying to leap directly to "Internet
Standard".

I would argue that Section 4.1 of RFC 2026 concurs with that position.

-MSK, ART Area Director
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree walk is screwed up

[Murray S. Kucherawy]

On Wed, Jan 26, 2022 at 9:56 AM John Levine  wrote:

> More saliently, we had an entire working group called DBOUND that tried
> and failed
> to come up with a way to publish boundary info about the DNS:
>
> https://datatracker.ietf.org/wg/dbound/about/
>

DBOUND came up with two ways to deal with this, but no clear winner emerged
in terms of development of consensus.  It doesn't necessarily mean those
proposals weren't valid.

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

Re: [dmarc-ietf] Tree walk is screwed up

[Murray S. Kucherawy]

On Tue, Jan 25, 2022 at 3:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Overall, I doubt that we can replace the PSL without moving to DMARCv2,
> and I don't think we have a standards-worthy document unless the PSL is
> replaced.
>

I don't think such an opinion is going to ruffle any feathers in here.  The
PSL has been non-ideal since the beginning, but it's all we had to work
with at the time.  RFC 7489 anticipated its replacement someday with
something better.

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

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

[Murray S. Kucherawy]

On Tue, Jan 25, 2022 at 11:26 AM John R Levine  wrote:

> On Tue, 25 Jan 2022, Murray S. Kucherawy wrote:
> >> will get the same result. It also occurs to me that in the absence of
> >> a PSL-like thing, the idea of an organizational domain is no longer
> >> useful.
> >
> > Aren't we basically trying to identify the same thing, just in a
> different
> > (and more robust) way?
>
> Yes, but that leads to the question of whether the org domain is useful on
> its own or it's just a way to figure out alignment.  I think it's the
> latter, dunno what other people think.
>

It's an interesting thought exercise at least.  We should be sure to give a
decent treatment to this in the "differences since RFC 7489" part of the
document.

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

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

[Murray S. Kucherawy]

On Tue, Jan 25, 2022 at 9:40 AM John Levine  wrote:

> It appears that Scott Kitterman   said:
> >My impression is that the group is generally okay with PSD=y.  I prefer
> it over your suggestion.  My strongest preference is that we pick
> something, stick with it, and move on.
>
> I think I see where Ale's confusion is coming from. If we switch to a
> tree walk, we will have an algorithm rather than a heuristic, so
> anyone looking at the same domains and the same set of DMARC records
> will get the same result. It also occurs to me that in the absence of
> a PSL-like thing, the idea of an organizational domain is no longer
> useful.
>

Aren't we basically trying to identify the same thing, just in a different
(and more robust) way?

I'd be careful about saying "no longer useful"; doing so implies a much
bigger change than we might be aiming to "sell" here.

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

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

[Murray S. Kucherawy]

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

> Protocols are created to solve a problem, and solution design should
> include both normal operation and failure management.That’s why
> electrical panels use circuit breakers instead of simple on-off switches.
>
> In this current case, we are defining an access control system for email,
> so we have easy parallels with an access control system for doors.  The
> core protocol defines how the badge is formatted, how the reader
> interrogates the badge, and how it interprets the response.   But the
> solution is much more.  The solution needs to include a way to cope with
> employees who forgot their badges, badges that don’t work, guests who do
> not have a badge, solenoids that don’t open doors when the badge reads
> successfully, the emergency exit path if there is a fire, and probably
> other things.
>
> Mailing list messages can be considered equivalent to an employee who
> arrives at work without his badge.   Assume that an organization wants to
> trust mailing list messages from IETF.ORG.   How is this accomplished?
> My analysis says that there are ways to do this right and ways to do this
> wrong.   I have seen an abundance of wrong implementations.  Defining how
> to do it right is an example of failure management.  I do not believe that
> it is irrelevant to the protocol; rather it should be an integral part of
> it.
>
I think if you extend that logic to its conclusion, the core protocol for
email should contain DKIM, SPF, DMARC, maybe MIME, maybe greylisting,
DNSXLs, and a host of other things.  It would be massive.

I would wager that the manual for the badge readers at your place of work
or mine probably doesn't talk about what policy you should have for
employees who forget badges, handling of guests, emergency exits, or most
of the other things you listed.  How could it possibly know the right
answers to such questions?  I'm sure at least for reasons of liability,
they are tightly scoped, and such things are left to the purview of the
customer who has full context of how the reader is going to be used.

Since the email ecosystem evolves, parts are added over time and other
parts become obsolete, best practices evolve with new usage, etc., it's
more agile for us to be crisp in separating protocol from advice.  We
commonly publish protocol specifications in Standards Track documents and
then include advice of the sort you're advocating in Informational
documents.  This also allows us to evolve the advice text separately from
the protocol documents when doing so is warranted.  It also means the
protocol can advance toward publication while we might still be haggling
about the advice part.

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

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

[Murray S. Kucherawy]

On Thu, Jan 6, 2022 at 3:32 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> There are good reasons for talking about a default DMARC policy.   It is
> certainly not to give evaluators permission, because we know that
> evaluators can do whatever they want, and they will do what they deem to be
> in their best interest.
>
> The point of a specification like this is to understand each participant's
> best interest and channel that toward the common goal.   I perceive a false
> assumption that when a sender does not publish p=reject, then his messages
> cannot be blocked for failure to validate, and therefore DKIM signatures
> are unnecessary.   Your question about "none" equaling "ignore" comes
> across that way."None" means that the sender provides no guidance, it
> does not mean that the message cannot be blocked because of sender
> authentication failure.
>

I'm not sure I agree with the second paragraph's assertion.

DMARC, or any protocol specification really, is about interoperability
between two participants.  In DMARC's case, that's a sender and a
receiver.  When a policy is published, the receiver has asked the sender's
DNS for that information, received a reply, and put it to use in the DMARC
evaluation machine; the protocol has been followed.  However, when no
policy is published, or in the errant case where multiple policies are
published, the protocol cannot be said to have completed, since there was
no interaction between the sender and the receiver.

Similarly, the notion of a default DMARC policy suggests that when no
policy is published, the receiver has some means to assert "I think I know
what you probably would want" and then completes the protocol on that
basis.  But there's been no interoperability here; no interoperable
protocol has been executed.  It's on the same basis that Scott earlier said
Best-Guess SPF is not SPF.

It IS in the interest of an evaluator to apply the DMARC test to every
> message, so I believe it is in the interest of the specification to
> acknowledge that likelihood.  If someone in the group believes that it is
> contrary to an evaluator's best interest, we need to discuss and document
> that risk also.
>

I suggest that this might be the kind of advice we float in a Best Current
Practices document or similar, if that's the consensus opinion, but not in
the protocol itself.  At a minimum, I suggest that it should be informative
text, and certainly not mandatory.

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

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

[Murray S. Kucherawy]

On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> [...]
> The PASS-centric approach is the only one that makes sense to me.  This is
> why I have lobbied for changes to the introduction to explicitly state that
> FAIL is an ambiguous result.   If you accept that PASS-centric is the goal,
> then using default policies becomes the necessary way of coping with
> missing information.
>

I would argue that it's well understood by now that DKIM and SPF "pass"
results are the only things that convey usable information.  You know
something about a message that passes; when they fail, the algorithm itself
can't tell you what the exact nature of the failure is.  Section 6.3 of RFC
6376 spends some time discussing this.

I think in DMARC, a strong policy is a tacit expression that the domain
posting that policy understands the narrow but meaningful nature of the
"pass" cases of those protocols, and only wants participating receivers to
deliver messages within that definition.

But if we believe that's not implicit or made clear by the document as-is,
or if the industry at large has missed this point, then sure, we could say
so here.

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

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

[Murray S. Kucherawy]

On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I suggest the language should be more like this:
>
> If the set produced by the DNS Tree Walk contains no DMARC policy record
> (i.e., any indication that there is no such record as opposed to a
> transient DNS error), Mail Receivers MAY choose to proceed with the DMARC
> mechanism using a default alignment of "relaxed" and a default policy
> recommendation of "NONE".
>
>
This seems to me to be exactly the sort of thing Best Guess SPF tried to
do, and we've rejected that notion.  To paraphrase, this would not be
DMARC, but an action taken unilaterally by a receiver.  There's no
interoperation at the DMARC level happening here.

Moreover, if the default you're applying is "none", isn't that the same as
ignoring the message anyway?

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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Tue, Dec 21, 2021 at 11:32 AM John Levine  wrote:

> The DNS has had a formal definition of non-existence for over 30
> years. You look up a name, if it returns records or NOERROR it exists,
> if it returns NXDOMAIN it doesn't. There is no reason for us to invent
> something new and incompatible.
>
> >I don't remember exactly why we settled on A/ / MX, but the lack of a
> clear, actionable definition is why we included one.
>
> See above.  I don't remember where the text in A.4 came from, but it is
> wrong.
> If we are telling people to test whether a domain exists, they should do it
> the way the DNS does it.  The correct test happens to be cheaper than A.4,
> one query rather than three.
>

We're talking about two different things here, I think.  The DNS definition
of "nonexistent" is as cited above while the DMARC definition matches the
well established SMTP algorithm that figures out where the next hop for a
particular recipient is.  If there is no next hop, then for email purposes,
the domain doesn't "exist".  The logic goes something like: If this message
fails DMARC, and a bounce has nowhere to go, then I'm pretty sure I don't
want to deliver it.

We're free to change our minds about what test is appropriate here, but
that was the genesis of A.4.

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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Tue, Dec 21, 2021 at 4:31 AM Scott Kitterman 
wrote:

> I don't remember exactly why we settled on A/ / MX, but the lack of a
> clear, actionable definition is why we included one. Lack of DNS records
> related to email authentication only means lack of email authentication,
> which is in no way required.  Given the way most systems are typically
> architected, by the time you are doing email authentication, A or  and
> MX will already be in the local cache, so this is a pretty inexpensive
> thing to check.
>

It comes from SMTP itself.  RFC 5321 and its antecedent(s) specify that to
identify the next hop for a message needing routing, you look up the MX for
the recipient's domain.  If that's missing, you try the A/ for that
same name.  If that's also missing, the message is undeliverable.

Since that test has worked well for SMTP for rather a long time, DMARC
adopted it.

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

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We both know exactly what causes messages to lose credentials:
> - A record that is only SMTP validated, which is then forwarded without
> SMTP rewrite
> - A message which is forwarded after modifications, such as the ubiquitous
> "this message received from an external source".   Of course, it could be a
> mailing list modification also.
>

Yes, I'm aware of this aspect of message authentication.  That wasn't my
question.

The point of an NP test was, in my understanding, to identify names that
> were never valid in any circumstance, like 'junk.junk.ietf.com", without
> any dependencies on message path.Why would we want to create a
> duplicate of the mailing list problem?
>

I understand the first sentence.  I do not see how the second follows.

However, if MX/A/ is really the right test for fraudulent identifiers,
> then we need to open a CVE against all implementations of RFC7489, because
> implementations based on that spec have been confidently asserting honest
> identifiers without checking the MX/A/ condition.
>

I don't follow this either.

Why do I need to provide case studies?Isn't the burden of proof on the
> team that told us that MX/A/AAA was absolutely the best possible test to
> use?
>

Because I'm trying to understand your concern.  Sure, it's reasonable for
us to question our assumptions.  But if I don't understand how you get your
premises, or how your premises lead to your conclusions, am I being
unreasonable when I ask for clarification or concrete examples?

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

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Wed, Dec 15, 2021 at 9:58 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy.  Based on DMARC PASS, the
> RFC5322.From address is confidently judged to be "Honestly identified"
>  DMARC checks SPF and DKIM, but not MX or A/.
>
> But then it is forwarded and loses its credentials during forwarding.
>
> On reception, because of DMARC FAIL, it is tested against NP.NP checks
> MX and A/ but does not check SPF or DKIM.   The message fails this test
> and is confidently judged to be "Fraudulently identified".
>

The nearest thing I can imagine that would cause this is a From of "
f...@example.com" when that domain advertises a public key that verifies the
message, so it has a TXT at "selector._domainkey.example.com", but has no
MX, A, or  for "example.com".  On relay, a mutation causes the
signature validation to fail at the final recipient.

Are you seeing cases like this?

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

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

[Murray S. Kucherawy]

On Thu, Dec 9, 2021 at 3:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have trouble with this statement in section 5.7.1:
>
> "Multi-valued RFC5322.From header fields with multiple domains MUST be
> exempt from DMARC checking."
>
> This language will serve as an invite for spammers to create multiple-from
> messages to ensure that they will evade DMARC.
>

As Todd points out, the best an attacker can hope for in this situation is
to earn a DMARC "none".  It can't get them a "pass".

I can see "exempt" as indicating to some readers a bypass of some kind,
however.  Underscoring the distinction between "none" and "pass" might be
useful.

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

Re: [dmarc-ietf] Experiments

[Murray S. Kucherawy]

To those who said they're collecting data and hope to have some stuff to
share soon, is there anything interesting to report?

The topic of ARC's efficacy came up in another IETF context today (tools)
and I'm wondering if we have anything new here.

-MSK

On Thu, Sep 23, 2021 at 2:08 PM Brotman, Alex 
wrote:

> Murray,
>
>
>
> We’ve started (relatively recently, in volume) logging ARC data so we can
> try to make some informed decisions going forward.  We’re not yet acting on
> anything as a result, nor writing into the message. We’re also not doing
> anything when mail is being forwarded.  We’ll hopefully have more
> information/data available to share in the future (may not be the very near
> future given other projects going on).   This isn’t a guarantee that we’ll
> fully adopt ARC in the future, but enough to say we’re logging/analyzing
> things.
>
> Random thing while looking at some data just now .. At least one message
> apparently came through with seven ARC sets.
>
>
>
> Let me know if there’s anything I can answer at this point.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* dmarc  *On Behalf Of * Murray S. Kucherawy
> *Sent:* Wednesday, September 22, 2021 4:30 PM
> *To:* IETF DMARC WG 
> *Subject:* [dmarc-ietf] Experiments
>
>
>
> Is anyone in a position to comment on the ARC and PSD experiments and how
> they're progressing?  Deployment status?  Data acquired thus far?
>
>
>
> -MSK
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Murray S. Kucherawy]

On Sun, Dec 5, 2021 at 12:24 PM John R Levine  wrote:

> I'm pretty sure that changing DKIM is very out of scope for this working
> group.
>

As I read the charter, I don't agree.  It says in at least two places that
this could be in scope.

Whether the chairs want the WG to engage in such work right now is another
matter.

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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

[Murray S. Kucherawy]

On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely  wrote:

> The second paragraph says:
>
> Section 8 creates a registry for known DMARC tags and registers the
> initial set defined in this document.  Only tags defined in this
> document or in later extensions, and thus added to that registry, are
> to be processed; unknown tags MUST be ignored.
>
> Couldn't it say something like so:
>
> Section 8 creates a registry for known DMARC tags and registers the
> initial set defined in this document.  Only tags defined in that
> registry are to be processed.  Unknown tags MUST be ignored.
>
> That way, fo, rua, and ruf definitions could be moved to the corresponding
> I-Ds.
>

Those two paragraphs read identically to me.

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

Re: [dmarc-ietf] draft-ietf-dmarc-dmarcbis-04 Release Notes

[Murray S. Kucherawy]

On Thu, Dec 2, 2021 at 12:51 PM Todd Herr  wrote:

> The change log (Appendix C) has been removed, because even though there
> are only two new ideas introduced, there is enough shifting of text to make
> this revision effectively a reboot.
>

No objection to that change, but this leads me to a suggestion: A section,
or an appendix, summarizing what's different between this version of DMARC
and the one described in RFC 7489 might be of benefit, especially to people
who implemented the older specification and might be looking to be sure
they didn't miss anything when updating.

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 4:51 PM Dave Crocker  wrote:

> I'm going to suggest that that analysis is not formally correct.
>
> The DKIM specification precisely defines validation for the signature
> and it precisely defines what coverage is 'required'.
>
> A receiver can indeed choose to apply stricter requirements, but a
> failure to satisfy these is NOT a DKIM fail. The extra requirements are
> outside the scope of the DKIM specification and therefore the failure
> has nothing to do with the standard.
>
> This is not a minor point, but it does seem to be a common point of
> confusion.
>

Right, I stand corrected.  The distinction is actually in the definition of
Authentication-Results, where a DKIM "pass" can be reported as a "policy"
result rather than a "pass" when the algorithm completed successfully but
some aspect of the signature was not acceptable to the verifier.

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I think this text was inserted because of an open ticket when discussion
> was going nowhere and a new draft was created.  Perhaps the originator of
> that ticket can elaborate on his thinking.
>

I believe the admonishment against best-guess SPF was based at least in
part on the sentiments found here:

http://www.open-spf.org/FAQ/Best_guess_record/

...which is to say it's apparently a discouraged practice.

It makes it difficult for DMARC to be deterministic when the things upon
which it's built behave in unpredictable ways.  That's not to say this is
unique though; DKIM, for example, allows verifiers to decide what an
acceptable signature is (a favorite I remember from the early days was "I
don't want to accept a DKIM signature that didn't cover the Subject
field"), which again means one site's "pass" is another site's "fail".

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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Murray S. Kucherawy]

Argh:

On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy 
wrote:

>
> I'd be happy with either of these two definitions:
>
> (a) All messages are subjected to DMARC checking, and "pct" identifies the
> percentage of messages failing the check that should be subjected to the
> policy;
>
> (b) "pct" identifies the percentage of messages subjected to the DMARC
> check, irrespective of the outcome.
>
> So the dice-roll happens either before you start DMARC, or after you find
> a "fail".  They're not the same thing, and (again if "pct" stays) we need
> to be clear about which one people are expected to implement.
>
> The original intent, as I recall, was (a).  We preferred that because if
> you choose early on to exclude the message you're handling, you avoid all
> that processing cost.
>

The clown who said this hit "Send" without proofreading.  The original
intent was (b), for the reason given.

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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Murray S. Kucherawy]

On Fri, Dec 3, 2021 at 10:38 AM Todd Herr  wrote:

> We can have this conversation too. I will promise, however, that if the
> group decides to keep 'pct', I will absolutely insist that the first
> sentence in its definition be changed. Somehow, RFC 7489 got released with
> this text:
>
>pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
>
>   default is 100).  Percentage of messages from the Domain Owner's
>
>   mail stream to which the DMARC policy is to be applied.
>
>
> And I will go to my grave stating that DMARC policies cannot be applied to
> messages that pass DMARC authentication checks, and the definitions of
> 'quarantine' and 'reject' explicitly refer to messages that fail DMARC
> authentication checks.
>
> The sentence should read something like this:
>
> Percentage of messages using the Domain Owner's domain and failing DMARC
> authentication checks to which the DMARC policy is to be applied.
>
>
I'd be happy with either of these two definitions:

(a) All messages are subjected to DMARC checking, and "pct" identifies the
percentage of messages failing the check that should be subjected to the
policy;

(b) "pct" identifies the percentage of messages subjected to the DMARC
check, irrespective of the outcome.

So the dice-roll happens either before you start DMARC, or after you find a
"fail".  They're not the same thing, and (again if "pct" stays) we need to
be clear about which one people are expected to implement.

The original intent, as I recall, was (a).  We preferred that because if
you choose early on to exclude the message you're handling, you avoid all
that processing cost.

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

Re: [dmarc-ietf] Additions to introduction

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 9:55 AM John Levine  wrote:

> The point of a spec is to tell people how to interpoerate.  I don't see
> how this
> contributes to that.
>

Lots of specifications include informative guidance or best practices
advice as well as normative specification.  DKIM has loads of it.

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

[dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

[Murray S. Kucherawy]

This was reported but not sent to the WG.  I believe the right disposition
is "Hold for Document Update".  Does anyone want to argue for "Rejected" or
"Verified"?

-MSK

-- Forwarded message -
From: RFC Errata System 
Date: Mon, Nov 1, 2021 at 4:31 PM
Subject: [Technical Errata Reported] RFC7489 (6729)
To: , , 
Cc: , 


The following errata report has been submitted for RFC7489,
"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6729

--
Type: Technical
Reported by: Scott Kitterman 

Section: 3.2

Original Text
-
   3.  Search the public suffix list for the name that matches the
   largest number of labels found in the subject DNS domain.  Let
   that number be "x".

Corrected Text
--
   3.  Search the ICANN DOMAINS section of the public suffix list for
   the name that matches the largest number of labels found in the
   subject DNS domain.  Let that number be "x".

Notes
-
The PSL includes both public and private domains.  RFC 7489 should have
limited name matching to the public, ICANN DOMAINS section of the PSL.  As
an example, using the current PSL, the organizational domain for
example.s3.dualstack.ap-northeast-1.amazonaws.com is
example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since
it is listed in the private section of the PSL.  This is clearly the wrong
result.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC7489 (draft-kucherawy-dmarc-base-12)
--
Title   : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Publication Date: March 2015
Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
Category: INFORMATIONAL
Source  : INDEPENDENT
Area: N/A
Stream  : INDEPENDENT
Verifying Party : ISE & Editorial Board
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Additions to introduction

[Murray S. Kucherawy]

On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I propose that a paragraph along these lines be inserted into the
> introduction:
>
> The DMARC test is characterized by a one-tailed error distribution:
>  Messages which pass verification have a low probability of being false
> positives of actual impersonation. When a recipient intends to exempt a
> high-value sender from content filtering, identity verification ensures
> that such special treatment can be done safely, without concern for
> impersonation.However, the same cannot be said about verification
> failures.  Verification failures can occur for many reasons, and many such
> messages will be safe and desired by the recipient.   Messages which do not
> verify are optimally handled with manual review, but this may not be
> feasible due to message volume.DMARC provides a way for senders and
> receivers to safely cooperate to minimize the probability that automated
> disposition decisions will be suboptimal.
>

I have no objection to adding text such as this.  It's worth noting,
though, that DKIM certainly says this already (at least in its Section
6.1), SPF probably says something similar, and DMARC clearly depends on
those.  DMARC alludes to this in RFC 7489, Section 10.5, but it's not as
explicit as what's proposed here.

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

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Murray S. Kucherawy]

On Sun, Nov 28, 2021 at 3:31 PM Wei Chuang  wrote:

>
> This approach and benefit was what I was thinking could be feasible as
> well.  The cited draft-kucherawy-dkim-list-canon
>  draft 
> notes
> your contribution to the concept described there i.e. to perform hashing as
> a mime-tree (though that draft doesn't do content transport decoding).
>

It does, in Section 3.

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

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Murray S. Kucherawy]

On Thu, Nov 25, 2021 at 12:07 AM Wei Chuang  wrote:

> Sorry I wasn't too clear here.  It's largely the same idea as the DKIM
> body length "l=" field above except for reformulated for the Subject header
> and its mailing list mutations.  The original sender would encode a length
> of the original subject say "s.l=".  A receiver would only hash the
> right most "s.l=" length string when validating a Subject hash from
> the original sender.  This assumes that mailing lists may prepend a string
> typically for identification.


Seems to me that means I could insert anything I want before the last N
octets of Subject -- say, a URI pointing you to an ad or other unsavory
content -- and the original signature will verify.

-MSK

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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

[Murray S. Kucherawy]

On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Under a collaboration solution, the subscriber goes to her email support
> and says,"I joined list X, and they say that for the best user experience,
> we need to configure a whitelist entry to bypass >From Filtering on
> messages from one SPF-verified SMTP address.Then I need to give them a
> response whether this change has been implemented or not."
>
> Under an unmunging solution, the subscriber conversation is more like
> this, "I joined list X, and they say that for the best user experience, we
> need to configure an unmunging MTA.   Hope this is not too much trouble.  I
> hope you can get this implemented quickly."
>

It feels to me like an arrangement like this can't scale well.  Given
millions of users at a single email service provider, even a fraction of a
percent of those joining lists means thousands of people have register with
the MTA in some way.  This causes two problems:

a) Many users will forget, many others will be confused by the process
since they've never had to do that before; you should expect that all of
those will complain, screw it up, or both.

b) Teaching an MTA to use a configuration file with that scale of entries
seems like it would be a beast.  Large scale infrastructures can possibly
handle something like that, and boutique operators only have to do it for
their small handful of users, but the space in between could be pretty
unpleasant.

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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

[Murray S. Kucherawy]

On Thu, Oct 7, 2021 at 7:57 AM Dave Crocker  wrote:

> Sorry, but I've lost track of which document would informationally
> document this issue.
>
> The re-writing hack is an operational one that might or might not prove
> the be transient. Having a spec note the effect of what it does, in
> terms of rendering mailing use problematic, is reasonable.
>
> Having a spec go into details about the hack of the moment isn't.  On
> the other hand, it's reasonable to put such discussion into a companion
> 'usage' doc, IMO.
>

He didn't specify, but I took the suggestion to mean a new document, not
any of the current ones.

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

Re: [dmarc-ietf] Experiments

[Murray S. Kucherawy]

On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman 
wrote:

> I can comment on the status of PSD.
>

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

[dmarc-ietf] Experiments

[Murray S. Kucherawy]

Is anyone in a position to comment on the ARC and PSD experiments and how
they're progressing?  Deployment status?  Data acquired thus far?

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

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

[Murray S. Kucherawy]

On Thu, Aug 19, 2021 at 4:19 AM Alessandro Vesely  wrote:

> On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
> > If you feel as though something is amiss, or I've misinterpreted the
> consensus, please let me know.
>
>
> I'd swap SHOULD and MUST between the following sentences:
>
>  If a report generator needs to re-send a report, the system
>  SHOULD use the same filename as the original report.
>

Why is this only SHOULD?  What legitimate reason might an implementation
have for deviating from this advice?

 The RFC5322.Subject field for individual report submissions
>  MUST conform to the following ABNF:
>
> For the subject, alternatively, "Report-Id" msg-id could be optional,
> as it is with the filename.  It is very noisy and doesn't seem to be
> much useful if it doesn't match the filename, let alone its uniqueness.
>

If there's information being encoded in the Subject field that the
recipient is expected to be able to decode, I think this makes sense.  If
it's just a "it sure would be nice" sort of deal, then I don't even think
this should even be a SHOULD.

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

Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

[Murray S. Kucherawy]

On Thu, Aug 19, 2021 at 1:50 PM Dotzero  wrote:

> I'm troubled by this whole section. Unless IETF is getting into the
> certification or enforcement business, documenting anything about
> "implementation claims" would seem to be a non-starter. Do we have any
> similar requirements for "claims" about implementing SMTP, DNS or other
> standards? We should stick to the normative requirements for
> interoperability and avoid dealing with "claims". Folks who implement
> poorly will get an earful from both their mail users and the folks they
> interoperate with and that should be sufficient.
>
> This really does seem like pushing on a rope.
>

I could see specifying the minimum implementation needed to interoperate in
a useful way, if it's necessary to do so in a summary section.  Of course,
one should be able to glean that from the collection of MUSTs and SHOULDs
in the document anyway, but summaries can be helpful.

I should add to my other remarks that I don't think it's a bad idea to
spend some text in the document describing how valuable we think generating
reports is, and that we think it's a really good idea to find some way to
participate because the intelligence it provides can be valuable, etc.  I
just don't think a mandate is defensible.

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

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

[Murray S. Kucherawy]

On Thu, Aug 19, 2021 at 5:53 AM Todd Herr  wrote:

> On Thu, Aug 19, 2021 at 7:19 AM Alessandro Vesely  wrote:
>
>> On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
>> >
>> > The main update in this draft is removal of the "pct" tag, with an
>> > explanation as to why, and an introduction of the "t" tag in an effort
>> > to maintain the functionality provided today by "pct=0" and "pct=100".
>>
>>
>> As held earlier, I disagree with such gratuitous breaking of the
>> existing installed base and published records.
>>
>
> I disagree with your characterization of removal of the "pct" tag as
> "gratuitous breaking"; the spec has long contained the following text:
>
> Only tags defined in this document or in later extensions, and thus added
> to that registry,
> are to be processed; unknown tags MUST be ignored.
>
> and so should a DMARC protocol without the "pct" tag be formally adopted,
> there should be no breaking of any existing DMARC implementations.
>

Not expressing an opinion on the new text, but just on this point:

I agree the parsers won't break from this change, but an operator currently
advertising "pct=33" will suddenly stop getting what it thought it was
asking for.  One could argue that this constitutes "breakage".

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

Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

[Murray S. Kucherawy]

On Thu, Aug 19, 2021 at 11:24 AM Todd Herr  wrote:

>
>Mail Receiver: To implement DMARC, a mail receiver MUST do the
>
>following:
>
>
>*  Perform DMARC validation checks on inbound mail
>
>
>*  Perform validation checks on any authentication check results
>
>   recorded by mediators that handled the message prior to its
>
>   reaching the Mail Receiver.
>
>
>*  Send aggregate reports to Domain Owners at least every 24 hours
>
>   when a minimum of 100 messages with that domain in the
>
>   RFC5322.From header field have been seen during the reporting
>
>   period
>
> Let's discuss...
>

I'm of the opinion that this last bullet can't be a MUST.  I understand
that operators in this space really want this to be mandatory, but we are
going to run into cases where doing this is difficult or impossible either
because of operational difficulties (think resource-constrained
environments) or policies ("I am not willing to share any detail about what
mail arrives here").  Making this a MUST explicitly disqualifies them.

Moreover, I would claim that not generating aggregate reports does not
impede interoperability at all, which means use of MUST or even SHOULD here
is not appropriate.

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

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[Murray S. Kucherawy]

On Thu, Aug 5, 2021 at 4:22 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> PCT could work IF evaluators are willing and able to send a Temporary
> Error result (probably 451), instead of a permanent error, when
> - a DMARC verification fails,
> - the message is not unconditionally blocked or accepted on other
> criteria, and
> - the sender's PCT is between 1 and 99.
> The result should include an extended status code in the 4.7.2x range.
>
> This approach assumes that the temporary error status will cause the
> sender to retry multiple times over an extended period.
>

It should, since that's what the standard says ought to happen.  But then,
as was observed elsewhere in this thread, not all clients behave that way.

Based on observed configurations, this probably works out to at least 10
> attempts.  In most cases, the PCT formula will cause the message to be
> accepted after a delay, which is a result equivalent to PCT=0.
>

We usually use 4yz SMTP reply codes to mean there's some transient
condition preventing delivery; a later retry may yield a different result.
Random chance seems an awkward thing to shoe-horn into the notion of
"transient condition".

I think this could also DMARC skew statistics, as now any given message
could result in multiple distinct delivery attempts over a period usually
measured in days.  Care would have to be taken to identify and aggregate
the ones representing the same message.

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

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[Murray S. Kucherawy]

On Mon, Aug 2, 2021 at 12:49 PM Todd Herr  wrote:

> And this:
>
>
> 6.7.4.  History of the "pct" Tag
>
> [...]
>

I suggest making this an appendix instead of leaving it up in the normative
area, with an appropriate forward reference.

And +1 to Michael's point about "experimental".

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

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[Murray S. Kucherawy]

On Fri, Jul 30, 2021 at 5:13 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Unfortunately, it seems the extended status codes have very limited
> deployment.   When I searched my recent history, I could only find codes
> 2.0.0 and 2.6.0, which communicate nothing incremental.
>

Indeed; I would like to understand what 2.6.0 is meant to convey.  As I
read the IANA registry entries, "2" means success but "6" means there was a
media type error.

Would it be reasonable to add language saying that we RECOMMEND that
> evaluators use extended status codes, for both accepted and rejected
> messages, to indicate the message authentication status?   We could
> highlight the codes that are particularly relevant to this need.
>

I'm not sure about RECOMMENDED, but reminding readers of this mechanism for
providing additional information seems at least harmless to me.

If we say RECOMMENDED, I'd be inclined to think we should say something
about both producers of these codes and consumers of them, to encourage
interoperability.  There's no point in making a strong push toward
generating them if nobody has any incentive to do something with them when
they're observed.

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

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Murray S. Kucherawy]

On Thu, Jun 17, 2021 at 9:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> This is frustrating.   NP is a new design and the design issues should
> have been discussed before we got to this point.   I don't know why so many
> people are eager to not define the new technology.
>

Please don't conflate "I still don't understand what you're talking about"
with "I am eager not to define NP" or "I am unwilling to acknowledge
(something)".  They're not the same thing, and only the former is true.

Your message continues to assert something abstract.  I'll repeat my
previous request:

Could you craft a sample message (including DKIM details), sample envelope,
and sample DNS context (including A, , MX, and SPF details) that
highlights the problem you're talking about?  Maybe then it'll snap into
focus.

NP is an effort to partition the RFC 7489 SP=NONE result set, so that a
> subset of all SP results can be blocked on some additional criteria.
> This additional criterion could be based on non-existent as indicated by
> NXDOMAIN, or it could be based on "not used for email" based on a criterion
> to be defined.   Either approach needs to have a mechanism for
> non-compliant names to be made compliant.   I believe that this should
> involve a DNS entry, but the compliance measure should be specific to the
> NP test.   Requiring that every FROM address be linked to an IP address
> does not meet that requirement.
>

If I squint at this, maybe I can see what you're trying to argue: "
example.com" can't publish an "np" policy if they use a subdomain of "
example.com" that has no representation of any kind in the DNS.  Is that
correct?  If so, do you find this to be a defect, or simply a limitation to
be documented?  If you think it's a defect, why is that so?

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

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Murray S. Kucherawy]

I continue to not understand the defect you're highlighting here.

I think you've expressed yourself primarily in the abstract.  Could you
craft a sample message, sample envelope, and sample DNS context that
highlights the problem you're talking about?  Maybe then it'll snap into
focus.

On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> NXDomain on RFC5322.From is a completely different issue.It means that
> the name is only used for service provider messaging, and is therefore not
> linked to any IP address or other physical infrastructure.  It affects the
> ability to define a meaningful NP test.   The issue becomes irrelevant to
> DMARC if and only if we drop the NP policy idea completely.
>
> The proposed MX/A//SPF test has two significant problems:
> - It incorrectly classifies some names as NP because they do not need
> MX/A//SPF records because they are not tied to an IP address, and we
> have provided a very poor mechanism for a domain owner to come into
> compliance.
>

There's a workaround here: If I want to use a name that is not represented
in the DNS according to that test, all I need to do is DKIM sign with my
parent domain.  That makes "p" apply because now you have an aligned
"pass", which presumably trumps any "np" that's set.

If you aren't signing with DKIM in that scenario, and you obviously can't
pass SPF either, then you can't possibly hope to pass DMARC irrespective of
any test being done on the name's validity.

- It incorrectly classifies some names that are not used for email as not
> NP, simply because they have an A/ record.   It provides no method for
> the domain owner to signal that the name is not used for email and
> therefore should be treated as NP.
>

If they're not used for email, then they're not in DMARC's problem space.

At any rate, since PSD has been approved, I'm hoping the experiment is
underway, or will be soon, and then we might have some actual data about
the severity of this defect and thus also possibly some hints about ways it
can be mitigated.

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

[Murray S. Kucherawy]

I don't understand what "demeaning a domain's policy" means.

On Fri, May 28, 2021 at 10:20 AM Alessandro Vesely  wrote:

> On Fri 28/May/2021 17:43:37 +0200 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 think the text in RFC 7489 is quite good.  Perhaps a word could be added
> for
> pct=0; for example:
>
> OLD
> pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
>default is 100).  Percentage of messages from the Domain Owner's
>mail stream to which the DMARC policy is to be applied.  However,
>this MUST NOT be applied to the DMARC-generated reports, all of
>which must be sent and received unhindered.  The purpose of the
>"pct" tag is to allow Domain Owners to enact a slow rollout
>enforcement of the DMARC mechanism.  The prospect of "all or
>nothing" is recognized as preventing many organizations from
>experimenting with strong authentication-based mechanisms.  See
>Section 6.6.4 for details.  Note that random selection based on
>this percentage, such as the following pseudocode, is adequate:
>
> if (random mod 100) < pct then
>   selected = true
> else
>   selected = false
>
> NEW
> pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
>default is 100).  Percentage of messages from the Domain Owner's
>mail stream to which the DMARC policy is to be applied.  However,
>this MUST NOT be applied to any other use, such as skipping DMARC
>reports or demeaning a domain's policy.  The purpose of the
>"pct" tag is to allow Domain Owners to enact a slow rollout
>enforcement of the DMARC mechanism.  Using this tag, organizations
>can experiment with strong authentication-based mechanisms while
>lowering or even voiding the risk of non-delivery.  See Section
> 6.6.4
>for details.  Note that random selection based on this percentage,
>such as the following pseudocode, is adequate:
>
> if (random mod 100) < pct then
>   selected = true
> else
>   selected = false
>
> jm2c
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Sun, May 23, 2021 at 12:25 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> [...]
> 145 of 169 (86%) of non-verified domains had MX or A records,
> Of the 24 without MX or A records, 23 were spam and 1 was legitimate
> For 20 of the 24 , SPF on the From address returned NXDomain and were
> obvious spam without checking NS
> All of the remaining 4 domains had NS records
>

I believe this means that for 2.4% of the non-verified domains, or 0.65% of
the total domains, the proposed NS check yielded useful signal beyond the
standard checking of MX/A/.

One surprise for me:
> NS lookup on email3.reachmd.com returns NXDomain, but NS lookup on
> sg.email3.reachmd.com returns NS data.
> I thought that the existence of a subdomain would be sufficient for a
> domain to return NS data.
>

Right, it isn't.

Summary:
> - MX/A produced 11 false positives
>

Is that 11 false positive messages, or 11 false positive unique domains?
If the former, we're talking about around 0.3%.  If the latter, we're
talking about 1.8%.

So based on the data you collected, what conclusion are you proposing?

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Fatal flaws with the MX/A/ test
>
>- During DMARC policy evaluation, the process may have retrieved an
>SPF policy or a DKIM public key which is associated with the RFC5322.From
>domain or one of its descendants, even though the SPF test did not pass and
>any relevant DKIM tests did not verify.   Obtaining such data provides
>evidence that the domain name is in use by the domain owner and therefore
>the failure should be handled as SP rather than NP.   But adding this
>condition into the evaluation means that the evaluation is no longer
>deterministic, since the pool of supplementary information can vary from
>one message to the next..
>
>
In what way does the SPF and DKIM information fetched for one message taint
the resolution of the message coming after it from the same domain?


>
>- If the RFC5321.MailFrom domain is a parent of, or unrelated to, the
>RFC5322.From domain,. then the DMARC evaluation will not have checked for
>an SPF policy on the From domain.   The presence of an SPF policy indicates
>that the domain does exist and that the domain owner has implemented this
>sender authentication mechanism.If SPF is present, the policy
>evaluation should be SP, not NP, but the SPF policy is not considered by
>the MX/A/ rule.
>
> The same is true for an unaligned DKIM signature.

To me, this just means trying to piggyback the MX/A/ semantics off of
the presence of DKIM and SPF results is fallible.

Problematic ambiguity, depending on the presumed justification for the
> MX/A/ test
>
>- Both MX and SPF can be used to allow or block traffic.   MX can
>block message delivery using a host name of "." (RFC 7505) or any other
>invalid or non-routable name.   SPF can be used to block traffic if the
>policy is "-ALL".   If the selection of MX is intended to score the domain
>for a probability that it is used for email, then the block signals should
>be considered as indicators of NP, and the non-blocking signals should be
>considered as SP.   But then what to do if the signals are not in the same
>direction?
>
> I don't follow this at all.  A "." MX is an indication that the domain
exists but wishes to publish that it offers no way to receive mail.  It
might send perfectly legitimate and possibly even desirable email.  An SPF
"-all" is an indication that the sender handles all of its own mail (or at
least thinks it does).  It, too, might send perfectly legitimate and
possibly even desirable mail.  Neither of those strike me as equivalent to
"this domain doesn't exist for the purposes of email".


>-
>
> Constraints imposed by DNS
>
> DNS Queries for a specific RR type produce one of three results
>
>- Data:  An entry matches the requested name, exactly or by wildcard,
>and also matches the requested RR type.
>- NoData:   An entry matches the requested name, exactly or by
>wildcard, but the requested RR type cannot be matched
>- NXDomain:  No entry exists for the name, either exactly or wildcard,
>for any RR type.
>
> When multiple query types are checked for the same domain name, the
> multiple three-way results must be consolidated into a single binary
> conclusion: SP or NP.That conclusion will be heavily influenced by
> assumptions about how domain administrators will configure their domains,
> and such assumptions are difficult to apply globally.
>

DMARC is clear about this, in my opinion: RFC 7489, Appendix A.4, says
NXDOMAIN and NODATA are equivalent because in both cases "no such records
were published".  If you're arguing that this definition is hurting DMARC's
efficacy, I'd love to see some data.

The one exception to this problem is the NS query.   It acts as a query for
> type=ANY with the specific results discarded.   As a result, it has only
> two outcomes:
>
>- Data:  The name is used in DNS (policy applied = SP)
>- NXDomain:  The name is not used in DNS.(policy used = NP)
>
> Interesting.  Are there any data to suggest this is more effective or
accurate than the MX/A/ test?

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

Re: [dmarc-ietf] https reports, or nits in draft-ietf-dmarc-aggregate-reporting-02

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 12:22 PM John R Levine  wrote:

> On Fri, 7 May 2021, Murray S. Kucherawy wrote:
> > [ mail and web departments don't talk to each other ]
> > If that logic also holds for mail people and web people,
> > I imagine the lack of interest here has a similar basis; we're talking
> > about standing up a whole service or endpoint here, not just adding
> records
> > to a zone file.
>
> That's true but there's also the fact that a handful of analysis services
> like dmarcian and valimail collect a large fraction of DMARC reports.  If
> a few of them were interested in https reports, it'd be worth adding.
>

Ah, that's a good point.

I think both of them are represented here, and maybe some other report
processors.  Any feedback on this from them?

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Murray S. Kucherawy]

On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely  wrote:

> > - #62 makes reporting mandatory, which leaves the mail receiver with no
> > means to mitigate the privacy threat.
>

#62 (assuming it has WG consensus) makes it clear we really want reporting
to be mandatory, but at a glance I don't see any "MUST generate" sort of
language in the draft.  It may be in the other draft, but I haven't looked
there yet.  This draft does a pretty firm job of extolling the virtues of
report generation, however.

Personally, I think mandatory reporting wouldn't survive Last Call or IESG
Evaluation.  Even if it did, there's no mechanism to enforce it (i.e.,
operators that don't want to send such reports simply won't, and that's
that), other than maybe industry peer pressure, so I think what's in the
draft is as close as we can get.

Making it mandatory is possible since RFC 8962 established the protocol
> police.
>

I trust we're all aware of the significance of the publication date of that
RFC.

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

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

[Murray S. Kucherawy]

On Fri, Apr 23, 2021 at 11:21 AM  wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
> Title   : DMARC Aggregate Reporting
> Author  : Alex Brotman
> Filename: draft-ietf-dmarc-aggregate-reporting-02.txt
> Pages   : 23
> Date: 2021-04-23
>
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
>
>This document (along with others) obsoletes RFC7489.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
> [...]
>

I've done only a cursory review so far.  (This is *not* an official AD
review; I'm just participating here.)

First, thanks for the work put into this.  It was clearly not a trivial
undertaking.

Two quick comments, with something more detailed to follow:

RFC2119 used to be all there was to BCP 14, but BCP 14 now includes RFC
8174, which changed the boilerplate you need to include if you want to use
MUSTard language in IETF documents.  Please update the references and
boilerplate accordingly.  You'll find it in RFC 8174 itself.

Second, a pet peeve of mine when reviewing documents across all areas (and
you can thank Pete Resnick for this part of my personality): There are many
"naked" SHOULDs in here.  By that, I mean: "SHOULD [NOT]" presents the
implementer with advice but also a choice; an implementation is technically
compliant if it doesn't do what the SHOULD [NOT] says.  It strengthens the
document to provide the reader with some guidance as to when one might make
the informed decision to choose not to follow that advice; or, perhaps more
importantly, the SHOULD [NOT] feels like it's dangling or unjustified
without such guidance.

For instance, the first SHOULD in this draft is this one:

A single report SHOULD contain data for one policy
   configuration.

Why might an implementer not do this?  If there's no good answer to
this question, maybe this ought to be a MUST or a MAY, not a SHOULD.

Sometimes the answer here is backward compatibility. Maybe you really
want this to be a MUST, but existing implementations didn't do it, so
to grandfather them in, you made it a SHOULD.
In such cases, I think you should either say this, or say something
like new implementations MUST do this, but acknowledge that legacy
implementations might not comply, and consumers need
to be prepared to deal with that.

Also worth considering: You can be normative without saying MUST.
Continuing with this example, you could just as easily say: "A single
report contains data for exactly one policy configuration."
That's normative without using any BCP 14 language.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 7:53 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My problem with MX/A/AAA is that it IS a "mail enabled" test, which is
> exactly the concept that you rejected in a recent previous post.
>

I don't know how to answer that, since I don't know what "mail enabled"
means.

It is also an SMTP-dependent test.  Since SMTP addressing is independent of
> Message addressing, it is a poor fit at best for distinguishing between NP
> and SP.
>

I don't know what those middle two terms mean either.

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

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

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 1:25 PM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> >
> >I think it's an IETF tools problem.  The URL is theirs, not yours.
>
> tools.ietf.org is running on fumes and will be going away.  The
> htmlized version of the draft on the datatracker works:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02
>

Yeah, but it also means the tools team should probably arrange that
announcements of new I-Ds don't use the dead URLs.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My argument is that that A//MX has no useful relevance to determining
> whether the RFC5322.FROM address of a message should be evaluated based on
> SP or NP. NP is described as testing "non-existent", rather than "possibly
> able to receive mail". We need a test that evaluates whether the domain
> exists or not, and is maximally protected from false positives caused by
> host names and wildcards.
>
> If this group is convinced that A//MX is meaningful for the distinction 
> between SP and NP, I am asking someone to provide the justification and 
> define the algorithm.  Right now I have seen neither.
>
>
I continue to be unclear on why you think that test suite against a name is
inadequate.  Can you demonstrate a live case of a false positive or false
negative?  Perhaps an actual example will help to move this from the
abstract to the concrete.

In the meantime, here's what I think is the justification: If you try to
send me mail apparently from a domain that appears to have no email-related
presence in the DNS, that strikes me as a reasonable situation in which to
bounce such a message, and accordingly, a viable test for DMARC to use.
It's also relatively cheap, given that the DNS is a globally distributed
highly resilient database specifically built to answer such questions.  An
"email-related presence" is the three RRTYPEs that SMTP specifically uses
in trying to make use of a reverse path, and since this is an email
application, that also strikes me as reasonable.

You could (and some have) go one step further and attempt to make a
connection to whatever address that test resolved, on port 25, and see if
something answers.  You could go even further and try to interact via SMTP
with the server you find there, and test to see if the RFC5322.From address
responds 250 to RCPT.  But those are far more heavyweight tests, which can
add substantial time to DMARC processing, and such tests can get you
blocked from further interaction with those sites as they look like
address  harvesting probes.

Wildcards are a fact of life.  We will make no progress asserting that
everyone has to stop using them because they muddy DMARC's waters.  DMARC
could confirm on getting a positive MX reply that there is (or is not) a
wildcard MX in play, but I don't know how you would use that information
because the answer is the same both for "real" names and "fake" ones.  Is
this the basis for your position that the triple query done today is
inadequate?

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 4:19 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I was referring to this section of RFC 7208, which I have interpreted as a
> replacement for the older language of RFC 5321.
> Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if
> the system is confident that the return-path target is not forged.
> My perception has been that NDRs are widely ignored even when they are
> sent.  Is your experience different?
>

I interpret the cited RFC 7208 text to mean: "If you do SPF checking, then
don't generate an NDR to an address that has failed the SPF test."  It
doesn't supersede the more general guidance of RFC 5321, to which SPF is
basically an add-on.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 1:03 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> *The existence / non-existence test:*
>
> Given an identifier which is presumed to be a DNS domain name, perfrom a
> DNS lookup based on that name.
> The query may:
> [...]
> - return results using data from a parent domain
>

Can you give an example?  Otherwise I don't know what distinction you're
trying to make.

Is there a query or collection of queries that can ensure that we only
> accept results from the identifier domain and not from the parent?
>

I don't understand.  In the "answer" portion of a DNS record, you either
get what you asked for (or something matching it like a wildcard), or you
don't.  Anything else you might get is "glue" data, which as I recall is
easy to identify and exclude.


> *Wildcard DNS:*
>
> Wildcard entries create intentional ambiguity.   How do we suggest that
> wildcard results should be factored into the evaluation?
>

You can't, as far as I know.  That's the nature of wildcard records.

*The mail-enabled test:*
>
> Once existence / non-existence is determined, is it desirable to test for
> "mail enabled"?
>

It may be, but it's historically an expensive test with false negatives, as
far as I recall from my time working on mailing list software.  Those sorts
of probes get you into block lists if you do them a lot.

If so, what role should parent-domain results play in answering this
> question?
> If "Mail Enabled" is relevant, why is the existence of an SPF policy
> irrelevant?
>

I don't understand the purpose of the latter question.

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

Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 9:46 AM John Levine  wrote:

> >  2.  I’d welcome other inputs here on the original idea for this
> option.  I would imagine modern systems would be able to deal with rather
> >large XML files, though MTAs routinely set limits under 50M for accepting
> messages.
>
> I suggested an option to deliver reports by https POST or PUT, like
> MTA-STS does,
> with precious little interest, even though it's a much more efficient way
> to ship
> large files around since it doesn't need base64 encoding and doesn't relay.
>

I agree that it's optimal.  But long ago (in DKIM, at least) we took note
of the fact that mail people and DNS people in large organizations are
often not the same teams and sometimes it's hard for one to get something
out of the other.  If that logic also holds for mail people and web people,
I imagine the lack of interest here has a similar basis; we're talking
about standing up a whole service or endpoint here, not just adding records
to a zone file.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 9:06 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I objected vigorously during the PSD review, but the Area Director
> directed me to defer the discussion so the experiment could move forward.
>

Can you please cite what I said to give you this impression?  I don't
remember saying anything that rose to the level of "directed".

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 5:02 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have begun data collection on the effectiveness of the MX and A tests.
>  Wildcard DNS entries increase the frequency of false positives and reduce
> the usability of the test.   For example, "msaqq189.ford.com" returns a
> set of MX results, but I rather doubt that I made a lucky guess and found a
> mail domain that Ford Motor actually uses.
>

There's no need to guess.  You can query for wildcard records:

$ host -t mx '*.ford.com'
*.ford.com mail is handled by 10 cluster4.us.messagelabs.com.
*.ford.com mail is handled by 20 cluster4a.us.messagelabs.com.

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

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

[Murray S. Kucherawy]

I think it's an IETF tools problem.  The URL is theirs, not yours.

On Fri, May 7, 2021 at 7:48 AM Brotman, Alex 
wrote:

> I sent this over to support the other day, and it was forwarded to
> operations.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* Murray S. Kucherawy 
> *Sent:* Monday, May 3, 2021 8:03 PM
> *To:* Brotman, Alex 
> *Cc:* Alessandro Vesely ; IETF DMARC WG 
> *Subject:* Re: [dmarc-ietf] I-D Action:
> draft-ietf-dmarc-aggregate-reporting-02.txt
>
>
>
> On Mon, May 3, 2021 at 11:49 AM Brotman, Alex  40comcast@dmarc.ietf.org> wrote:
>
> I apologize, corporate mail gateway does that (I've asked them to exempt
> ietf.org
> <https://urldefense.com/v3/__http:/ietf.org__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Y97QeLs$>
> now). The links have an expiration of a few days.
>
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6bqFdLuE$>
>
>
>
> One of the URLs that came from the datatracker was:
> https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Ys_rsaT$>
>
>
>
> It appears to return blank for me as well.
>
>
>
> -MSK
>
___
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

[Murray S. Kucherawy]

On Wed, May 5, 2021 at 9:27 PM Seth Blank  wrote:

> The Chairs ask group participants to explicitly speak up if:
> 1) they intend to participate in the interim
>

I'll be there.

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Murray S. Kucherawy]

On Mon, May 3, 2021 at 5:26 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I meant to say that we need N unique (and valid) smtp TO addresses, so
> that an attacker cannot send a single email address and wait for an rua
> report to know where it lands.
>
> Valid addresses are needed to hinder usage of bogus addresses to defeat
> the test.
>

Is that enough?  If I control a domain, I can make up any number of
apparently-valid envelope addresses I want.

Using DKIM selectors for tracking will also put a huge load on DNS if
> implemented at scale [...]
>

How so?

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

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

[Murray S. Kucherawy]

On Mon, May 3, 2021 at 11:49 AM Brotman, Alex  wrote:

> I apologize, corporate mail gateway does that (I've asked them to exempt
> ietf.org now). The links have an expiration of a few days.
>
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
>

One of the URLs that came from the datatracker was:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02

It appears to return blank for me as well.

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

[dmarc-ietf] Chair rotation

[Murray S. Kucherawy]

Colleagues,

As Barry has stepped down from the IESG, he's available to re-engage in
other roles.  He has generously volunteered to invest time and energy in
the DMARC WG to carry the torch once the design teams complete their work
in the near future.

With much gratitude to all of the current chairs for managing this working
group, I will be rotating Alexey and Tim out so they can focus on other
things with their limited time, and bringing in Barry.  Alexey, I suspect,
needs all available bandwidth for EMAILCORE.  I know Tim is also a busy man
with DNSOP.  Seth, now free of the work that is EMAILCORE, will remain.

Thank you once again,

-MSK, your friendly neighborhood ART AD
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Mon, Apr 12, 2021 at 3:25 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
> Title   : Experimental DMARC Extension For Public Suffix
> Domains
> Authors : Scott Kitterman
>   Tim Wicinski
> Filename: draft-ietf-dmarc-psd-12.txt
> Pages   : 14
> Date: 2021-04-12
>
> Abstract:
>Domain-based Message Authentication, Reporting, and Conformance
>(DMARC) permits a domain-controlling organization to express domain-
>level policies and preferences for message validation, disposition,
>and reporting, which a mail-receiving organization can use to improve
>mail handling.
>
>DMARC distinguishes the portion of a name that is a Public Suffix
>Domain (PSD), below which organizational domain names are created.
>The basic DMARC capability allows organizational domains to specify
>policies that apply to their subdomains, but it does not give that
>capability to PSDs.  This document describes an extension to DMARC to
>fully enable DMARC functionality for PSDs.
>
>Some implementations of DMARC consider a PSD to be ineligible for
>DMARC enforcement.  This specification addresses that case.
> [...]
>

Thanks.  This is now in IESG Evaluation and will probably make the next
telechat (on the 22nd).

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

Re: [dmarc-ietf] NXDOMAIN

[Murray S. Kucherawy]

On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Why is it problematic to document this risk, and indicate that when "No
> Policy detected" occurs, it is recommended to check whether the domain
> exists, and if it does not exist then local policy for nonexistent domains
> should be applied?
>

Can you put together an example message exhibiting the properties you're
talking about, and what DNS records are in play in that scenario?

I still can't picture the problem you're trying to solve.

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

Re: [dmarc-ietf] NXDOMAIN

[Murray S. Kucherawy]

Further to what Todd said:

On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I am hearing that we have a defacto standard to check return-path using
> MX/A/.  It is implemented with sufficient breadth,that (unlike SPF)
> senders should consider it mandatory.Additionally, and more importantly
> for this group, it is presumed to be equally applicable for validation of
> the RFC5322.From, even though that address is unrelated to the
> SMTP return-path.  But because the test is not explicitly documented, some
> products (my vendors) do not implement it at all, leaving a protection gap.
>

I think I'm confused about how this ties to DMARC.  What you're describing
is, I believe, a common anti-spam tactic that was in use even before SPF or
DKIM were a thing.  It probably still is, irrespective of those protocols.

However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC
had such a test, but it was removed because of too many false negatives.


> If DMARC is to be dependent on return-path-check and inter-dependent with
> ARC, then I do not see how we can avoid producing a formal specification
> for the test and integrating it into A-R, as a co-requisite to the DMARC
> specification.
>

How is DMARC dependent on a return path check?  SPF is, but DMARC isn't.
DMARC only cares what the SPF result was, and whether the domain it
evaluated is aligned with the RFC5322.From domain.  In fact, a DMARC filter
could operate correctly with no knowledge of what the return path was,
provided the A-R fields are correct and complete.

Another perspective: If the RFC5322.From domain doesn't exist, it's not
possible for a DMARC policy to be discovered for it, nor is it possible
that SPF or DKIM will pass for it or align to it.  Therefore, is such a
domain even in scope here, much less a need to describe a way to test it?

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

Re: [dmarc-ietf] NXDOMAIN

[Murray S. Kucherawy]

On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with
> all the information needed to make a decision.   (The sender is violating
> ICANN name registration policies).   Ignoring NXDOMAIN and continuing to
> look for MX/A/ is a waste of information and a waste of resources.
>

I agree.

But clearly, the norm in this group is to check MX/A/AAA because it seems
> likely to be a more powerful filter.   I wonder if that is actually true.
>

In the context of the code doing the SPF evaluation, I don't think it is.
If TXT returns NXDOMAIN for a name, so will any other type.  That's the
definition of NXDOMAIN; there are no data of any type for this name.  See
also RFC 8020.  Fortunately, a properly functioning local nameserver will
cache the answer and just repeat it when subsequent MX, A, or  queries
get issued, so the waste is relatively cheap.

I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting "That
name does not exist (rcode=NXDOMAIN)" differently from "That name exists,
but there's no record of the type you requested (rcode=NOERROR,
ancount=0)", which can result in some wasted time, but I expect the end
result would be the same.

1)  A/ is a pretty weak test, since many domains have A/ records on
> the domain name for web purposes.
>

Independently of SPF, it's not a weak test since the standards allow
exactly this kind of setup for a domain that wants to receive mail.  Again,
Section 5.1 of RFC 5321.

I do respond to SPF NONE by applying a best-guess SPF policy which includes
> MX and A, and sometimes produces SPF PASS.   But I no longer do that for
> non-existent domains.
>

"Best guess SPF" is discouraged.  See
http://www.open-spf.org/FAQ/Best_guess_record/.

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

Re: [dmarc-ietf] NXDOMAIN

[Murray S. Kucherawy]

On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> As a result of earlier discussions, I have been investigating NXDOMAIN as
> an email filtering criteria.
>
> One question from those discussions was the best way to detect NXDOMAIN.
> I realized that I needed a query which specifically returns NXDOMAIN as a
> result, not simply the absence of a particular result.   Additionally, a
> lookup on A/ with results could represent either a domain name with no
> host segment, or a host segment and a parent domain..   Consequently, the
> best test seems to query for type=TXT, match=domainname.
>
> I have applied this rule to incoming RFC5322.MailFrom addresses and found
> the test to be useful.  For my mail stream, 20% of the messages with
> SPF=NONE have this result because of NXDOMAIN.  The percentages were
> roughly equal whether evaluating unique domain names or unique messages.
>
> While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is
> probably unwanted, NXDOMAIN has a higher probability of being unwanted.
>
> I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but
> hope to get that done in the weeks ahead.
>
> Is anyone else collecting data on NXDOMAIN, and able to share experience?
>

Due to terminology pedantry, I'm having trouble understanding this.
Someone please check my math here:

If I ask for MX records for example.com, NXDOMAIN comes back as the
response's error code not if there's no MX record for that name, but rather
if there are no records of any kind for that name.  On the other hand, if
there's no MX but there is an A or , I'm going to get a success error
code (NOERROR), but with an answer count of 0.

So I don't know what "detect NXDOMAIN" means: Your DNS reply either has
that error code, or it doesn't.

If instead you're trying to determine whether a name can receive mail, at
least according to DNS data, it seems to me you query one record type (MX)
and see if you get >0 answers, 0 answers, or NXDOMAIN.  If you got
NXDOMAIN, you're done; there's no way to route this message.  If you got 0
answers, you should query A and/or  and send there.  If you got >0
answers, now you have to resolve the names you got to addresses; assuming
at least one of those resolves, you have someplace to send the message.
This is what RFC 5321 says to do.

I don't think querying TXT would tell you anything more.

What am I missing?

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

Re: [dmarc-ietf] NXDOMAIN

[Murray S. Kucherawy]

On Mon, Apr 5, 2021 at 3:08 PM Todd Herr  wrote:

> I did not require an MX record, per se; the requirement was that there be
> either an MX record or, failing that, an A/ record.
>

Given that this is what RFC 5321 Section 5.1 prescribes in terms of
answering the question "Where should I try to connect to deliver this?",
that seems like a sane thing to use as a test.

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

Re: [dmarc-ietf] AD Evaluation: draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Fri, Mar 19, 2021 at 9:35 AM Murray S. Kucherawy 
wrote:

> And with that, I'll set up the Last Call.
>

Last Call has ended.  Scott/Tim, please make whatever resulting edits are
appropriate and let me know when it's ready for a telechat.  I've marked it
as "Revised I-D Needed".

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

Re: [dmarc-ietf] Sender vs From Addresses

[Murray S. Kucherawy]

On Thu, Mar 25, 2021 at 2:39 PM Charles Gregory 
wrote:

> I DO think this is an unnecessary problem that CAN be fixed/improved in
> one of two fairly straightforward manners through DNS (behavior switch or
> list authorized alternate domains).  And I can't see anything but upside in
> doing so; nobody has demonstrated a downside anyways.  Yet I have no idea
> how such decisions are made or the part that anyone plays here.  I will
> review RFC 4407.  Thanks.
>

Even if ATPS had taken off, there's a matter of scale: Very large mailbox
providers like Gmail, Yahoo, etc., would need to find some way to populate
such a list.  They could let their users do it (though getting users to do
more work to manage their accounts is certain to be an uphill battle with a
lot of configuration detritus as collateral), or they could try to automate
it (a non-trivial and probably open-ended engineering investment).  Neither
path is appealing.

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

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

[Murray S. Kucherawy]

Just to nit-pick:

On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely  wrote:

> There's still a few style points that I'd propose.  They can be dealt with
> in
> auth48.
>

After Last Call, please.  Don't wait for AUTH48 to process this feedback.

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

[dmarc-ietf] AD Evaluation: draft-ietf-dmarc-psd

[Murray S. Kucherawy]

Happy to see this in my inbox this morning.  Thanks to all that contributed
to getting this final text to where we want it.

A couple of minor points, which you can deal with after any Last Call
comments come in rather than cranking a new version now:

In the Introduction where you say "Public Suffix List" for the first time,
you might want to also introduce the PSL acronym since you use it later in
that section.

Section 3.2 introduces and registers a new tag pointing to this document,
but it also updates two existing tags yet does not add references to this
document in the registry.  I'm not sure what the best way to resolve this
is, or if it's even worth fixing for an experiment, but it feels asymmetric.

And with that, I'll set up the Last Call.

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

Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues

[Murray S. Kucherawy]

On Tue, Mar 2, 2021 at 3:51 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Because CNAME usage was not mentioned in the previous DMARC document,
> existing implementations may not have tested this configuration.   For the
> policy publishing organization, this increases the possibility that some
> recipients may treat the mail as not protected by DMARC. As with any
> deployment issue, the publishing organization has no reliable way to know
> if the deployment of DMARC implementations with full CNAME support is
> "essentially complete".  This uncertainty may be acceptable for some
> organizations, but may be an obstacle for others, depending on their
> motivations for implementing DMARC.
>
> On the implementation side, the use of CNAME will introduce the
> possibility of referral errors, which may or may not require mentioning in
> the DMARC specification, since such issues have probably been addressed in
> core DNS documents.   The issues that come to mind are:
> CNAME referrals to non-existent names
> Nested CNAME referrals (what depth is allowed?)
> CNAME referrals that produce loops or excessive nesting depth.
>

I don't understand why we need to say anything special about CNAMEs here.
They are processed by the resolver as they would be for any other
application.

If there's a bug in opendmarc, that's a different question that has nothing
to do with the output of the working group.

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

[Murray S. Kucherawy]

These all work for me.  Thanks for the contributions.

Scott, please work your magic with a revision so the chairs can request
publication and we can get this on its way.

-MSK

On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker  wrote:

> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>
> Especially in the case of the PSD policies, one should not expect that the
> controlling organization would necessarily be "a mail-originating
> organization". Generally the idea is to *disavow* being such :-)
>
> Suggested alternate text:
>
> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
> permits a domain-controlling
> organization to express domain-level policies and preferences for message
> validation, disposition, and reporting,
> which a mail-receiving organization can use to improve mail handling.
>
> +1
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red crossdave.crock...@redcross.org
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba  wrote:

> I agree that the abstract is unclear.  This makes no sense to me:
>
>domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>occurred; it does not permit a domain name to have both of these
>properties simultaneously.
>
> I don't understand the distinction that it's trying to make between
> the two possibilities.
> I also don't see the antecedent to "these domains" in the final
> sentence of that paragraph.
>
> Beyond that:
> > I'm at a loss to understand what's confusing.  I'm not convinced that
> "registrations" in the
> > context of domain names is unclear to a reader familiar with this space.
>
> I am absolutely convinced that it is.  Think of people in M3AAWG, for
> whom this is very relevant.  Many of them don't know much about
> registries, registrars, and such, and in general, the average reader
> won't understand the difference, from a "registration" standpoint,
> between facebook.com (which is registered) and "www.facebook.com"
> (which is not).  To the average reader, "facebook.com" is registered
> under com, and "www.facebook.com" is registered under facebook.  And
> the ones who don't think that will likely not understand why we can't
> just talk about second-level domains and be done with it.
>

Actually that's a community that I would expect to know exactly what all
those terms mean and how they are all related.

I think the use of "registered" seems to be the source of some of this
confusion.  To work with the example you gave here, I agree that "
facebook.com" is registered (under "com"), but disagree that "
www.facebook.com" is registered at all; "facebook.com" was delegated to
some company that now "owns" that piece of the namespace tree and can
create whatever it wants under there without any external arrangement.  To
my mind, "register" involves a specific transaction, sometimes involving
money, with whoever gates access to make those delegations.

All that needs to be explained in the Introduction, not the Abstract.
> But the Abstract has to explain enough for a reader to understand why
> she might or might not be interested in getting the document and
> reading it.  So it's going to be tough to word it carefully and to
> keep it concise.  But we have to.
>
> Stressing a point:
> We very clearly do NOT want to explain this stuff in the Abstract.  In
> fact, we don't have to explain much at all in the Abstract.  What we
> have to do is make sure that the Abstract doesn't say stuff that's
> *wrong* or confusing.  So let's try to find some fifth-grade language
> that can suffice, and then make sure the Introduction has the right
> words to make it clear to people who know how to do email, but who
> don't already understand the issues involved here.
>

How's this?:

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.

   Within the Domain Name System (DNS) on the public Internet, which is

   organized as a tree, some nodes of that tree are reserved for use by

   registrars, who delegate sub-trees to other operators on request.
DMARC currently
   permits expression of policy only for such sub-trees.  There is a
marked desire to

   be able to express policy for the reserved nodes as well.  This document

   describes an experimental extension to DMARC to add that capability.

If we like that as a replacement Abstract, I'll carry on and propose a
revision to the Introduction.

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

[Murray S. Kucherawy]

Circling back to this:

On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker  wrote:

> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>
> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:
>
>>
>> Abstract
>>
>>DMARC (Domain-based Message Authentication, Reporting, and
>>Conformance) is a scalable mechanism by which a mail-originating
>>organization can express domain-level policies and preferences for
>>message validation, disposition, and reporting, that a mail-receiving
>>organization can use to improve mail handling.  The design of DMARC
>>presumes that domain names represent either nodes in the tree below
>>which registrations occur, or nodes where registrations have
>>
>> DMARC does not have 'registrations'.
>>
>
> It's referring to domain name registrations, not DMARC registrations.
>
> Also the occur/occured contrast has no obvious meaning to me.  Really, I
>> have no idea what's intended by it.
>>
> "exist"?
> "take place"?
> "are made"?
> "are done"?
>
> The issue wasn't synonyms but semantics.  'registrations occurred' has no
> obvious DMARC meaning.
>
> unless, perhaps, the meaning is 'domain names exist', but that still
> doesn't explain the contrast being drawn.
>
I'm struggling to understand the concern here.  I think we all know what it
means to register a domain, and that the namespace is arranged as a tree,
and that trees are made up of nodes, and that some nodes are above the cut
where registrations take place while the rest are below.  What other
meaning might someone in this space infer from this text?

Maybe this is better, just for the sake of having something else to look at?

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent nodes in the DNS tree that are either
   reserved as points below which new domain name registrations are made, or are
   the results of those registrations; it does not permit a node to
have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

Apart from that, I'm at a loss to understand what's confusing.  I'm not
convinced that "registrations" in the context of domain names is unclear to
a reader familiar with this space.

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely  wrote:

> I just run a quick test on my current folder.  Out of 3879 messages I
> extracted
> 944 unique helo names.  721 of these matched the reverse lookup exactly.
> Out
> of the 223 remaining, 127 had an SPF pass for the helo identity anyway.
> So in
> 96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining
> ~90%
> something worth considering?
>

I am admittedly quite heavily biased against using the HELO/EHLO value for
anything.  I have simply never found value in it, probably because at the
SMTP layer it's simply a value that gets logged or used in cute ways in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a bogus
value, so it's even explicitly not useful to me.

Even if it's not junk, there's pretty much always something else on which
to hang a pass/fail decision about the apparent authenticity of a message
that at least feels safer if not actually being more sound.  Or put another
way, if you present to me a DKIM-signed message with a MAIL FROM value and
the only thing that passes is an SPF check against HELO, I'm mighty
skeptical.

Anyway, I'll let consensus fall where it may.

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

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:

>
> Abstract
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.  The design of DMARC
>presumes that domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>
> DMARC does not have 'registrations'.
>

It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me.  Really, I
> have no idea what's intended by it.
>
"exist"?
"take place"?
"are made"?
"are done"?

>
>occurred; it does not permit a domain name to have both of these
>
> "both" of what?  registration?
>

It's describing properties of nodes in the domain name tree.  DMARC's
current design stipulates that every node is either (a) a node below which
registrations can occur, or (b) a node at which a registration has
occurred.  An example of the former is "org", and an example of the latter
is "ietf.org" and its entire subtree.

   properties simultaneously.  Since its deployment in 2015, use of
>DMARC has shown a clear need for the ability to express policy for
>these domains as well.
>
> Which domains?
>

The intent is to augment DMARC's ability to describe the domain name tree
such that a node can be both (a) and (b) at the same time, for the purposes
of policy expression.  So those are the nodes (domains) of interest.


>Domains at which registrations can occur are referred to as Public
>Suffix Domains (PSDs).  This document describes an extension to DMARC
>to enable DMARC functionality for PSDs.
>
> This is the definition of public suffix provided by the PSL folk:
>
> "A public suffix is a set of DNS names or wildcards concatenated with
> dots. It represents the part of a domain name which is *not* under the
> control of the individual registrant."
>

That seems to say the same thing to me, though perhaps more crisply.

>
>This document also seeks to address implementations that consider a
>domain on a public Suffix list to be ineligible for DMARC
>enforcement.
>
> seeks?
> [...]
>

Hmm.  Maybe that sentence can be struck entirely.  Is this a problem with
certain implementations only, or with DMARC as specified in 7489?  If the
latter, I think we can drop this because the main paragraph already says
this.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 8:21 AM Kurt Andersen (b)  wrote:

> On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski  wrote:
>
>>
>> I suggest adding it to this paragraph:
>>
>>This document specifies experimental updates to the DMARC and PSL
>>algorithm cited above, in an attempt to mitigate this abuse.
>>
>
> update to DMARC = yes; update to PSL = no
>

Why?


>
>> On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>>>
>>>> Since this is an experiment, Appendix A discusses the updates that
>>>> happen.  we don't actually say explicitly "if the experiment is a success,
>>>> the following changes will be made" and perhaps I should add some wording
>>>> like that.
>>>>
>>>
>>> Something like this, perhaps?
>>>
>>> "A standards track update to [RFC7489] will take into account the
>>> results of this experiment."
>>>
>>> ... somewhere in Section 1.
>>>
>>
> A normative dependency from an experimental spec imposed upon a standards
> track spec seems like a bad idea to me. At the very least it would impose a
> timing constraint that DMARCbis could not be "completed" until after the
> PSD experiment is "completed", analyzed and consensus achieved.
>

I thought that was exactly the intent here.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:

> Since this is an experiment, Appendix A discusses the updates that
> happen.  we don't actually say explicitly "if the experiment is a success,
> the following changes will be made" and perhaps I should add some wording
> like that.
>

Something like this, perhaps?

"A standards track update to [RFC7489] will take into account the results
of this experiment."

... somewhere in Section 1.

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

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

[Murray S. Kucherawy]

On Thu, Jan 28, 2021 at 1:42 PM John R Levine  wrote:

> > This to me is almost exactly the same thing as saying "Don't generate a
> > bounce about a bounce",
>
> Because these are not bounces.  They are not even a little bit like
> bounces.  Bounces are about invalid recipient addresses, but these have no
> relation to anything about the recipient address.
>

Yes, I realize the difference.  I was making an analogy.

They are fresh new messages sent from a system that presumably cares
> enough about DMARC to send reports about it, and presumably wants to send
> all of its mail with DMARC alignment.  If they are unaligned, that is
> because the sending system is broken, and if that systems publishes an
> ruf= tag, it is specifically asking to be inforned about exactly that
> breakage.
>

OK, let's hop into your example.  I care enough about DMARC to send reports
about it, and I want to send all of my mail aligned.  I send a test message
that ends up unaligned somehow, perhaps through a broken relay I don't own,
and I would ideally like to get one message back that tells me that.  If I
happen to send my test to a place that unintentionally sends an unaligned
report back to me, perhaps because of the same relay, I'm going to get
flooded, even though my local setup is verifiably correct.  And, probably,
so are they.

You're saying the only real answer here is that the two end operators in
this example need to fix their evidently-crappy setups, or change their DNS
records to remove the "ruf" value until they can get the guy in the middle
to fix whatever's broken?

Maybe I'm the dim one, but I can't see why it's manifestly absurd to think
we might somehow augment either the report or the message containing it by
adding just enough metadata someplace to signal one end or the other, or
both, to avert the flood.

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

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

[Murray S. Kucherawy]

On Wed, Jan 27, 2021 at 7:08 PM John R Levine  wrote:

> Which of these should we do:
>
> A) Everyone in the world who produces failure reports adds special cases
> to look for incoming failure reports, and heuristics to try and recognize
> failure reports in the wrong format, and when it finds one of them, it
> makes a note not to send a failure report about it.
>
> B) Someone slaps me upside the head and I fix my SPF record so my reports
> are sent correctly.
>

I'm suggesting:

C) Stipulate somehow that generated reports should not contain data about
received reports.  (If you do that, then you likely obviate the need to
generate a new report back to that operator in the first place.)

This to me is almost exactly the same thing as saying "Don't generate a
bounce about a bounce", which has been part of SMTP for decades (it's a
SHOULD NOT in 2821).  I don't understand why you're saying it's appropriate
in one but a non-issue in the other.

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Murray S. Kucherawy]

On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely  wrote:

> > DKIM (in its simplest form) returns N tuples of the form (d= domain,
> > pass/fail).  All of them were run through exactly the same check; all of
> > them were attached to the message in exactly the same way; all of them
> have
> > essentially identical semantics.  Giving them equal footing makes sense
> to
> > me.
> >
> > The two identifiers in SPF hold different places in the SMTP session, and
> > have different semantics.  I think treating them differently is also just
> > fine.
>
> It is relevant that both identifier come from /the same/ SMTP session.
> That's
> not true for many DKIM signatures.
>

I guess if report consumers really want this information, we can include
it.  I just don't see the value in the HELO parameter if it's effectively
random junk in the session.  At least a passing DKIM signature is
associated with a domain that existed at some point in time and whose DNS
contained apparently-valid public keys.  I can mostly type anything I want
to HELO or EHLO.

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

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

[Murray S. Kucherawy]

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.

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

Re: [dmarc-ietf] understanding section 7.2

[Murray S. Kucherawy]

The schema's already pretty large, and probably has to be, but maybe a
trivial example report would be reasonable to craft and include?

On Tue, Jan 26, 2021 at 11:05 AM Michael Thomas  wrote:

>
> So I'm an outsider who has not tried to digest what's going on in the
> reports until recently so my eyes are fresh. Basically section 7.2 is
> extremely hard to understand what is in the reports. I know that the XML
> is what ought to be normative, but a little bit of ascii art could go a
> long way to helping people understand what the reports do and don't
> have. I've been staring at the XML all morning trying to understand it
> and it is very difficult when all you're trying to do is figure out what
> the reports supply or not. It would be extremely helpful to layout what
> is in each record for human consumption to just understand what the
> reports do and don't contain.
>
> Mike
>
> ___
> 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