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

[Steven M Jones]

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


I support the change.

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

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

[Steven M Jones]

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


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

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

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

[Steven M Jones]

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


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


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

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

[Steven M Jones]

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


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


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

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

[Steven M Jones]

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


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

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

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

[Steven M Jones]

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


I support the proposed change.

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

Re: [dmarc-ietf] Question on ABNF

[Seth Blank]

Tim, please add a ticket for this

On Fri, May 28, 2021 at 13:54 Dave Crocker  wrote:

> On 5/28/2021 12:10 PM, Tim Wicinski wrote:
>
> So in looking at removing the "ri" tag from the document, I realized that
> the ABNF reference needed to be removed also.
> Thinking about that, I realized that when one adds a new tag to the
> registry there should be a formalized way that it is represented in the
> ABNF.   Perhaps the IANA Consideration section should also spell out that
> for new tags, the specification should also include the incorporating ABNF.
>
> +1
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank* | VP, Product
*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] Question on ABNF

[Dave Crocker]

On 5/28/2021 12:10 PM, Tim Wicinski wrote:
So in looking at removing the "ri" tag from the document, I realized 
that the ABNF reference needed to be removed also.
Thinking about that, I realized that when one adds a new tag to the 
registry there should be a formalized way that it is represented in 
the ABNF.   Perhaps the IANA Consideration section should also spell 
out that for new tags, the specification should also include the 
incorporating ABNF.



+1

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[dmarc-ietf] Question on ABNF

[Tim Wicinski]

So in looking at removing the "ri" tag from the document, I realized that
the ABNF reference needed to be removed also.
Thinking about that, I realized that when one adds a new tag to the
registry there should be a formalized way that it is represented in the
ABNF.   Perhaps the IANA Consideration section should also spell out that
for new tags, the specification should also include the incorporating ABNF.


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

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

[Tim Wicinski]

Editors,

I sent y'all a pull request.

Tim

On Fri, May 28, 2021 at 2:35 PM Dotzero  wrote:

>
>
> On Fri, May 28, 2021 at 1:59 PM John Levine  wrote:
>
>> It appears that Tim Wicinski   said:
>> >-=-=-=-=-=-
>> >
>> >All,
>> >
>> >This is the current text in Section 10.4 of dmarc-bis
>> >
>> >   Names of DMARC tags must be registered with IANA in this new sub-
>> >   registry.  New entries are assigned only for values that have been
>> >   documented in a manner that satisfies the terms of Specification
>> >   Required, per [RFC8126].  Each registration must include the tag
>> >   name; the specification that defines it; a brief description; and its
>> >   status, which must be one of "current", "experimental", or
>> >   "historic".  The Designated Expert needs to confirm that the provided
>> >   specification adequately describes the new tag and clearly presents
>> >   how it would be used within the DMARC context by Domain Owners and
>> >   Mail Receivers.
>> >
>> >I don't believe we can actually remove said tag from the IANA registry,
>> >but we can mark them as "historic", and remove the text from the
>> >new document.
>>
>> Marking it "historic" seems appropriate, since that'll keep future
>> versions
>> of DMARC from using it for something else.
>>
>> --
>> Regards,
>> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
>> Dummies",
>> Please consider the environment before reading this e-mail. https://jl.ly
>>
>
> +1
>
> Michael Hammer
>
> ___
> 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] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

[Dotzero]

On Fri, May 28, 2021 at 1:59 PM John Levine  wrote:

> It appears that Tim Wicinski   said:
> >-=-=-=-=-=-
> >
> >All,
> >
> >This is the current text in Section 10.4 of dmarc-bis
> >
> >   Names of DMARC tags must be registered with IANA in this new sub-
> >   registry.  New entries are assigned only for values that have been
> >   documented in a manner that satisfies the terms of Specification
> >   Required, per [RFC8126].  Each registration must include the tag
> >   name; the specification that defines it; a brief description; and its
> >   status, which must be one of "current", "experimental", or
> >   "historic".  The Designated Expert needs to confirm that the provided
> >   specification adequately describes the new tag and clearly presents
> >   how it would be used within the DMARC context by Domain Owners and
> >   Mail Receivers.
> >
> >I don't believe we can actually remove said tag from the IANA registry,
> >but we can mark them as "historic", and remove the text from the
> >new document.
>
> Marking it "historic" seems appropriate, since that'll keep future versions
> of DMARC from using it for something else.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>

+1

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

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

[Dotzero]

On Fri, May 28, 2021 at 1:32 PM Alessandro Vesely  wrote:

> On Fri 28/May/2021 17:47:25 +0200 Todd Herr wrote:
> >
> > Consensus on Ticket #82 
> (Deprecate
> > rf= and maybe fo= tag) was reached during the May 27 DMARC Interim to
> remove
> > the "rf" tag from the core spec and allow for the possibility that it
> could
> > potentially be reintroduced, if needed, in the separate failure
> reporting spec.
> > (The fo tag was not discussed during this part of the Interim).
>
>
> Agree to totally eliminate rf= from the spec.  As an unknown tag, it won't
> invalidate existing DMARC records.
>
>
> Best
> Ale
> --
>
>
+1

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

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

[Dotzero]

On Fri, May 28, 2021 at 2:03 PM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >On Fri 28/May/2021 17:46:54 +0200 Todd Herr wrote:
> >> Greetings.
> >>
> >> Consensus on Ticket #54 
> (Remove or
> >> expand limits on number of recipients per report) was reached during
> the May 27
> >> DMARC Interim to update the text in the DMARC URIs section to read:
> >>
> >> The place such URIs are specified (see Section 6.3)
> >> allows a list of these to be provided. The list of URIs is
> separated by
> >> commas (ASCII 0x2c). A report SHOULD be sent to each listed URI
> provided in
> >> the DMARC record.
> >
> >
> >Works for me.  (Note that a limit of 100 recipients is silently enforced
> by
> >most underlying MTAs.)
>
> That's 100 recipients per SMTP session.  Nothing keeps you from sending
> mail to 10,000
> recipients in 100 sessions.  I do not think this detail affects the
> decision to take
> out the limit since it's hard to imagine a useful scenario with as many as
> 10 recipients.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>

+1

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

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

[Dotzero]

On Fri, May 28, 2021 at 2:01 PM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:
> >>
> >> Consensus on Ticket #53 
> (Remove
> >> reporting message size chunking) was reached during the May 27 DMARC
> Interim to
> >> remove the feature and update the IANA registry and ABNF grammar as
> necessary.
> >
> >Agreed.  However, the grammar should be retained in order to not
> invalidate
> >existing records.  Any !10m tail should just be ignored.
>
> What I heard at the interim was that not only does nobody implement size
> limits,
> some large receivers don't recognize the !nn suffix and the reports fail.
> Take
> it out so the spec agrees with reality.
>
> R's,
> John
>

+1 to what John wrote.

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

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

[Dotzero]

On Fri, May 28, 2021 at 1:41 PM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >On Fri 28/May/2021 17:43:09 +0200 Todd Herr wrote:
> >> The value of this tag is either "0", "1", or a colon-separated list
> of the
> >> options represented by alphabetic characters.
> >
> >Works for me.
>
> Yes.
>
> R's,
> John
>

+1

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

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

[John Levine]

It appears that Alessandro Vesely   said:
>On Fri 28/May/2021 17:46:54 +0200 Todd Herr wrote:
>> Greetings.
>> 
>> Consensus on Ticket #54  (Remove 
>> or 
>> expand limits on number of recipients per report) was reached during the May 
>> 27 
>> DMARC Interim to update the text in the DMARC URIs section to read:
>> 
>> The place such URIs are specified (see Section 6.3)
>> allows a list of these to be provided. The list of URIs is separated by
>> commas (ASCII 0x2c). A report SHOULD be sent to each listed URI provided 
>> in
>> the DMARC record.
>
>
>Works for me.  (Note that a limit of 100 recipients is silently enforced by 
>most underlying MTAs.)

That's 100 recipients per SMTP session.  Nothing keeps you from sending mail to 
10,000
recipients in 100 sessions.  I do not think this detail affects the decision to 
take
out the limit since it's hard to imagine a useful scenario with as many as 10 
recipients.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

[John Levine]

It appears that Alessandro Vesely   said:
>On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:
>> 
>> Consensus on Ticket #53  (Remove 
>> reporting message size chunking) was reached during the May 27 DMARC Interim 
>> to 
>> remove the feature and update the IANA registry and ABNF grammar as 
>> necessary.
>
>Agreed.  However, the grammar should be retained in order to not invalidate 
>existing records.  Any !10m tail should just be ignored.

What I heard at the interim was that not only does nobody implement size limits,
some large receivers don't recognize the !nn suffix and the reports fail.  Take
it out so the spec agrees with reality.

R's,
John

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

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

[John Levine]

