Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Jim Fenton]

On 5 May 2021, at 21:26, Seth Blank wrote:

Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 
4-6pm

GMT.


2) I wish to participate in the interim, but the timing does not work

(Unless some standing meetings get cancelled). But it looks like I’m 
the only one, so have fun, everyone.


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

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

[Douglas Foster]

This is about
Section 3.8. Non-existent Domains

   For DMARC purposes, a non-existent domain is a domain for which there
   is an NXDOMAIN or NODATA response for A, , and MX records.  This
   is a broader definition than that in [RFC8020].

My argument is that that A//MX has no useful relevance to
determining whether the RFC5322.FROM address of a message should be
evaluated based on SP or NP.  NP is described as testing
"non-existent", rather than "possibly able to receive mail".   We need
a test that evaluates whether the domain exists or not, and is
maximally protected from false positives caused by host names and
wildcards.

If this group is convinced that A//MX is meaningful for the
distinction between SP and NP, I am asking someone to provide the
justification and define the algorithm.  Right now I have seen
neither.


On Thu, May 6, 2021 at 9:52 PM Seth Blank  wrote:

> On Thu, May 6, 2021 at 18:47 John Levine  wrote:
>
>> It appears that Douglas Foster  
>> said:
>> >My perception has been that NDRs are widely ignored even when they are
>> >sent.  Is your experience different?
>>
>> Yes.  We are not going to rewrite RFC 5321 here.  Please stop.
>
>
> Doug, I don’t understand what textual consideration within the DMARCbis
> documents you are discussing.
>
> Please reference the text in question and your proposed modifications, or
> move on to a topic which is material to driving this bis documents to
> completion, which is our current work item.
>
> Seth, as Chair
> --
>
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Seth Blank]

On Thu, May 6, 2021 at 18:47 John Levine  wrote:

> It appears that Douglas Foster  
> said:
> >My perception has been that NDRs are widely ignored even when they are
> >sent.  Is your experience different?
>
> Yes.  We are not going to rewrite RFC 5321 here.  Please stop.


Doug, I don’t understand what textual consideration within the DMARCbis
documents you are discussing.

Please reference the text in question and your proposed modifications, or
move on to a topic which is material to driving this bis documents to
completion, which is our current work item.

Seth, as Chair
-- 

*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] Ticket #111 - MX/A/AAAA test needs justification

[John Levine]

It appears that Douglas Foster   said:
>My perception has been that NDRs are widely ignored even when they are
>sent.  Is your experience different?

Yes.  We are not going to rewrite RFC 5321 here.  Please stop.

R's,
John

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

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

[Hector Santos]

On 5/6/2021 8:02 PM, Douglas Foster wrote:
I have begun data collection on the effectiveness of the MX and A 
tests.   Wildcard DNS entries increase the frequency of false 
positives and reduce the usability of the test.   For example, 
"msaqq189.ford.com " returns a set of MX 
results, but I rather doubt that I made a lucky guess and found a 
mail domain that Ford Motor actually uses.


You are adding an human element to this that doesn't exist.

At best, all you can do is enforce the protocol requirements, the MUST 
semantics for sure, the SHOULD, most of the time (it is not a MUST) 
and the possible MAYS.   You have to be ready for all that independent 
of reputation.


The beauty of the DKIM Policy-based Model that began with DomainKeys, 
extended with DKIM which included SSP, reduced to ADSP when splitting 
SSP from DKIM-BASE, then abandoned and now DMARC which brought it back 
to life by adding Reporting, is the DOMAIN now giving the world a hint 
about its operations.


DMARC is very limited to three policies: reject, quarantine & none.

Reject and Quarantine is equivalent to an exclusive, restrictive 
policy which gives SMTP transport rejection authorization. Otherwise, 
you did nothing with a "none" policy.


There are the protocol rules.  The restrictive policies has alignment 
rules and there are procedures to getting to these results, like 
lookup DNS requirements.


Independent of DMARC,  MX is a SHOULD for a domain, you can still send 
mail to a domain that does not have MX records.    is obviously a 
SHOULD because not everyone is TCP6 ready.  Everyone is not going to 
have a DMARC record, nor a DKIM record.  SSP, ADSP and now DMARC are 
the only way to get a DOMAIN policy above and beyond standard SMTP.  
SPF is also an extension to SMTP with its own independent requirements 
that DMARC MUST match.


So whats the easiest for a domain not to have any trouble with any of 
this?


Don't support it.  Don't pretend to support it.  Just ignore SPF, DKIM 
and its add-ons.


SMTP Receivers are not at a point where we can enforce what may not 
exist - a domain policy extractable at two points:


SMTP.MAIL FROM:  for SPF
SMTP.DATA.FROM: for DMARC

I have proposed that we exploit the SUBMITTER protocol and optimized 
this high overhead protocol, by passing the 5322.FROM field to the 
MAIL FROM: line


MAIL FROM:  submitter=5322.from


Now SMTP has the ability to check for the DMARC policy to see how 
strong SPF SHOULD be and if its fails or not.


This will allow for the short circuiting and optimization of MAIL data 
I/O which today is increasingly getting larger with multi-media data 
transfer.



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



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

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

[Douglas Foster]

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



On Thu, May 6, 2021 at 6:32 PM Jeremy Harris  wrote:

> On 05/05/2021 12:28, Douglas Foster wrote:
> > Non-delivery reports are officially discouraged
>
> RFC 5321 Section 6.2 says the reverse.
>
> --
> Cheers,
>Jeremy
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

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

Doug Foster


2.5 .  Location of Checks

   The authorization check SHOULD be performed during the processing of
   the SMTP transaction that receives the mail.  This reduces the
   complexity of determining the correct IP address to use as an input
   to check_host() and allows errors to be returned directly to the
   sending MTA by way of SMTP replies.  Appendix D of [RFC7001]
 provides
   a more thorough discussion of this topic.

   The authorization check is performed during the SMTP transaction at
   the time of the MAIL command, and uses the MAIL FROM value and the
   client IP address.  Performing the check at later times or with other
   input can cause problems such as the following:

   o  It might be difficult to accurately extract the required
  information from potentially deceptive headers.

   o  Legitimate email might fail the authorization check because the
  sender's policy has since changed.

   Generating non-delivery notifications to forged identities that have
   failed the authorization check often constitutes backscatter, i.e.,
   nuisance rejection notices that are not actionable.  Operators are
   strongly advised to avoid such practices.  Section 2 of [RFC3834]

   describes backscatter and the problems it causes.



On Thu, May 6, 2021 at 6:32 PM Jeremy Harris  wrote:

> On 05/05/2021 12:28, Douglas Foster wrote:
> > Non-delivery reports are officially discouraged
>
> RFC 5321 Section 6.2 says the reverse.
>
> --
> Cheers,
>Jeremy
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jeremy Harris]

On 05/05/2021 12:28, Douglas Foster wrote:

Non-delivery reports are officially discouraged


RFC 5321 Section 6.2 says the reverse.

--
Cheers,
  Jeremy

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Kurt Andersen (b)]

Yes, I will participate and the proposed timing is fine.

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

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dotzero]

Overall I'm comfortable with the introduction verbiage. I do have one
concern:

"For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the Domain Owner and/or any, some, or all of the

   Authenticated Identifiers.  Therefore, reputation assessment of that

   stream by the mail-receiving organization does not need to be

   encumbered by accounting for unauthorized use of any domains."



My concern is with "does not need to be encumbered by accounting for
unauthorized use of any domains". This ignores cases such as DNS hijacking
and domain compromise. Perhaps changing it to "does not need to be
encumbered by accounting for unauthorized use of any domains by 3rd party
senders" or  "does not need to be encumbered by accounting for unauthorized
use of any domains by 3rd party originators"

Michael Hammer

On Thu, May 6, 2021 at 8:22 AM Todd Herr  wrote:

> On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely  wrote:
>
>> Todd,
>>
>> does your message assume that the relevant tickets are all accepted as
>> valid
>> indications to alter the spec?  In particular, tickets #52 and #75 have
>> never
>> been discussed on list. I'd guess they'll have to be discussed in their
>> own
>> threads.
>>
>
> I don't know if each of those individual tickets has to be discussed in
> their own threads or not, and I think it's more a decision for the chairs
> to make than for the editors or the working group, but I could be very
> wrong about that.
>
> What I will say is this:
>
>- The design team went off and effectively created a new version of
>draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
>proposed text, nothing more, nothing less.
>- The design team's work was influenced by those tickets which
>currently show a status of 'infoneeded'.
>- Due to the nature of the text, both of the following are true:
>   - Most, but perhaps not all, of the 'infoneeded' tickets had
>   impacts on multiple sections of draft-ietf-dmarc-dmarcbis-01
>   - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
>   that were made in producing draft-ietf-dmarc-dmarcbis-01 were 
> influenced by
>   multiple tickets
>
> Back on April 23, when I posted here about setting expectations, I thought
> at the time that adjudicating each of the infoneeded tickets might be the
> way to go, but upon further reflection I'm not sure that's the case, since
> it can be argued that those tickets were created against a work product
> that no longer exists. It's also true that because those tickets affect the
> wording in multiple sections of the document, adjudicating the -00 tickets
> can theoretically result in a morass of edits made across multiple sections
> of -01 and subsequent revisions, and everyone eventually losing the plot.
>
> Chairs, your thoughts?
>
>
>> Discussing the resulting text before those tickets entails, for example,
>> noting
>> the cumbersomeness of the locution "severity of concern" where something
>> like
>> "desired disposition" might seem more immediate.  In fact, ticket #85 was
>> only
>> discussed as a side effect of ticket #39, where the consensus, IIRC, was
>> to
>> keep the existing policy names while wavering about how to describe them.
>>
>> The term RFC5322.From is consistently used, notwithstanding ticket #96.
>> For an
>> alternative, let me attempt to define DMARC in terms of its acronym:
>>
>> The Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC)
>> protocol recognizes the prevailing importance of the domain appearing
>> in the
>> From: header field of email messages.  That domain name will be
>> called the
>> Main Identifier in this document.  DMARC leverages the Sender Policy
>> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
>> protocols
>> by focusing the authentication mechanisms they provide toward the Main
>> Identifier.  The Domain Owners corresponding to the Main Identifier
>> are
>> endowed with the possibility to receive feedback reports about
>> authentication results at receivers.  Finally, receivers are provided
>> with
>> the Domain Owners' desiderata about messages that fail
>> authentication, which
>> receivers may or may not decide to conform to.
>>
>>
> As I stated above, I believe the better path for the working group is to
> adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
> labeled "Introduction", you have proposed alternate text for that section,
> let's discuss that section on the list, come to a consensus, and do it all
> under the auspices of ticket 113.
>
> But that's just my opinion...
>
> --
>
> *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 

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Alessandro Vesely]

On Thu 06/May/2021 06:26:56 +0200 Seth Blank wrote:

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


Yup, the intention is present.


Best
Ale
--










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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Tim Wicinski]

I will be able to attend.

I will ask the kind chairs that once an Interim is scheduled, you could
send a calendar invite with all the details for those of us unable to
function
without one?

thanks
tim


On Thu, May 6, 2021 at 11:08 AM John Levine  wrote:

> It appears that Seth Blank   said:
> >The Chairs ask group participants to explicitly speak up if:
> >1) they intend to participate in the interim
> >or 2) they wish to participate in the interim, but the timing does not
> work
>
> I can do it at that time.
>
> R's,
> John
>
> ___
> 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] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[John Levine]

It appears that Seth Blank   said:
>The Chairs ask group participants to explicitly speak up if:
>1) they intend to participate in the interim
>or 2) they wish to participate in the interim, but the timing does not work

I can do it at that time.

R's,
John

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Dave Crocker]

On 5/5/2021 9:26 PM, Seth Blank wrote:

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


yes.

d/

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

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Trent Adams]

I intend to participate in the interim meeting at the proposed time.

Thanks,
Trent


From: dmarc  on behalf of Seth Blank 

Date: Wednesday, May 5, 2021 at 10:27 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group 
feedback on timing and participation

WG colleagues,

We committed to holding an interim meeting after the DMARCbis documents were 
delivered, and cancelled our IETF 110 meeting to make space for the design team 
to work.

We now have new documents from the design team, and it's time to schedule the 
Interim.
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 4-6pm GMT.

We believe this provides sufficient time for the group to digest the newly 
proposed text and have a productive discussion.

The Chairs ask group participants to explicitly speak up if:
1) they intend to participate in the interim
or 2) they wish to participate in the interim, but the timing does not work

Thanks,

Seth and Barry, as Chairs

--
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] Recipient domain in aggregate reports (#23)

[Barry Leiba]

Chair weighing in, as chair:

We're divided in the sense that there are some who want to add this
information, but as I see it the rough consensus is not divided:
- This is extra information that's being proposed... so, a new
feature.  That requires rough consensus to add it.
- Serious privacy issues have been raised with respect to adding that
information.
- No refutation of those privacy issues has been given, and no
adequate mitigation has been proposed.  The suggestion of requiring a
minimum level of aggregation is insufficient, as there's ample general
evidence that privacy leaks survive aggregation.
- We therefore do not have rough consensus to add this.

The chairs, therefore, declare this issue closed.

I'll also note that the IESG *will* bring up the privacy issues and
would very likely block the document on those grounds.  I don't think
we want to go there.

Barry

On Wed, May 5, 2021 at 9:18 PM Brotman, Alex
 wrote:
>
> Are we divided?  Seems like use cases have been noted.  However, removing 
> these completely protects some aspects of privacy.  Could we perhaps err on 
> the side of caution, removing these definitions, and leave a note to suggest 
> that if domain holders need further assistance to reach out to the report 
> generator. The generator can then make decisions about how much information 
> to expose.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> > -Original Message-
> > From: dmarc  On Behalf Of Alessandro Vesely
> > Sent: Tuesday, May 4, 2021 5:07 AM
> > To: dmarc@ietf.org; Douglas Foster
> > 
> > Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
> >
> > Doug,
> >
> >
> > On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
> > > No.  I can't talk straight.
> > >
> > > I meant to say that we need N unique (and valid) smtp TO addresses, so
> > > that an attacker cannot send a single email address and wait for an
> > > rua report to know where it lands.
> >
> >
> > A simple positive DSN can confirm email addresses better than elaborate
> > DKIM design.  To confirm delivery is usually not considered a privacy
> > violation, given that the sender learned the recipient's address.  Privacy
> > violation occurs when senders track the recipient's opening of each message,
> > which is typically obtained by inserting unique images in HTML messages.
> >
> > Avoiding to reveal final email addresses requires various precautions, 
> > which,
> > if I understood what Laura wrote, can be put into effect on forwarding.  I
> > would *add to the Privacy Consideration section* that, due to reporting,
> > changing the envelope from is not enough, From: has to be changed as well
> > in order to forward without revealing the final address.
> >
> >
> > > Valid addresses are needed to hinder usage of bogus addresses to defeat
> > the test.
> >
> >
> > However, the aggregate report counts the number of messages, not the
> > number of recipients.
> >
> >
> > > Requiring aggregation on DKIM selector follows the sane logic to hinder
> > > tracking an individual.
> > >
> > > Using DKIM selectors for tracking will also put a huge load on DNS if
> > > implemented at scale, so it needs to be obstructed.
> >
> >
> > I think mass mailers have better means to track recipients.  But I agree 
> > that
> > to generate, publish, retrieve and report million DKIM selectors would be
> > somewhat impractical.  Putting a limit on aggregate report size (even if not
> > requested by the report consumer) can prevent excessive disaggregation.
> >
> >
> > > It is also not enough to null the DKIM selector; the null aggregate still 
> > > needs
> > > to meet the N recipient requirement.  If not, then additional selectors 
> > > need
> > to
> > > be nulled or the nulled-selector messages need to be completely excluded
> > from
> > > the report.
> >
> >
> > Most reports I send have 1, given my volumes.  Yet, by
> > aggregating many of them one could reach significant sums.
> >
> >
> > > If the To domain is included in the report, the aggregation rules should 
> > > still
> > > apply.  If they cannot be met, then the To domain must be nulled out or
> > the
> > > report not sent.
> >
> >
> > This is a recipient's choice.  If I wanted to stay anonymous, I'd use a 
> > domain
> > like gmail.com rather than tana.it.
> >
> >
> > > I favor making To domain an option which the owner domain requests and
> > the
> > > sending domain chooses to follow or ignore.  This provides upward
> > > compatibility.  The request for this data element keeps coming up.  The
> > > protocol can allow flexibility so that the participants make the final 
> > > decision.
> >
> >
> > It is already optional in the I-D.  (Not that I find it useful.)
> >
> >
> > > I asked previously whether report senders do any filtering based on
> > domain
> > > reputation, and the answer was "probably not".  I think the specification
> > > should encourage recipients to omit reporting to sources with negative
> > 

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Dotzero]

On Thu, May 6, 2021 at 12:27 AM Seth Blank  wrote:

> WG colleagues,
>
> We committed to holding an interim meeting after the DMARCbis documents
> were delivered, and cancelled our IETF 110 meeting to make space for the
> design team to work.
>
> We now have new documents from the design team, and it's time to schedule
> the Interim.
> - https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> - https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
>
> Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 4-6pm
> GMT.
>
> We believe this provides sufficient time for the group to digest the
> newly proposed text and have a productive discussion.
>
> The Chairs ask group participants to explicitly speak up if:
> 1) they intend to participate in the interim
> or 2) they wish to participate in the interim, but the timing does not work
>
> 1) I intend to participate.
>

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Todd Herr]

On Thu, May 6, 2021 at 8:21 AM Brotman, Alex  wrote:

>
>1. Just blocked off the time on my calendar to attend
>
> Same.

-- 

*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] Ticket #113 - DMARCbis -01 Introduction Section

[Todd Herr]

On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely  wrote:

> Todd,
>
> does your message assume that the relevant tickets are all accepted as
> valid
> indications to alter the spec?  In particular, tickets #52 and #75 have
> never
> been discussed on list. I'd guess they'll have to be discussed in their
> own
> threads.
>

I don't know if each of those individual tickets has to be discussed in
their own threads or not, and I think it's more a decision for the chairs
to make than for the editors or the working group, but I could be very
wrong about that.

What I will say is this:

   - The design team went off and effectively created a new version of
   draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
   proposed text, nothing more, nothing less.
   - The design team's work was influenced by those tickets which
   currently show a status of 'infoneeded'.
   - Due to the nature of the text, both of the following are true:
  - Most, but perhaps not all, of the 'infoneeded' tickets had impacts
  on multiple sections of draft-ietf-dmarc-dmarcbis-01
  - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
  that were made in producing draft-ietf-dmarc-dmarcbis-01 were
influenced by
  multiple tickets

Back on April 23, when I posted here about setting expectations, I thought
at the time that adjudicating each of the infoneeded tickets might be the
way to go, but upon further reflection I'm not sure that's the case, since
it can be argued that those tickets were created against a work product
that no longer exists. It's also true that because those tickets affect the
wording in multiple sections of the document, adjudicating the -00 tickets
can theoretically result in a morass of edits made across multiple sections
of -01 and subsequent revisions, and everyone eventually losing the plot.

Chairs, your thoughts?


> Discussing the resulting text before those tickets entails, for example,
> noting
> the cumbersomeness of the locution "severity of concern" where something
> like
> "desired disposition" might seem more immediate.  In fact, ticket #85 was
> only
> discussed as a side effect of ticket #39, where the consensus, IIRC, was
> to
> keep the existing policy names while wavering about how to describe them.
>
> The term RFC5322.From is consistently used, notwithstanding ticket #96.
> For an
> alternative, let me attempt to define DMARC in terms of its acronym:
>
> The Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
> protocol recognizes the prevailing importance of the domain appearing
> in the
> From: header field of email messages.  That domain name will be called
> the
> Main Identifier in this document.  DMARC leverages the Sender Policy
> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
> protocols
> by focusing the authentication mechanisms they provide toward the Main
> Identifier.  The Domain Owners corresponding to the Main Identifier are
> endowed with the possibility to receive feedback reports about
> authentication results at receivers.  Finally, receivers are provided
> with
> the Domain Owners' desiderata about messages that fail authentication,
> which
> receivers may or may not decide to conform to.
>
>
As I stated above, I believe the better path for the working group is to
adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
labeled "Introduction", you have proposed alternate text for that section,
let's discuss that section on the list, come to a consensus, and do it all
under the auspices of ticket 113.

But that's just my opinion...

-- 

*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] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Brotman, Alex]

  1.  Just blocked off the time on my calendar to attend

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

From: dmarc  On Behalf Of Seth Blank
Sent: Thursday, May 6, 2021 12:27 AM
To: IETF DMARC WG 
Subject: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group 
feedback on timing and participation

WG colleagues,

We committed to holding an interim meeting after the DMARCbis documents were 
delivered, and cancelled our IETF 110 meeting to make space for the design team 
to work.

We now have new documents from the design team, and it's time to schedule the 
Interim.
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 4-6pm GMT.

We believe this provides sufficient time for the group to digest the newly 
proposed text and have a productive discussion.

The Chairs ask group participants to explicitly speak up if:
1) they intend to participate in the interim
or 2) they wish to participate in the interim, but the timing does not work

Thanks,

Seth and Barry, as Chairs

--
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] Ticket #113 - DMARCbis -01 Introduction Section

[Alessandro Vesely]

Todd,

does your message assume that the relevant tickets are all accepted as valid 
indications to alter the spec?  In particular, tickets #52 and #75 have never 
been discussed on list. I'd guess they'll have to be discussed in their own 
threads.


Discussing the resulting text before those tickets entails, for example, noting 
the cumbersomeness of the locution "severity of concern" where something like 
"desired disposition" might seem more immediate.  In fact, ticket #85 was only 
discussed as a side effect of ticket #39, where the consensus, IIRC, was to 
keep the existing policy names while wavering about how to describe them.


The term RFC5322.From is consistently used, notwithstanding ticket #96.  For an 
alternative, let me attempt to define DMARC in terms of its acronym:


   The Domain-based Message Authentication, Reporting, and Conformance (DMARC)
   protocol recognizes the prevailing importance of the domain appearing in the
   From: header field of email messages.  That domain name will be called the
   Main Identifier in this document.  DMARC leverages the Sender Policy
   Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols
   by focusing the authentication mechanisms they provide toward the Main
   Identifier.  The Domain Owners corresponding to the Main Identifier are
   endowed with the possibility to receive feedback reports about
   authentication results at receivers.  Finally, receivers are provided with
   the Domain Owners' desiderata about messages that fail authentication, which
   receivers may or may not decide to conform to.

jm2c
Ale
--



On Wed 05/May/2021 20:48:51 +0200 Todd Herr wrote:

Greetings.

This thread will be used to track discussion of the proposed text for the 
Introduction section of draft-ietf-dmarc-dmarcbis-01.


The proposed text was influenced not only by the original text from 
draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and 108. 
Rather than trying to track changes to the Introduction section through all six 
of those tickets, a new one (Ticket 113 
) has been opened.


The request from the design team/editors for this ticket is as follows:

If you object to some or all of the proposed text, please communicate the
part(s) to which you object, and propose replacement text for those part(s).

We would like to achieve rough consensus on this section of text by Friday, May 
21.

Current proposed text follows, and side-by-side diffs with version -00 can be 
found here 
 



begin current proposed text 
---

1. Introduction

The Sender Policy Framework ([RFC7208]) and DomainKeys Identified

Mail ([RFC6376]) protocols provide domain-level authentication which

is not directly associated with the RFC5322.From domain, and DMARC

builds on those protocols.Using DMARC, Domain Owners that originate

email can publish a DNS TXT record with their email authentication

policies, state their level of concern for mail that fails

authentication checks, and request reports about email use of the

domain name.Similarly, Public Suffix Operators (PSOs) may do the

same for PSO Controlled Domain Names and non-existent subdomains of

the PSO Controlled Domain Name.

As with SPF and DKIM, DMARC authentication checks result in verdicts

of "pass" or "fail".A DMARC pass verdict requires not only that SPF

or DKIM pass for the message in question, but also that the domain

validated by the SPF or DKIM check is aligned with the RFC5322.From

domain.In the DMARC protocol, two domains are said to be "in

alignment" if they have the same Organizational Domain.

A DMARC pass result indicates only that the RFC5322.From domain has

been authenticated in that message; there is no explicit or implied

value assertion attributed to a message that receives such a verdict.

A mail-receiving organization that performs a DMARC validation check

on inbound mail can choose to use the result and the published

severity of concern expressed by the Domain Owner or PSO for

authentication failures to inform its mail handling decision for that

message.


For a mail-receiving organization supporting DMARC, a message that

passes validation is part of a message stream that is reliably

associated with the Domain Owner and/or any, some, or all of the

Authenticated Identifiers.Therefore, reputation assessment of that

stream by the mail-receiving organization does not need to be

encumbered by accounting for unauthorized use of any domains.A

message that fails this validation cannot reliably be associated with

the Domain Owner's domain and its reputation.

DMARC, in the associated [DMARC-Aggregate-Reporting] and

[DMARC-Failure-Reporting] documents, also describes a reporting

framework in which mail-receiving domains can generate 

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Murray S. Kucherawy]

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

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

I'll be there.

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Steven M Jones]

On 5/5/21 21:26, Seth Blank wrote:
>
> The Chairs ask group participants to explicitly speak up if:
> 1) they intend to participate in the interim
> or 2) they wish to participate in the interim, but the timing does not
> work


1) Intend to participate


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