[dmarc-ietf] tree walk and DNS optimization

[Douglas E. Foster]

Performance is probably a BCP issue.   However, since DNS performance concerns 
are a limiting factor on our specification options, the topic seems relevant 
menioning now.

In my mail stream, only a small subset requires a DMARC policy lookup to 
determine disposition.   I wonder if others have similar or different results.

- One large portion of mail is sent direct:   SPF-compliant and domain aligned, 
so it passes DMARC criteria without checking signatures.   This includes both 
spam and legitimate mail.

- Another large portion is from major email service providers and mailbox 
providers:   Based on observation and provider reputation, I have concluded 
that the RFC5322.From address accurate reflects the providers client domain.
This observation includes ESPs that service both spammers and legitimate 
clients, where I need to filter on the RFC5322.From to determine whether the 
message is wanted or unwanted.   In ESP messages, the presence of a valid 
signature for the client domain is correlated with a DMARC-enforcing policy, 
and the absence of a signature is correlated with non-enforcing client domains.

- A third portion is spam which we block based on nominal source identity.  
When blocking on source identity, we do not worry about verifying whether the 
unwanted source is valid or spoofed.

A smaller fourth portion includes messages from trusted senders that have 
configuration errors which cause SPF or DMARC policy failure.   I whitelist 
them based on verified characteristics, without needing to check DMARC policy.

For all four of these message groups, policy lookup is not needed during 
message processing.Consequently, the DMARC lookup can be deferred until the 
preparation of the RUA report, and duplicates can be eliminated to minimize DNS 
traffic when that report is being prepared.   This approach minimizes resource 
usage during message processing, so it seems in the interest of DMARC 
developers as well as DNS operations.

If developers will optimize in this way, the aggregate DNS workload will be 
significantly reduced, regardless of the algorithms specified.

Doug Foster

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

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

[Todd Herr]

On Fri, Nov 13, 2020 at 1:41 PM Tim Wicinski  wrote:

>
> All
>
> During the chairs call this morning we were discussing the upcoming
> meeting.  Now Seth has a conflict with the meeting time that can't be
> altered.   Since work items have been progressing rather well recently, and
> the editors are in positing, we discussed canceling the meeting.  We wanted
> to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.  Should we 1) have a
> meeting around these topics;  2) discuss other topics or 3) cancel the
> meeting and keep moving along.
>
> [snip]
>

I vote option 3. There's quite a lot of meaty discussion to be had on these
topics, and I can't see any of them reaching consensus or anything close to
it during the 30 minutes or so each would be allotted.

-- 

*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] IETF 109 possible agenda/session discussion

[Tim Wicinski]

Dave

It's the latter.   Alexey and I are quite fine with running the meeting,
that was part of our conversation.

tim


On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker  wrote:

> On 11/13/2020 10:40 AM, Tim Wicinski wrote:
> > During the chairs call this morning we were discussing the upcoming
> > meeting.  Now Seth has a conflict with the meeting time that can't be
> > altered.   Since work items have been progressing rather well recently,
> > and the editors are in positing, we discussed canceling the meeting.  We
> > wanted to get some feedback from the working group.
> >
> > Here is a lightweight agenda Seth put together.  Should we 1) have a
> > meeting around these topics;  2) discuss other topics or 3) cancel the
> > meeting and keep moving along.
>
>
> Four days before a scheduled, rare meeting, it's being canceled because
> one of its 3 chairs can't attend?
>
> Or because it has suddenly been realized that the meeting won't be useful?
>
> Really?
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

[Dave Crocker]

On 11/13/2020 10:40 AM, Tim Wicinski wrote:
During the chairs call this morning we were discussing the upcoming 
meeting.  Now Seth has a conflict with the meeting time that can't be 
altered.   Since work items have been progressing rather well recently, 
and the editors are in positing, we discussed canceling the meeting.  We 
wanted to get some feedback from the working group.


Here is a lightweight agenda Seth put together.  Should we 1) have a 
meeting around these topics;  2) discuss other topics or 3) cancel the 
meeting and keep moving along.



Four days before a scheduled, rare meeting, it's being canceled because 
one of its 3 chairs can't attend?


Or because it has suddenly been realized that the meeting won't be useful?

Really?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt)

[Todd Herr]

Hi.

I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00
differs from the existing RFC 7489.

