future wishes - ACAP and LDAP support

future wishes - ACAP and LDAP support

[Richard Coleman]

Since there is discussion of IMAP support, I thought
I would discuss a couple related protocols to consider.

IMAP has a companion protocol called ACAP
(http://andrew2.andrew.cmu.edu/cyrus/acap/).
ACAP is a lightweight protocol designed to allow you to
retrieve configuration information from a server.
This is very nice if you wish to use IMAP from multiple
different machines (work, home, laptop, etc) and wish to
easily keep your mail configuration the same on every
machine.

Even though ACAP is very useful for IMAP, it would have
utility outside of IMAP (and Gnus).  Maybe we could design
a general ACAP library for (X)Emacs.

Also, many IMAP implementations have LDAP support (I don't
have a URL handy).  This is another protocol that would be
useful for Gnus, but have utility outside of Gnus.

Any comments?

--
Richard Coleman
coleman@math.gatech.edu

Re: future wishes - ACAP and LDAP support

[Andrew J Cosgriff]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Richard" == Richard Coleman <coleman@math.gatech.edu> writes:

Richard> Since there is discussion of IMAP support, I thought I would
Richard> discuss a couple related protocols to consider.

[ ... ]

Richard> Also, many IMAP implementations have LDAP support (I don't
Richard> have a URL handy).  This is another protocol that would be
Richard> useful for Gnus, but have utility outside of Gnus.

I think it ought to be done a bit more generally than just in Gnus,
but yes, definitely.

There's vague talk on the BBDB list about making some future direction 
of BBDB possibly do LDAP to some extent or other.

A few months ago I wrote an extremely proof-of-concept piece of elisp
that uses the UMich command-line "ldapsearch" tool to look up people's
email addresses in an LDAP directory.

It's available at

http://www-personal.monash.edu.au/~ajc/interests/geekstuff/hacks/elisp/ldap.el

but I haven't touched it in a while now.  It'd be better (eventually)
to just link the UMich LDAP library straight into emacs and provide a
proper elisp interface to it all.

- -- 
 - Andrew J Cosgriff -                                   ajc@bing.wattle.id.au
                                      ==
                    Yow!  Are you the self-frying president?

\f

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNDGpkKSeshTHvVP1AQElpQP8DdWFk/tztUaWvGY3KoIDb2LoQS6gttiB
Dw3W0EQ3szGA7PNP9HvEwJZpGqE5YP57HeyZddXBOErP6QE2CbRQkD30M7ijIJVZ
ApCkAO8uM0Xt3qE2Tz1LHcdwumkp8YURa9q5ykn9Ux72qrdBtuic3pBvFrYCIV2o
1maml1Av9AQ=
=bb8M
-----END PGP SIGNATURE-----

Re: future wishes - ACAP and LDAP support

[Jason R Mastaler]

Richard Coleman <coleman@math.gatech.edu> writes:

> Also, many IMAP implementations have LDAP support (I don't
> have a URL handy).  This is another protocol that would be
> useful for Gnus, but have utility outside of Gnus.

http://www.umich.edu/~dirsvcs/ldap/index.html 

   Jason R. Mastaler                      jason@mastaler.com

Re: future wishes - ACAP and LDAP support

[Rolf Marvin B|e Lindgren]

[Richard Coleman]

| Since there is discussion of IMAP support, I thought
| I would discuss a couple related protocols to consider.

I'd like GNUS to be able to read Microsoft Exchange mail.  So I could
throw out Outlook.

-- 

       Rolf Lindgren           |       "The opinions expressed above are
       Sofienberggt. 13b       |        not necessarily those of anyone"
       N-0551 OSLO             |               roffe@ask.uio.no 

-- 

       Rolf Lindgren           |       "The opinions expressed above are
       Sofienberggt. 13b       |        not necessarily those of anyone"
       N-0551 OSLO             |               roffe@ask.uio.no 

Re: future wishes - ACAP and LDAP support

[William M. Perry]

Rolf Marvin B|e Lindgren <roffe@tag.uio.no> writes:

> [Richard Coleman]
> 
> | Since there is discussion of IMAP support, I thought
> | I would discuss a couple related protocols to consider.
> 
> I'd like GNUS to be able to read Microsoft Exchange mail.  So I could
> throw out Outlook.

  this could probably be done by having a movemail program that used the
'mapi' interface.  Or just make Emacs under 95/nt deal with it natively. :)

  It's been a _LONG_ time since I looked at MAPI though, and I like it here 
in unix land. :)

-Bill P.

Re: future wishes - ACAP and LDAP support

[Lars Magne Ingebrigtsen]

Rolf Marvin B|e Lindgren <roffe@tag.uio.no> writes:

> I'd like GNUS to be able to read Microsoft Exchange mail.  So I could
> throw out Outlook.

If someone writes code for talking MAPI, I'll install it in Gnus.

Which reminds me -- the overhaul of the mail fetching code.  There are
two things I want to add:

1) A greater flexibility in specifying how mail is to be fetched.  For
instance, you may have several POP maildrops with different user names
and passwords, as well and local mail spools, MAPI servers, Qmail
spools and other animals.  We need a way to specify this.

2) Instead of the current model, where (basically) nnmail pushes *all*
the mail out the the first mail backend that happens to come alive, we
should have a way of saying "this mail goes to that backend, and that
mail to this backend".  Or rather, the mail backends should be able to
specify which mail they want to have incorporated into themselves.

Ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: future wishes - ACAP and LDAP support

[David Kågedal]

It would be nice to specify something like:

(setq nnmail-sources '(("/var/mail/davidk" . (nnfolder "mail"))
		       ("other source" . (another server))))

What is needed also is that when new news are fetched (with 'g' for
instance) the *first* mail group in every mail server that wants to be
updated should fetch mail for that server and update all groups, and
updating the rest of the groups in that server should be a no-op. As I
understand it, each of the mail groups today goes out to check for new
mail. That's slow.

-- 
David Kågedal     Lysator Academic Computer Society       davidk@lysator.liu.se
http://www.lysator.liu.se/~davidk/                              +46-13 17 65 89

Re: future wishes - ACAP and LDAP support

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> 1) A greater flexibility in specifying how mail is to be fetched.  For
> instance, you may have several POP maildrops with different user names
> and passwords, as well and local mail spools, MAPI servers, Qmail
> spools and other animals.  We need a way to specify this.

This is quite easy.  For instance, you can use VM's model for POP
specification:

    A POP maildrop specification has the following format:

       \"HOST:PORT:AUTH:USER:PASSWORD\"

    HOST is the host name of the POP server
    PORT is the TCP port number to connect to (should normally be 110).
    USER is the user name sent to the server.
    PASSWORD is the secret shared by you and the server for
    authentication purposes.  How is it used depends on the value of
    the AUTH parameter.  If the PASSWORD is \"*\", VM will prompt
    you for the password the first time you try to retrieve mail from
    maildrop.  If the password is valid, VM will not ask you for the
    password again during this Emacs session.

    AUTH is the authentication method used to convince the server you
    should have access to the maildrop.  Acceptable values are
    \"pass\", \"rpop\" and \"apop\".  For \"pass\", the PASSWORD is sent to
    the server with the POP PASS command.  For \"rpop\", the PASSWORD
    should be the string to be sent to the server via the RPOP
    command.  In this case the string is not really a secret;
    authentication is done by other means.  For \"apop\", an MD5 digest
    of the PASSWORD appended to the server timestamp will be sent to
    the server with the APOP command.  In order to use \"apop\" you
    will have to set the value of vm-pop-md5-program appropriately to
    point at the program that will generate the MD5 digest that VM
    needs.


Alternatively, we could make `nnmail-spool-file' be more than just a
list of strings, for instance:

(setq nnmail-spool-file '("/var/mail/hniksic"
                          (pop :host "regoc" :user "hniksic" :password "uhoh")
                          (mapi :host "fubar")
                          ...))

It would be backward-compatible, and straightforward to implement.
More or less, anyway.

Also, it should be renamed to something nicer, like
`nnmail-spool-methods', the old variable being just a varalias.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

Re: future wishes - ACAP and LDAP support

[Kim-Minh Kaplan]

>>>>> On October  4, 1997, Lars Magne Ingebrigtsen said:

Lars> 1) A greater flexibility in specifying how mail is to be
Lars> fetched.  For instance, you may have several POP maildrops with
Lars> different user names and passwords, as well and local mail
Lars> spools, MAPI servers, Qmail spools and other animals.  We need a
Lars> way to specify this.

I think something akin to select methods would be great :

(setq nnmail-spool-file
      '("/usr/spool/mail/kaplan"
        (nnmbox "/var/spool/mail/kaplan")
        (nnpop "kimminh.kaplan" "utopia.eunet.fr" "This is not my password")
        (nnmapi "user" "foo.bar.com")
        (nntp "news.server.fr" "newsgroup" "authentication key")))

We need someone to code this :-)

Kim-Minh.

Re: future wishes - ACAP and LDAP support

[Paul Franklin]

Lars asked for comments, so I figure I'll share mine.

Here's a more concrete proposal which builds on Hrvoje's ideas...
	(if I only had time to code)

nnmail-spool-methods becomes a server variable, containing a list of
methods.  We start with the following methods, so that implementing
spool methods isn't an issue yet:

* default (old behavior--chooses between simple & movemail)
* simple (emacs does everything itself)
* movemail (calls external movemail program)

	These all take the same string as nnmail-spool-file does,
		which defaults to the same things as nnmail-spool-file.
	Also, movemail can take a second string--a path to movemail.

* vmpop (calls vm's pop code, which many folks say works well)
	This one takes the same string that vmpop does.
		[Sidenote--does vmpop stash its password someplace
		secure after prompting for it?]

So I might have this in my nnml server definition:

	(nnmail-spool-methods
		(simple "~/Gnus/outgoing")
		(vmpop "pop.cs.washingon.edu:110:pass:paul:*"))

Then, of course, there's backwards compatibility.  I propose not
making things strictly backwards compatible, instead making things
work how novice users probably expect, and forcing expert users to
possibly do some work.  A server would only use nnmail-spool-file if
all of these apply for that server:

* The server is the first mail server in the list of
	(cons native-server secondary-servers)
* nnmail-get-new-mail is t
* nnmail-spool-file is well-defined
* nnmail-spool-methods is not defined

Then nnmail-get-new-mail would still default to t; people actually
using nnmail-spool-methods would normally set it to nil.

These restrictions would help people not shoot themselves in the foot
when they play around and add a second mail server.  (Hmm.
Non-native/secondary (editable) servers could notice if
nnmail-spool-methods is not defined, and ask whether it should be set
to nil or (default), to help out folks who create their first mail
server from the server buffer and want it to get new mail.  Did that
make sense?)

--Paul

Re: future wishes - ACAP and LDAP support

[Kai Grossjohann]

>>>>> On 04 Oct 1997, Lars Magne Ingebrigtsen said:

  Lars> 2) Instead of the current model, where (basically) nnmail
  Lars> pushes *all* the mail out the the first mail backend that
  Lars> happens to come alive, we should have a way of saying "this
  Lars> mail goes to that backend, and that mail to this backend".  Or
  Lars> rather, the mail backends should be able to specify which mail
  Lars> they want to have incorporated into themselves.

Are you talking about things that happen when the user types g in the
group buffer, or are you talking about things that happen when the
user is sending mail?

I assume the former.

Isn't there a form that uniquely identifies a group among all the
different servers (or select methods?) that exist?  Stuff like
"nnfoo+baux:bar"?  Couldn't that be used in nnmail-split-methods?  And
would it make sense to have the nnmail-use-procmail stuff use the same
names?  And default to the old server if the server spec isn't
present, as is true currently?

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: future wishes - ACAP and LDAP support

[Lars Magne Ingebrigtsen]

"David Kågedal" <davidk@lysator.liu.se> writes:

> It would be nice to specify something like:
> 
> (setq nnmail-sources '(("/var/mail/davidk" . (nnfolder "mail"))
> 		       ("other source" . (another server))))

I think I want to do it the other way around -- that is, there would
be a server variable that says which mailboxes to fetch for that
server.  `nnfolder-mail-sources', etc.

> What is needed also is that when new news are fetched (with 'g' for
> instance) the *first* mail group in every mail server that wants to be
> updated should fetch mail for that server and update all groups, and
> updating the rest of the groups in that server should be a no-op. As I
> understand it, each of the mail groups today goes out to check for new
> mail. That's slow.

But it doesn't do that any more.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: future wishes - ACAP and LDAP support

[Lars Magne Ingebrigtsen]

Paul Franklin <paul@cs.washington.edu> writes:

> So I might have this in my nnml server definition:
> 
> 	(nnmail-spool-methods
> 		(simple "~/Gnus/outgoing")
> 		(vmpop "pop.cs.washingon.edu:110:pass:paul:*"))

Yes, that's a good idea for a syntax.  Perhaps

(nnmail-spool-methods
 (mbox "~/Gnus/outgoing" :move-function "movemail")
 (pop :server "pop.cs.washingon.edu" :port 110 :password ask :user "paul"
      :protocol apop))

would be clearer, though.  It would be quite extendable, in any case. 

> Then, of course, there's backwards compatibility.  I propose not
> making things strictly backwards compatible, instead making things
> work how novice users probably expect, and forcing expert users to
> possibly do some work.  A server would only use nnmail-spool-file if
> all of these apply for that server:
> 
> * The server is the first mail server in the list of
> 	(cons native-server secondary-servers)
> * nnmail-get-new-mail is t
> * nnmail-spool-file is well-defined
> * nnmail-spool-methods is not defined

Hm.  I think `nnmail-spool-file' should override `nn*-spool-methods'
(or whatever).  So users with more complex needs would set
`nnmail-spool-file' to nil to use the server-specific spool methods.

`nnmail-spool-file' would be extended to support the new syntax,
though.

A related note -- setting server variables is kinda tricky at the
moment, so I think I'll add a setter function for these:

(nnoo-set SERVER VARIABLE VALUE)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: future wishes - ACAP and LDAP support

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.cs.uni-dortmund.de> writes:

> Isn't there a form that uniquely identifies a group among all the
> different servers (or select methods?) that exist?  Stuff like
> "nnfoo+baux:bar"?  Couldn't that be used in nnmail-split-methods?  And
> would it make sense to have the nnmail-use-procmail stuff use the same
> names?  And default to the old server if the server spec isn't
> present, as is true currently?

One could do it that way, but I think it will be more handy to do it
the other way.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen