Re: [dmarc-ietf] DMARC variations

[Tobias Herkula]

I’m the Author of that pamphlet and yes „slow-entry“ stands for rate limiting, 
as we do not plan to reject traffic completly, I also would like to mention 
that this is a WIP document and I’m fascinated that it pops up here, as it only 
was a small comment on a completly different topic. I would also like to 
emphasis that this is not directly DMARC related as the goal we want to achieve 
is different and we also plan to bring our DMARC implementation forward at the 
same time.

/ Tobias Herkula
--
Senior Product Owner Mail Security
Product Mail Platform

1&1 Mail & Media GmbH

Von: dmarc  Im Auftrag von Douglas Foster
Gesendet: Sonntag, 24. Oktober 2021 19:37
An: Alessandro Vesely 
Cc: dmarc-ietf 
Betreff: Re: [dmarc-ietf] DMARC variations

What is meant by "slow entry" in the title?   Does it mean that non-compliant 
messages will be throttled with 4xx temporay failure result codes?


On Sun, Oct 24, 2021, 10:51 AM Alessandro Vesely 
mailto:ves...@tana.it>> wrote:
Hi all,

this proposal by some German mailbox providers sounds interesting:

https://docs.google.com/document/d/e/2PACX-1vQeodijKJJJPX6fCma3tm00n8m0aJI0VyuO17hKXTy0y7JYUzIxd5Cqh2VSttvJkw-yxWK5fT8NFDcO/pub

Note that it "is not directly referencing DMARC as a technology with similar 
functionalities, as [they] strive to establish a common ground, where DMARC, 
BIMI and future Systems can build up additional benefits for all sides."


Best
Ale
--








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

[dmarc-ietf] Topic for IETF 112 - Policy Discovery

[Todd Herr]

Greetings.

There are, by my count, eleven tickets that are primarily focused on or at
least touch on the issue of policy discovery. A specialized query for them
is at this URL - https://trac.ietf.org/trac/dmarc/report/15

The question of policy discovery has a few options as its answer:

   - Leave things as they are (meaning look up the policy for the
   RFC5322.From domain and the organizational domain of that domain if
   different)
   - Add a third lookup for a public suffix domain
   - Walk the DNS tree from the RFC5322.From domain all the way to an
   agreed-upon level in the DNS hierarchy
   - Something other than what's listed here

The topic of policy discovery has been proposed for the agenda for the
upcoming DMARC session at IETF 112, and so this message should serve to
kick off a discussion of the topic now, so that we can have a most
productive discussion on the 9th.

Thank you.

-- 

*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

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

[Brotman, Alex]

I know there has been a fair bit of talk about walk-the-tree.  Taking a 24h set 
of data, and trying to measure the number of times where this situation may be 
warranted.  We can try to make a guess the goal is to look for a DMARC policy 
between the 5322.From which has an unknown number of dotted sections, and the 
second-level/apex/organizational domain.  I extracted the 5322.From and counted 
the number of "." in the field.  So "1" dot, means example.com, "2" means 
third.example.com, and so on.  I included the policy as well, 
abs(ent)/none/quarantine/reject.

In roughly 86% of cases, the domain of record is in the format of 
"example.com".  In about 13%, we have "third.example.com".  The other <1% are 
other variations.  Not exactly sure if this data tells us walking-the-tree is 
going to be advantageous, but thought I would share with others.

Let me know if you have questions, or would like to see different data (that 
I'd be allowed to share)

Note: This is percentage of messages, not percentage of domains
(apologies if the formatting goes sideways)

Num_dotsPolicy  PctOfTraffic
--  -  ---
1   none60.9147275180
1   abs 11.4060937845
1   reject  10.9984823560
2   quarantine  7.3245642177
1   quarantine  3.1460328512
2   abs 2.5626295515
2   reject  2.1029313056
2   none1.1140098795
3   abs 0.1924108697
3   reject  0.1362830691
3   none0.0797639119
3   quarantine  0.0173744076
4   abs 0.0021115047
4   reject  0.0017292496
6   abs 0.0003094447
4   none0.0002730394
4   quarantine  0.0001092158
5   quarantine  0.0001092158
5   abs 0.364053
5   none0.091013
6   none0.091013



--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Todd Herr
Sent: Monday, October 25, 2021 3:30 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

Greetings.


There are, by my count, eleven tickets that are primarily focused on or at 
least touch on the issue of policy discovery. A specialized query for them is 
at this URL - 
https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/report/15__;!!CQl3mcHX2A!VGJAEdJ0DpNqMeFma5x4t8ehOeZpPCdYqZs4Dq9_D2Zja366Lx0pcwqK4DFcSskDWHhaFXGCzA$

The question of policy discovery has a few options as its answer:
• Leave things as they are (meaning look up the policy for the RFC5322.From 
domain and the organizational domain of that domain if different)
• Add a third lookup for a public suffix domain
• Walk the DNS tree from the RFC5322.From domain all the way to an agreed-upon 
level in the DNS hierarchy
• Something other than what's listed here
The topic of policy discovery has been proposed for the agenda for the upcoming 
DMARC session at IETF 112, and so this message should serve to kick off a 
discussion of the topic now, so that we can have a most productive discussion 
on the 9th.

Thank you.

--
Todd Herr | Technical Director, Standards and Ecosystem
e: mailto: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

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

[Douglas Foster]

For me, the appeal of a tree walk would be to eliminate the PSL.   But an
artificially constructed domain name could have more than 100 segments, so
walking the entire tree seems like an opportunity for denial of service
attacks.

If we walk up from the bottom and quit too soon, a phony but long name
could be used to evade the actual domain policy.

We could limit complexity by starting at the PSL or organization and
walking down a limited number of segments, but this approach preserves the
need for a PSL.

These objections would not apply to a solution like the one suggested in
ticket #59, where a name is checked for membership in a single
sub-organizational unit.  Eliminating the PSL was not an objective of
ticket 59.

Doug





On Mon, Oct 25, 2021 at 3:33 PM Todd Herr  wrote:

> Greetings.
>
> There are, by my count, eleven tickets that are primarily focused on or at
> least touch on the issue of policy discovery. A specialized query for them
> is at this URL - https://trac.ietf.org/trac/dmarc/report/15
>
> The question of policy discovery has a few options as its answer:
>
>- Leave things as they are (meaning look up the policy for the
>RFC5322.From domain and the organizational domain of that domain if
>different)
>- Add a third lookup for a public suffix domain
>- Walk the DNS tree from the RFC5322.From domain all the way to an
>agreed-upon level in the DNS hierarchy
>- Something other than what's listed here
>
> The topic of policy discovery has been proposed for the agenda for the
> upcoming DMARC session at IETF 112, and so this message should serve to
> kick off a discussion of the topic now, so that we can have a most
> productive discussion on the 9th.
>
> Thank you.
>
> --
>
> *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