POP3 vs IMAP answered. MAILDROP asked.

Alan Cohen alan-QVObF66B6qeOg/Yh5kgvkFaTQe2KTcn/ at public.gmane.org
Mon Sep 22 23:37:00 UTC 2003


On Mon, 2003-09-22 at 12:35, Kareem Shehata wrote:
> On Mon, 2003-09-22 at 12:24, Madison Kelly wrote:
> > Thanks for the reply, Kareen!
> > 
> >   I am running 1.2.2-5 so maybe an upgrade is in order. Can I ask, I am
> > almost ashamed to ask how IMAP differs from POP but it is something I
> > never considered but now you have piqued my interest!

Kareem wrote
> I don't know much about the protocol itself, but the end result from a
> user's perspective is essentially server-side vs. client-side storage. 
> I know that both can be used for both purposes, but from what I've seen
> IMAP is far more effective than POP3 at storing mail and synchronizing
> to one or more clients for the same inbox.
> Kareem

IMAP is a most elegant protocol. It is far better from what I've heard
and personally witnessed than POP3. (Its surprising lack of wider
acceptance may be due to ISP reluctance: Afterall, IMAP invites you to
leave messages on the server which ISPs probably don't relish.)

IMAP puts each message into its own file.
File locking problems don't happen.
Life is simpler.

For each folder, it constructs 3 sub-directories: tmp, new, cur

- "tmp" (as you might guess) is a temporary directory. New messages are
  first written to an individual file in "tmp". Once that task is done,
  the file is moved to the "new" directory.

- "new" is the directory that contains messages that the user hasn't
  seen yet. Once they have been seen, they are moved to the "cur" dir.

- "cur" is where a message file tends to live. Once there, the user
  could choose to delete it or move it elsewhere.

The files have rather long names, but are designed so that an "ls" will
show them in date order. Beyond that, the end of a filename hold
characters that indicate such things as "message flagged for deletion"
or "message flagged as read or not read"

One of the other beauties of IMAP is that moving files from one
directory to another or changing a file's name involves minimal I/O.

The 3 sub-dirs tmp,cur,new typically reside in a sub-dir called
"Maildir" which may contain little more than that.

However, if I have a folder called "lists" then Maildir will also have
another sub-dir called ".lists" (note leading dot). In sub-dir ".lists"
the structure is repeated, ie: 3 sub-dirs called tmp,cur,new

If I have a folder called "tlug" which is a sub-folder of "lists" then
Maildir will have such additional sub-dirs, which are
	.lists
	.lists.tlug

Note that .lists.tlug is a sub-dir of Maildir
      ie: .lists.tlug is NOT a sub-dir of Maildir/.lists

Rather than a traditional on-and-on hierarchy of sub-directories, things
are flatter, although not completely flat.

There will always be these sub-directories (ie: a depth of 2)
	-- Maildir
	------- Maildir/cur
	------- Maildir/new
	------- Maildir/tmp

Things could go deeper conceptually, but never physically deeper than a
sub-directory depth of 3. Even if you have folders and sub-folders and
sub-sub-folders, you won't go beyond that depth of 3

Physically, we never go more than 3 directories in depth
	--1--   --2--   --3-- 
	-- Maildir
	------- Maildir/cur
	------- Maildir/new
	------- Maildir/tmp
	------- Maildir.lists
	--------------- Maildir/.lists/cur
	--------------- Maildir/.lists/new
	--------------- Maildir/.lists/tmp
	------- Maildir/.lists.tlug
	--------------- Maildir/.lists.tlug/cur
	--------------- Maildir/.lists.tlug/new
	--------------- Maildir/.lists.tlug/tmp
	------- Maildir/.lists.tlug.2003.
	--------------- Maildir/.lists.tlug.2003/cur
	--------------- Maildir/.lists.tlug.2003/new
	--------------- Maildir/.lists.tlug.2003/tmp
	------- Maildir/.lists.tlug.2003.july
	--------------- Maildir/.lists.tlug.2003.july/cur
	--------------- Maildir/.lists.tlug.2003.july/new
	--------------- Maildir/.lists.tlug.2003.july/tmp

Conceptually, we might go much deeper
"July"    is a sub-folder of "2003"
"2003"    is a sub-folder of "tlug"
"Tlug"    is a sub-folder of "lists"
"Lists"   is a sub-folder of "Maildir" (a.k.a. "INBOX")

I'm using
	- EXIM as my MTA
	- CourierIMAP (handles both POP & IMAP) message retrieval
	- SqWebMail (which loves CourierIMAP)
	- Maildrop (which also loves CourierIMAP) is my latest
	  challenge.

---- So much for today's contribution. Now for today's question ----

I'm trying to write MAILDROP support for 
	- "blacklists" and  "whiteFromLists"
	- allow a sender to put himself in a whiteFromLists by sending
	  a message with a predetermined code in the subject header
	- the ability to place (that's easy) after detecting user
	  preference (that's harder) that a message is be automatically
	  placed in a particular IMAP folder.

Maildrop does impressive things, but I wish it had more of Perl's power.

Does anyone have experience with such a scenario? 

-- 
-------------------------------------- Please do not respond in HTML
Alan Cohen alan-QVObF66B6qeOg/Yh5kgvkFaTQe2KTcn/@public.gmane.org
voice: 416-783-9826
fax:   240-269-7457

--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list