Re: [dmarc-ietf] ARC protocol-15 posted

On 06/25/2018 05:27 AM, Kurt Andersen wrote: > I've now posted draft 15 of the ARC protocol. Section 4.1.3 ARC-Seal (AS) Second bullet point: "Section Section 5.1.1" - reads oddly in the text version. It's more clear in the html version, where the second "Section" is part of a link.

Re: [dmarc-ietf] ARC protocol-15 posted

On 06/25/2018 05:09 PM, Dave Crocker wrote: > On 6/25/2018 6:03 AM, Jeremy Harris wrote: >> On 06/25/2018 04:44 PM, Dave Crocker wrote: >>> If the creator of the information does not have a reliable way of >>> knowing what the receiver of it will do with

Re: [dmarc-ietf] ARC protocol-15 posted

On 06/27/2018 09:15 PM, Kurt Andersen (b) wrote: > We already tried to walk that line in the spec. In general, any tag that > does not have a defined interpretation (firstly in the ARC spec, then > falling back to the DKIM spec) gets ignored with certain exceptions, such > as the "h" tag in an AS

Re: [dmarc-ietf] ARC protocol-15 posted

On 06/25/2018 04:18 PM, Kurt Andersen (b) wrote: > Correct - this was a clarification that has been added. If people find it > objectionable we can take it back out. What would your parser do if it > found an "h" tag in the header? Just ignore it or override the implicit "h" > that is defined for

Re: [dmarc-ietf] ARC protocol-15 posted

On 06/25/2018 04:44 PM, Dave Crocker wrote: > On 6/25/2018 5:38 AM, Kurt Andersen (b) wrote: >> That's the right approach, but the ambiguity of what a validator might >> do is why we thought it best to be explicit. > > > Yup. > > Anything that comes close to 'do whatever you want with this >

Re: [dmarc-ietf] ARC protocol-15 posted

On 06/25/2018 04:10 PM, Kurt Andersen (b) wrote: >>+ this (new?) requirement to check on h-tags for >> AS mean that a common parse routine for the three >> header types cannot be used. Did I miss the discussion >> introducing the requirement? >> > > The 'h' tag was never

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

On 22/01/18 22:47, internet-dra...@ietf.org wrote: > Title : Authenticated Received Chain (ARC) Protocol - Section 6 gives verifier actions for evaluating the chain state, but they do not cover the need for the arc.oldest-pass value required by 5.2.1. - 5.2.1 mentions a

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

On 22/01/18 22:47, internet-dra...@ietf.org wrote: > Filename: draft-ietf-dmarc-arc-protocol-11.txt [...] > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 Section 5.3 defines the AMS as being identical, with exceptions, to a DKIM signature header. This might be taken

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt

On 24/04/18 22:45, Kurt Andersen (b) wrote: > On Tue, Apr 24, 2018 at 1:10 PM, Jeremy Harris <j...@wizmail.org> wrote: > >> On 24/04/18 04:02, internet-dra...@ietf.org wrote: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 >> >> Sec

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt

On 24/04/18 04:02, internet-dra...@ietf.org wrote: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14 Section 3.3: For AMS generation, what is the intention regarding oversigning? Section 11: Additional implementation: Organization: Exim developers Status of

Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

On 21/03/18 15:18, Murray S. Kucherawy wrote: > On Wed, Mar 21, 2018 at 3:00 PM, wrote: > >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt >> has been successfully submitted by Kurt Andersen and posted to the >> IETF repository. I see that Google are still

Re: [dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted

On 23/10/2018 07:09, Steven M Jones wrote: > Consider this a reminder that your questions and suggestions are welcome. > > New version: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-06 How about another subsection 5.x saying when Originating ADMDs should take any ARC action? For

Re: [dmarc-ietf] Rethinking DMARC for PSDs

On 08/04/2019 12:02, Douglas E. Foster wrote: > I had only these rudimentary requirements: > [...] A secure-email method for outbound messages with sensitive > content Rudimentary? How secure; what's your threat model? Those two things often don't go together. (I should declare an

Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

On 02/08/2019 20:58, Murray S. Kucherawy wrote: > For guidance here, I would rely on anecdotes of implementation. Has anyone > implemented something that attaches "iprev" results? Exim does. -- Cheers, Jeremy ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

On 11/11/2019 06:30, Murray S. Kucherawy wrote: >> Authentication-Results: example.com; >> dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv >> > > Are there any MTAs that would take a different action based on this > information? For Exim it would be a fairly simple bit of

Re: [dmarc-ietf] non-mailing list use case for differing header domains

On 29/07/2020 18:34, Hector Santos wrote: > Look at my DMARC record for my isdg.net domain: > > v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; > ruf=mailto:dmarc-...@isdg.net; > > The atps=y [...] > So anyone out there can see that I authorized bayviewphysicians.com to > sign for

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 05/07/2020 23:39, Murray S. Kucherawy wrote: > Any opinion on the whole thing generally? Certainly worthy of discussion. I wonder if it needs tying to ARC rather than, or in addition to DKIM? -- Cheers, Jeremy ___ dmarc mailing list

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt

On 05/07/2020 22:56, Murray S. Kucherawy wrote: > https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Substansive: section 6, on footers: - Is not a common boundary marker a signature-marker, namely two dashes, space, end-of-line? The exim-users list, for example, uses that. Nit:

Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field

On 15/07/2020 10:25, Benny Lyne Amorsen wrote: > At the other end of the spectrum, domains which never ever > participate in mailing lists or mail forwarding need some kind of > "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the > policy. The domain owner doesn't know. It's

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

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] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On 18/12/2021 03:47, Douglas Foster wrote: MX checks are a valid tool for assessing SMTP MailFrom addresses, since the sender is supposed to be ready to accept non-delivery reports and other automated messages. Of course, this has applicability if (but only if) the RFC5322.From domain is the