🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

4 total messages Started by lamy Thu, 27 Aug 1987 00:54
Re: X.400 ean mail system
#4353
Author: lamy
Date: Thu, 27 Aug 1987 00:54
44 lines
3058 bytes
In article <186@bernina.UUCP> wyle@ethz.UUCP (Mitchell Wyle) writes:
>The public domain, University of California Berkeley's (UCB) Unix mail
>system is not much better, but at least there is no "rebuild" command,
>and the files are standard unix text files.  One can use the Unix shell
>environment, the "mail-tool" interface on Suns, and the file directory
>tree to add structure to mail messages.  UCB Unix mail is programmable
>and richer in commands.  It is standard on many different machines, and
>identical on Suns and vaxen.  Most importantly, the data are
>interchangeable, and can be backed up!

UCB mail is not public domain, and it does not really mesh well with the Unix
directories (retrieving an individual message is a pain).  There is no
programmability either.  The mailtool on the Suns does not allow you to chose
which editor you want to edit the messages.  UCB mail is not screen oriented.
In fact, I must admit that I really don't give much credence to your claim
that UCB mail's interface is any richer than EAN's.  Yes, I have used both.

ELM will give you a screen oriented interface. If you want full
configurability, then use MH, from within an editor if you wish.  MH uses the
directory structure for folders and gives you a query facility to retrieve
messages.

In fact, there is no real reason either why you can't have the best of all
worlds.  This message is composed in a MH mode in GNU-emacs (with roughly the
same features as mailtool), will be processed by the standard Unix sendmail,
and may end up being sent by EAN, acting as a message transfer agent (we also
have connection to the Internet, UUCP and Bitnet). Getting EAN to
interface with other mailers can be a pain, but there is hope (this site
is a living proof that an interface with the standard Unix setup can be done,
and the VMS/EAN gatewaying seems to work fine as well),  In other words,
a little patience may be in order.

Wrt your comment about parse errors, note that even relay.cs.net
will complain about (hackish) addresses with a % in them.  I don't see
this as a problem with EAN.

I am not the greatest fan of X.400 mail (especially with respect to 
the proposed organization-oriented directory service), but I don't think
EAN is such a bad deal for a site with a single connection to the outside
world.

Jean-Francois Lamy                      lamy@ai.toronto.edu (CSnet,UUCP,Bitnet)
AI Group, Dept of Computer Science      lamy@ai.toronto.cdn (EAN X.400)
University of Toronto, Canada M5S 1A4   {seismo,watmath}!ai.toronto.edu!lamy
Re: MH (was X.400 ean mail system)
#4356
Author: wayne
Date: Tue, 01 Sep 1987 00:14
18 lines
1605 bytes
In article <8708270054.AA02979@ephemeral.ai.toronto.edu> lamy@ai.toronto.edu (Jean-Francois Lamy) writes:

>In fact, there is no real reason either why you can't have the best of all
>worlds.  This message is composed in a MH mode in GNU-emacs (with roughly the
>same features as mailtool), will be processed by the standard Unix sendmail,
						      ^^^^^^^
Right.  "Standard" if you have BSD.  What about all the poor suckers out
there that have System V (like me)?  We end up with a broken mailer that
taunts us with wonderful promises but fails to deliver (pun intended).
Why can't Rand/UCI/someone make MH run without depending on sendmail (on
top of smail, for example)?  Trying to run on a SysV box without sendmail
is pure hell.  If anything else came close, I would switch immediately
but I'm spoiled by the parts that do work.


-- 
Michael R. Wayne   ***   TMC & Associates   ***  Arpa: wayne@ford-vax.arpa
uucp: {philabs | pyramid} !fmsrl7!wayne   OR   wayne@fmsrl7.UUCP
Mail User's Shell
#4367
Author: Bill Wohler
Date: Sat, 05 Sep 1987 20:53
58 lines
3889 bytes
In article <1700@fmsrl7.UUCP>, wayne@fmsrl7.UUCP (//ichael R. //ayne) writes:
> In article <8708270054.AA02979@ephemeral.ai.toronto.edu> lamy@ai.toronto.edu (Jean-Francois Lamy) writes:
> 
> >In fact, there is no real reason either why you can't have the best of all
> >worlds.  This message is composed in a MH mode in GNU-emacs (with roughly the
> >same features as mailtool), will be processed by the standard Unix sendmail,
> 						      ^^^^^^^
> Right.  "Standard" if you have BSD.  What about all the poor suckers out
> there that have System V (like me)?  We end up with a broken mailer that
> taunts us with wonderful promises but fails to deliver (pun intended).

(Using a friend's account -- please don't respond to this account; respond to
 island!argv@sun.com)

may I suggest "mush" -- the Mail User's Shell.  It is in queue to be posted
on comp.sources.unix, but who knows what's happened ...

anyway, I wrote this mailer and many of you might find it useful.  It
can run under sendmail, delivermail, execmail, smail ... I haven't seen
it run on anything else.  I mention this mailer here because I've seen a lot
of discussion lately on user interfaces being unacceptable or a general
desire to "have the best of all worlds."

I'm not claiming that my mailer is better than MH or Elm -- but if you're
frustrated with whatever you're running (Especially ucb-Mail or sun's
mail/mailtool) give mush a try and see what you think.

On sun's, it'll run in tool-mode under 2.0 and up (mailtool only runs 3.0+)
and is fully compatible with sun's mailer and ucb-Mail.  This interface is
only available on suns, but other computers running many flavors of unix
can successfully use mush's other two interfaces.

The screen oriented interface that has 'vi' style pattern searches and screen
movement between messages.  curses based commands are editable and function
keys or other key sequences may be bound to mail commands.

The line mode (which requires no terminal capabilities at all) is like 'csh'
in that you can create command line aliases, supports a subset of csh-style
command history reference and pattern matching, and has a piping mechanism
allowing you to pipe mail commands to one another.

More functions include sorting messages (plus subsorting), automatic
forwarding, filtering scripts, and unix command access without having
to fork a shell. If new mail comes in while you're in a mail session,
it is automatically appended to the end of your folder so you don't have
to update your mailbox or exit and re-enter mail just to read it.

There is much more than I have room to discuss here, but I thought I would
announce it's availability to those who wish to use it. You can get a copy
from anonymous ftp at spam.istc.src.com in ~ftp/pub/mush/mush.tar-5.6.Z

It _should_ be posted officially as soon as ... well, as soon as it happens :-)
I have no usenet access, so I can't followup to this article if any 
discussion is generated.  However, please feel free to mail me at the address
posted above.  Sorry, I can *not* send source via uucp at this time. This
restriction is indefinite at the moment.  If you do not have arpanet access
to obtain the sources yourself, I request you find someone on the net who
can uucp the source for you.
Re: MH (was X.400 ean mail system)
#4377
Author: Leonard H. Tower Jr.
Date: Thu, 10 Sep 1987 17:50
91 lines
5523 bytes
In article <1700@fmsrl7.UUCP> wayne@fmsrl7.UUCP (Michael R. Wayne) writes:
 > In article <8708270054.AA02979@ephemeral.ai.toronto.edu>
 > lamy@ai.toronto.edu (Jean-Francois Lamy) writes:
 > 
 > >In fact, there is no real reason either why you can't have the best of all
 > >worlds.  This message is composed in a MH mode in GNU-emacs (with roughly
 > >the same features as mailtool), 
 > >will be processed by the standard Unix sendmail,
 > 			      ^^^^^^^
 > Right.  "Standard" if you have BSD.  What about all the poor suckers out
 > there that have System V (like me)?  We end up with a broken mailer that
 > taunts us with wonderful promises but fails to deliver (pun intended).
 > Why can't Rand/UCI/someone make MH run without depending on sendmail (on
 > top of smail, for example)?  Trying to run on a SysV box without sendmail
 > is pure hell.  If anything else came close, I would switch immediately
 > but I'm spoiled by the parts that do work.