The key differences are as follows:

   - Section 7, DMARC Feedback, has been mostly removed except for a
   paragraph that mentions that reporting will be discussed in a different
   document (as per current plans)
   - Section 9, Privacy Considerations, has been removed (under the
   expectation that they'll be discussed in the reporting documents)
   - Appendix C, DMARC XML Schema, has been removed (under the expectation
   that it'll be discussed in the the reporting documents)
   - Remaining target references to "verifying-external-destinations",
   "failure-reports", and "aggregate-reports", which were anchors in the
   removed sections mentioned above, have been replaced by hand-wavy language
   referencing "The DMARC reporting document(s)"
   - The Abstract and Introduction section have been rewritten as an
   attempt to address issue #80  -
   *DMARCbis Should Have a Clear and Concise Definition of DMARC*

Obviously the text applicable to the first four bullet points above will
evolve over time, and it may not yet be the right time in the process to
discuss those sections. However, the proposed new text for the Abstract and
Introduction is certainly worthy of discussion at this time, I believe.

On Wed, Nov 11, 2020 at 4:55 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   : Domain-based Message Authentication, Reporting,
> and Conformance (DMARC)
> Authors : Emil Gustafsson
>   Todd M. Herr
>   John Levine
> Filename: draft-ietf-dmarc-dmarcbis-00.txt
> Pages   : 55
> Date: 2020-11-11
>
> Abstract:
>This document describes the Domain-based Message Authentication,
>Reporting, and Conformance (DMARC) protocol.
>
>DMARC is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting.  Mail-receiving
>organizations can in turn use these expressions of policies and
>preferences to inform their mail handling decisions should they
>choose to do so.
>
>This document obsoletes RFC 7489.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>


-- 

*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] IETF 109 possible agenda/session discussion

[Kurt Andersen (b)]

On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski  wrote:

>
> All
>
> During the chairs call this morning we were discussing the upcoming
> meeting.  Now Seth has a conflict with the meeting time that can't be
> altered.   Since work items have been progressing rather well recently, and
> the editors are in positing, we discussed canceling the meeting.  We wanted
> to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.  Should we 1) have a
> meeting around these topics;  2) discuss other topics or 3) cancel the
> meeting and keep moving along.
>

I'd vote for 3. I think that it would be better to discuss/hash out these
topics on the list. Perhaps we could start each one with a cogent summary
of the issues related to the topic.

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John Levine]

In article <903acb7d-847e-c87c-f21b-dcfa698bf...@wisc.edu> you write:
>You can't think of universities as single entities with central management 
>authority.  For the longest time our CS department owned
>wisc.edu and central IT had to ask them for permission to use it for 
>campus-wide email.

I believe you, and I am quite aware that UW is not the only university
with a governance model based on that of the Holy Roman Empire. (I
went to Yale which was like that, too.)

On the other hand, whether or not we like it, the DNS is a tree, and if an
organization's DNS structure doesn't match their management structure, there
is no way to tell from the outside and it's up tp them to sort it out.

R's,
John

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

[dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

[Tim Wicinski]

All

During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
raised with some of the document.   Most of them are editorial but the one
big item was the description of the Experiment.   The chairs sat down and
broke out the experiment section into three separate experiments, and
included language on how to capture the data to confirm how the experiment
worked.

It's enough of a change that we wanted to do a second working group last
call to make sure the working group agrees with our changes. The diff of
the current version with the previous version is here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09

This starts a *one* week second working group last call for
draft-ietf-dmarc-psd

Please review the changes and offer up comments to the working group.


This working group last call 20 November 2020

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Douglas E. Foster]

I beleive that we can and should address the Columbia University problem.  Here 
are some thoughts:

Policy Types
=---
We have three types of policies:

- "p=" policy for a specific domain
- "sp=" policy for subdomains that do not enumerate their own
- "sp=" policy for non-existent subdomains

Deploying a specific "p=" to every node will provide granular control for 
subdomains that exist, but it does not solve the problem for non-existent 
subdomains.

Non-Existent Domains
--
In almost every case, the policy for non-existent subdomains should be stricter 
than the one for existent subdomains, so sharing one policy for both purposes 
is problematic.   I created ticket #83 last night with a proposal to define a 
policy option for non-existent domains.

Roll-up Policy
--
When rolling a security policy up from leaf nodes upward toward higher level 
nodes, the weakest policy is the one that has to forwarded upward, unless there 
is a mid-tree override mechanism.  By allowing a lower-level subtree to apply a 
different policy than the parent, we allow the stricter policy to flow upward 
while the weak subtree retains its carve-out exception.

If a subtree needs a weak policy and that setting can only be accomplished at 
the top of the domain, then the entire organizaiton's security is weakened for 
the sake of the problematic leaf node.   This is exactly the situation that 
causes sp=none to persist indefinitely.

Inheritance
---
For subdomains that actually exist, one has to ask whether it is reasonable to 
expect an organization to implement a DMARC policy at every node of its domain 
tree.   In the event that a reporting address changes, the organization has a 
lot of changes needed to propagate that change everywhere. We would benefit 
from providing an ability to inherit from an upper-level entry using syntax 
like "inherit=N", where N is an integer number of domain levels.The 
evaluator determines the values for sp, rua, and ruf at the referenced domain, 
and uses the sp result for p and sp on the referencing subdomain.   Similarly, 
the rua and ruf values from the referenced domain are used to supply those 
values if they are not specified on the referencing subdomain DMARC record.   
Since the flow is only upward, the maximum number of iterations is limited, 
even if nested inheritance is allowed.   However, nested inheritance could be 
limited to a maximum number or disaloowed completely.  This approach allows 
subtrees to configure different reporting than the top-level of the 
organization.

Inheritance provides a more efficient method of walking up the domain tree, as 
compared to sequential iteration, for subdomains that actually exist and have 
an inheritance record defined..

QueryDown
--
Walking down the tree has some possibilities as well.

Assume that the top of the organization is located using the PSL, but as in the 
Columbia University example, the sp policy at that level is not necessarily 
determinative.A  token of the form "querydown=1" instructs the evaluator to 
accept the sp policy at this level as a candidate policy, but to check the next 
level down to see if an override applies.   If the token is missing or 0, then 
this record is determinative and the search stops.

- If the next level down is the original domain, then of course the process 
stops because this domain has already been checked for a p policy and been 
found lacking.
- If the next level down produces a DMARC record, the sp at this level becomes 
the new candidate policy, subject to checking for another querydown token.
- If the next level down does not have a DMARC record, the search stops and the 
last candidate policy is the effective policy.
In most cases, this process will end quickly because it will either exhaust the 
domain string, encounter a missing DMARC record, or encounter a DMARC record 
with querydown=0 (or missing).

If the querydown parameter is larger than one, the evaluator can jump down that 
many levels, eliminating intermediate ones.   Again, if this positions the 
match at or below the original domain or below, then the search stops and the 
last candidate policy is applied.

Again, a limit on the number of downward iterations would be applicable.   If 
an "inherit=n" token is being used to walk up the  tree, then the querydown 
parameter would be ignored.

Hope this helps,

Doug Foster



From: Joseph Brennan 
Sent: 11/12/20 9:24 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On 
splitting documents and DBOUND

On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker  wrote:
Just to invoke a bit of ancient history, here, you are saying that if
there was the domain name:

engineering.sun.com

people would be surprised that the organization domain is

oracle.com

As another case, would people be surprised that email for the 

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/13/2020 9:09 AM, Jesse Thompson wrote:

You can't think of universities as single entities with central management 
authority.  For the longest time our CS department owned wisc.edu and central 
IT had to ask them for permission to use it for campus-wide email.



This highlights that the example that was provided was of a university 
that might be asserting 'global' policy under its domain that isn't 
really valid.


That is, the problem with a component group's being affected by a 
higher-level domain's default record is, really, a problem that is 
internal to the organization, not one that should entail accommodation 
by, and the considerable costs of, a public standard.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/13/20 9:03 AM, dotz...@gmail.com wrote:
> 
> 
> On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan  > wrote:
> 
> 
> 
> As another case, would people be surprised that email for the 
> medical center cumc.columbia.edu  is a separate 
> system managed by a separate IT group from columbia.edu 
> , and that any authentication for one should not be 
> applied to the other?  I don't think this is unique in large decentralized 
> universities. The real email world is a complicated place.
> 
> 
> The simple solution is for  cumc.columbia.edu 
> to publish its own record. Done.
> 
> Michael Hammer
> 
> 
> I don't think I have the right to force the owner of another domain to 
> publish dmarc. The owner of the other domain may want to allow users in their 
> domain to contribute to lists and groups without having their messages 
> rejected, or mangled by well-intentioned workarounds. This is not simple. 
> This is a real-world case with the domains ending columbia.edu 
> . 
> 
> 
> If CUMC publishes a DMARC record for cumc.columbia.edu 
> , how is it forcing another domain to do anything? 
> As far as "owner of a domain", If Columbia University registered the domain 
> columbia.edu , then CUMC is using the subdomain because 
> Columbia University is allowing it to, presumably through some sort of 
> written agreement. A technical standards body cannot address business and 
> contractual arrangement in the manner you appear to be asking. If Columbia 
> University stopped delegating the subdomain cumc.columbia.edu 
> , would you turn to the IETF for redress?  

You can't think of universities as single entities with central management 
authority.  For the longest time our CS department owned wisc.edu and central 
IT had to ask them for permission to use it for campus-wide email.

Yes, 3rd level domains should be encouraged to publish DMARC records for their 
domains to reflect how they are being used, and putting p=none not a big ask of 
them.  

The departmental IT who understand DMARC immediately ask: "How do I publish a 
subdomain policy?  Oh, I can't?  Well, you better not ever change sp=none at 
the org domain."

Jesse

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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/12/20 5:06 PM, Kurt Andersen (b) wrote:
> On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson 
> mailto:40wisc@dmarc.ietf.org>> 
> wrote:
> 
> On 11/12/20 3:23 PM, John Levine wrote:
> > You now can put a DMARC
> > record on a name below the org domain to shadow a subtree, but I don't
> > think that is a problem that needs to be solved.
> 
> I'm confused by this statement.  Are you saying that you can "now" do 
> subtree shadowing with sp?  as in the following language is being changed 
> "now"?
> 
> 
> I think that John was referring the potential future state where tree-walks 
> were being done, but even then I don't think it would work quite that easily. 
> A record at "a.b.example" would not shadow "x.y.a.b.example" if "x" or "y" 
> chose to express some policy.

Yes, that makes sense for a defined policy to override any inherited subdomain 
policy. 

Jesse

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/13/2020 6:46 AM, Joseph Brennan wrote:

The simple solution is for cumc.columbia.edu
to publish its own record. Done.

Michael Hammer


I don't think I have the right to force the owner of another domain to 
publish dmarc. The owner of the other domain may want to allow users in 
their domain to contribute to lists and groups without having their 
messages rejected, or mangled by well-intentioned workarounds. This is 
not simple. This is a real-world case with the domains ending 
columbia.edu .



I'm not sure how 'forcing' is involved here, but let's make sure we have 
the same foundation for discussion:


A domain name falls under an administrative authority.  Names above or 
below this domain name might fall under the same, or a different, authority.


An administrative authority has the responsibility for setting policies 
for the domains over which it has authority.


The discussion, here, concerns finding a domain that is the 'top' of an 
administrative authority hierarchy, in order to discern a possible, 
default dmarc record.


While there has sometimes been discussion about whether that default in 
fact can override a specific domain's DMARC record's attributes, I 
believe the accepted view is that it is applied only in the absence of a 
specific domain's dmarc record, rather than being applied to selectively 
modify one.


An administrative authority might set a strict default, such as 
d=reject.  Any subordinate domain, within that authority, can override 
this by merely publishing its own record with a different set of 
parameters, such as d=none.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dotzero]

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan  wrote:

>
>
>>> As another case, would people be surprised that email for the medical
>>> center cumc.columbia.edu is a separate system managed by a separate IT
>>> group from columbia.edu, and that any authentication for one should not
>>> be applied to the other?  I don't think this is unique in large
>>> decentralized universities. The real email world is a complicated place.
>>>
>>>
>> The simple solution is for  cumc.columbia.eduto publish its own record.
>> Done.
>>
>> Michael Hammer
>>
>
> I don't think I have the right to force the owner of another domain to
> publish dmarc. The owner of the other domain may want to allow users in
> their domain to contribute to lists and groups without having their
> messages rejected, or mangled by well-intentioned workarounds. This is not
> simple. This is a real-world case with the domains ending columbia.edu.
>

If CUMC publishes a DMARC record for cumc.columbia.edu, how is it forcing
another domain to do anything? As far as "owner of a domain", If Columbia
University registered the domain columbia.edu, then CUMC is using the
subdomain because Columbia University is allowing it to, presumably through
some sort of written agreement. A technical standards body cannot address
business and contractual arrangement in the manner you appear to be asking.
If Columbia University stopped delegating the subdomain cumc.columbia.edu,
would you turn to the IETF for redress?

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Joseph Brennan]

>
>> As another case, would people be surprised that email for the medical
>> center cumc.columbia.edu is a separate system managed by a separate IT
>> group from columbia.edu, and that any authentication for one should not
>> be applied to the other?  I don't think this is unique in large
>> decentralized universities. The real email world is a complicated place.
>>
>>
> The simple solution is for  cumc.columbia.eduto publish its own record.
> Done.
>
> Michael Hammer
>

I don't think I have the right to force the owner of another domain to
publish dmarc. The owner of the other domain may want to allow users in
their domain to contribute to lists and groups without having their
messages rejected, or mangled by well-intentioned workarounds. This is not
simple. This is a real-world case with the domains ending columbia.edu.

-- 
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] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Alessandro Vesely]

On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote:

On 11/12/2020 1:23 PM, John Levine wrote:

The semantics are definitely not the same. You now can put a DMARC
record on a name below the org domain to shadow a subtree,



that's why the group should first focus on the semantics it wants/doesn't want, 
independent of how the semantics are achieved.  The statement of what is wanted 
should be administrative/authority language, not technical language.



Agreed.  And I don't think that a tree walk would match DMARC semantics.

AIUI, the Organizational Domain must be a domain recognized by all "subdomains" 
as authoritative on policies.


Of course, if every organization had the ability to generate DNS records for 
each domain, there would've been no need to use the PSL.  SPF experience taught 
that even "smart" organizations may lack the ability to do so.  Hence, the 
Organizational Domain must be such that its admins are entitled to generate 
those records if they wanted to.



Best
Ale
--
























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