I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-uta-smtp-tlsrpt-18
Reviewer: Joel Halpern
Review Date: 2018-04-05
IETF LC End Date: 2018-04-02
IESG Telechat date: 2018-04-19

Summary: This document is ready for publication as a Proposed Standard RFC
    My thanks to the authors for addressing my major concerns and most of my minor concerns.

Major issues:

Minor issues:
     There are several areas where the document would be helped by better explanations.  From my previous review:

    Section 3, bullet 3, says that submitters using POST can ignore certificate
    validation errors when using https.  That seems to undermine the usage of
    https.  As such, I would expect to at least see some explanation of when
    and why ignoring such errors is appropriate.

    It is surprising in Section 3 Bullet 4 that reporting via email requires
    that the report submitted use DKIM.  Particularly while ignoring any
    security errors in communicating with the recipient domain.

    In the formal definition of the txt record, shouldn't the URI format also
    indicate that semicolon needs to be encoded?

    Section 5.1 defines a report filename.  This is probably a naive question,
    but what is that for?  If using HTTPS, the earlier text says that the POST
    operation goes to the target URI from the txt record.  When using email,
    there is no apparent need for a filename.

    Most of the security risks described in the Security section (7) do not
    seem to have any mitigation.  Should there not be some explanation why
    deployment is acceptable with these risks?

Nits/editorial comments: