Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

[Murray S. Kucherawy]

On Thu, Oct 25, 2018 at 8:15 AM Kurt Andersen (b)  wrote:

>
> Both of these are indeed normative in usage, but I was under the
> impression that one could not refer to I-Ds as normative.
>

At least 7601bis will be an RFC at the same time as this one is, if not
sooner.  I don't know what the plans are for the other one.


>
>> 2) I am glad that broken examples from Appendix B were removed, but I
>> would like to have some examples in the document. Is somebody working on
>> generating these?
>>
>
> Yes, work is in progress. It is really hard to do "fake" signing of
> non-existent IP and domains with real production software. That has been
> the hangup.
>

You can do that with OpenARC, I believe.  You don't need an IP address to
seal something.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

[Seth Blank]

I concur. This is an important work item for the group, and fits cleanly
into Phase 3 of our charter.

On Thu, Oct 25, 2018 at 10:42 AM Kurt Andersen  wrote:

> I'd like to recommend that we (DMARC-WG) accept
> https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work
> queue. It aligns with our charter already.
>
> --Kurt Andersen
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

[Hector Santos]

On 10/25/2018 1:42 PM, Kurt Andersen wrote:


I'd like to recommend that we (DMARC-WG) accept
https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work
queue. It aligns with our charter already.

--Kurt Andersen


+1

I would also suggest to use the document proposal (and subsequent WG 
discussions) to help codify sub-domain alignment ambiguities in DMARC 
(rfc7489, section 3.1, 3.1.1 and 3.1.2) between the identities:


Author Domain,
Signer Domain, and
Return Path Domain

and how this proposal applies.

--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Request to accept a new I-D into the WG work items

[Kurt Andersen]

I'd like to recommend that we (DMARC-WG) accept
https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work
queue. It aligns with our charter already.

--Kurt Andersen
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

[Kurt Andersen (b)]

On Thu, Oct 25, 2018 at 4:52 AM Alexey Melnikov 
wrote:

> I've reviewed recent changes and they look like an improvement over
> earlier versions. I have a few minor comments:
>
> 1) I think several references need to be reclassified as Normative:
>
> [I-D-7601bis]
>Kucherawy, M., "Message Header Field for Indicating
>Message Authentication Status", February 2018,
>draft-ietf-dmarc-rfc7601bis/>.
>
> I am pretty sure this document is a Normative reference for ARC. Please
> move it to Normative references.
>
> [draft-levine-eaiauth]
>Levine, J., "E-mail Authentication for Internationalized
>Mail", August 2018, draft-levine-appsarea-eaiauth-03>.
>
> This also looks like a Normative reference. E.g. see the text in Section
> 4.1.4 of this draft.
>

Both of these are indeed normative in usage, but I was under the impression
that one could not refer to I-Ds as normative.


> 2) I am glad that broken examples from Appendix B were removed, but I
> would like to have some examples in the document. Is somebody working on
> generating these?
>

Yes, work is in progress. It is really hard to do "fake" signing of
non-existent IP and domains with real production software. That has been
the hangup.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

[Hector Santos]

On 10/25/2018 7:51 AM, Alexey Melnikov wrote:


2) I am glad that broken examples from Appendix B were removed, but I
would like to have some examples in the document. Is somebody working
on generating these?


+1.

Especially examples of DMARC.

--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Last Call: (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

[The IESG]

The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'Message Header Field for Indicating Message Authentication Status'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-11-08. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ballot/


No IPR declarations have been submitted directly on this I-D.




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18

[Alexey Melnikov]

I've reviewed recent changes and they look like an improvement over 
earlier versions. I have a few minor comments:


1) I think several references need to be reclassified as Normative:

   [I-D-7601bis]
  Kucherawy, M., "Message Header Field for Indicating
  Message Authentication Status", February 2018,
  .

I am pretty sure this document is a Normative reference for ARC. Please 
move it to Normative references.


   [draft-levine-eaiauth]
  Levine, J., "E-mail Authentication for Internationalized
  Mail", August 2018, .

This also looks like a Normative reference. E.g. see the text in Section 
4.1.4 of this draft.


2) I am glad that broken examples from Appendix B were removed, but I 
would like to have some examples in the document. Is somebody working on 
generating these?


Thank you,

Alexey


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Milestones changed for dmarc WG

[IETF Secretariat]

Changed milestone "Complete Authenticated Received Chain (ARC) protocol
spec", resolved as "Done".

URL: https://datatracker.ietf.org/wg/dmarc/about/

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt

[Alexey Melnikov]

Hi,

I've started IETF LC on the document, as my comments are really minor:

1) I am not sure that deleted IANA registry descriptions (when compared 
to RFC 7601) is the best way, considering that this document obsoletes 
RFC 7601. I think it would be better to just keep the text and add a 
sentence saying that it is unchanged from RFC 7601. But I am happy to 
hear what IESG has to say about this.


2) The following took really long time to verify for correctness:

Section 2.5 says about authserv-id:

  Note that in an EAI-formatted message, this identifier may be
    expressed in UTF-8.

So I decided to check whether this statement is actually true.
authserv-id is defined in Section 2.2 as:

  authserv-id = value

  "value" is as defined in Section 5.1 of [MIME].


Section 5.1 of RFC 2045:

   value := token / quoted-string

"token" doesn't allow UTF-8 (I think), but quoted-strings does, if 
updated by RFC 6532.


So, can I suggest that in Section 2.2, the following clarification is made:

OLD:

"value" is as defined in Section 5.1 of [MIME].

NEW:

"value" is as defined in Section 5.1 of [MIME], with "quoted-string" 
updated as specified in RFC 6532.



Best Regards,

Alexey



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc