Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Wed, May 31, 2017 at 9:20 PM, Murray S. Kucherawy wrote: > What we're seeking to do here is add it to A-R as a way to get that > information through to a place where DMARC can get it to include in > reports. If we want to redefine what A-R is to meet that requirement,

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein wrote: > So as a consumer of these reports I'd definitely like to see a structured > value with as much information as possible. > > The ideal would be to get as much information as we'd get if the final > receiver had seen the

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

On Wed, May 31, 2017 at 5:47 AM, Barry Leiba wrote: > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. > > Does anyone think we *should*

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > 2) smtp.client-id > > > > The goal here is to track the originating source_ip for DMARC > > categorization and reporting. Otherwise, all ARC messages will

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) wrote: > There's another question that had been raised by Seth about whether d= > needs to match within an ARC set. The answer is yes, [...] > Why? -MSK ___ dmarc mailing list

Re: [dmarc-ietf] cv=invalid

On Wed, May 31, 2017 at 6:40 PM, Kurt Andersen (b) wrote: > If a verifier decides an ARC is invalid, it's supposed to set >> "cv=invalid", when generating its own ARC-Seal. This seems odd; we're >> cryptographically signing a chain that is known to be broken, meaning the >>

Re: [dmarc-ietf] cv=invalid

On Thu, Jun 1, 2017 at 5:32 AM, Murray S. Kucherawy wrote: > > If a verifier decides an ARC is invalid, it's supposed to set > "cv=invalid", when generating its own ARC-Seal. This seems odd; we're > cryptographically signing a chain that is known to be broken, meaning the >

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Tue, May 30, 2017 at 10:33 AM, Scott Kitterman wrote: > > At some point in the process, an AAR and ARC signature get created. Later, > someone else has to validate them. > > My point was that when you are on the signing end of this, you have to > grovel > through all the

Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature

SHOULD be the same? I can't think of a good thing to say here, or a solid justification for any choice. I can't imagine why they would ever differ, but I can't come up with a solid technical reason to demand it either. As a verifier I might be skeptical if they're wildly different names, but

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Wed, May 31, 2017 at 3:25 PM, A. Schulze wrote: > > I can give an update on the list. > please :-) OpenARC is effectively in an Alpha state, implementing the -03 draft. The code is available via github. It is correctly validating and generating seals and signatures

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > I've taken a look at the proposed draft and have a few notes as well. > > 4. The currently specified limits on i= are not included MUST >10, SHOULD > > 50, etc > 50 seems oddly high. I think sendmail out-of-the-box limits

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > In 5.1 defining the AMS, you say that it should cover DKIM-Signature and > AuthRes headers. In particular, AuthRes headers are expected to be removed > by ADMDs, especially if the message transits the same ADMD multiple

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

Am 01.06.2017 um 00:11 schrieb Murray S. Kucherawy: > I can give an update on the list. please :-) > Status reports aren't a good reason to hold a F2F meeting; meeting time is > for discussion. yes, there whare long disscussion thread on this list, that make it (to me) hard to follow. But I

Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC)

On Tue, May 30, 2017 at 10:50 PM, Kurt Andersen (b) wrote: > (Reposting with adjusted subject) > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) > wrote: > >> Barry et al, >> >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: >>

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

On Wed, May 24, 2017 at 3:55 PM, Seth Blank wrote: > Looping back about this. > > Currently openarc only supports relaxed canonicalization for the ARC > Message Signature. > > On closer inspection, https://tools.ietf.org/html/dr > aft-ietf-dmarc-arc-protocol-03#section-5.1.2

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 3:08 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > > wrote: >> >>> What benefit is there to covering AAR

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

I'll also be in Prague, but will unfortunately not be able to make the hackathon. I think there are four items for the WG to discuss that most likely will not be resolved by mid July: - The ARC specs (the current spec and the proposed spec, and how to merge if this is what the group wants) - The

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Tue, May 30, 2017 at 7:57 AM, A. Schulze wrote: > Am 29.05.2017 um 18:49 schrieb Barry Leiba: > > We've had one request for a DMARC session in Prague, with no further > > response from the working group. > > I didn't follow all ARC discussion over the last months. An

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Mon, May 29, 2017 at 9:49 AM, Barry Leiba wrote: > We've had one request for a DMARC session in Prague, with no further > response from the working group. > > We've had one suggestion for an interop test in Prague, with no > further response from the working group. >

Re: [dmarc-ietf] cv=invalid

On 5/31/2017 2:32 PM, Murray S. Kucherawy wrote: If a verifier decides an ARC is invalid, it's supposed to set "cv=invalid", when generating its own ARC-Seal. This seems odd; we're cryptographically signing a chain that is known to be broken, meaning the next handler might not even be able to

[dmarc-ietf] cv=invalid

I think this was discussed before, but perhaps it didn't reach a logical conclusion: If a verifier decides an ARC is invalid, it's supposed to set "cv=invalid", when generating its own ARC-Seal. This seems odd; we're cryptographically signing a chain that is known to be broken, meaning the next

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy wrote: > > What's the added value in covering AAR[n] twice, once with its b= and once > without? > > Sorry, that got out before my thought was fully formed. What benefit is there to covering AAR with both the AMS and the

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

On Tue, May 30, 2017 at 6:38 PM, Kurt Andersen (b) wrote: > On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote: > >> This might be a non-issue, but we're asking this question specifically >> because we've run into an implementation issue within openarc that

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

> On May 31, 2017, at 8:47 AM, Barry Leiba wrote: > > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. > > Does anyone think we *should*

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

I agree with this. If there's stable documentation on DMARC usage that we can cite, there's little value in adding our own, which is likely to end up diverging from the others. Does anyone think we *should* proceed with writing this? Barry On Wed, May 31, 2017 at 9:32 PM, Kurt Andersen (b)

Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC)

How long do we think we need for this discussion? b On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) wrote: > (Reposting with adjusted subject) > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) wrote: >> >> Barry et al, >> >> On Wed, May 31, 2017 at

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

I have requested a 30-minute slot (in a U-shaped room arrangement). I can change this to 60 minutes if we decide by Friday that we'd like more time. I'd rather err on the side of keeping us tight and not booking people's time unnecessarily. Barry On Wed, May 31, 2017 at 2:49 PM, Kurt Andersen

[dmarc-ietf] dmarc - New Meeting Session Request for IETF 99

A new meeting session request has just been submitted by Barry Leiba, a Chair of the dmarc working group. - Working Group Name: Domain-based Message Authentication, Reporting Conformance Area Name: Applications and Real-Time Area

[dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

For the sake of discussion: I'd like to suggest that writing a DMARC usage guide under a BCP sort of moniker is not a useful activity for this WG. There are lots of white papers and other "how to use DMARC" guides available on the internet. What value would it add to have something preserved in

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

>>> Most of the effort has been focused on getting ARC deployed in to >>> production so there has been relatively little attention to the "what's >>> next" question. Peter had started a thread a few months ago but it did not >>> get much (or any) traction. How sacrosanct is the "deliverable" list

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

On Wed, May 31, 2017 at 5:26 PM, Alexey Melnikov wrote: > Hi Kurt, > > On 31 May 2017, at 06:49, Kurt Andersen (b) wrote: > > even if we need to discuss the next steps, we haven't done that on the >> list yet, so we >> don't know that we need face time

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

Hi Kurt, On 31 May 2017, at 06:49, Kurt Andersen (b) wrote: >> even if we need to discuss the next steps, we haven't done that on the list >> yet, so we >> don't know that we need face time for it. > > Most of the effort has been focused on getting ARC deployed in to