Subject: mail_subscribe et al

From: Mike Macgirvin <[email-masked]>
Date: Wed, 8 Dec 1993 09:48:19 -0800 (PST)

In using mail_subscribe() and friends for the first time (anticipating 
the day when xlview and pine can use the same support files) I ran across a few
anomolies...

	mail_subscribe() , mail_unsubscribe() :

		The host component is stripped from the passed mailbox name 
before adding/removing to/from .mailboxlist -- I guess this is sorta' OK, but 
in a multpile mailhost world it would be nicer to preserve the name which is 
passed, host and all. Perhaps this is the reason for IMSP. In XLView we try to 
host qualify anything that isn't direct file access; so if there's a server 
connection, there's a host component. Is there any way to consolidate ours and 
Pine's view of the mailbox world? Is it possible, through recursion, to get the
host part added to the file? Such as 
mail_subscribe(NIL,"{host.domain}{host.domain}mailbox");
	or will this recurse on the stream open and leave us right back where 
we started? (Haven't tried). 

	mail_subscribe_bboard(), mail_unsubscribe_bboard() :

	Curious as to why we have to strip the leading "*" character so it can 
be tacked back on again... i.e. let's say I'm trying to subscribe to 
"*{nntpserver/nntp}alt.sources"; I have to point mail_subscribe_bboard() at 
"{nntpserver/nntp}alt.sources" so it can tack on an asterisk of its own.
	Anyway, this works; but I'm just a little puzzled why the extra 
kludginess is needed.

mike

---

From: Mark Crispin <[email-masked]>
Date: Wed, 8 Dec 1993 22:10:32 -0800 (PST)

> before adding/removing to/from .mailboxlist

I think you are confused.  If you give mail_subscribe() an IMAP name it will
do a subscription on the *server*, not the client.  In other words,
	mail_subscribe (NIL,"{foo}bar.zap");
will add ``bar.zap'' to the .mailboxlist on host foo.

If you want to add an IMAP name to the client subscription list (e.g. as a
glue pointer to that IMAP server), you need to use sm_subscribe().

> "{nntpserver/nntp}alt.sources" so it can tack on an asterisk of its own.

This is going to change, most likely incompatably, due to the deletion of
bboards from the IMAP spec at the Houston IETF.