InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0013.txt

Text File | 1993-07-02 | 7.5 KB | 145 lines

> I especially don't want my outgoing mail making two international hops
> when I am sending domestic mail, just because I happen to be talking to
> a foreign IMAP server.

Indeed not. But how can you guarantee that the client isn't configured
to send its SMTP mail to a relay host in another continent? With some
POP-based clients, users are encouraged to carry around a floppy disk
(created at their home base) with their draft messages and other user
environment, including the address of the SMTP relay host. So there is
nothing to prevent redundant international hops even with the
SMTP-submission method.

Surely, what we should be aiming at is sufficient common sense, in both
client and server, to send data from _where it is_, to _the nearest SMTP
relay_, _without an intervening hop_. This must include the case where the
data is at the server, i.e. when it is a draft message managed by the
server.

> I'd undoubtably feel differently if my primary machine was my Mac (or a PC)
> instead of my NeXT.

I think it's this word 'my' that's causing the trouble! Many users will not
have a machine which they can call their own. Many people will use computers
for little, perhaps nothing, else besides mail. We see mail as a universal
resource, like telephones. It must not become merely another luxury for the
computer-owning, computer-literate minority. IMAP2, by delegating function
to a central server, and reducing whichever computer the user happens to
have walked up to to the status of a (rather intelligent) dumb terminal,
helps to achieve that goal. But, by requiring the user to know about file
systems to manage their draft messages, it does not go the whole way.

Please understand that I am not asking (yet) for data-at-the-client to be
sent by any other means than ordinary SMTP. (Though there is scope for some
interaction with the IMAP2 server, e.g. notifying it that a message in its
store has been replied to.)

> The problem with adding an `optional submission subset' to IMAP is:
>  . it will make IMAP hairy -- we seek to avoid this
>  . it will create applications which *only* use the `optional' submission
>    mechanism.  This is a REAL threat -- the POP world is already filled with
>    POP applications which DO NOT WORK unless the POP server supports the
>    unofficial and undocumented `optional' submission mechanism of Berkeley
>    popper.

If clients create unnecessary traffic by forwarding all messages via the
server, they deserve to be rejected. But clients which use IMAP2 for draft
message management can reasonably expect draft messages at the server to be
submitted without having to retrieve them to the (perhaps intercontinental)
client. Maybe I should have talked about the `optional draft message
management subset' and made it clear that submission from the draft message
store is an integral and necessary part of that subset.

> On the other hand, it is undoubtably related to IMAP, and belongs as part of a
> sister protocol to IMAP.  We have already identified Mail Management as one
> sister protocol.  I think that authenticated transport is probably going to be
> part of a different sister.  Let's start thinking about these siblings and not
> allow IMAP's focus to be blurred.

I hope these protocols become a reality. But the closer they are to IMAP2,
the better the chance of them being integrated into IMAP2 clients. Is there
any chance that these protocols could use the same syntax as IMAP2, as far
as possible? For example, if draft message management is a part of these
protocols, it would be silly to have analogues of SEARCH and FETCH with
different syntaxes.

(I am dubious about the value of creating dozens of protocols. Multiplexing
two protocol subsets over a single TCP connection is not fundamentally
different from using two TCP connections. Relying on an optional subset of
one service is not different from relying on an optional service itself.
I assume that the 'Mail Management' protocol will talk to the IMAP2 server
in some way, so what is gained by separation?)
From [e-mail]  Fri Sep 25 11:30:23 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA19747; Fri, 25 Sep 92 11:30:23 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA17967; Fri, 25 Sep 92 11:30:12 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA17961; Fri, 25 Sep 92 11:30:01 -0700
Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42587-1>; Fri, 25 Sep 1992 12:29:30 -0600
Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Fri, 25 Sep 92 11:31 MDT
Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp
    (Smail3.1.26.7 #1) id m0mYJYt-000cuxC; Fri, 25 Sep 92 11:34 MDT
Received: by isasun-3.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1)
    id <[e-mail]>; Fri, 25 Sep 92 11:29 MDT
Date:     Fri, 25 Sep 1992 11:05:56 -0600
From: Steve Hole <[e-mail]>
Subject: Some general mail message issues
To: [e-mail], [e-mail]
Message-Id: <Pine.3.03.9209251156.A21395-c100000@isasun-3>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


None of these are really IMAP or pine issues themselves, but are related - they are
general questions concerning the handling of mail messages.

1.  Is there a mailing list for the discussion of the MIME message format?  I am
    interested in discussing the howtos on including PEM key information in MIME
    messages, and want to make sure to ask the *right* people.

2.  Who is responsible for the development of the message management protocol?
    Is there a mailing list for this?   What is the status of this effort?

    This is becoming a real issue for us.   The ability to get and configure
    services like delivery acknowledgement, read acknowledgments, and automatic
    reply are a high priority for many of our clients - especially when packages
    like Microsoft mail are able to do it.  I know that the architecture is much
    simpler and not very good for MS Mail - but that is what the users still
    see.   The issue needs to be addressed presently or we are going to find
    ourselves swamped with proprietary file system based mail systems in user
    workgroups.

3.  Is there a list of "management services" or whatever you want to call them
    available.   The X.400 spec has a list that seems comprehensive enough
    (watch me burn on that one :-) to use as a base point.  Is there an
    equivalent for Internet mail services?

4.  Is there an agreement or description of where services like automatic reply
    should be provided - in the MTA or the MUA?   X.400 specifies the message
    store (which makes sense), but there is no equivalent in the Internet
    architecture (I think there should be).

5.  There was some mention on work being done to implement lightwieght directory
    access protocols for getting X.500 information quickly.   Could someone
    point me to these individuals again?   This is very important to us as a
    mechanism for distributing public keys for PEM.

... and specifically for Mark ...

6.  Is there a todo list for the c-client?   What are the current priorities for
    the c-client?

Thanks all.   Cheers.

--
Steve Hole                  Director of Research and Communications
ISA Corporation            mail:  [e-mail]
Edmonton, Alberta, Canada       phone: [phone]