headers
Trevor Paquette | 1 Mar 2008 02:38
Picon

RE: The "such responses" extension sentence (was: Re: MX to CNAME and (mis)interpretation of 2821)


>-----Original Message-----
>From: owner-ietf-smtp <at> mail.imc.org
[mailto:owner-ietf-smtp <at> mail.imc.org] On Behalf Of Mark >Martinec
>Sent: Monday, February 25, 2008 10:05 AM
>To: ietf-smtp <at> imc.org
>Subject: Re: The "such responses" extension sentence (was: Re: MX to
CNAME and >(mis)interpretation of 2821)
>
>
>SM wrote:
>>    When a domain name associated with an MX RR is looked up and
>>    the associated data field obtained, the data field of that
>>    response MUST contain a fully-qualified domain name.  That
>>    fully-qualified domain name, when queried, MUST return at
>>    least one address record (e.g., A or AAAA RR) that gives the
>>    IP address of the SMTP server to which the message should
>>    be directed.  Any other response,  specifically including a
>>    value that will return a CNAME record when queried, lies
>>    outside the scope of this standard.  The prohibition on CNAME
>>    RRs is discussed in more detail in RFC 2181, Section 10.3 [29].
>
>That looks like a good compromise to me.
>I'd remove the word 'specifically', it makes me read the statement
>more than once to be sure of its meaning, and is probably redundant.
>
>  Mark

As the culprit who actually started all of this... (sorry!). I like this
one the best.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SM | 2 Mar 2008 14:52

Re: random rfc2821bis-08 notes


At 12:33 27-02-2008, Mark E. Mallett wrote:
>Appendix D.4  Verifying and Sending Scenario
>
>Do we really want an example using the "SEND FROM" command?  Maybe the
>point of this is whooshing over my head, but if somebody implements a
>server according to this document, the SEND FROM command in this example
>will be rejected (particularly since it's not advertised in the EHLO
>response as per F.6)

The "SEND FROM:" in Appendix D.4 could be replaced with "MAIL FROM:".

Regards,
-sm
Permalink | Reply | 0 comments |
headers
Dave Crocker | 9 Mar 2008 00:10

email-arch -- comments solicited on I8N


Folks,

A concern has been raised about the email-arch document's silence on the 
question of internationalization.  Here's what I've added to the changes 
sections, for now, to explain my view of the dilemma for the document:

                      <t hangText="Internationalization:  ">

                      The document contains
                      no discussion of this important topic.  Frankly, I have not
                      thought of what the document should usefully say about the
                      topic and am particularly worried that the problematic and
                      fluid nature of the topic would cause the architecture
                      document to conflict with the reality of work that is
                      underway.  Offerings of candidate text for the document, to
                      deal with I8N are encouraged.</t>

I would appreciate the list chatting about this, briefly, to see if there is 
anything approaching consensus.  Given the above text, you won't be surprised 
that I will consider anything less than a substantial consensus as meaning that 
the document should continue to be silent on the topic.

I don't consider that a desirable outcome, but am very worried that anything 
else could derail the document's publication.

d/
--

-- 

   Dave Crocker
(Continue reading)

Permalink | Reply | 18 comments |
headers
Dave Crocker | 9 Mar 2008 00:15

email-arch -- Security Considerations


Folks,

A question has been raised about the very brief Security Considerations section 
in the email-arch draft.  I've modified the section slight, for the next draft, 
but the section still defers meaningful discussion to existing specifications.

This is the latest version:

> <section title="Security Considerations">
>             <t>This document does not specify any new Internet Mail
>                functionality. Consequently it is not intended to introduce any
>                security considerations, beyond those already established for
>                Internet Mail. </t>
>             <t>However its discussion of the roles and responsibilities for
>                different mail service modules, and the information they create,
>                highlights the considerable degree to which security issues are
>                present when implementing any component of the Internet Mail
>                service. In addition, email transfer protocols can operate over
>                authenticated and/or encrypted links, and message content or
>                authorship can be authenticated and/or encrypted. </t>
>             <t>The core of the Internet Mail architecture does not impose any
>                security requirements or functions on the end-to-end or
>                hop-by-hop components. Details of security considerations for
>                particular Internet Mail mechanisms are provided in the detailed
>                specifications for those mechanisms.</t>
>          </section>

As for I8N, I believe that doing more in the document requires some rather 
compelling consensus among the community -- ie, you folk.
(Continue reading)

Permalink | Reply | 703 comments |
headers
John Levine | 9 Mar 2008 06:08

Re: email-arch -- comments solicited on I8N


My impression is that MIME has done an adequate job of handling I18N
in message bodies and in Subject: lines.  The remaining ASCII-only
parts of the message are the headers that include addresses.  They
present a difficult I8N problem because the MIME encodings provide
multiple ways to represent a string, but mail addressing demands an
exact match, other than case folding in domains.

I presume that we'll eventually use some version of punycode since
it's essentially the same problem as I18n DNS, but it's way too early
to say anything about that.

R's,
John
Permalink | Reply | 17 comments |
headers
Hector Santos | 9 Mar 2008 06:14

Re: email-arch -- Security Considerations


Dave Crocker wrote:
> 
> Folks,
> 
> A question has been raised about the very brief Security Considerations 
> section in the email-arch draft.  I've modified the section slight, for 
> the next draft, but the section still defers meaningful discussion to 
> existing specifications.
> 
> This is the latest version:
> 
>> <section title="Security Considerations">
>>             <t>This document does not specify any new Internet Mail
>>                functionality. Consequently it is not intended to 
>> introduce any
>>                security considerations, beyond those already 
>> established for
>>                Internet Mail. </t>
>>             <t>However its discussion of the roles and 
>> responsibilities for
>>                different mail service modules, and the information 
>> they create,
>>                highlights the considerable degree to which security 
>> issues are
>>                present when implementing any component of the Internet 
>> Mail
>>                service. In addition, email transfer protocols can 
>> operate over
>>                authenticated and/or encrypted links, and message
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 9 Mar 2008 06:17
Picon
Picon

email-arch I18N (was: email-arch -- Security Considerations)


Dave Crocker wrote:

> As for I8N, I believe that doing more in the document requires some
> rather compelling consensus among the community -- ie, you folk.

Proposed text, insert in chapter 6 between "Security" and "IANA":

Internationalization

 The core email architecture is still based on US-ASCII headers in
 message/rfc822 objects including any MIME part headers.  Other
 charsets and the indication of languages in headers require US ASCII
 compatible MIME encodings as specified in RFC 2047 and RFC 2231.

 Similar MIME content-transfer encodings allow to use other charsets
 in message bodies, and to indicate any language, even for text/plain
 bodies with a Content-Language header field as specified in RFC 3282
 and RFC 4646, or similar techniques for other content types such as
 text/html.  

 The 8BITMIME extension of SMTP [STD 10] allows to use many charsets
 "as is" in message/rfc822 bodies without the overhead of a MIME
 content transfer encoding.

 Ongoing work on Email Address Internationalization (EAI) is expected
 to introduce message/global objects allowing to use UTF-8 [STD 63]
 in email addresses and message/global headers, see RFC 4952.

---
(Continue reading)

Permalink | Reply | 7 comments |
headers
Alessandro Vesely | 9 Mar 2008 12:35
Picon
Favicon

Re: email-arch I18N


Frank Ellermann wrote:
> Dave Crocker wrote:
>  
>> As for I8N, I believe that doing more in the document requires some
>> rather compelling consensus among the community -- ie, you folk.
> 
> Proposed text, insert in chapter 6 between "Security" and "IANA":
> 
> Internationalization
> 
>  The core email architecture is still based on US-ASCII headers in
>  message/rfc822 objects including any MIME part headers.  Other
>  charsets and the indication of languages in headers require US ASCII
>  compatible MIME encodings as specified in RFC 2047 and RFC 2231.

It may be worth to explicitly state that, although the *values* of 
some headers may be expressed in different languages an possibly 
encoded using different charsets, the headers *names* are *not* to be 
translated into different languages. Mail clients who understand any 
standard name MAY display its translation instead, provided it is 
clear to users what they do (e.g. no translated source views.)

In addition, some mail clients translate IMAP special-use folders 
names _on the server_, resulting in a loss of interoperability with 
clients that expect the de facto standard names. If it were possible 
to state that *any* translation should be carried out by the client on 
the fly, it may help refraining the temptation to internationalize too 
much...
(Continue reading)

Permalink | Reply | 6 comments |
headers
Frank Ellermann | 9 Mar 2008 14:09
Picon
Picon

Re: email-arch I18N


Alessandro Vesely wrote:

> It may be worth to explicitly state that, although the *values* of 
> some headers may be expressed in different languages an possibly 
> encoded using different charsets, the headers *names* are *not* to
> be translated into different languages.

Yes, but I guess that's too far down into 2821bis + 2822upd details,
of course we don't "translate" MAIL FROM into say "POST VON" (de) or
similar, like we don't translate <body> in XHTML.

> some mail clients translate IMAP special-use folders names _on the
> server_, resulting in a loss of interoperability with clients that
> expect the de facto standard names.

The effect of switching from "en" to "en-GB" with Gmail was funny,
my MUA needed a hard kick to note that the "trash" is now a "bin" ;-)

While that's funny I don't think it belongs into email-arch, it has
a normative reference to RFC 3501.  IMAP I18N is a rathole of its
own right with interesting "lemonade" flamewars.

The purpose of an I18N section in email arch would be to offer some
pointers for interested readers, plus context wrt the architecture,
BCP 15, UTF-8, MIME, 8BITMIME, lang-tags (maybe), and arguably EAI.

 Frank
(Continue reading)

Permalink | Reply | 5 comments |
headers
Keld Jørn Simonsen | 9 Mar 2008 14:28
Picon

Re: email-arch I18N


On Sun, Mar 09, 2008 at 02:09:25PM +0100, Frank Ellermann wrote:
> 
> Alessandro Vesely wrote:
>  
> > It may be worth to explicitly state that, although the *values* of 
> > some headers may be expressed in different languages an possibly 
> > encoded using different charsets, the headers *names* are *not* to
> > be translated into different languages.
> 
> Yes, but I guess that's too far down into 2821bis + 2822upd details,
> of course we don't "translate" MAIL FROM into say "POST VON" (de) or
> similar, like we don't translate <body> in XHTML.
>  
> > some mail clients translate IMAP special-use folders names _on the
> > server_, resulting in a loss of interoperability with clients that
> > expect the de facto standard names.
> 
> The effect of switching from "en" to "en-GB" with Gmail was funny,
> my MUA needed a hard kick to note that the "trash" is now a "bin" ;-)
>  
> While that's funny I don't think it belongs into email-arch, it has
> a normative reference to RFC 3501.  IMAP I18N is a rathole of its
> own right with interesting "lemonade" flamewars.
> 
> The purpose of an I18N section in email arch would be to offer some
> pointers for interested readers, plus context wrt the architecture,
> BCP 15, UTF-8, MIME, 8BITMIME, lang-tags (maybe), and arguably EAI.

You could also refer RFC 2130 which describes the IAB policies on the
(Continue reading)

Permalink | Reply | 4 comments |

Gmane