Re: [Q] spooling from several sources

Re: [Q] spooling from several sources

[Jan Vroonhof]

The following message is a courtesy copy of an article
that has been posted as well.

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> > Is it possible to set up an nnml mail group to read mail from an nnmh
> > group, as well as its own mbox spool file.
> >
> > If eg. nnmh:mail.private normally read .procmail filtered email from
> > 	~/Mail/spool/mail.private.spool
> > is it possible to make it, in addition, pick up mail from
> > 	nnml:private
> > and then mark the picked up messages as read, and then expire this
> > folder.
> 
> Doing something like this would require quite a lot of work, I think.
> It kinda goes against the grain of what the mail backends usually do
> when splitting mail, so implementing this would be a pain.

I already tried to ask for the same feature on the ding list a while ago. But
you didn't understand what I meant then. Kai pointed me to the B r
respool command. The above would be equivalent to doing a

1. Enter group nnml:private 
2. process mark all new mail temporarily
3. setup the spilitting rules to put everything in nnmh:mail.private
4. "B r" respool all the message
5. restore the old splitting rules
6. leave nnml:private

So Gnus can already do this. The trick is only to automate it.

Jan

Re: [Q] spooling from several sources

[Paul Franklin]

First, 'B m' is identical to hacking split rules and doing 'B r' (I
think).  They share elisp functions inside of gnus.  Note though that
neither of these allow the original message to expire; it's expunged
immediately.

Hmm.  I'll throw out a design and see what people think..

I've wondered for a while if mail spools should really be specified as
server parameters instead of by variables.  To solve this problem,
spools could also be specified as group parameters.

Moreover, a new syntax for spools is needed, and there may need to be
some mini-backends for getting mail.  Spool specifications might look
like:
	file:/home/paul/maildrop   (is this the same as nnmbox: ?)
	movemail:/usr/spool/mail/paul
	nnmh:private
	popmail:rpop/paul@cs.washington.edu
	nnimap:paul@cs.washington.edu
The first two are just moving stuff around which already exists in
gnus.  The last two aren't implemented yet, although popmail could
call movemail with the magic POP filename syntax in the meantime.

Spools specified as server parameters would use the 'B r' code.
Spools specified as group parameters would use the 'B m' code.

Some interesting questions come up though.  This requires scanning all
groups to see if they have the appropriate spool parameter.  And there
probably need to be a few backends which only have the functions
needed to get mail, which means they're probably missing some of the
things currently listed as required.  (Can this be dealt with by
having a new class of backends called 'maildrop' to augment the
current 'mail' and 'news' backends?  I don't know.)

--Paul

Re: [Q] spooling from several sources

[Lars Magne Ingebrigtsen]

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

> Moreover, a new syntax for spools is needed, and there may need to be
> some mini-backends for getting mail.  Spool specifications might look
> like:
> 	file:/home/paul/maildrop   (is this the same as nnmbox: ?)
> 	movemail:/usr/spool/mail/paul
> 	nnmh:private
> 	popmail:rpop/paul@cs.washington.edu
> 	nnimap:paul@cs.washington.edu

Yes, a cleanup in the mail fetching department is needed, I think.
There's way too many odd variables at this point.

> Some interesting questions come up though.  This requires scanning all
> groups to see if they have the appropriate spool parameter.  And there
> probably need to be a few backends which only have the functions
> needed to get mail, which means they're probably missing some of the
> things currently listed as required.  (Can this be dealt with by
> having a new class of backends called 'maildrop' to augment the
> current 'mail' and 'news' backends?  I don't know.)

And you also have the interesting problem of having some mail going to
one backend, and other mail going to another backend.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: [Q] spooling from several sources

[Jan Vroonhof]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:


> 1. Enter group nnml:private 
> 2. process mark all new mail temporarily
> 3. setup the spilitting rules to put everything in nnmh:mail.private
> 4. "B r" respool all the message
> 5. restore the old splitting rules
> 6. leave nnml:private

Lars, you wrote that that the mail backends don't support this. That
isn't quite true. Not all do (nndir and nnvirtual unfortunately don't) 

I just "limit unread",-"mark all"-,-"move"-ed between two nnfolder
groups. So it can work.

I also was able to do the same but with copy between an nnvirtual and
nnfolder group. (Although the subjects were all lost :-( ).

Under the assumption that "Copy will work for most groups". What about
an a "Nuke" flag that would be something like a
expire-really-immediately.
Then where moving isn't possible we could "copy-and-set-nuke".
If a group is closed then the backend will try to do the sensible
thing (for instance the nnvirtual could pass on the
nuke, nndoc would do the same if all the messages in the nndoc
group were marked nuke, nnfolder will expire, nntp will mark as read etc.)

Jan

Re: [Q] spooling from several sources

[Scott Blachowicz]

[I missed/forgot some of the earlier messages in this thread, so I may be
 missing the point here, but...]

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

> Moreover, a new syntax for spools is needed, and there may need to be
> some mini-backends for getting mail.  Spool specifications might look
> like:
> 	file:/home/paul/maildrop   (is this the same as nnmbox: ?)
> 	movemail:/usr/spool/mail/paul
> 	nnmh:private
> 	popmail:rpop/paul@cs.washington.edu
> 	nnimap:paul@cs.washington.edu

Except that the last one (with IMAP) is really more analogous to a
"server" instead of a group. I'm not sure how relevant this is for the
current discussion, but IMAP lets you get at many folders and the
USER@HOSTNAME part is needed for all of them. The first 4 items really
specify a group where the nnimap spec refers to a server...the incoming
mail spool would typically be referred to as something like

    nnimap+paul@cs.washington.edu:INBOX

or some such where the USER, HOSTNAME are part of the server settings and
INBOX is the actual group name.  With pine, at least, I can also reference
my own mbox format folders with something like

    {mailhost}gnus-list

or MH folders with

    {mailhost}#mh/lists/gnus

Do any of those other mail spool types have that property?

I haven't gotten into group & server specifications much at all, so this
is probably already in the syntax (right?), but nnimap is pretty close to
nntp except that nnimap lets you write to groups.

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: [Q] spooling from several sources

[Usenet news]

m0vLw3O-0003wAC@main.statsci.com>
Mail-Copies-To: paul@cs.washington.edu
From: Paul Franklin <paul@cs.washington.edu>
Date: 08 Nov 1996 15:13:33 -0800
Message-ID: <r9qzq0sch9e.fsf@fester.cs.washington.edu>
Organization: Computer Science, U of Washington, Seattle, WA, USA
Lines: 38
X-Newsreader: Red Gnus v0.47/Emacs 19.34
Path: fester.cs.washington.edu
NNTP-Posting-Host: fester.cs.washington.edu

>>>>> Scott Blachowicz writes:

 >> Moreover, a new syntax for spools is needed, and there may need to be
 >> some mini-backends for getting mail.  Spool specifications might look
 >> like:
 >> 	file:/home/paul/maildrop   (is this the same as nnmbox: ?)
 >> 	movemail:/usr/spool/mail/paul
 >> 	nnmh:private
 >> 	popmail:rpop/paul@cs.washington.edu
 >> 	nnimap:paul@cs.washington.edu

 > Except that the last one (with IMAP) is really more analogous to a
 > "server" instead of a group.

 >     nnimap+paul@cs.washington.edu:INBOX

Yup.  I had intended INBOX to be the default, but your syntax is more
consistent with the rest of gnus.  I'm not sure if 'popmail' should be
made to look more like it or not.

 > or MH folders with

 >     {mailhost}#mh/lists/gnus

This is a property of your IMAP server, not of pine (your IMAP
client).  Pine stops parsing after the close brace.  Gnus merely has
to pass the '#' symbol on to the IMAP server and all will work as it
should.

The '#' character indicates a "namespace", which ends up being roughly
equivalent to a gnus server specification, although in practice, I
think you just get to name a backend (no server parameters or
address).  The example I found was of the form "#news.comp.arch.fpga".
Gee, so in the future, I will be able to read news in gnus via nntp,
or via IMAP (which might use either nntp or a news spool local to the
IMAP server).

--Paul

Re: [Q] spooling from several sources

[Scott Blachowicz]

>  >     {mailhost}#mh/lists/gnus
> 
> This is a property of your IMAP server, not of pine (your IMAP
> client).  Pine stops parsing after the close brace.  Gnus merely has
> to pass the '#' symbol on to the IMAP server and all will work as it
> should.

Also...doesn't IMAP handle the need for a password internally somehow? I
notice that if I have a /etc/rimapd on my server system and 'rsh' (or
'ssh' or whatever) lets me thru without a password, that pine doesn't ask
for one.  So, can gnus handle the need for a password dynamically? or
would it need to be specified as a setting for a specific gnus-server that
needs be specified "statically"?

> The '#' character indicates a "namespace", which ends up being roughly
> equivalent to a gnus server specification, although in practice, I
> think you just get to name a backend (no server parameters or
> address).  The example I found was of the form "#news.comp.arch.fpga".
> Gee, so in the future, I will be able to read news in gnus via nntp,
> or via IMAP (which might use either nntp or a news spool local to the
> IMAP server).

I dunno...that some seems kinda weird & twisted. I like it. :-))

This sounds kinda fun...

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: [Q] spooling from several sources

[Uwe Sigurd Valentin Kubosch]

Please unsubscribe me from this list.

Uwe
-- 
Uwe S.V. Kubosch       Milron Data          Crusaders Productions
Stavikbakken 3         Johan Svensensv. 2a  Stasjonsveien 56
N-1472 Fjellhamar      N-1472 Fjellhamar    N-2010 Strømmen
Norway                 Norway               Norway
Phone:+47 67 90 11 95  Phone:+47 6790 9524  Phone:+47 63 80 33 24
Phone:+47 92 20 60 46                       Phone:+47 63 80 00 53 (ISDN)
     Web:<http://www.ifi.uio.no/~uwek/>     Fax  :+47 63 80 00 54 (ISDN)
    Crusaders:<http://www.crusaders.no/>    BBS  :+47 22 10 46 46

Re: [Q] spooling from several sources

[Paul Franklin]

>>>>> Scott Blachowicz writes:

 > Also...doesn't IMAP handle the need for a password internally somehow? I
 > notice that if I have a /etc/rimapd on my server system and 'rsh' (or
 > 'ssh' or whatever) lets me thru without a password, that pine doesn't ask
 > for one.  So, can gnus handle the need for a password dynamically? or
 > would it need to be specified as a setting for a specific gnus-server that
 > needs be specified "statically"?

Pine does this by forking and execing 'rsh <host> /etc/rimapd'.  (Boy,
do I wish pop did this instead of RPOP, since RPOP requires movemail
to be setuid root.)  There are a bunch of other authentication methods
as well, but this one is probably the simplest.

--Paul