Comments on draft-ietf-eai-downgraded-display-01

View: New views
2 Messages — Rating Filter:   Alert me  

Comments on draft-ietf-eai-downgraded-display-01

by sm-7 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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".

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.

       "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.

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.

Regards,
-sm

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: Comments on draft-ietf-eai-downgraded-display-01

by fujiwara-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Thanks for your comments.

> From: SM <sm@...>
> 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@...>
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima