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.
>
> I would like to schedule
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 update
> is welcome. Also
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 with both the AMS and th
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 and
> https://tools.i
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:
>>
>>> The current spec defines an arc authres method (
>>> h
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 times.
> Also, the inf
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 you to 20
Received
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 and
generating ARC-Authe
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
tha
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 relevant AR header fie
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
>> next handler might no
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
dmarc@ietf.org
https://w
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 have a
> DMARC
> > repor
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* proceed with writing this?
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 original email direct
On Wed, May 31, 2017 at 10:30 PM, Seth Blank wrote:
>
> So I guess returning to the original thread, there are two matters:
>
> 1) Should we stamp header.b in the A-R? (consensus seems to be yes)
>
It's defined, may as well use it.
> 2) How should we transmit the source_ip for the DMARC report
On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) wrote:
> On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy
> wrote:
>
>> Another way to look at it: A-R is meant to be a channel to record what
>> authentication was done and what thing in the visible message got
>
On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote:
> On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy
> wrote:
>
>> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b)
>> wrote:
>>
>>> There's another question that had been raised by Seth abou
On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman wrote:
> I don't have particularly strong opinions here. I can see no reason for
> the d= to differ, but also no harm in allowing it do so. So I think the
> question of what to do here is slightly more philosophical. I think I
> generally fall on the
On Sat, Jun 3, 2017 at 3:32 AM, Ken O'Driscoll
wrote:
> Not to mention, the irony of the official DMARC mailing list discouraging
> postings from DMARC protected domains due to compatibility issues!
>
Not long ago there was some advice circulated that DMARC is really only for
protecting domains
On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote:
> On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b)
> wrote:
>
>> On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman
>> wrote:
>>
>>>
>>> It seems we have two choices available to us upon receipt of an invalid
>>> chain(which is defined as AS b= u
On Wed, Jun 21, 2017 at 6:19 PM, Seth Blank wrote:
> On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote:
>>
>> If you put arc=fail in an AR and then the next hop ignores and strips the
>>> AR (per spec), what good is it?
>>>
>>
>> None, but what good is the broken chain? If all you're doing is
On Fri, Jun 30, 2017 at 2:45 PM, Brandon Long wrote:
> Someone's using a keysize of 4098... that's odd.
>
That Dave Crocker did not take this opportunity to say "No it's not, it's
even" must mean he's traveling.
-MSK
___
dmarc mailing list
dmarc@ietf.
On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote:
> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy > wrote:
>
>> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein
>> wrote:
>>
>>> So as a consumer of these reports I'd definitely like t
On Wed, Jul 5, 2017 at 4:36 PM, Seth Blank wrote:
> The *only* intent here is to report back services that break
> authentication to the domain owner in a DMARC report. As such, the selector
> disambiguates services (especially when there are multiple hops, some of
> which might have the same d=)
On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank wrote:
> This thread is only about encapsulating information useful for a consumer
> of DMARC reports, as that consumer will not have the message and its
> headers. Selectors are critical here for tying things together.
>
> The DMARC report data is gene
On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman
wrote:
> In this context, having the selector in DMARC feedback reporting to help
> define a 'source' is really useful.
>
The DMARC report also includes other things that might be able to help you
identify the bad source, like the IP address. But
On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan
wrote:
> I always feel like experimental status ought to come with some
> description of what success or failure would mean and how that would
> be determined. I think that is aligned with (but not entailed by)
> https://www.ietf.org/iesg/informat
On Fri, Jul 7, 2017 at 12:50 PM, Steven M Jones wrote:
> I may be misreading your response, but I wasn't suggesting a timeline
> without criteria. I would hope to see criteria and a provisional
> timeline for when to apply them. "A, B, and C will be tracked and
> evaluated at IETF 101, next move
On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker wrote:
> I've come to believe that it makes more sense, at this stage, to seek a
> status of Experimental. That's not meant as a criticism of the work, but
> rather to accurately reflect the current understanding of ARC dynamics.
>
> Having intermedi
On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote:
> Or maybe, put a different way, the question is: what's the simplest way,
> with the least delta to the spec, that allows for transmission of selectors
> and source ip? This would enable DMARC reports for messages delivered due
> to ARC to have
On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker wrote:
> 2. The mechanics of cascading signatures that ARC does /is/ unusual
> and possibly unique. I believe the only operationally established exemplar
> in this space is the X.509 cert signature hierarchy. However it is an
> relatively static,
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote:
> On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy
> wrote:
>
>> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote:
>>
>>> Or maybe, put a different way, the question is: what's the simplest way,
>>
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote:
> I think it needs to be specified. Receivers construct DMARC reports in a
> known manner, they shouldn't need to guess how to get the appropriate
> information out of ARC headers in an intermediary-implementation-specific
> manner. The spec shoul
On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) wrote:
> Regarding timelines, I think that we can have wishes and hopes, but, since
> we will now be holding our seventh(!) interop event during the IETF99
> hackathon, I don't expect that "months" is even the right scale upon which
> to base our
On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) wrote:
>
> 1) Include the additional information in the AAR which is wanted
> downstream for a DMARC report to be emitted from a receiver N hops away -
> this requires additional fields to the basic RFC7601 A-R spec
>
This seems to be the least
Why is OpenARC's status an IETF agenda item?
On Sat, Jul 15, 2017 at 12:46 AM, Kurt Andersen wrote:
> If there are any missing items, please let us know as early as you can.
> Here's the proposed agenda: https://datatracker.
> ietf.org/meeting/99/agenda/dmarc/
>
> --Kurt
>
>
On Sat, Jul 15, 2017 at 2:43 AM, Kurt Andersen wrote:
> On Sat, Jul 15, 2017 at 11:28 AM, Juri Haberland
> wrote:
>
>> On 15.07.2017 10:33, Kurt Andersen wrote:
>>
>> > But if the parsing fails, then it was hanging and causing message
>> deferral,
>> > even if the AuthServID would have disqualif
Status reports are great list material. I don't think it's useful for mic
time. Unless something specific about OpenARC is germane to the draft(s),
I feel we have plenty of other stuff to discuss during face time.
On Sun, Jul 16, 2017 at 9:51 AM, Barry Leiba
wrote:
> > Why is OpenARC's status
On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen wrote:
>
> I don't understand. Mediators ARC sign, the header is everything you need
>> for this identification, is it not?
>>
>
> Let's take ietf.org as an example. There are @ietf.org individuals and
> then there are all the mailing lists. If IETF
On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote:
> There has been an on-list discussion about this, but in it no consensus
> was reached: https://mailarchive.ietf.org/arch/msg/dmarc/
> KvpNpf_9ywZpK6oMcwJ1OJthiHM
>
> Off list the consensus from those I've spoken with (which is obviously not
> n
On Tue, Jul 25, 2017 at 10:00 AM, Alexey Melnikov
wrote:
> I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so
> some of the issues identified below might no longer be relevant:
>
> 1) The new abstract doesn't even use the word "email". This needs to be
> fixed, because otherwise
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
wrote:
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender. Otherwise that site will bounce the email.
>
>
Goodness, it's a wonder that we've
On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
wrote:
> On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
>
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> wrote:
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can&#
On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank wrote:
> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
> wrote:
>>
>> I laugh as well, but it's more than p=reject isn't enough in the ARC
>> world, because it doesn't distinguish between:
>> a) I'm OK with email from my domain being sent via mailing
On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker wrote:
> On 8/18/2017 10:00 AM, Seth Blank wrote:
>
>>
>> Right now, we've got deployed code that we know works and improves the
>> landscape. Everything else is - rightly or wrongly - conjecture.
>>
>
>
> Personal Point of order:
>
>Using an 'in
On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote:
> We went down the path of including a diff of the message in the headers,
> but you run up against more complicated changes that make that
> challenging. Ie, mailing lists which strip attachments. If all we cared
> about were subject munging
On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana
wrote:
> On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
>
> On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote:
>
> We went down the path of including a diff of the message in the headers,
> but you run up agains
On Thu, Sep 7, 2017 at 10:11 AM, Seth Blank wrote:
> I'll go over this in more detail and post substantive comments sometime in
> the next day or so, but at first glance, a crucial change in 5.1 was missed
> and the draft language still makes a normative change to 7601 ("data SHOULD
> be added to
At the risk of bringing up the whole "cv=invalid" debate again...
When a chain is invalid (say, an AMS is missing), Section 9.3 says to add a
seal that only covers itself but uses N+1 for its "i=" value. Could
someone propose some informational text for the draft that explains why
that decision w
On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba
wrote:
> We also need to understand whether there's really anything we intend
> to do with DMARC. Do we *know* what we might do? Do we have any plan
> for a way forward? Are we hoping that ARC will fix enough of it that
> we can make the combination
On Wed, Nov 29, 2017 at 9:17 AM, Kurt Andersen (b) wrote:
> While I have a number of issues with the details of the proposal, I'll
> tackle those in another thread. The fundamental problem that I have with
> the whole "experiment" approach is that it is something like throwing a
> baseball into a
Omitting stylistic nits for now:
On Wed, Nov 22, 2017 at 9:34 PM, Seth Blank wrote:
> 16 Experimental Considerations
>
> [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be
> removed by the document editor, or should it stay with the document as long
> as it’s experimental?
On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank wrote:
> Replace 5.1.1 with:
>
> 5.1.1. ptypes and properties for arc-info
>
> Certain information pertinent to ascertaining message disposition can be
> lost in transit when messages are handled by intermediaries. For example,
> failing DKIM signatures
On Fri, Dec 1, 2017 at 10:09 AM, Kurt Andersen (b) wrote:
>
> Where would you like to gather such a consensus? Is this DMARC-WG
> sufficient or would you want input from a wider community?
>
Here's fine. Or the ART list, or ietf-822. Or really, anywhere the IETF
considers "on-the-record" in te
On Fri, Dec 1, 2017 at 11:52 AM, Dave Crocker wrote:
> The more-difficult question is what the basis of analysis should be? An
> inherent problem with "in this working group" or the like is just how small
> a sampling of the email industry it is. It makes it too easy for the
> relatively few pa
On Fri, Dec 1, 2017 at 3:23 PM, Scott Kitterman
wrote:
>
> Isn't Dispatch ( https://datatracker.ietf.org/wg/dispatch/about/ ) the
> proper
> venue to discuss this (as the successor to appswg)?
>
No; "art" is the right list for general ART area topics. DISPATCH is the
right place to discuss work
There's now an open source implementation of ARC available for download if
anyone wants to try practice rather than theory, and you can be an integral
part of the experiment. Here's the release announcement.
--
The Trusted Domain Project is pleased to announce the availability of the
first alpha
On Tue, Dec 19, 2017 at 6:49 AM, Kurt Andersen (b) wrote:
> * Update the AAR definition section (formerly 5.1) using Seth's suggested
> 7601bis wording (also adjusting for feedback that came in on the list) and
> annotating the section to be adjusted if we can kick off the 7601bis work
> in a tim
On Wed, Dec 20, 2017 at 4:39 PM, Brandon Long wrote:
> I think algorithm rotation is more challenging for ARC than it is for
> DKIM, since with DKIM you can just sign with both... but for ARC, there's a
> chain of signers and the you have to handle links not being able to verify
> intermediate st
On Thu, Dec 21, 2017 at 3:18 PM, Seth Blank wrote:
> That is also what I remember, and why I proposed the Experimental
> Considerstions as part of the primary draft and not the usage guide.
>
> Kurt had some strong opinions on why they belonged in the usage guide,
> which I suggest we revisit in
On Fri, Dec 22, 2017 at 9:37 AM, John Levine wrote:
> In article x0hj...@mail.gmail.com> you write:
> >"Experimental" is perfectly fine. As I understand it, EAI did that first
> >and went to the standards track after it had some field use.
>
> That is true, but it's also true that the standards
On Thu, Dec 28, 2017 at 4:15 PM, Seth Blank wrote:
> 1) Unless a chair speaks up that consensus is already Experimental, we
> should have the conversation now and nail this down.
>
> 2) Unless there is opposition, I'd like to move the Experimental
> Considerations out of the usage guide into the
Chairs, should we start using the WG's issue tracker for this stuff?
On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank wrote:
> Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/
> arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the
> protocol elements section of the
On Thu, Dec 28, 2017 at 5:21 PM, Seth Blank wrote:
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-13
>
> Beyond my notes below, the Security Considerations section feels weak, and
> like it should at least inherit DKIM's security considerations.
> Additionally, there have
The second bullet on 14.4 can go. The third one can go once a new version
of OpenDMARC is out, which can happen in early January.
On Thu, Dec 28, 2017 at 5:23 PM, Seth Blank wrote:
> The Implementation Status section of the draft (
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#
On Thu, Dec 28, 2017 at 7:57 PM, John Levine wrote:
> In article gmail.com> you write:
> >https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10)
> >feels clunky and itself says it needs more work.
>
> To put it mildly.
>
> >Assuming we're proceeding as an Experiment, I propose
On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) wrote:
> While John Levine cited the benefits of the "experimental" approach taken
> for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/
> gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play
> nice" mess that came from des
On Wed, Jan 3, 2018 at 5:50 PM, Kurt Andersen (b) wrote:
> While I wait for Bron's confirmation that my understanding matches his
> (see email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank <
> s...@sethblank.com> wrote:
>
>>
>> . . .text for . . . arc.closest-fail . . .
>>
>
> I'm u
On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) wrote:
> On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana
> wrote:
>
>> I assume this was the one that you wanted my clarification on?
>>
>
> Yes, thanks
>
>
>> But let's rewrite it as oldest-pass, because that's clearer. Your case:
>>
>> * ARC 1:
on Notification for
draft-kucherawy-dmarc-rfc7601bis-00.txt
To: "Murray S. Kucherawy"
A new version of I-D, draft-kucherawy-dmarc-rfc7601bis-00.txt
has been successfully submitted by Murray Kucherawy and posted to the
IETF repository.
Name: draft-kucherawy-dmarc-rfc7601bis
On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen wrote:
> That is our plan. The change to 7601 is to segment the ABNF for clearer
> extension by ARC. Wait and see what Murray puts in and then we can discuss.
>
> On Jan 20, 2018 09:18, "Hector Santos" wrote:
>
>> IMEV, 7601 should be extendable wit
On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) wrote:
> On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba
> wrote:
>
>> > I'd like to request a F2F meeting in London at IETF101. I plan to
>> create a
>> > WGLC-eligible draft as soon as the 7601bis-01 work lands in a form that
>> can
>> > be refere
Message Header Field for Indicating Message
> Authentication Status
> Author : Murray S. Kucherawy
> Filename: draft-ietf-dmarc-rfc7601bis-00.txt
> Pages : 48
> Date: 2018-02-07
>
> Abstract:
>This
On Sat, Feb 10, 2018 at 10:40 AM, John R. Levine wrote:
> Here's some stuff from my EAI authentication draft which it would be nice
> if you could fold in.
> [...]
Is this stuff in scope for this working group? This feels a bit like
feature creep.
Or should your draft just modify this one ins
On Sat, Feb 17, 2018 at 3:49 AM, John Levine wrote:
> Seems fine, although I've long found 7601 one of the most mysterious RFCs
> ever published.
>
Why's that? (And why wasn't this mentioned when 7601 or any of its
antecedents was in last call? No errata?)
> The IANA registry says that there
On Mon, Feb 19, 2018 at 2:28 PM, Scott Kitterman
wrote:
> > 7601bis loosens the language about what's appropriate to send downstream,
> > from being only authenticated identifiers to also allowing other related
> > stuff that downstream agents might want to use or log. That means things
> > like
On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely wrote:
> Would it be possible to insert a dnswl method in the new spec?
> [...]
>
I'd prefer to do this as its own document. The current one is feeling very
"kitchen sink" already, and this change has more meat to it than the others
that have
On Mon, Mar 19, 2018 at 5:29 PM, Alessandro Vesely wrote:
> On Sun 18/Mar/2018 13:43:56 +0100 Murray S. Kucherawy wrote:
> > On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely > <mailto:ves...@tana.it>> wrote:
> >
> > Would it be possible to inse
ssage Header Field for Indicating Message
> Authentication Status
> Author : Murray S. Kucherawy
> Filename: draft-ietf-dmarc-rfc7601bis-01.txt
> Pages : 48
> Date: 2018-03-20
>
> Abstract:
>This do
On Tue, Mar 20, 2018 at 10:50 PM, Scott Kitterman
wrote:
> In the diff I sent in, I also proposed header.s (selector). I think that's
> important for troubleshooting. Is there a reason you left it out? I can
> do
> another draft for it, if you want, but it seems like a lot of process
> overhea
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.
>
> Name: draft-ietf-dmarc-arc-protocol
> Revision: 13
> Title: Authenticated Recei
On Wed, Mar 21, 2018 at 2:20 PM, Kurt Andersen (b) wrote:
> In the diff I sent in, I also proposed header.s (selector). I think that's
>
>> important for troubleshooting. Is there a reason you left it out? I can
>>> do
>>> another draft for it, if you want, but it seems like a lot of process
>
On Fri, Mar 23, 2018 at 12:40 PM, Alexey Melnikov wrote:
> On 23 Mar 2018, at 12:27, John R. Levine wrote:
> >> I have now posted
> >> https://tools.ietf.org/html/draft-andersen-historic-4406-etal-00 for
> this
> >> task.
> >>
> >> Please let me know if that fits the bill.
> >
> > Looks good to
On Fri, Mar 23, 2018 at 2:05 PM, Ned Freed wrote:
> WFM.
+1
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Mon, Jun 25, 2018 at 9:03 AM, Jeremy Harris wrote:
> "any tag not specified here, in any of the three ARC headers,
> MUST be ignored".
In my view this is the right approach, but keep in mind that what's valid
in an AMS header field value is largely defined by what's valid in DKIM,
and wh
On Wed, Jun 27, 2018 at 1:20 PM, Jeremy Harris wrote:
> 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 i
On Sun, Jun 24, 2018 at 9:27 PM, Kurt Andersen wrote:
> I've now posted draft 15 of the ARC protocol. It should be ready for last
> call - please review with that in mind. Note that the XML was a little
> wacky in the Implementation Status section. I'll fix that formatting in the
> next rev.
>
I
On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton wrote:
> On 7/9/18 7:28 PM, Kurt Andersen (b) wrote:
>
> On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton
> wrote:
>
>> Substantive issues:
>>
>> General: I see lots of references to "authentication state", beginning
>> with two references in the abstract,
On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton wrote:
> On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:
>
>
> AMS is basically the same as DKIM-Signature, and so it covers body
> modifications. When you verify the seal, you must also verify the latest
> AMS, which in turn
On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee <
martijn=40dmarcanalyzer@dmarc.ietf.org> wrote:
> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states
> to include the ARC Set currently being added.
> However, the signature cannot include the current ARC-Seal header
or can we WGLC it?
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton wrote:
> On 7/11/18 6:23 PM, Kurt Andersen (b) wrote:
>
> On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton
> wrote:
>
>>
>> So essentially we're creating a bunch of header bloat (creating duplicate
>> header fields with different names where that could be a
On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton wrote:
>
> I suggest that as part of WG Last Call that the DNS Directorate be
> consulted, largely to socialize this with them so they aren't surprised by
> the request load requirements.
>
Should the draft say more than what Section 9.2 already says?
On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank wrote:
> I've reviewed. All the technical matters look good, and earlier comments
> have all been addressed. I have two final comments:
>
> 1) Section 6.4 mentions changes to section 2.3 which include slightly
> different language than in 7601. I see no
On Mon, Jul 16, 2018 at 4:02 PM, Barry Leiba
wrote:
> We have a good set of comments on -15, and thanks, everyone, for that.
> Kurt and Seth, please make the changes that make sense based on the
> discussion, and publish -16 when you've done that. When I see -16 go
> up, I'll put it into working
On Tue, Jul 17, 2018 at 10:49 AM, John Levine wrote:
> Try this:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-
> rfc7601bis-02&url1=rfc7601
>
> Looks OK to me. I have some minor editorial niggles about the wording
> of the EAI advice, but the substance is fine.
>
>
[re-adding dmarc@ie
On Wed, Jul 18, 2018 at 1:37 PM, Seth Blank wrote:
>
>
>> My review of -14 noted problems with the abstract. While there have been
>> some changes, the Abstract remains too... abstract. While the current text
>> is better it really does not provide simple, direct statements about the
>> problem
On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana
wrote:
> This isn't a detailed review, because I haven't had time to do it, but
> I've been following the process and I'm happy that ARC-16 is ready as an
> experimental standard.
>
What's an "experimental standard"?
-MSK
__
Applied for RFC7601bis. I'll post a new version when WGLC ends.
On Sun, Jul 22, 2018 at 7:07 PM, John R Levine wrote:
> An erratum on RFC7601 just appeared that reports a bug in the ABNF for the
> resinfo rule. I think the purported bug is not a bug but his suggested
> rewrite to the ABNF is c
701 - 800 of 1014 matches
Mail list logo
