Re: [EAI] Comments on draft-ietf-eai-downgraded-display-01

[fujiwara at jprs.co.jp]

Hi, 

Thanks for your comments.

> From: SM <sm at resistor.net>
> Hello,
> 
> These comments are for draft-ietf-eai-downgraded-display-01.  Please
> consider them as "I read the document".
> 
> In Section 2:
> 
>   "An "UTF8SMTP message" is an Email messages expanded by [RFC5335]."
> 
> There is a typo for "Email message".

I will update.

> In Section 4:
> 
>      "Apply Email header fields downgrading defined in section 5
>       of [I-D.ietf-eai-downgrade] to the output of Step 2 without re-
>       generating "Downgraded-" header fields."
> 
> This document describes the restoration methods.  I read the above as
> apply downgrading again as defined in RFC 5504.

I will try to rewrite the procedure to understand easy.
Displaying downgraded header uses Section 5 of RFC 5504.

>       "Don't change "Downgraded-Mail-From" and "Downgraded-Rcpt-To"
>       header fields because they do not have their original header
>       fields."
> 
> You are not changing these header fields as they correspond with a
> SMTP envelope, i.e. the original is not a header field.

I will rewrite as:
    Other "Downgraded-" heder fields ("Envelope  
    Information Preservation Header Fields" and "Address Header  
    Fields' Preservation Header Fields" are not targets of this step. 

> In Section 5:
> 
>   "While information in any email header should usually treated with
>    some suspicion, current email systems commonly employ various
>    mechanisms and protocols to make the information more trustworthy.
>    For example, an organization's boundary MTA can modify From: lines so
>    that messages arriving from outside the organization are easily
>    distinguishable from internal emails. As a result of rewriting, the
>    Downgraded-From header field may not be decoded."
> 
> Modifying the "From:" lines does not make the information more
> trustworthy.  It is more of a hack to get around the limitations of
> the MUA.  Please see whether the "decoding failure" (last sentence in
> the paragraph above) note would be more appropriate in Section 4
> instead of Section 5.  The Security Considerations section needs some
> more thought in my opinion.

I will add some sentence in security considerations.

Regards,

--
Kazunori Fujiwara, JPRS <fujiwara at jprs.co.jp>