Re: [EAI] REVIEW: draft-ietf-eai-downgrade-07

[Harald Alvestrand <harald at alvestrand.no>]

Thank you very much for your review!

SM wrote:
> At 04:16 17-06-2008, Harald Alvestrand wrote:
> > This is the WG Last Call for the document entitled "Downgrading
> > mechanism for Email Address Internationalization",
> > draft-ietf-eai-downgrade-07.txt.
>
> The abstract mentions:
>
>   "To avoid bouncing internationalized Email messages when a server in 
> the
>    delivery path does not support the UTF8SMTP extension, some sort of
>    converting mechanism is required."
>
> I suggest using "rejecting" instead of "bouncing" as bounces are frown 
> upon nowadays.

Since "reject" is commonly used to cover both refusals to accept and 
returning of non-delivery notifications, I agree with the change.
I wouldn't agree with a change that suggested that non-delivery 
notifications can't be used.

For the rest, these seem like improvements to the text. Thanks!
> In Section 1:
>
>   "To avoid bouncing such messages when a
>    server is encountered which does not support the UTF8SMTP extension,
>    this document describes a downgrading mechanism."
>
> I suggest a rewording:
>
>   This document describes a downgrading mechanism to avoid rejection 
> of such messages
>   when a server which does not support the UTF8SMTP extension is 
> encountered.
>
>   "In Section 3, many header fields starting with "downgraded" are
>    introduced."
>
> I suggest using "Downgraded-" as in Section 3.
>
>   In Section 3, many header fields starting with "Downgraded-" are
>   introduced.
>
> In Section 4:
>
>   "The "RCPT TO" command may have an ORCPT parameter when the recipient
>    address is downgraded.  The ORCPT parameter is used for DSN
>    [RFC3461]."
>
> The wording might suggest that an ORCPT parameter is added when a 
> downgrade is done.
>
>    The "RCPT TO" command can have an ORCPT parameter if the DSN extension
>    [RFC3461] is supported. If the ORCPT parameter contains ...
>
>   "As a result of the recipient address replacement, the domain part of
>    the original recipient address may not equal to the domain part of
>    the new recipient address."
>
> Is that "original recipient address" the address in the ORCPT 
> parameter?  It doesn't sound like it if I read the entire paragraph.  
> That term is used in RFC 3461.  It's better to avoid it.
>
>    As a result of the recipient address downgrading, the domain part of
>    the recipient address prior to downgrading might be different from the
>    domain part of the new recipient address.  If the result of address
>    resolution for the domain part of the new recipient address contains
>    the server at the connection destination of the SMTP session for the
>    recipient address prior to downgrading, the SMTP connection is 
> valid for
>    the new recipient address.  Otherwise, the downgrading process MUST 
> NOT
>    send the downgraded message to the new recipient address via the 
> connection
>    and MUST try to send the downgraded message to the new recipient 
> address.
>
> In Section 7:
>
>   "Recipients addresses can be undisclosed if those addresses are
>   listed on Bcc or group address.  Those undisclosed addresses are
>   used only in the Envelope.  Copying information from the Envelope
>   into headers risks inadvertent information disclosure (not just
>   about addresses).  See Section 4 for instructions on recipient
>   address handling."
>
> I'm copying a sentence from RFC 2821 Section 7.2:
>
>   Addresses that do not appear in the message headers may appear in the
>   RCPT commands to an SMTP server for a number of reasons.  Copying
>   information from the Envelope into headers risks inadvertent 
> information
>   disclosure (see RFC 2821).
>
> Regards,
> -sm
> _______________________________________________
> IMA mailing list
> IMA at ietf.org
> https://www.ietf.org/mailman/listinfo/ima

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