* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dmarc Status Pages

Domain-based Message Authentication, Reporting & Conformance (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2014-Aug-11 —  
Chairs
 
 
 


IETF-99 dmarc minutes

Session 2017-07-20 0930-1200: Berlin/Brussels - Audio stream - dmarc chatroom

Minutes

minutes-99-dmarc-02 minute



          DMARC notes from IETF 99
          
            1. Introduction & administrative
          
          Barry: New mailing list policy: if you post from a p=reject address
          and it causes unsubscribes, you will be asked to post from a different
          address.  If you don't, your address will be blocked from posting.
          
            2. Report from Hackathon project
          
          Kurt: Did testing, builds, new forwarder, fastmail perl milter
          advanced.  Several other implementations in progress.  Will have
          updates at M3AAWG in October (Toronto).
          
          Barry: Plan another hackathon weekend before IETF 100 in Singapore.
          
            3. Report about handling IETF Mailman
          
          Kurt: Planning to integrate ARC into IETF's Mailman 2, looking for
          stability
          for what's on the wire, packaging in progress.  Aiming for early
          September.
          
          Alexey: Also planning workaround that rewrites  addresses, start
          experimenting in September.  Different  rewriting than existing
          patches.
          
          Barry: Need to experiment turning mitigations on and off to see how
          recipient
          systems react to the ARC signing.
          
            4. Open issues in the ARC specs
               - Include discussion of document status (Standards Track vs
               Experimental)
          
          Kurt: Settled issues:
            -  AAR need not be signed
            -  combine cv=invalid/fail into fail
            -  add policy failures into A-R
            -  combine multiple A-R into a single AAR
          
          Bron: What do you report from temporary vs. permanent DNS failures?
          Kurt: likely defer with 421 code, or eventually reject like any other
          long temp failure.
          
          Kurt: Language updates for a revised draft in progress.  Working on
          language to handle
          multiple signing algorithms.  Language for trust within a trust boundary.
          
          Whether to signal whether a system participates?  Probably not, can't
          trust
          self-assertions.
          
          Questions about AAR content and format.
          
          Barry: When ready for WGLC?
          Kurt: New draft tomorrow, hope to be ready for LC in a week.
          
            4a. Document status discussion
          
          Dave Crocker: Suggest experimental for now because the operational issues
          associated
          with the chain of signing aren't known.  Revisit when ready for a BCP.
          Kurt: Have enough implementations to make a proposed standard.
          Murray: If it's WGLC in a week, I'd prefer experimental.  If we take
          more time, then
          proposed standard.
          Andreas Schultze: Not being Standards Track made some not want to
          implement DMARC.
          Maarten Aertsen: Will small operators implement ARC at all?
          Kurt: There is some interest.
          Seth Blank: We did ARC training at M3AAWG; major receivers put together a
          bootstrap whitelist of 2000 intermediaries for small receivers, will
          publish it.
          It really is an experiment.
          Barry: What will give best implementation experience: stable draft
          vs. experimental RFC?
          Chris Newman: Protocol draft seems fine.  Reputation is uncertain,
          but reputation is not
          in the protocol spec.  Operational questions aren't in the protocol spec.
          Protocol is
          ready for Proposed Standard.
          Dave: Yes, the spec is *probably* fine, but might not be since it's a
          new trust model
          and we don't know what the operational dynamics are.  As we get experience
          we may find
          that we need to change stuff.
          Barry: Does realtime make this different from certs?
          Dave: certs are typically signed statically.
          Eric Rescorla: How is sequential signing different?
          Rich Salz: How can the signatures get out of order?
          Barry: The point is that it's a dependent chain, with each sig dependent
          upon the earlier.
          Bron: What happens if there's a DNS failure in the middle of the chain?
          Kurt: Typically back to whoever it came from.
          Bron: Config failures cause failures in the wrong place, such as
          unsubscribing someone.
          Dave: DKIM as model works in some contexts but fragile within an
          enterprise,
          example of sequential fragility.
          Alexey: Pick one, no strong opinion.  Can ask ops and dns directorates
          if they see problems.
          Murray/Kurt: If it's experimental make it clear what the experiment is.
          Dave: When there's comfort to write operational advice document it's no
          longer
          an experiment.
          
          Decision: We will continue discussing on the list, and will not hold up
          WGLC for this issue.
          We need to have a working group decision by the time we request
          publication (after WGLC).
          
            5. Handling enhanced reporting
               - What should be reported in a DMARC report when ARC is involved?
          
          Kurt: A-R was for humans, AAR is for machines.  Selector and source IP
          useful
          for sender troubleshooting, so adding them to AAR is useful.  Inline JSON
          in
          a comment?  Does each step send reports?  Probably.
          Seth: Need to get what's transmitted and how into current spec, update
          to DMARC
          can wait.
          
            7. DMARC "usage" document -- status and what to do
          
          Tim: Summary posted.  Publish draft, gather experience, guide is useful
          to
          codify experience.  Small set of people to contribute to usage guide, but
          is there enough interest to do it now?  If not, could do it elsewhere
          later.
          Barry: The objection is that as there are already lots of DMARC usage
          guides,
          why do another one?
          Kurt: Are we looking for anecdotal reports?  Does that provide value?
          Jim Fenton: Do we need an ARC usage document instead?
          Barry: "Instead", or in addition, or combined...
          Alexey: Need not be RFC, could be a wiki or the like.
          Barry: Exactly.  Tim, are you willing to continue work on this with the
          understanding
          that the working group might later decide not to publish it?
          Tim: Yes.
          
          Decision: Tim will continue work on the DMARC usage document, and after
          we see where it
          goes, the working group will decide whether to publish it.
          
            8. AOB
          
          Kurt: A charter goal was to get DMARC to standards track.  When we finish
          ARC, what
          do we do next?
          Barry: I believe we need something in DMARC to address the breakage
          problem before going
          standards track.  Maybe not realistic but think about it as a challenge.
          Murray: We can start collecting issues in the tracker now, and don't
          have to wait.
          
          



Generated from PyHt script /wg/dmarc/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -