[EAI] Re: draft-hurtta-eai-messagestore-00.txt

[Frank Ellermann <nobody at xyzzy.claranet.de>]

Kari Hurtta wrote:

> http://www.ietf.org/internet-drafts/draft-hurtta-eai-messagestore-00.txt

Some quick notes from reading it once:

|  (g)  WWW browser access mail server with HTTP [RFC2616].

I think you can resolve (2g) by a note stating that Web mail
is typically based on IMAP or POP3, and therefore covered by
your (2e) or (2f).  If that's true, my POV is limited to a
few ISPs and my guesses what they might do, behind what I see.

| There is two mail reason why UTF8SMTP ignorant MUAs must
| not see UTF8SMTP messages:

What about users using different MUAs and different access
methods depending on where they are ?  E.g. users sometimes
need Web mail, and that should be an "UTF8SMTP aware" access
method, but generally use whatever their box offers (= some
legacy software).  You can't let the message/utf-8 rot in a
message store until the user happens to try Web mail again.

| This implies that UTF8SMTP ignorant MUA does not see any
| message (if downgrading is not provided).

Well, that case is kind of obvious.  And maybe better than
splitting the message store into a part for message/rfc822
working always, and another part for message/utf-8 working
only "sometimes" (with an "UTF8SMTP aware" MUA).

| To discover message is UTF8SMTP message may require that
| all message header fields (including header fields from
| MIME body parts) are parsed.

As always that violates anything I think to know about data
abstraction and modularization.  MIME part headers are not
the business of agents transporting MIME 1.0 messages.  You
are not designing message stores for 7bit MUAs.  If "old"
8bit MUAs can't handle a message/utf-8 part within an 8bit
message/rfc822 it's no problem to be solved by the MDA:

There are tons of MIME types not supported by any given MUA,
and maybe the user has helper applications to deal with
some of these "unknown" (from the MUA's POV) MIME types.

To read message/utf-8 parts within a message/rfc822 behind
a "UTF8SMTP ignorant" MUA a decent text editor with macros
to decode QP or B64 should be enough.

And if it's not enough the user can ask what these parts
are supposed to be, the message/rfc822 has an US ASCII
header working with his "UTF8SMTP ignorant" MUA.

| If communication between final delivery MTA and MDA use
| LMTP, UTF8SMTP response to LHLO command tells that MDA
| is UTF8SMTP

That's rather late to decide this.  Is your model limited
to verified (SPF PASS or similar) return paths ?  It won't
fly if you drop undeliverable message/utf-8 at the final
delivery MTA.

| UTF8SMTP messages are stored to /var/mail/{username}:UTF8
| file by MDA (for UTF8SMTP messages ':UTF8' is appended
| to name of file.)

Implementation details.  Please note that this chapter is
only an example (e.g. not working on file systems where a
colon isn't allowed within the path).

| 8.  Security Considerations

Oh, there you have my issue noted above, the message/utf-8
rotting in a place rarely accessed by the user.  I think
that case has to be avoided as good as possible.  For the
file system case you've proposed a way how that _could_ be
done (presence of user:UTF8 mbox file), but I think you
need some MUSTard to cover it.

Otherwise the I-D is clear, and I think the WG should add
it to its agenda.  You've mentioned changes needed for
LMTP, does one of the many EAI I-Ds discuss this already,
and I missed it, or should it be added somewhere ?

Frank



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