Re: [dmarc-ietf] ARC questions

[Murray S. Kucherawy]

On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Michael, I think the purpose is stated well enough:   Mailing lists want
> to keep adding their content to messages, without being blocked by
> recipients.   This means that they have to provide recipients with enough
> information for them to accept the forwarded content.   Google and
> Microsoft seem to be on-board with this project, so it seems pretty
> successful already.   This train is not easily stopped.
>

That sounds about right.  Put another way: DMARC's success is at least in
part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to
carry forward from the MLM, in a credible way, an indication of what the
MLM saw in terms of DKIM results when the message got to the MLM.  So then,
although an author signature will fail post-MLM, the MLM signature will
pass, and the ARC data will tell you that the author signature was good
when the MLM got it.  If you trust the chain, then that can be an
alternative to the DKIM input when the final recipient performs a DMARC
evaluation.

Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps not as
concretely as one might like.

In my opinion, ARC does leave a lot of unanswered questions about how you
> use the data that ARC provides.   Again, the big organizations have the
> brain power at their disposal to figure that out for themselves, later.
>

This is why it was published as Experimental.  Its efficacy is not (yet)
known, nor are any side effects.  Although, now that you have me thinking
about it: It's been a year; have we any meaningful data about this yet?

It seems like a lot of software logic to create an ARC set, even more code
> to parse it, and even more code to use it intelligently.   This is a big
> problem if you are trying to write the code yourself, but a small problem
> if you have a big programming organization.
>

When I implemented it, there was a great deal of processing logic that was
recycled from DKIM.  That was advantageous.  But I agree, someone
implementing ARC with no context at all could easily find it a challenge to
get it to interoperate.

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

Re: [dmarc-ietf] ARC questions

[Douglas Foster]

Michael, I think the purpose is stated well enough:   Mailing lists want to
keep adding their content to messages, without being blocked by
recipients.   This means that they have to provide recipients with enough
information for them to accept the forwarded content.   Google and
Microsoft seem to be on-board with this project, so it seems pretty
successful already.   This train is not easily stopped.

As to the technical pieces:
- Unvalidated data, which includes the entire Received header chain, is
only useful for blacklisting.   A spammer will fabricate any header content
that he thinks will get his garbage through your spam filter.

- The recipient filter needs to be convinced that the submitting MTA is not
lying and that the submitting MTA has not been duped.   Digital signatures
are the only tool we have for validating forwarded content.   Since the
goal is favorable treatment, digital signatures are necessary.

- Interlocking signatures are needed to get around the problem of DKIM
signatures being damaged by mid-stream content changes.

As John said early on, this all works in conjunction with private knowledge
that decides who you believe is not lying.   Google and Microsoft have that
kind of data.

In my opinion, ARC does leave a lot of unanswered questions about how you
use the data that ARC provides.   Again, the big organizations have the
brain power at their disposal to figure that out for themselves, later.

It seems like a lot of software logic to create an ARC set, even more code
to parse it, and even more code to use it intelligently.   This is a big
problem if you are trying to write the code yourself, but a small problem
if you have a big programming organization.

The email market is moving to a few large organizations that provide
hosting for most everyone, a few other large cloud services that provide
filtering for much of the remainder, and then everybody else.   Smaller
organizations are stuck with lousy vendor options or custom development,
neither of which is entirely satisfactory.   ARC may not be the right
solution for smaller organizations with fewer development resources, but
80% of the world needs the big organizations to be successful, and the
mailing lists need the big organizations to be accepting of their product.
 ARC seems to meet those important goals.

Doug Foster


On Tue, Nov 24, 2020 at 6:57 PM Michael Thomas  wrote:

>
> On 11/24/20 3:24 PM, Brandon Long wrote:
>
>
> On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas  wrote:
>
>>
>>
>> Sorry, changing the auth-res to old-auth-res and dkim signing the
>> message would be completely sufficient, and far easier to understand
>> with a lot less bloat. All of this hand wringing about dozens of message
>> manglers in the path before it get to the destination and not be able to
>> figure out which auth-res was which seems wildly out of proportion for
>> what the normal case is: 1 message mangler in the path before it arrives
>> at the receiver's domain. Just like this message right here. That's why
>> I asked how common that was, which was dismissed, but not answered.
>>
>
> Note that this was exactly what we started with,
> X-Original-Authentication-Results
> and with Google's implementation signing that with X-Google-DKIM-Signature.
>
> Our version didn't just sign with DKIM-Signature because of the reasons
> already stated in this
> thread, that our understanding of how DKIM-Signature was being used made
> it a poor choice.
>
>
> Sorry, I didn't see that. Pointer?
>
>
> Our experience also showed that more than one hop is quite common in
> enterprise deployments,
> and those are also the places where the most complexity arises.  Others
> shared our experience
> as well.
>
> That's more than one modifying intermediary in *separate* administrative
> domains? Within your own administrative domain there shouldn't be an issue
> of trust since you can trust your own servers auth-res and that they are
> not maliciously trying to forge an auth-res for better treatment. and
> course it's best to stop a bad message as soon as possible in the mail
> pipeline if for no other reason than why waste the resources.
>
>
>
> You say that your message had 1 mangler in the path, but really you don't
> know that.  It is
> likely that some people on this list are on enterprise accounts who are
> behind mangling inbound
> gateways (rewriting urls to go through safety checking hops is common, for
> example).  Or maybe
> they are on with University accounts using exchange but forward their mail
> to a personal or department
> gmail account.
>
>
> Well sure, I'm sure it can happen but is it common enough to worry about?
> And I'm still not convinced that figuring out who signed what and which
> auth-res it belonged to is in insurmountable problem. for one, there are
> received headers which better not be getting out of order to help correlate
> with the messages' path through intermediary verifiers too.
>
> Mike
>
> 

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[ned+dmarc]

> In article  you write:
> >> One of the points of the tree walk is to get rid of the PSL processing.
> >

> > The PSL processing is a local lookup on an in-memory suffix tree.  How is 
> > it a
> > progress to replace it with a tree walk?  A PSL search is lightning faster 
> > than
> > even a single DNS lookup, isn't it?

We added PSL support for other reasons some time back.

FWIW, there were some intricacies I didn't like in the suffix tree approach.
And since memory use really isn't a consideration for something this small, I
opted for multiple lookups in a hash table instead. We have our own hash table
code and loadable format, but there are compile-to-loadable-format tools out
there if you don't want to roll your own.

> You have to download a copy of the PSL,

Hopefully you're doing that in the background...

