On 5/31/2004 11:59 AM, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
2. HTTP is not used to deliver, post or even transfer mail, as a
semantic object.
I hate to have to disagree again, but it most certainly has been used
this way. For example, it is entirely possible to push MUA
functionality into the web browser using, say, Java, and then transfer
messages as semantic objects to and from the browser using HTTP.
See also http://www.thecodeproject.com/csharp/httpmail.asp. Before saying
that this stuff doesn't count because it's non-standard, remember that so
is STDIN and /usr/lib/sendmail.
Having said that, balancing filters (such as /-dav.*\.hotmail\.com$/ in
this example) also prove useful given the relative immaturity of these
interfaces and the speed with which they have been exploited.
MUAs may also provide local mailbox storage and it is perfectly
reasonable for messages to be delivered to such storage directly. But
an MUA that provides local message storage is not a message store, for
two reasons: (1) It doesn't provide remote access and (2) It doesn't
support multiple users.
The specs don't dictate anything to do with storage formats or how the
mail should be read. Any mechanisms for accessing mail (including reading
it via local filesystem directly) is equal. We might have feelings and
ideas about what we think are real mailstores or not but I can't think of
any separators that survive for long.
The mbox folders on the sparc workstation in my lab are created by way of
LMTP over UNIX-domain sockets, and there's only one set of folders in the
filesystem-based mailstore. The mbox folders on the windows laptop are
created by way of IMAP and support multiple users via profiles. Which one
is more serious? The sparc runs SMTP and IMAP daemons, but that's all got
to do with protocols not the mailstore.
I'd say that when a message reaches the storage where it is acted upon by
the authorized agent (where disposition notifications are generated, for
example), then it has reached a legitimate mailstore.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/