It appears that Tim Wicinski   said:
>-=-=-=-=-=-
>
>All,
>
>This is the current text in Section 10.4 of dmarc-bis
>
>   Names of DMARC tags must be registered with IANA in this new sub-
>   registry.  New entries are assigned only for values that have been
>   documented in a manner that satisfies the terms of Specification
>   Required, per [RFC8126].  Each registration must include the tag
>   name; the specification that defines it; a brief description; and its
>   status, which must be one of "current", "experimental", or
>   "historic".  The Designated Expert needs to confirm that the provided
>   specification adequately describes the new tag and clearly presents
>   how it would be used within the DMARC context by Domain Owners and
>   Mail Receivers.
>
>I don't believe we can actually remove said tag from the IANA registry,
>but we can mark them as "historic", and remove the text from the
>new document.

Marking it "historic" seems appropriate, since that'll keep future versions
of DMARC from using it for something else.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Consensus Sought - Ticket #4 (Definition of "fo" parameter) - With Interim Notes

[John Levine]

It appears that Alessandro Vesely   said:
>On Fri 28/May/2021 17:43:09 +0200 Todd Herr wrote:
>> The value of this tag is either "0", "1", or a colon-separated list of 
>> the
>> options represented by alphabetic characters.
>
>Works for me.

Yes.

R's,
John

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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:43:59 +0200 Todd Herr wrote:


Consensus on Ticket #50  (Remove 
ri= tag) was reached during the May 27 DMARC Interim to remove the tag and 
update the IANA registry to reflect its removal.



Agree to totally eliminate ri= from the spec.  Report producers should be free 
to choose the best reporting frequency.



Best
Ale
--












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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:47:25 +0200 Todd Herr wrote:


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



Agree to totally eliminate rf= from the spec.  As an unknown tag, it won't 
invalidate existing DMARC records.



Best
Ale
--

















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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:46:54 +0200 Todd Herr wrote:

Greetings.

Consensus on Ticket #54  (Remove or 
expand limits on number of recipients per report) was reached during the May 27 
DMARC Interim to update the text in the DMARC URIs section to read:


The place such URIs are specified (see Section 6.3)
allows a list of these to be provided. The list of URIs is separated by
commas (ASCII 0x2c). A report SHOULD be sent to each listed URI provided in
the DMARC record.



Works for me.  (Note that a limit of 100 recipients is silently enforced by 
most underlying MTAs.)



Best
Ale
--























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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:46:20 +0200 Todd Herr wrote:


Consensus on Ticket #53  (Remove 
reporting message size chunking) was reached during the May 27 DMARC Interim to 
remove the feature and update the IANA registry and ABNF grammar as necessary.



Agreed.  However, the grammar should be retained in order to not invalidate 
existing records.  Any !10m tail should just be ignored.



Best
Ale
--
















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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:43:37 +0200 Todd Herr wrote:


Consensus on Ticket #47  (Removal 
of "pct" tag) was reached during the May 27 DMARC Interim to keep the tag, but 
to rewrite its definition in whole or in part to make its usage better understood.



I think the text in RFC 7489 is quite good.  Perhaps a word could be added for 
pct=0; for example:


OLD
   pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
  default is 100).  Percentage of messages from the Domain Owner's
  mail stream to which the DMARC policy is to be applied.  However,
  this MUST NOT be applied to the DMARC-generated reports, all of
  which must be sent and received unhindered.  The purpose of the
  "pct" tag is to allow Domain Owners to enact a slow rollout
  enforcement of the DMARC mechanism.  The prospect of "all or
  nothing" is recognized as preventing many organizations from
  experimenting with strong authentication-based mechanisms.  See
  Section 6.6.4 for details.  Note that random selection based on
  this percentage, such as the following pseudocode, is adequate:

   if (random mod 100) < pct then
 selected = true
   else
 selected = false

NEW
   pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
  default is 100).  Percentage of messages from the Domain Owner's
  mail stream to which the DMARC policy is to be applied.  However,
  this MUST NOT be applied to any other use, such as skipping DMARC
  reports or demeaning a domain's policy.  The purpose of the
  "pct" tag is to allow Domain Owners to enact a slow rollout
  enforcement of the DMARC mechanism.  Using this tag, organizations
  can experiment with strong authentication-based mechanisms while
  lowering or even voiding the risk of non-delivery.  See Section 6.6.4
  for details.  Note that random selection based on this percentage,
  such as the following pseudocode, is adequate:

   if (random mod 100) < pct then
 selected = true
   else
 selected = false

jm2c
Ale
--





















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

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

[Alessandro Vesely]

On Fri 28/May/2021 17:43:09 +0200 Todd Herr wrote:

The value of this tag is either "0", "1", or a colon-separated list of the
options represented by alphabetic characters.



Works for me.


Ale
--











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

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

[Tim Wicinski]

All,

This is the current text in Section 10.4 of dmarc-bis

   Names of DMARC tags must be registered with IANA in this new sub-
   registry.  New entries are assigned only for values that have been
   documented in a manner that satisfies the terms of Specification
   Required, per [RFC8126].  Each registration must include the tag
   name; the specification that defines it; a brief description; and its
   status, which must be one of "current", "experimental", or
   "historic".  The Designated Expert needs to confirm that the provided
   specification adequately describes the new tag and clearly presents
   how it would be used within the DMARC context by Domain Owners and
   Mail Receivers.

I don't believe we can actually remove said tag from the IANA registry,
but we can mark them as "historic", and remove the text from the
new document.

Someone should consult with the IANA folks for specifics.
I'll volunteer to take point if so desired.

tim



On Fri, May 28, 2021 at 11:44 AM Todd Herr  wrote:

> Greetings.
>
> Consensus on Ticket #50 
> (Remove ri= tag) was reached during the May 27 DMARC Interim to remove the
> tag and update the IANA registry to reflect its removal.
>
> I seek consensus from the working group at large on this ticket, and
> request that a decision be made by Friday, June 11. Discussions about this
> issue should be contained in this thread.
>
> Thank you.
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *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

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

[Todd Herr]

Greetings.

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

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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-ietf] Consensus Sought - Ticket #54 (Limits on recipients per report) - With Interim Notes

[Todd Herr]

Greetings.

Consensus on Ticket #54 
(Remove or expand limits on number of recipients per report) was reached
during the May 27 DMARC Interim to update the text in the DMARC URIs
section to read:

The place such URIs are specified (see Section 6.3
)
allows a list of these to be provided. The list of URIs is separated by
commas (ASCII 0x2c). A report SHOULD be sent to each listed URI provided in
the DMARC record.

This proposed change will be made in the next version of dmarcbis,
scheduled for release in the next few weeks.

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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-ietf] Consensus Sought - Ticket #53 (Remove reporting message size chunking) - With Interim Notes

[Todd Herr]

Greetings.

Consensus on Ticket #53 
(Remove reporting message size chunking) was reached during the May 27
DMARC Interim to remove the feature and update the IANA registry and ABNF
grammar as necessary.

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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-ietf] Consensus Sought - Ticket #50 (Remove ri= tag) - With Interim Notes

[Todd Herr]

Greetings.

Consensus on Ticket #50 
(Remove ri= tag) was reached during the May 27 DMARC Interim to remove the
tag and update the IANA registry to reflect its removal.

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

[Todd Herr]

Greetings.

Consensus on Ticket #47 
(Removal of "pct" tag) was reached during the May 27 DMARC Interim to keep
the tag, but to rewrite its definition in whole or in part to make its
usage better understood.

This rewriting is planned to be included in the next version of dmarcbis,
scheduled for release in the next few weeks.

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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-ietf] Consensus Sought - Ticket #4 (Definition of "fo" parameter) - With Interim Notes

[Todd Herr]

Greetings.

Consensus on Ticket #4 (Definition
of "fo" parameter) was reached during the May 27 DMARC Interim to update
the definition of the "fo" parameter with the following sentence, as shown
in dmarcbis-01:

The value of this tag is either "0", "1", or a colon-separated list of the
options represented by alphabetic characters.


It is understood from the discussion that ABNF for the "fo" tag will have
to be updated, and this update will happen in the next version of dmarcbis,
scheduled for release in the next few weeks.

I seek consensus from the working group at large on this ticket, and
request that a decision be made by Friday, June 11. Discussions about this
issue should be contained in this thread.

Thank you.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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] Notes from DMARC interim teleconference, 27 May 2021

[Barry Leiba]

Todd sent me the final slides — thanks — and they are now uploaded at the
same link as the minutes.

Barry

On Thu, May 27, 2021 at 5:32 PM Todd Herr  wrote:

> On Thu, May 27, 2021 at 5:06 PM Tim Wicinski  wrote:
>
>> Thanks to all, especially note takers
>>
>> One request to the chairs - can you upload the slide deck into the
>> datatracker also?
>>
>>
>>
> I have the action to do this, and will take care of it on Friday the 28th.
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *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