> read it into your program, and
> parse it into some internal form. The PSL is over 200K of text and
> 13,000 lines, so while it's not a large file, it's not zero either.

Our implementation processes a bunch of text files from various sources, of
which the PSL is less than 5% of the total size, into our loadable format.

I just checked, and it takes a litle over 2 CPU seconds to run the program. On
an 333Mhz Alpha.

I really don't think this is a concern.

> If you're lucky you can amortize your PSL parsing across multiple
> DMARC checks, but your DNS cache amortizes DNS lookups across mutiple
> checke, too.

Parse only happens when one of the input files changes. Why would you
implement it any other way? 

> The DNS approach has the advantage that you don't have to depend on a
> third party's text file updated at unknown intervals, and also makes
> it easier to deal with what I've called the Holy Roman Empire problem.

So you download and check every week or whatever. Still not seeing a problem.

Finally, there's the HRE issue. Which I guess could be a problem. But so can
DNS usage, which is subject to what I'll now call the fiefdom problem, where
you're required to use a DNS service operated by someone else in your org and
they are ... problematic.

Of course DNS use is unavoidable. Even so, the fiefdom problem has led to
requests to minimize DNS usage by any means possible.

The HRE problem remains theoretical for us at least.

Ned

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely  wrote:
>
>> The PSL is the result of a community-maintained effort. ...

>I'm curious as to whether this is the consensus opinion of the PSL.  It's
>my impression that it is not, given the arguments that supported the
>creation of the DBOUND working group in the first place, for instance.

The PSL lives at github and has three committers.

https://github.com/publicsuffix

Anyone can send in a pull request and they have a process to decide
what to accept. I agree they do a pretty good job but it is a tiny
project run by a few volunteers. They do not go looking for changes
beyond tracking what's in the root.

Keep in mind that the purpose of the PSL is to manage cross-site
cookies in web browsers. If it works for anything else, it's a
coincidence.

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

Re: [dmarc-ietf] ARC questions

[John R Levine]

On Tue, 24 Nov 2020, Michael Thomas wrote:
Our experience also showed that more than one hop is quite common in 
enterprise deployments, and those are also the places where the most 
complexity arises. Others shared our experience as well.


That's more than one modifying intermediary in *separate* administrative 
domains?


Microsoft currently appears to add an ARC seal for everything that
transits their hosted mail system, no mailing lists or whatever
involved. I think I may have seen stuff from them with two seals.

Here's the headers of something from MS that I picked out of the
spamtrap. It's a fake Sharepoint message, and all of the SPF and DMARC
checks failed, which of course makes one wonder why they sent it to me
at all, but there's plenty of ARC-age there in case I want to do the
filtering they didn't.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


Return-Path: 
Received: (qmail 53861 invoked from network); 24 Nov 2020 23:04:40 -
Authentication-Results: iecc.com; spf=pass spf.mailfrom=no-re...@sharepointonline.com 
spf.helo=APC01-SG2-obe.outbound.protection.outlook.com smtp.remote-ip="40.107.131.117"; dkim=pass 
header.d=spoapaceop.onmicrosoft.com header.s=selector1-spoapaceop-onmicrosoft-com header.a=rsa-sha256 
header.b="wrH3TGY5"; dkim=pass header.d=sharepointonline.com header.s=selector1 header.a=rsa-sha256 
header.b="nk5sNj5U"; dmarc=pass header.from=sharepointonline.com (p=reject, pct=100)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 
b=O1UbAqs382laXh6I4AhWTigOPfRFerozKTibyzMawpdnyHHn4iHRW4u6+HZ1KlqNZHfhco5U9KgrgsCzP1VvHaD686U2omsloPRlsuR8+8UQPucSS/qtgYrv+5vDfF8cNqvnyfRvS/kOy3bAzr4vVPfhtgPbQ2sn+L5wMjo+w8kV+AZ6O6KedBqZSrX6Mt6OpsqFT1l3sTybAuOHlrmjo++cp2Dn0atKYnqDAAu1OIOSW6/dnc0u6fwbVoURavwPtWVhnK2/1MjHnlJO6XZTQeQtvvU82RSaaEikGgrQhsAO41Uz2HJPMt3S6e4RAWYS1n995BOeosRNjLcKxFNx2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=WpRrZ43L7klrMFI7e2Xg+LjrKHEocOU52J2YWHSirU4EX4J1yqrqMWT1MqGQze8tEbPEtTSa8r2ZM6ff235Mch1QlpbmQt2HtmGClJGe+ZYkRTf5zTmGyLxSokIrNfFaAHtztaqnct0XlLgMCm3Uu5zxqzaIfh9Wi2vMlLpX/mHRx+W6XOw1+Frb1msMbyf4LbjtjFWCv1+KBpACSaxC9vWIc70+P7stlVkuGyxM9rE+oO7jodaUCAHvkBQtASZ+PVeGe/gxxP3Pv26WnM31HDxVKGkn6mVsCkhkqW6L/4O2/SBCjtyM0gUoatMprsAOTian7sDbnQYtzTzTP2f0wA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is
 13.75.93.237) smtp.rcpttodomain=repmark.com
 smtp.mailfrom=sharepointonline.com; dmarc=fail (p=reject sp=reject pct=100)
 action=oreject header.from=sharepointonline.com; dkim=none (message not
 signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=spoapaceop.onmicrosoft.com; s=selector1-spoapaceop-onmicrosoft-com;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=wrH3TGY50Qitk5Kc82kUaGKKbBcgore8XTTR+QrqeSmGIEyalPhCQ+HoQXN6Euuhzc0EM9GOEYvMk2I5wYiZZ9eihJ4UuBARo1EHK7zYDlda2EAql0V+/5oWR0jHFvYBmH+QUCQ5SJ+R2IxO5x9yK0fXUJtpTPmZgYpvwH+AIA4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharepointonline.com;
 s=selector1;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=nk5sNj5UH1ZrUT387iGCYgiYCAZspugCdueY19ZRfrz+hs1F/ltpSFIUvvB/PZ8QRP1H4qGujpRuLnD3PlNLPn1Qak0pFp13mwip2g5eV8ObJxBw1d11zLM7PM090Z6Ri2NrKK241iAgmOl5gZrcrLgur7F2ckhtMYJsSkCKiUEDOfHSns3JN/AHVXm7C46BOMrQbJbhWqwTojkasOgVEGnAZbEcUbVT13mAmKvB1t7BL3wCk56q37jYm09vuSzvhja3+oegQ/iaLsurvCDzJkW2WvmRt2+Y+LYaG4HYboUQ7W/P6pDJCPpMDZzHp9aRwrHGamKgpdi/0lrXwz9G4w==
X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 13.75.93.237)
 smtp.mailfrom=sharepointonline.com; repmark.com; dkim=none (message not
 signed) header.d=none;repmark.com; dmarc=fail action=oreject
 header.from=sharepointonline.com;
Date: Tue, 24 Nov 2020 23:04:25 +
Subject: Ashley Barker shared "I'M 28 Years Horny & Sexy" with you.
Message-Id: 

Sender: Ashley Barker 
To: jamaicadiscountvacationpacka...@repmark.com,
 wevmas...@marshfieldtravel.com, tcw...@hiwaay.net, rrbr...@ptdprolog.net,
 memb...@onlinecityguide.com, david_burnst...@lecg.com, aimee_sm...@dell.com,
 mtu...@tivoli.com, bassm...@earthlink.net, alfac...@nectar.com, ti...@gcm.com,
 tm...@ais.net, tam...@tamarasmith.com, uu-req...@iecc.com, n...@net.com,
 tra...@worldaccess.com, randiha...@yahoo.com, jc_sm...@dell.com,
 ksteph...@supnet.com, tamerasm...@sprintmail.com, sa...@sovam.com,
 temp...@storm.net, smit...@hotmail.com, smit...@hotmail.com,
 ssmith...@docsolinc.com, mistersm...@free-online.co.uk,
 brettatay...@comcast.net, wbatter...@steptoe.com, jlup-lupini...@gmx.com,
 

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 11/24/20 4:56 PM, Brandon Long wrote:



On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas > wrote:




Our experience also showed that more than one hop is quite common
in enterprise deployments,
and those are also the places where the most complexity arises. 
Others shared our experience
as well.


That's more than one modifying intermediary in *separate*
administrative domains? Within your own administrative domain
there shouldn't be an issue of trust since you can trust your own
servers auth-res and that they are not maliciously trying to forge
an auth-res for better treatment. and course it's best to stop a
bad message as soon as possible in the mail pipeline if for no
other reason than why waste the resources.

The administrative domain in practice tends to be per-vendor and 
multi-tenant.  Ie, gsuite/gmail is on google.com , 
various third party anti-spam gateways also different, on-premise 
being also separate.  Passing that trust between domains is one of the 
things that ARC can handle.


One of the failings of many, many ietf documents is to not tell the 
story of what exactly the problem is and why the protocol is needed. 
It's really frustrating to the reader to not have the context of endless 
wg list discussions distilled so that an outsider can understand the 
design tradeoffs. I still don't understand why a DKIM signature was a 
"poor choice". That's especially true when something is an experiment 
that assumedly has yes/no endpoint.


So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it 
would run into problems? I haven't put up a DMARC policy, but if I did I 
might run into issues with false positives? Like I said, I'm trying to 
get my head around what the actual problems are, and this is coming from 
a person who stressed mightily from the very beginning about the mailing 
list problem.





Well sure, I'm sure it can happen but is it common enough to worry
about? And I'm still not convinced that figuring out who signed
what and which auth-res it belonged to is in insurmountable
problem. for one, there are received headers which better not be
getting out of order to help correlate with the messages' path
through intermediary verifiers too.

So, we do have some Received header walking code, and allow admins to 
set up the list of IPs that are considered "internal" (beyond private 
addresses)... but O365 uses public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible 
for admins to maintain a list.  Obviously we can all add code to 
handle Microsoft specially... and whichever other ones come up.




But can't you trust the received headers once you have possession of the 
message within your domain? I'm sorry if I'm being dense here but 
received headers are definitely ordered and if you loan out a message to 
be processed by a different domain and they aren't trustworthy, that's 
the least of your problems. That's part of the overall problem though: 
it's really hard to understand what the problem here actually is. 
Explain it like I'm five :)


Mike

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Murray S. Kucherawy]

On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely  wrote:

> The PSL is the result of a community-maintained effort.  They do not
> follow
> intricate naming restrictions that ccTLDs might theorize, but actively
> track
> subdomains as they become visible/ noticed.  It is remarkably good.
>

I'm curious as to whether this is the consensus opinion of the PSL.  It's
my impression that it is not, given the arguments that supported the
creation of the DBOUND working group in the first place, for instance.

The citations you made here appear to support that notion as well.

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

Re: [dmarc-ietf] ARC questions

[Brandon Long]

On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas  wrote:

>
> On 11/24/20 3:24 PM, Brandon Long wrote:
>
>
> On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas  wrote:
>
>>
>>
>> Sorry, changing the auth-res to old-auth-res and dkim signing the
>> message would be completely sufficient, and far easier to understand
>> with a lot less bloat. All of this hand wringing about dozens of message
>> manglers in the path before it get to the destination and not be able to
>> figure out which auth-res was which seems wildly out of proportion for
>> what the normal case is: 1 message mangler in the path before it arrives
>> at the receiver's domain. Just like this message right here. That's why
>> I asked how common that was, which was dismissed, but not answered.
>>
>
> Note that this was exactly what we started with,
> X-Original-Authentication-Results
> and with Google's implementation signing that with X-Google-DKIM-Signature.
>
> Our version didn't just sign with DKIM-Signature because of the reasons
> already stated in this
> thread, that our understanding of how DKIM-Signature was being used made
> it a poor choice.
>
>
> Sorry, I didn't see that. Pointer?
>
>
> Our experience also showed that more than one hop is quite common in
> enterprise deployments,
> and those are also the places where the most complexity arises.  Others
> shared our experience
> as well.
>
> That's more than one modifying intermediary in *separate* administrative
> domains? Within your own administrative domain there shouldn't be an issue
> of trust since you can trust your own servers auth-res and that they are
> not maliciously trying to forge an auth-res for better treatment. and
> course it's best to stop a bad message as soon as possible in the mail
> pipeline if for no other reason than why waste the resources.
>
The administrative domain in practice tends to be per-vendor and
multi-tenant.  Ie, gsuite/gmail is on google.com, various third party
anti-spam gateways also different, on-premise being also separate.  Passing
that trust between domains is one of the things that ARC can handle.

O365 does a better job than Gmail at this, since there you can set up third
parties to be called from within a particular customer more specifically
(like an API), you can do this with GSuite or ad-hoc MTAs, but it tends to
be more manual by chaining MTAs and there isn't as much of an auth
mechanism to use.

As for stopping bad messages early, there tends to be strong majority in
favor of that for malware, less so for spam where people want access from
their mailboxes to false positives.  Some products do have separate
administrative quarantine areas that can be checked by admins, but that's
also an extra burden for IT... some of which want that burden, and some
definitely don't.  Some quarantines can be self-administered by users, but
that's obviously a separate thing they have to check, whether that's worse
than a spam folder, *shrug*.

> You say that your message had 1 mangler in the path, but really you don't
> know that.  It is
> likely that some people on this list are on enterprise accounts who are
> behind mangling inbound
> gateways (rewriting urls to go through safety checking hops is common, for
> example).  Or maybe
> they are on with University accounts using exchange but forward their mail
> to a personal or department
> gmail account.
>
>
> Well sure, I'm sure it can happen but is it common enough to worry about?
> And I'm still not convinced that figuring out who signed what and which
> auth-res it belonged to is in insurmountable problem. for one, there are
> received headers which better not be getting out of order to help correlate
> with the messages' path through intermediary verifiers too.
>
So, we do have some Received header walking code, and allow admins to set
up the list of IPs that are considered "internal" (beyond private
addresses)... but O365 uses public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible for
admins to maintain a list.  Obviously we can all add code to handle
Microsoft specially... and whichever other ones come up.

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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 11/24/20 3:24 PM, Brandon Long wrote:


On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas > wrote:




Sorry, changing the auth-res to old-auth-res and dkim signing the
message would be completely sufficient, and far easier to understand
with a lot less bloat. All of this hand wringing about dozens of
message
manglers in the path before it get to the destination and not be
able to
figure out which auth-res was which seems wildly out of proportion
for
what the normal case is: 1 message mangler in the path before it
arrives
at the receiver's domain. Just like this message right here.
That's why
I asked how common that was, which was dismissed, but not answered.


Note that this was exactly what we started with, 
X-Original-Authentication-Results
and with Google's implementation signing that with 
X-Google-DKIM-Signature.


Our version didn't just sign with DKIM-Signature because of the 
reasons already stated in this
thread, that our understanding of how DKIM-Signature was being used 
made it a poor choice.



Sorry, I didn't see that. Pointer?



Our experience also showed that more than one hop is quite common in 
enterprise deployments,
and those are also the places where the most complexity arises.  
Others shared our experience

as well.


That's more than one modifying intermediary in *separate* administrative 
domains? Within your own administrative domain there shouldn't be an 
issue of trust since you can trust your own servers auth-res and that 
they are not maliciously trying to forge an auth-res for better 
treatment. and course it's best to stop a bad message as soon as 
possible in the mail pipeline if for no other reason than why waste the 
resources.





You say that your message had 1 mangler in the path, but really you 
don't know that.  It is
likely that some people on this list are on enterprise accounts who 
are behind mangling inbound
gateways (rewriting urls to go through safety checking hops is common, 
for example).  Or maybe
they are on with University accounts using exchange but forward their 
mail to a personal or department

gmail account.



Well sure, I'm sure it can happen but is it common enough to worry 
about? And I'm still not convinced that figuring out who signed what and 
which auth-res it belonged to is in insurmountable problem. for one, 
there are received headers which better not be getting out of order to 
help correlate with the messages' path through intermediary verifiers too.


Mike


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

[dmarc-ietf] Messages passing more than one modifying intermediary?

[Michael Thomas]

Does anybody know what percentage of traffic that passes through more 
than one modifying intermediary in different administrative domains? I 
know that modifying intermediaries like mailing lists are relatively 
rare, so I'd think that messages that go through more than one would be 
extremely rare.


I'm not looking for anecdotes, just hard data.

Mike

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

Re: [dmarc-ietf] ARC questions

[Seth Blank]

As Chair-

This thread is quickly becoming unproductive and veering to personal
attacks, which will not be tolerated.

Please engage productively and on the merits, take the conversation
elsewhere, or disengage.

Seth

On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas  wrote:

> You'd be wrong. The only ad hominem was yours from yesterday and it was
> I think where *you* dismissed the very question I raised:
>
> "Two or more levels of forward are quite common, particularly in large
> mail systems.  Look at mail coming out of Google and Microsoft's hosted
> mail and you'll see a lot of ARC headers.
>
> Considering that the ARC RFC was published over a year ago, and it is
> implemented all over the place, could you explain what the point of this
> discussion is?  The people who designed ARC are not idiots.  If we could
> have fixed the mailing list problem with existing DKIM signatures, we
> would have."
>
> And as I've said repeatedly, do not contact me in private.
>
> Mike
>
> On 11/24/20 2:53 PM, John R Levine wrote:
> > This appears to me to be an ad-hominem attack on the people who
> > designed ARC, so I think we're done.
> >
> > On Tue, 24 Nov 2020, Michael Thomas wrote:
> >
> >>
> >> On 11/23/20 6:04 PM, John Levine wrote:
> >>> In article  you write:
>  What I'm struggling to understand is what having authenticated
>  auth-res
> >>> >from a previous hop helps. this is what i found:
> >>>
> >>> See some of the previous messages. My usual example is a mailing list
> >>> message that fails DMARC at the final recipient but passed DMARC (as
> >>> recorded in AAR) when it arrived at the list. This lets the final
> >>> recipient distinguish between real messages from subscribers and mail
> >>> from spambots that happened to scrape both the list address and some
> >>> subscribers' address and sends mail to one pretending to be from the
> >>> other. (That definitely happens, I've seen it on lists I'm on.)
> >>>
> >>> I agree that the ARC document does not do a great job of explaining
> >>> that.
> >>>
>  It would be kind of nice to understand what gap ARC actually plugs and
>  why it's important if you ask me. Also: there seem to be a lot of ways
>  to achieve this, but this one is probably the most complicated one
>  that
>  I can envision.
> >>> If you want to pass the A-R results through multiple rounds of
> >>> forwarding, you can't do much less.
> >>
> >>
> >> Sorry, changing the auth-res to old-auth-res and dkim signing the
> >> message would be completely sufficient, and far easier to understand
> >> with a lot less bloat. All of this hand wringing about dozens of
> >> message manglers in the path before it get to the destination and not
> >> be able to figure out which auth-res was which seems wildly out of
> >> proportion for what the normal case is: 1 message mangler in the path
> >> before it arrives at the receiver's domain. Just like this message
> >> right here. That's why I asked how common that was, which was
> >> dismissed, but not answered.
> >>
> >> Mike
> >>
> >>
> >
> > Regards,
> > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail.
> https://jl.ly
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

You'd be wrong. The only ad hominem was yours from yesterday and it was 
I think where *you* dismissed the very question I raised:


"Two or more levels of forward are quite common, particularly in large 
mail systems.  Look at mail coming out of Google and Microsoft's hosted 
mail and you'll see a lot of ARC headers.


Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of this 
discussion is?  The people who designed ARC are not idiots.  If we could 
have fixed the mailing list problem with existing DKIM signatures, we 
would have."


And as I've said repeatedly, do not contact me in private.

Mike

On 11/24/20 2:53 PM, John R Levine wrote:
This appears to me to be an ad-hominem attack on the people who 
designed ARC, so I think we're done.


On Tue, 24 Nov 2020, Michael Thomas wrote:



On 11/23/20 6:04 PM, John Levine wrote:

In article  you write:
What I'm struggling to understand is what having authenticated 
auth-res

>from a previous hop helps. this is what i found:

See some of the previous messages. My usual example is a mailing list
message that fails DMARC at the final recipient but passed DMARC (as
recorded in AAR) when it arrived at the list. This lets the final
recipient distinguish between real messages from subscribers and mail
from spambots that happened to scrape both the list address and some
subscribers' address and sends mail to one pretending to be from the
other. (That definitely happens, I've seen it on lists I'm on.)

I agree that the ARC document does not do a great job of explaining 
that.



It would be kind of nice to understand what gap ARC actually plugs and
why it's important if you ask me. Also: there seem to be a lot of ways
to achieve this, but this one is probably the most complicated one 
that

I can envision.

If you want to pass the A-R results through multiple rounds of
forwarding, you can't do much less.



Sorry, changing the auth-res to old-auth-res and dkim signing the 
message would be completely sufficient, and far easier to understand 
with a lot less bloat. All of this hand wringing about dozens of 
message manglers in the path before it get to the destination and not 
be able to figure out which auth-res was which seems wildly out of 
proportion for what the normal case is: 1 message mangler in the path 
before it arrives at the receiver's domain. Just like this message 
right here. That's why I asked how common that was, which was 
dismissed, but not answered.


Mike




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


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

Re: [dmarc-ietf] ARC questions

[Michael Thomas]

On 11/23/20 6:04 PM, John Levine wrote:

In article  you write:

What I'm struggling to understand is what having authenticated auth-res

>from a previous hop helps. this is what i found:

See some of the previous messages. My usual example is a mailing list
message that fails DMARC at the final recipient but passed DMARC (as
recorded in AAR) when it arrived at the list. This lets the final
recipient distinguish between real messages from subscribers and mail
from spambots that happened to scrape both the list address and some
subscribers' address and sends mail to one pretending to be from the
other. (That definitely happens, I've seen it on lists I'm on.)

I agree that the ARC document does not do a great job of explaining that.


It would be kind of nice to understand what gap ARC actually plugs and
why it's important if you ask me. Also: there seem to be a lot of ways
to achieve this, but this one is probably the most complicated one that
I can envision.

If you want to pass the A-R results through multiple rounds of
forwarding, you can't do much less.



Sorry, changing the auth-res to old-auth-res and dkim signing the 
message would be completely sufficient, and far easier to understand 
with a lot less bloat. All of this hand wringing about dozens of message 
manglers in the path before it get to the destination and not be able to 
figure out which auth-res was which seems wildly out of proportion for 
what the normal case is: 1 message mangler in the path before it arrives 
at the receiver's domain. Just like this message right here. That's why 
I asked how common that was, which was dismissed, but not answered.


Mike

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[John R Levine]

Right.  The optimal solution would be to load the list and the lookup 
algorithm as a shared object.  Currently, my filter has its private copy of 
it.  But then I don't reload the filter so often that parsing the file is 
noticeable.  To wit, loading the virus database takes much much longer.


Indeed.  I don't think that processing the PSL is an overwhelming amount 
of work, but I also don't think there is much difference in performance 
between using the PSL and making DNS queries that are likely to be 
answered from a local cache.



"Holy Roman Empire"


Organizations, typically universities, where the nominal organization tree 
and the actual control are different.  The PSL isn't useful because the 
party that controls their Org domain often doesn't control lower parts of 
the DNS tree.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Alessandro Vesely]

On Tue 24/Nov/2020 18:03:51 +0100 John Levine wrote:

In article  you write:

One of the points of the tree walk is to get rid of the PSL processing.


The PSL processing is a local lookup on an in-memory suffix tree.  How is it a 
progress to replace it with a tree walk?  A PSL search is lightning faster than 
even a single DNS lookup, isn't it?


You have to download a copy of the PSL, read it into your program, and
parse it into some internal form. The PSL is over 200K of text and
13,000 lines, so while it's not a large file, it's not zero either.



Right.  The optimal solution would be to load the list and the lookup algorithm 
as a shared object.  Currently, my filter has its private copy of it.  But then 
I don't reload the filter so often that parsing the file is noticeable.  To 
wit, loading the virus database takes much much longer.




If you're lucky you can amortize your PSL parsing across multiple
DMARC checks, but your DNS cache amortizes DNS lookups across multiple
checks, too.



I doubt I'd get comparable efficiency, even if my mail server has a dedicated 
caching resolver.  Mail servers that rely on stub resolvers would experience a 
noticeable degradation.




The DNS approach has the advantage that you don't have to depend on a
third party's text file updated at unknown intervals,



Agreed.



and also makes it easier to deal with what I've called the Holy Roman Empire
problem.



Uh?  The Holy Roman Empire became a disconnected tree soon after Charlemagne's 
death, so that looks like some of the dystopic scenarios that ISOC conceived a 
few years ago.  Not sure what you mean.



Best
Ale
--




















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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Doug Foster]

Better a correct answer slowly than an incorrect answer quickly.

 

For the existing PSL, it is not just the accuracy of the document itself, but 
also the accuracy of the parsing process.   Is there a well-trusted parser 
floating around?

 

DF

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Tuesday, November 24, 2020 1:19 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

 

On 11/24/2020 9:21 AM, John Levine wrote:

With the tree walk, I was thinking that if the tree walk finds a _dmarc record, 
that acts
as the organizational domain, so finance.acme.example can only allow alignment 
with itself
or its descendants.
 
This is different from the way that OD works now, but the questions are is it 
worse, and what
will break if we do it.

 

Let's consider some attributes, starting with a trivial initial set...

 

Accuracy:   How accurate is the data that gets retrieved?

Reliability:How likely is it that a query will complete successfully?

Latency:How long does it take for a query to complete?

Vulnerability:  How easily/likely is it that the service can be compromised?

Scaling:How well does it operate, at Internet scale?

 

   PSL  Tree-Walk

Accuracy:  Known problematic100%

Reliability:   High Mixed

Latency:   None Potentially high

Vulnerability: Generally none   DOS

Scaling:   Poor admin, good ops Good admin, potentially poor ops

 

d/

-- 
Dave Crocker
dcroc...@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Alessandro Vesely]

On Tue 24/Nov/2020 17:50:20 +0100 Murray S. Kucherawy wrote:

On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely  wrote:


If I'm going to go to the effort to download and decode a PSL and find
the OD, I'll just use the OD. >>>
One of the points of the tree walk is to get rid of the PSL processing.


The PSL processing is a local lookup on an in-memory suffix tree.  How is 
it a progress to replace it with a tree walk?  A PSL search is lightning

faster than even a single DNS lookup, isn't it? >>


Sure, but only if you think the PSL is accurate.  Otherwise you're basing
your shortcut up the tree on data you don't have reason to trust.  On the
other hand, a tree walk, while more expensive in terms of queries, isn't a
heuristic based on possibly stale information.



The PSL is the result of a community-maintained effort.  They do not follow 
intricate naming restrictions that ccTLDs might theorize, but actively track 
subdomains as they become visible/ noticed.  It is remarkably good.


The reason why one may happen to use stale information is because updates are 
not so well organized.  Arguably, it's not going to reach a stable state until 
it's considered a sort of hack.


For one, the CA/Browser forum had that stance:

On Feb 1, 2013, at 10:25 AM, Phillip wrote:
The public suffix list is a hack. It should go away. There needs to be a
mechanism for determining if a domain is a public suffix or not but that
information should be distributed through the DNS and not through an ad hoc
list that a third party is meant to be maintaining under ill-defined
criteria and without the active participation of the TLD operators.
https://archive.cabforum.org/pipermail/public/2013-February/001146.html

That stance is justified by Section 8.2 of RFC 6454.  However, their current 
Baseline Requirements state the following:


Determination of what is “registry-controlled” versus the registerable
portion of a Country Code Top-Level Domain Namespace is not standardized
at the time of writing and is not a property of the DNS itself. Current
best practice is to consult a “public suffix list” such as the Public
Suffix List (PSL), and to retrieve a fresh copy regularly.
   https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf

And, noticeably, the URL Living Standard references the PSL plainly.  They call 
*registrable domain* what we call Organizational Domain.  See:

https://url.spec.whatwg.org/#host-public-suffix


Best
Ale
--
























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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Dave Crocker]

On 11/24/2020 9:21 AM, John Levine wrote:

With the tree walk, I was thinking that if the tree walk finds a _dmarc record, 
that acts
as the organizational domain, so finance.acme.example can only allow alignment 
with itself
or its descendants.

This is different from the way that OD works now, but the questions are is it 
worse, and what
will break if we do it.



Let's consider some attributes, starting with a trivial initial set...


*Accuracy:*   How accurate is the data that gets retrieved?

*Reliability*:    How likely is it that a query will complete successfully?

*Latency:*    How long does it take for a query to complete?

*Vulnerability:*  How easily/likely is it that the service can be 
compromised?


*Scaling:*    How well does it operate, at Internet scale?


*PSL* *Tree-Walk*

*Accuracy: *   Known problematic    100%

*Reliability:* High Mixed

*Latency: * None Potentially high

*Vulnerability:* Generally none   DOS

*Scaling:*   Poor admin, good ops Good admin, potentially 
poor ops



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] org domain and dns-perimeter draft

[Doug Foster]

I am intrigued by Dave's document.   I have not yet read John's.   John
described this topic as a battle, so I wonder if we need a crash course in
the results of those battles before revisiting the topic.

One of the issues that did not seem sufficiently addressed was split-mode
nodes, where some descendants are public suffixes and some are
organizations.At that point, the plan becomes dependent on organizations
publishing BEGIN records. Similarly, if we ask PSL's to put a flag into
their DNS entries, we have to assume that some will comply and some will
not, and some will do so in phases.   TThe document did not provide a
mechanism for the evaluator to assess whether data is complete or missing.
I am attempting to fix those concerns.

Nonetheless, these thoughts are an abstraction inspired from Dave's
document.

Note:  I only know how to make this work if we assume a tree walk that goes
downward.

At each public suffix entry in the DNS hierarchy, we check for these flags:
 
Public suffix flag:  This is a PSL entry, it neither sends nor accepts
email.  You must look for an organization start somewhere below this point.

(Optional)  End flag:  There are no public suffixes below this point.  Every
lower entry is an organization start node.   Entries with a public suffix
flag are stating an organization preference or spoofing.

Deployment flag:   All public suffixes below this point have been tagged.   
- Once this flag is detected, if the search finds a node without the PSL
flag, it is an organization, not a public suffix 
- If this flag has not been detected and the search finds a node without the
PSL flag, use the old PSL to find the organization node.

An evaluator can walk down the tree and can always find one of these:
- an Organization entry, 
- an ambiguous ending which triggers the need to consult the old PSL, or 
- an excessive search depth which is handled as no-data-found and possible
malicious intent.


Spoofing assessment:
We cannot prevent people from mimicking a PSL flag, so we just need to limit
the risk.

As the tree is walked downward, the first entry without a PSL flag stops the
search.The PSL flag should never be checked based on a walk up the tree.
This eliminates the opportunity for mid-tree spoofing.

I see no great risk if an organization wants the top of its DNS structure to
behave like a public suffix, so I don't know that mimicking a public suffix
is a problem.   The only caveat is that we need a maximum depth to limit
malicious DNS structures intended to waste search effort by evaluators.

Doug Foster




-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, November 18, 2020 12:55 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] org domain and dns-perimeter draft

Given the renewed discussion about organizational domain and alternative
boundaries, I'll suggest that this draft from last year might be relevant:


DNS Perimeter Overlay




> Abstract
> 
>The Domain Name System (DNS) naming syntax provides no meta-data for
>indicating administrative transitions through the hierarchy.  For
>example, it does not distinguish the higher-level portions that
>operate as public registries, versus those that operate as private
>organizations.  This specification creates a basic overlay mechanism
>for defining a logical Perimeter between administrative entities
>through the naming hierarchy.  The mechanism can then be applied for
>a variety of independent administrative indications.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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] Doing a tree walk rather than PSL lookup

[John Levine]

In article <9ab0d7b9-2e35-f64b-02ea-a111c10ac...@wisc.edu> you write:
>So if acme.example publishes aspf=s adkim=s 
>It does not prevent finance.acme.example from publishing aspf=r adkim=r
>Which would align widgets.acme.example with finance.acme.example even if the 
>intent was to only align
>delegated-esp.finance.acme.example with finance.foo.example

With the tree walk, I was thinking that if the tree walk finds a _dmarc record, 
that acts
as the organizational domain, so finance.acme.example can only allow alignment 
with itself
or its descendants.

This is different from the way that OD works now, but the questions are is it 
worse, and what
will break if we do it.

R's,
John

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

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

[John Levine]

In article  you write:
>On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote:
>> I had one spam message that had 13 parts.  It included both "_mta-sts" and 
>> "mta-sts" in there, as well as
>"mail" nine times.  The last two parts were the org domain.
>
>If the message happened to authenticate, negative reputation is better added 
>to 
>that org domain rather than to .com or to some random mta-sts.mail.something.

Why would you think that spam was sent by the actual holder of that
org domain? Since the address contained an underscore, it's invalid
anyway so you could probably reject the message without a lot of extra
checks.

>IOW, if we need the OD anyway for alignment, there's no point in discovery 
>DMARC records by tree walk.

My plan is that whatever you discover by the tree walk replaces the OD.  In the 
likely
common case that the tree walk ends at _dmarc. you get the same 
result either
way.

R's,
John

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[John Levine]

In article  you write:
>> One of the points of the tree walk is to get rid of the PSL processing.
>
>The PSL processing is a local lookup on an in-memory suffix tree.  How is it a 
>progress to replace it with a tree walk?  A PSL search is lightning faster 
>than 
>even a single DNS lookup, isn't it?

You have to download a copy of the PSL, read it into your program, and
parse it into some internal form. The PSL is over 200K of text and
13,000 lines, so while it's not a large file, it's not zero either.

If you're lucky you can amortize your PSL parsing across multiple
DMARC checks, but your DNS cache amortizes DNS lookups across mutiple
checke, too.

The DNS approach has the advantage that you don't have to depend on a
third party's text file updated at unknown intervals, and also makes
it easier to deal with what I've called the Holy Roman Empire problem.

R's,
John

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Jesse Thompson]

On 11/24/20 9:52 AM, todd.herr=40valimail@dmarc.ietf.org wrote:
> On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker  > wrote:
> 
> Just to be clear, I'm not challenging the need.  Rather I'm just looking 
> for text that explains the need.  And I'm not finding it...
> 
> On 11/24/2020 7:28 AM, Todd Herr wrote:
>> There are two reasons (at least) for needing the Organizational Domain, 
>> and they are discussed in RFC 7489:
>>
>>  1. DMARC also allows for the explicit or implicit expression of policy 
>> for sub-domains at the Organizational Domain level. This matters for those 
>> times when _dmarc.RFC5322.From.domain is non-existent and 
>> RFC5322.From.domain is a sub-domain of the Organizational Domain.
>>  2. The default mode for authenticated identifier alignment, relaxed, 
>> requires only that the Organizational Domains for both identifiers are the 
>> same, and so the Organizational Domain must be known in order for relaxed 
>> alignment to be ascertained.
>>
> Except that I do not find either of these points provided in the document.
> 
> For point 1, this is from Section 6.6.3, Policy Discovery:
> 
>1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
>DNS domain matching the one found in the RFC5322 
> .From domain in
>the message.  A possibly empty set of records is returned.
> 
>2.  Records that do not start with a "v=" tag that identifies the
>current version of DMARC are discarded.
> 
>3.  If the set is now empty, the Mail Receiver MUST query the DNS for
>a DMARC TXT record at the DNS domain matching the Organizational
>Domain in place of the RFC5322 
> .From domain in the message (if
>different).  This record can contain policy to be asserted for
>subdomains of the Organizational Domain.  A possibly empty set of
>records is returned.
> 
> 
> 
> For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:
> 
>In relaxed mode, the Organizational Domains of both the [DKIM 
> ]-
>authenticated signing domain (taken from the value of the "d=" tag in
>the signature) and that of the RFC5322 
> .From domain must be equal if
>the identifiers are to be considered aligned.  In strict mode, only
>an exact match between both of the Fully Qualified Domain Names
>(FQDNs) is considered to produce Identifier Alignment.

The end of Section 3.1 might need to be clarified:

"Relaxed mode can be used when the operator also wishes to affect message flows 
bearing subdomains of the verified domains."

* I assume that relaxed mode can be set in the DMARC policy of a subdomain even 
if the Organizational Domain doesn't have (or want) that in its policy

* The subdomains in this context are the subdomains of the Organizational 
Domain, rather than the subdomains of the domain that published the relaxed 
mode in its policy

So if acme.example publishes aspf=s adkim=s 
It does not prevent finance.acme.example from publishing aspf=r adkim=r
Which would align widgets.acme.example with finance.acme.example even if the 
intent was to only align delegated-esp.finance.acme.example with 
finance.foo.example

Suggested better wording:

"Relaxed mode is determined from the policy of the RFC5322.From domain or from 
the Organizational Domain policy if the RFC5322.From domain has no policy.  It 
can be used when the operator also wishes to affect message flows bearing 
subdomains of the Organizational Domain."

If "walking the tree" is viable, then perhaps it should be:

"Relaxed mode is determined from the policy of the RFC5322.From domain or from 
[something about walking the tree to determine the policy].  It can be used 
when the operator also wishes to affect message flows bearing subdomains of the 
domain that published the relaxed mode policy."

Jesse

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

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

[Alessandro Vesely]

On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote:

I had one spam message that had 13 parts.  It included both "_mta-sts" and "mta-sts" in 
there, as well as "mail" nine times.  The last two parts were the org domain.



If the message happened to authenticate, negative reputation is better added to 
that org domain rather than to .com or to some random mta-sts.mail.something.


IOW, if we need the OD anyway for alignment, there's no point in discovery 
DMARC records by tree walk.



Best
Ale
--




















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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Murray S. Kucherawy]

On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely  wrote:

> > If I'm going to go to the effort to download and decode a PSL and find
> the OD, I'll just use the OD.
> >
> > One of the points of the tree walk is to get rid of the PSL processing.
>
> The PSL processing is a local lookup on an in-memory suffix tree.  How is
> it a
> progress to replace it with a tree walk?  A PSL search is lightning faster
> than
> even a single DNS lookup, isn't it?
>

Sure, but only if you think the PSL is accurate.  Otherwise you're basing
your shortcut up the tree on data you don't have reason to trust.  On the
other hand, a tree walk, while more expensive in terms of queries, isn't a
heuristic based on possibly stale information.

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Murray S. Kucherawy]

On Tue, Nov 24, 2020 at 7:56 AM Dave Crocker  wrote:

> Perhaps I am misreading these, but I see them only as 'what' and 'how',
> not 'why'.  The 'why' is important.  It is often noted in our
> discussions, but seems to be missing from the spec.


Seems like something the -bis document should tackle.

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Dave Crocker]

On 11/24/2020 7:52 AM, Todd Herr wrote:

For point 1, this is from Section 6.6.3, Policy Discovery:
...
For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:



Perhaps I am misreading these, but I see them only as 'what' and 'how', 
not 'why'.  The 'why' is important.  It is often noted in our 
discussions, but seems to be missing from the spec.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Todd Herr]

On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker  wrote:

> Just to be clear, I'm not challenging the need.  Rather I'm just looking
> for text that explains the need.  And I'm not finding it...
>
> On 11/24/2020 7:28 AM, Todd Herr wrote:
>
> There are two reasons (at least) for needing the Organizational Domain,
> and they are discussed in RFC 7489:
>
>1. DMARC also allows for the explicit or implicit expression of policy
>for sub-domains at the Organizational Domain level. This matters for those
>times when _dmarc.RFC5322.From.domain is non-existent and
>RFC5322.From.domain is a sub-domain of the Organizational Domain.
>2. The default mode for authenticated identifier alignment, relaxed,
>requires only that the Organizational Domains for both identifiers are the
>same, and so the Organizational Domain must be known in order for relaxed
>alignment to be ascertained.
>
> Except that I do not find either of these points provided in the document.
>
For point 1, this is from Section 6.6.3, Policy Discovery:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
   DNS domain matching the one found in the RFC5322
.From domain in
   the message.  A possibly empty set of records is returned.

   2.  Records that do not start with a "v=" tag that identifies the
   current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
   a DMARC TXT record at the DNS domain matching the Organizational
   Domain in place of the RFC5322
.From domain in the message (if
   different).  This record can contain policy to be asserted for
   subdomains of the Organizational Domain.  A possibly empty set of
   records is returned.



For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:

   In relaxed mode, the Organizational Domains of both the [DKIM
]-
   authenticated signing domain (taken from the value of the "d=" tag in
   the signature) and that of the RFC5322
.From domain must be equal if
   the identifiers are to be considered aligned.  In strict mode, only
   an exact match between both of the Fully Qualified Domain Names
   (FQDNs) is considered to produce Identifier Alignment.




Also for point 2, this is from Section 3.1.2, SPF-Authenticated Identifiers:

   In relaxed mode, the [SPF
]-authenticated domain
and RFC5322 .From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.




-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Dave Crocker]

Just to be clear, I'm not challenging the need.  Rather I'm just looking 
for text that explains the need.  And I'm not finding it...


On 11/24/2020 7:28 AM, Todd Herr wrote:
There are two reasons (at least) for needing the Organizational 
Domain, and they are discussed in RFC 7489:


 1. DMARC also allows for the explicit or implicit expression of
policy for sub-domains at the Organizational Domain level. This
matters for those times when _dmarc.RFC5322.From.domain is
non-existent and RFC5322.From.domain is a sub-domain of the
Organizational Domain.
 2. The default mode for authenticated identifier alignment, relaxed,
requires only that the Organizational Domains for both identifiers
are the same, and so the Organizational Domain must be known in
order for relaxed alignment to be ascertained.


Except that I do not find either of these points provided in the document.


What is perhaps missing from RFC 7489 is the reason that the authors 
chose to make these two items part of the specification.


That would, of course, also be nice to include.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Todd Herr]

On Tue, Nov 24, 2020 at 10:15 AM Dave Crocker  wrote:

> On 11/24/2020 7:00 AM, Joseph Brennan wrote:
> > I will ask why the recipient system should look up anything but the
> > dmarc record for the specific domain in the Header From.
>
>
> Hmmm.  Unless I've missed it, the DMARC spec does not explain the reason
> for needing the Organizational Domain.
>
>
There are two reasons (at least) for needing the Organizational Domain, and
they are discussed in RFC 7489:

   1. DMARC also allows for the explicit or implicit expression of policy
   for sub-domains at the Organizational Domain level. This matters for those
   times when _dmarc.RFC5322.From.domain is non-existent and
   RFC5322.From.domain is a sub-domain of the Organizational Domain.
   2. The default mode for authenticated identifier alignment, relaxed,
   requires only that the Organizational Domains for both identifiers are the
   same, and so the Organizational Domain must be known in order for relaxed
   alignment to be ascertained.

What is perhaps missing from RFC 7489 is the reason that the authors chose
to make these two items part of the specification.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Dave Crocker]

On 11/24/2020 7:00 AM, Joseph Brennan wrote:
I will ask why the recipient system should look up anything but the 
dmarc record for the specific domain in the Header From. 



Hmmm.  Unless I've missed it, the DMARC spec does not explain the reason 
for needing the Organizational Domain.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Joseph Brennan]

I will ask why the recipient system should look up anything but the dmarc
record for the specific domain in the Header From.

In some cases looking up related domains is useful, and in some cases it
can lead to disruption. We don't look up SPF records for related domains,
because they are deliberately different in many cases, e.g. one domain for
mail from end users, another for mail sent by a vendor, yet another for
another vendor. Why is dmarc different?


-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Alessandro Vesely]

On Mon 23/Nov/2020 22:38:46 +0100 John Levine wrote:

In article <9f388e33-c15d-9fcc-e9d3-d7719288f...@gmail.com> you write:

On 11/23/2020 1:04 PM, Jesse Thompson wrote:
I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its policy. 

It seems like a decent compromise for the people worried about unnecessary DNS 
lookup overhead.


If I'm going to go to the effort to download and decode a PSL and find the OD, 
I'll just use the OD.

One of the points of the tree walk is to get rid of the PSL processing.



The PSL processing is a local lookup on an in-memory suffix tree.  How is it a 
progress to replace it with a tree walk?  A PSL search is lightning faster than 
even a single DNS lookup, isn't it?



Best
Ale
--

























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