GNU Emacs has another mail front end: rmail-mode.  The *Help* buffer
for the mode is appended.  rmail-mode is in the babyl family of
mailers.  It has many user settable variables, understand's
/usr/ucb/Mail's ~/.mailrc aliases and it's very customizable (as it's
almost entirely coded in GNU Emacs Lisp, and you get full source
code).  Its can be installed to work on both BSD and SysV systems, and
could easily be made to work with other mail delivery and/or operating
systems {assuming GNU Emacs is ported already ;-}.

To get info on how to obtain GNU Emacs and the GNU Project ask:
	<gnu@prep.ai.mit.edu>

enjoy -len
======================================================================
RMAIL Mode:
Rmail Mode is used by M-x rmail for editing Rmail files.
All normal editing commands are turned off.
Instead, these commands are available:

.	Move point to front of this message (same as ESC <).
SPC	Scroll to next screen of this message.
DEL	Scroll to previous screen of this message.
n	Move to Next non-deleted message.
p	Move to Previous non-deleted message.
M-n	Move to Next message whether deleted or not.
M-p	Move to Previous message whether deleted or not.
>	Move to the last message in Rmail file.
j	Jump to message specified by numeric position in file.
M-s	Search for string and show message it is found in.
d	Delete this message, move to next nondeleted.
C-d	Delete this message, move to previous nondeleted.
u	Undelete message.  Tries current message, then earlier messages
	till a deleted message is found.
e	Expunge deleted messages.
s	Expunge and save the file.
q       Quit Rmail: expunge, save, then switch to another buffer.
C-x C-s Save without expunging.
g	Move new mail from system spool directory or mbox into this file.
m	Mail a message (same as C-x 4 m).
c	Continue composing outgoing message started before.
r	Reply to this message.  Like m but initializes some fields.
f	Forward this message to another user.
o       Output this message to an Rmail file (append it).
C-o	Output this message to a Unix-format mail file (append it).
i	Input Rmail file.  Run Rmail on that file.
a	Add label to message.  It will be displayed in the mode line.
k	Kill label.  Remove a label from current message.
C-M-n   Move to Next message with specified label
          (label defaults to last one specified).
          Standard labels: filed, unseen, answered, forwarded, deleted.
          Any other label is present only if you add it with `a'.
C-M-p   Move to Previous message with specified label
C-M-h	Show headers buffer, with a one line summary of each message.
C-M-l	Like h only just messages with particular label(s) are summarized.
C-M-r   Like h only just messages with particular recipient(s) are summarized.
t	Toggle header, show Rmail header if unformatted or vice versa.
w	Edit the current message.  C-c C-c to return to Rmail.
======================================================================
Mail Mode:
Major mode for editing mail to be sent.
Like Text Mode but with these additional commands:
C-c C-s  mail-send (send the message)    C-c C-c  mail-send-and-exit
C-c C-f  move to a header field (and create it if there isn't):
	 C-c C-f C-t  move to To:	C-c C-f C-s  move to Subj:
	 C-c C-f C-b  move to BCC:	C-c C-f C-c  move to CC:
C-c C-w  mail-signature (insert ~/.signature at end).
C-c C-y  mail-yank-original (insert current message, in Rmail).
C-c C-q  mail-fill-yanked-message (fill what was yanked).
-- 
Len Tower, Distributed Systems Group, Boston University,
     111 Cummington Street, Boston, MA  02215, USA +1 (617) 353-2780
Home: 36 Porter Street, Somerville, MA  02143, USA +1 (617) 623-7739
UUCP: {}!harvard!bu-cs!tower		INTERNET:   tower@bu-cs.bu.edu
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads