POP 4 protocol
Stu
POP 3 is nice a lightweight and does the job. But I thought perhaps
some more features could be handy to people who want move serverside
control.
POP 3 specfically says don't add anything to it, so I propose POP 4.
Thought I'd mention it here and see if there are any interested
parties.
Mark Crispin
who doesn't want to implement IMAP. This part of his FAQ says it all:
> POP 3 is a nice simple protocol. It serves the purpose of enabling people
> to get their mail.
> IMAP Is none of the above.
> POP 4 adds some functionality to POP 3 while trying to maintain the simple
> ease of use design of POP 3.
> IMAP isn't that either.
For all of the disdain of IMAP, it's pretty amazing how much is copied
from it.
Lotsa luck getting anyone else to implement yet another mail access
protocol.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Daniel Feenberg
Perhaps you would elaborate on what functionality the POP4 client will
have that the POP3 client does not? Why is telling the client about
the quota better than letting the server handle it? Similarly why is
it better for the server to handle folders rather than the client?
It isn't that I think you are wrong, I just would like to hear your
reasoning.
You mention that the motivation for this is to allow improved web mail
clients. We use Neomail for our webmail service, it mounts /var/mail
over NFS and we have had no problems. Is it necessary that web mail
be based on POP?
I expect that spam/virus/security enhancements would be closer to
the top of typical user or admin wishlist. Assuming those are beyond
the scope of a POP-like protocol, I would say that in many years
of supporting Eudora and Outlook with POP the only problems we
have had are:
1) Very rare lockfile problems.
2) Clients that wish to scan very large mail spools too often can
overload the POP server.
3) It isn't easy to support encrypted passwords, although we
are now doing it.
We offer both POP and IMAP to several hundred users, and all but two
or three use POP. (Several dozen Pine users mount /var/mail over NFS,
as does our webmail client, Neomail).
PS: We very much appreciate Pine, as it is far more reliable than
the commercial clients.
Stu
force behind pop 4. Perhaps you remember Barry Lieba and I working on
something.
I don't deny that there are some good features of imap, but there are
many more bad ones that come along that I feel are unnecessary. I'm
proposing a small subset, with a much easier syntax, and I decided to
call it pop 4. That is all.
The poorest aspect of pop4 is it's timing, I should have written it in
1998 when I first got the idea. But better late than never.
POP 4 is simply an alternative. If you don't like it don't use it.
I don't like american cars, I buy european. So be it.
Mark Crispin <M...@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.55.03...@Tomobiki-Cho.CAC.Washington.EDU>...
> Oh dear, yet another attempt to add online functionality to POP by someone
> who doesn't want to implement IMAP. This part of his FAQ says it all:
Stu
a POP 3 client. POP 4 just presents a shift in power from the client
to the server.
It allows for more server side organization of mail. Personally, I
check my mail from more than one computer, so to organize the mail on
the server rather than the client (and not having to download in 6
places) would be useful to me. POP 4 allows for that.
If you're a one-computer user, I wouldn't expect you to notice any
difference.
Actually my motivation was my dislike of IMAP.
One of the abilities that pop 4 allows for is that you could write a
web mail program for the protocol.
Right now, all webmail programs act against a specific implementation
of a mailstore. I think it would be far more useful to implement
against a protocol which people can implement that acts against their
mailstore. It is not necessary but it certainly would allow for people
to choose their webmail program rather than only be able to use the
one written by the vendor of their mailstore. I'm not a big fan of
lots of layers (see http://deadpelican.com/whyj2eesucks.html) but in
this case, I think it's warranted. Mail is the 'killer app' no?
You are correct, mail has largly settled down and spam is the next
big evil. I've got an idea for that too. It's called a white list. If
people want to write a white list specification more power to them,
I'd love to help. Right now pop4 is my bag.
I'd like to make the world a better place, this is my effort. I know
other people think like this (they've told me) and since nobody has
sat down and done this, I have.
There's still plenty to be done in the world of email, and no, this
isn't at the top of the list, but if I can save even one programmer
from having to implement an IMAP server, I've done my job.
Stu
You have to consider where I'm coming from.
While most people don't have this problem, my mail system has to
support 5 million users.
You might find your IMAP solution breaks down before you get anywhere
close to that.
Sam
Hash: SHA1
In article <95ab1d6e.03042...@posting.google.com>,
spa...@deadpelican.com (Stu) writes:
> While most people don't have this problem, my mail system has to
> support 5 million users.
>
> You might find your IMAP solution breaks down before you get anywhere
> close to that.
With few exceptions, IMAP servers don't care what the total # of mail
accounts are. In nearly all cases the server's scalability is determined
by the number of different folders and/or folder size./
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE+qvxZ3ejdWUS0ltARAknLAJ4gusAWOEQszvS5+m7p+OR9RoEkSwCfUg6k
fH+hCvam2uB27KEX2QKKLxI=
=rOJB
-----END PGP SIGNATURE-----
Daniel Roedding
> http://www.pop4.org
>
> Thought I'd mention it here and see if there are any interested
> parties.
Looks interesting and should be really easy to implement, but
I doubt the world outside will take notice of it.
Some tech annotations after browsing your proposal:
- Avoid implicit assumptions on nested folders.
Work with absolute "paths" only and leave open how the server
treats folder names.
- Don't define message flags as numeric values. A flexible "name=value"
list does a better job. Declare mesasge flags as an optional feature.
- An optional(!) index-generating command would be nice, too. NNTP has
"XOVER" for this.
- I don't really like the idea of sending multiple-id lists to the
server on folder moves. POP3 has only multi-line responses being
sent from the server to the client. Another problem with multi-argument
folder moves in specific is that you don't have much flexibility in
returning results from partially failed operations.
Daniel
Stu
> Work with absolute "paths" only and leave open how the server
> treats folder names.
I'm not sure what you mean here. I believe I suggest full paths only.
In my server I allow partial (while I was debating the idea), but my
intention was only to allow full specs. It is a program after all, it
shouldn't care about typing and partial paths only make the
programming more complicated. It should be full paths, I'll change it
if it doesn't say that.
> - Don't define message flags as numeric values. A flexible "name=value"
> list does a better job. Declare mesasge flags as an optional feature.
The problem with that is clients wouldn't be able to understand the
flags as having the name meaning unless they were named. So I came up
with as many suggestions as I could think of that all clients should
agree on.
Herm. Okay, I see what you're getting at. Okay, lemme simmer
on that. I was going for simple bit twiddling, but I think perhaps
your point is more useful.
> - An optional(!) index-generating command would be nice, too. NNTP has
> "XOVER" for this.
Not into news, I'll check this out. Thanks.
> - I don't really like the idea of sending multiple-id lists to the
> server on folder moves. POP3 has only multi-line responses being
> sent from the server to the client. Another problem with multi-argument
> folder moves in specific is that you don't have much flexibility in
> returning results from partially failed operations.
I agree, I didn't like the idea of sending a variable length list to
the server. But I figure its worth the tradeoff considering the
optimization available to the server if you do allow it.
Also, consider, it's up to the client now isn't it. :-) If the client
wants to do one at a time, it can.
Thats whay I said there's a lot of room for error and if the server
responds with -ERR the client should assume nothing about the state of
the destination (or in the case of move, destination and source)
folder.
Thanks for the input though. As soon as I have some time, I'll work
in your ideas.
Unlike most RFC's, I'm actually requesting comments.