Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

Agree with Dave here. There's no actual usage issues that are being addressed that merit the split (and the work involved). If you want to receive reports, but not have receivers enforce a policy, set 'p=none' and a rua. If you want to set a policy but not receive reports, set 'p=' and an empty

Re: [dmarc-ietf] Proposing last call for draft-ietf-dmarc-eaiauth-00

+1 I think it should be submitted for last call. Best, Peter On Mon, Jan 21, 2019 at 9:39 AM Kurt Andersen (b) wrote: > Since we've had no controversy or concerns expressed regarding John's > document (draft-ietf-dmarc-eaiauth-00 > )

Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax

+1 I concur with Mike and Andrew. There's no no reason to ignore this element of the standard because there's no real barrier (other than lack of attention to the spec) preventing implementors from doing this correctly. And all we'd be doing is pushing the burden of handling ambiguity to the rece

Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work

+1 on adopting On Mon, Dec 10, 2018 at 7:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This

Re: [dmarc-ietf] inheritance and public suffix list

hority in the tree. But as I said, it's easy enough to state "DMARC doesn't handle that case" if it's not an effective abuse vector or a significant management problem. Best, Peter On Thu, Apr 5, 2018 at 8:19 AM, Kurt Andersen (b) wrote: > On Thu, Apr 5, 2018 at 7:

Re: [dmarc-ietf] inheritance and public suffix list

y, we could simply say that this is a case that DMARC itself doesn't handle, and that the registry owner may choose to modify their DNS responses to ensure they always return a DMARC record for any organizational domain on that TLD. Best, Peter On Thu, Apr 5, 2018 at 6:07 AM, Andrew Sullivan wr

Re: [dmarc-ietf] inheritance and public suffix list

Kurt, As you note, this issue has been discussed on-list (and off) a few times. And it definitely seems clear that some sort of modification to the lookup algorithm would be required to address the issue. As part of that discussion, there are a few scenarios that I think should be considered: 1.

Re: [dmarc-ietf] Fwd: DMARC report format syntax error in ARC draft-10 section 9.3

Thanks for capturing. I agree it makes sense to figure out ticket #16 ( https://trac.ietf.org/trac/dmarc/ticket/16#ticket) first. Best, Peter On Sun, Mar 18, 2018 at 11:00 AM, Kurt Andersen (b) wrote: > On Sun, Mar 18, 2018 at 6:54 PM, Peter M. Goldstein < > peter.m.goldst...@

[dmarc-ietf] Fwd: DMARC report format syntax error in ARC draft-10 section 9.3

Kurt, Re: -12, it doesn't appear to capture the feedback in the email Mark Eissler sent to the list on 2/27. There was also no on-list reply to his email that I saw, so I wanted to re-raise the issue. His email is included below. Mark's analysis appears to be on-point, and I think the XML fragm

Re: [dmarc-ietf] SHA1 and short keys, threat or menace

Great. If there's group consensus I can take updating the test suite as an action item. Any objections? Thanks. Best, Peter On Wed, Dec 13, 2017 at 11:55 AM, Kurt Andersen (b) wrote: > On Wed, Dec 13, 2017 at 7:40 PM, John R Levine wrote: > >> So my thought here is that now that DCRUP is d

Re: [dmarc-ietf] SHA1 and short keys, threat or menace

So my thought here is that now that DCRUP is due imminently, we should update the YANG test suite to reject SHA-1 hashes. Thoughts? Best, Peter On Wed, Dec 13, 2017 at 11:10 AM, John Levine wrote: > I am working on yet another ARC library and am wondering what to do > about SHA1 signatures an