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

From: SM <[email-masked]>
Date: Tue, 01 Jul 2008 12:54:13 -0700

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 04 Jul 2008 14:00:38 +0200

Thank you very much for your review!

SM wrote:
> 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!
> 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.
>