On Thu October 28 2004 19:54, Keith Moore wrote:
A message may contain an arbitrary
number of Comments fields. However, it does not solve the
problem of the incompatibility with RFC 2046 message/partial.
could you explain that supposed incompatibility again?
Fragmentation/reassembly is defined in RFC 2046 section 5.2.2 and
its subsections. The issue was discussed in some detail on the ietf-822
mailing list in June 2003 and again very briefly regarding specific
field (References, In-Reply-To, and Resent-Message-ID) in September
2004. Briefly, the fragmentation/reassembly process distributes
original (unfragmented) message header fields between the header
of the first fragment and the header of the encapsulated message
(which appears within the message/partial wrapper in the first
fragment; reassembly combines fields from those two headers to
produce a facsimile of the original message from fragment messages.
RFC 2046 lists specific fields which are taken from the encapsulated
header -- MIME Content- fields, Subject, Message-ID, Encrypted,
and MIME-version -- that list is amended by RFCs 2298/3798 to
include Disposition-Notification-To, Disposition-Notification-Options,
and Original-Recipient; these fields are the ones which pertain
specifically to the unfragmented original message as opposed to
any fragment.
Clearly, the proposed Archived-At field applies to a specific message
(like Message-ID), and should be in the same category as those
specifically mentioned. However, unlike RFC 3798 and its
predecessor, the archived-at draft does not amend the RFC2046
list of fields which are reassembled from the encapsulated message
header. Consequently, Archived-At would be treated like Comments;
when fragmenting a message, the field would be copied to the
first fragment message header, and would be reassembled from there
to the reconstituted facsimile of the original unfragmented
message (any such fields within the encapsulated message header
would be ignored, in accordance with the RFC 2046 rules). That
is inconsistent with the semantics proposed for Archived-At, viz. that
it references an archived copy of the specific message in which it
is conveyed. An Archived-At field that originally referred to an
archive of an unfragmented message would therefore be
inappropriately placed in the message header of a different message
(viz. the first fragment message). Moreover, it would be
indistinguishable there from an appropriate Archived-At field which
referred to an archive of that (first fragment) message. And
as fragments may be further fragmented, that issue may be
compounded.
not that I'm
really worried about it as (a) I haven't seen a message/partial since
the early 1990s (even then it was only as a test)
Hey, good for you; that's one data point. It is a valid media type
and corresponding mechanism which is in use (Ned reported having
seen just over one hundred fragmented messages in a year when
the issue was discussed on the ietf-822 list). Unless one is operating
a human-powered gateway, it is not surprising that one would not
see fragments, as fragmented messages are supposed to be
reassembled by gateways (RFC 1344) before being forwarded (see
also
http://lists.sans.org/pipermail/list/2002-September/054073.html
and the CERT advisory which can be found by following links for
issues that arise when careless or ignorant vendors of gateway
products fail to reassemble fragmented messages).
and (b) somehow I
doubt that most MUAs can reassemble message/partials anyway.
"Most MUAs" do not handle one or more aspects of messaging well.
Many MUAs, however, can reassemble fragmented messages. And
as noted above, fragmented messages are supposed to be
reassembled before reaching an MUA if there is a gateway (e.g.
spam- or virus-scanner) involved; MUAs are not the only things
that handle and/or process messages.
I don't see why in the world an MUA would download the URI in an
Archived-At field, because it already has the message on hand.
Neither do I, and that's why I raised the issue; if the field is in
fact intended solely for human use, then we've been going
down the wrong track for 8 months discussing syntax issues
for a structured field.
(no, I
don't consider message/partial a threat in this regard).
The security threat is not directly related to massage/partial; it
arises due to external references.
An imap scheme certainly indicates that the format is message/rfc822
I've certainly seen IMAP servers that would provide arbitrary contents.
Whether that was a bug or a feature, I was never sure.
Let's be clear about the issue; the IMAP protocol as implemented by
IMAP servers is capable of returning message sections or metadata
in response to specific client queries. The IMAP URI scheme (RFC
2192) can also access some of those objects. Note that it is
clear from the IMAP URI syntax what is being accessed (RFC 2192
section 2).
Accessing such an archive requires access credentials, which
would have to be communicated (probably possible within
the URI).
IIRC, IMAP was specifically designed to be able to provide read-only
access to archives. But it's been awhile.
Read-only vs. read-write authorization is intimately connected
with access credentials in IMAP. It is possible to permit anonymous
access, and the default user name is in fact "anonymous".
Other user names can be supplied in the URI, or interactively
from client/user dialog. I'm not sure if all schemes have similar
capability.
- a specification for making collections of mail messages available
via HTTP (maybe WebDav) and/or FTP
multipart/digest is an existing media type, which can be
transferred via HTTP and/or ftp, which *is* a collection
of messages.
yup, but as an archive format, it's pretty pessimal.
I think we were discussing transfer specifications/formats, not
necessarily what's stored on the archive server.
you can't easily
locate a particular message within the file
An MUA implementation issue. Some MUAs *can* locate
particular messages in a message/digest collection.
, nor can you append new
messages to the file.
I'm not sure I'd want random persons to be able to modify
existing archive files -- that defeats one of the purposes of
having an archive. That doesn't prevent messages being
added to the archive; serving the collection as message/digest
would serve a snapshot of the collection as it stands at the
time of the request.
and as much as I'd like to believe that email client vendors would
enthusiastically add support for these, market conditions don't
seem
to favor supporting new functionality standards in email clients
right now.
[incidentally, I'm not sure that I buy the "market conditions" line;
there are open source clients that continually add feature support --
what you say might be true for *commercial* clients, but not all
clients fall into that category]
There may be a more fundamental issue: IMAP (or NNTP) access
requires either handling a URI or configuration of the necessary
parameters which would be conveyed in a URI (host name, port,
user credentials). Certainly MUAs that provide IMAP client
functionality could be used without any additional design, but
the user would need to get the parameters from somewhere and
configure his MUA(s) accordingly. MUAs don't typically handle
generic URIs directly (mailto URIs are a notable exception), but
instead may hand them off to a browser (which in turn might
invoke an MUA for an imap scheme URI).
Parsing an IMAP URI is not rocket science, and doesn't need more than a
couple of hundred lines of code. Somehow I don't think this is the
limiting factor.
Show me an MUA that can access a collection of existing
messages by typing (or pasting) a URI (as opposed to
entering configuration information in a file or via some
GUI dialog). Now browsers do tend to have URI support,
and back in February I pointed to an example of a browser
with IMAP URI support; but browsers aren't MUAs. Merely
parsing a URI is an insignificant part of what needs to be
done to utilize a URI, much less configure IMAP access.
(Actually I think that all MUAs should allow their mailboxes and
submission servers to be specified using URLs - it's much simpler and
less error-prone than giving users lots of blanks with misleading
labels to fill in.)
Simpler for whom? A casual user who has no idea what a URL
is or how to construct one? My experience with a particular MUA
which required a specific type of URI for a particular piece of
configuration (without specifying that it in fact needed a
URI) was rather annoying.
I think the issue of a list of URIs might be revisited (and not
necessarily in a structured field), so that multiple access
methods to a given message could be specified (that does
not preclude multiple fields to indicate multiple places where
copies may be archived, except of course if comments in the
Message-ID field are used).
I don't see the point in specifying multiple ways to do the same thing.
The point is to enable an archive which has multiple access
schemes (e.g. http, ftp, IMAP, POP, NNTP, mailto) to be able
to provide pointers for that multiplicity of schemes for accessing
a particular archived message, distinct from the issue of
multiple separate archives. If you don't care which access
method is used, pick one at random -- but it sure sounds
like you do care, judging by your comments about HTML
archives.
There's a good argument for allowing multiple Archived-At fields
because the originator, the recipient's MTA, and any number of
intermediaries might archive a message - it's much cleaner to just let
each of them add a separate field. Given that I don't see any need to
have multiple URIs within a field also.
See above.
as for RFC 2231, I agree that they
can get ugly, but I think this will be rare.
Ugliness isn't the issue; the issue is that given that specification,
there needs to be code to handle what the specification
requires. Now of course, it is possible to come up with yet another
specification, but then that requires yet another mass of code.
and the MUA ought to have
code to handle RFC 2231 anyway.
In the specific places where it is specified (Content-Type and
Content-Disposition), yes. That is not necessarily available
for use in arbitrary fields, and cannot be applied to all fields
(there are fields with syntax that is not amenable to 2231
parameters, e.g. unstructured fields).
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################