🚀 go-pugleaf

Mitchell Wyle writes an interesting article about why he doesn't use
the EAN X.400 mail system from the University of British Columbia in
this group.  I'd like to discuss some of the points he raises a bit
further...

First off, I think it is important to note that X.400 and the related
ISO/CCITT standards are indeed an up and coming standard for the 
interchange of electronic mail in the world (certainly in Europe).  In
fact sources from both DEC, HP, and some third party market analysts
tell me that it is almost impossible to sell any large computer boxes
to firms there unless they have available an X.400 mail system...

In an environment of that nature, it is somewhat ironic to read that
a sophisticated, knowledgeable Unix user like Mitchell decides to use
something as simple as the Berkeley Mail system instead of the EAN
package.  My first curious question is how long will Mitchell be able
to use Berkeley Mail to send and receive mail there in Switzerland?  I
can imagine in the very near future his machine suddenly not speaking
the "RFC-822 style" mail that Berkeley Mail expects and generates.  Or,
as an alternative, having the extra overhead of a gateway/translator
for each message sent, even those local to his machine.  

Note that I haven't made any comments about the relative merits of the
X.400 protocol suite/standard nor of the RFC-822 (and related documents)
standard either.  The tough fact of the matter is that it is almost
completely irrelevant whether we like the standard or not - X.400 is
happening now regardless.  There are already countries where, as I said
previously, you *cannot* sell machines unless you offer a complete X.400
system.  (interestingly, the best selling X.400 package, All-In-One from
Digital Equipment Corporation, currently has a number of blatant protocol
violations on its lower-level interactions with other X.400 systems (but
we can be sure that DEC is working like mad to fix that as soon as they
possibly can!))

This is not to make light of the problems of an electronic mail package
user interface!  From dint of the experiences with not only the Msg and
Elm mail packages, but from the research I've put in on various articles
on electronic mail systems (the latest being in the book "The Unix Papers"
from Howard and Sams Publishing...) I've found that perhaps the *most*
important aspect of any system, and especially a system like one for the
creation, transmission and reception of electronic mail, is in fact the
user interface.

So with that preamble, I'd like to highlight the deficient areas of the
EAN package, based *purely* on what Mitchell Wyle posted in his article.

The first problem that is raised is that of the data storage method.  Not
only does EAN use a unique format for the storage of data (which, I would
venture a guess, is related to X.408 (MHS: Encoded Information Type
Conversion Rules) and X.409 (MHS: Presentation Transfer Syntax and Notation)
standards if nothing else..) and that a side effect of this is that 1. the
folder space is one-level deep (e.g. there is no capability for having 
folders within other folders), 2. the utilities that are available for
keeping your dataspace clean aren't totally reliable (e.g. "eanrebuild"),
and 3. EAN didn't like the data that was restored from a backup tape.

One of the stranger aspects of the X.400 suite from our anglocentric
point of view here in the US is that it doesn't store everything in an
English-based format.  In fact, the method by which the message
envelope (as they say) is built up and saved is designed to be as
*in*dependant of host language as possible.  One of the 'headers' of
an X.400 message is in fact the language that it was composed in, so
that the displaying system can easily choose the appropriate character
set.  An obvious side effect of this is that the data storage format
for the messages cannot suddenly be in a different, '822 style, format.
So instead, you're left with the necessity of having to use various
utilities to help maintain your data space.

Given that, I would suspect that the EAN group would be more than just
interested in hearing about problems with the reliability of their 
system!  Certainly if you can fully describe the situation whereby
the "eanrebuild" program destroyed your saved messages it would at least
be a big help in ensuring that they can fix it and make sure it doesn't
happen to other people!   And as to the problem with data off of a backup
tape, I suspect that it is a subtle problem with file modification times
or something, and that, again, if you were to *tell* the EAN people
about the situation they would quickly remedy it.

[general philosophical comment here: I find it unfortunate that so many
 people aren't willing to work with their software vendors in situations
 such as this - software is just like any other complex system and it
 occasionally needs some fine tuning.  But there is *no* way for the 
 intrepid vendor to achieve this if the users have something go wrong
 then simple stop using the product, instead of letting 'em know about
 it!  Let's get on the ball, people!]

Mitchell then goes on to talk about some aspects of the User Interface
to the EAN X.400 mail system.  Specifically, he states that a couple of
the problems he has are that; 1. there is no way to specify rules and
actions and otherwise make it a programmable interface,  2. there is
no way to have multi-level folders,  3. it doesn't exploit the additional
resource of the CRT *screen*,  and 4. it has no intelligent retrieval 
system for archived messages.

I must admit that I'm not sure exactly what Mitchell is talking about
in his first point here - I have on my machine a program which 'screens'
my electronic mail before allowing it to be delivered to me, and it can
reply to mail automatically, store it in folders for later perusal, 
or even instantly display it to the screen.  But that is one of only
three systems that I know of that offer this sort of functionality
and none of them are in widespread use (they are "filter", from the
Elm Mail System, "mh-hook" from the MH package, and MEP from John
Antypas).   I'm very interested in hearing more about what is being
suggested here (and shan't bias it by talking about how *I* think
mail systems should work!)

The problem with multi-level folders, and the related problem of
not having an intelligent retrieval system are actually symptomatic
of a much larger problem with generalized information retrieval
systems.  I believe that the *real* answer to this is to have a
hypertext system available and to obsolete the entire idea of
folders.  I know of a couple of systems in the works that support
just this, and I imagine now that Apple has released HyperCard for
the Macintosh that it's just a matter of time before some bright
cookie exploits that for the same area.  The idea here would be
to specify a list of criteria to base selection of possible 
messages on - sort of like full-text keywording - and then have
the system select messages based on that.  (I think this is really
the wave of the future and I'm looking forward to having it on
MY machine soon!)

As to the EAN interface not exploiting the resources and space of
the CRT screen, well, all I can say is that Andrew Draskoy of the
University of British Columbia and I have talked a couple of times
about full-screen interfaces for the EAN system and that he has
recently requested a copy of the Elm Mail System from me for some
ideas of how to exploit a full screen and still retain the ease of
use of a simple system...I wouldn't be suprised to see them release
an impressive and powerful new interface to their system within a
year.

By the way, Mitchell also refers to the Berkeley Mail package as being
"in the public domain".  This, of course, is not the case at all, and
the package is in fact covered under the same copyright and licensing
restrictions as the rest of the BSD binaries and sources.

Finally, I hope those of you that have managed to read this far have
found this an informative note.  I would like to hear further discussion
on electronic mail user interfaces and shall be forwarding the comments
as appropriate to interested other parties.  (there are also a number
of mailing lists dealing with mail user agents, mail handling systems,
the X.400 protocol suite, and so on - check the "list of lists" that
sporadically appears on the net...)

			From the far corners of the globe,

					-- Dave Taylor
					Hewlett-Packard Labs

Mitchell Wyle comments:
| ....  Because ean uses a
| bizarre method of storing its data (db5), one must periodically "clean"
| the data files ean creates.  Otherwise, they would continue to grow
| without bound, until the disk is full.  One day, the  "eanrebuild"
| command destroyed all of my ean data...

Dave Taylor replies:
| The first problem that is raised is that of the data storage method.  Not
| only does EAN use a unique format for the storage of data ...
| An obvious side effect of this is that the data storage format
| for the messages cannot suddenly be in a different, '822 style, format.
| So instead, you're left with the necessity of having to use various
| utilities to help maintain your data space.

  I think that dave has a misconception here: X.400 defines a format
for the contents of a file which constitutes {message*}.  This format
is very non-ascii and not fully convertable to RFC 822 ascii.  It does
not, as I read the specification (which is not fully convertable to a
human language), require the storage of the messages in a file or file
sequence that is not manipulatable with more-or-less normal system
tools.  The use of db5, if true, is a decisision made by the ean
developers, and appears to have caused a problem...

 --dave (i think i like the format, but i can't read the spec) cb

-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

	MH is a fabulous mail handling system if you get lots of mail.
Having used it, I find other mailers intolerable (elm is particularly
infuriating).  Unfortunately, the developers REALLY want you to run
sendmail as a transport agent.  The documentation claims that MH can run
without it but it doesn't really work.  If only MH could use smail as
a transport agent, things would be much simpler but I haven't heard much
going on along those lines.
	If you are on a BSD machine and you get a lot of mail, try MH.
If you are on a System V machine and you have sendmail, contact me (I
want it BAAAD) and get MH.  If you are stuck with System V and no sendmail,
it might still be worthwhile but it's a lot of headaches.
-- 
Michael R. Wayne   ***   TMC & Associates   ***  Arpa: wayne@ford-vax.arpa
uucp: {philabs | pyramid} !fmsrl7!wayne   OR   wayne@fmsrl7.UUCP

In article <1518@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes:
> 
> 	MH is a fabulous mail handling system if you get lots of mail.
> Having used it, I find other mailers intolerable (elm is particularly
> infuriating).

I think Dave Taylor's comments should apply here also.  If you dislike
the way a given piece of software runs (as it appears you do), please also
include some description of what it is you dislike about the software, and
if possible, some suggestions for the improvement of that software.  There
are a lot of folks running elm and from what I have heard, most are quite
happy with it.  As with most software, there is probably some room for 
improvement, but the best way that the developers (or maintainers) can
decide what to improve, they many times rely on constructive feedback from
the user community.

>                Unfortunately, the developers REALLY want you to run
> sendmail as a transport agent.  The documentation claims that MH can run
> without it but it doesn't really work.

I have heard that it also works quite well with mmdf.  Anyone running this
wish to comment???

> 	If you are on a BSD machine and you get a lot of mail, try MH.
> If you are on a System V machine and you have sendmail, contact me (I
> want it BAAAD) and get MH.

If you have access to the arpanet, there is a copy of the sendmail sources
on one of the Berkeley machines.

Tim Kehres
Control Data Corporation / Lawrence Livermore National Laboratory
-----------------------------------------------------------------
UUCP: {ames,ihnp4!ptsfa}!lll-tis!kehres
ARPA: kehres@lll-tis.ARPA
AT&T: (415) 463-6852

In article <719@hplabsz.HPL.HP.COM> taylor@hplabsz.UUCP (Dave Taylor) writes:
: First off, I think it is important to note that X.400 and the related
: ISO/CCITT standards are indeed an up and coming standard for the 
: interchange of electronic mail in the world (certainly in Europe).  In
: fact sources from both DEC, HP, and some third party market analysts
: tell me that it is almost impossible to sell any large computer boxes
: to firms there unless they have available an X.400 mail system...

Espacially interesting is: X.400 is the prot of the administrations. Those
"official" Mailboxsystems use X.400 and will gateway to others. If a host
wants to paricipate the commercial networks beeing established, it has to
to it by using X.400.

: 
: One of the stranger aspects of the X.400 suite from our anglocentric
: point of view here in the US is that it doesn't store everything in an
: English-based format. [...]
 
What means "stranger aspects? There are countries with users, who don't
speak English . So an language indepent Prot has its merits.

: 
: [general philosophical comment here: I find it unfortunate that so many
:  people aren't willing to work with their software vendors in situations
:  such as this - software is just like any other complex system and it
:  occasionally needs some fine tuning.  But there is *no* way for the 
:  intrepid vendor to achieve this if the users have something go wrong
:  then simple stop using the product, instead of letting 'em know about
:  it!  Let's get on the ball, people!]
: 

Stands for itself, just repeated to be kept in mind!

: 
: 					-- Dave Taylor
: 					Hewlett-Packard Labs

Trying to get hand on X.400 Software for UN*X I was given the address
of Sidney International. Contacting them resulted in the following
information: Source License Pound Sterling 250,000, Binary 5,000! Just
for an mailing system ... :-)

                                Rupert Mohr
                                RMI Aachen

In article <719@hplabsz.HPL.HP.COM> taylor@hplabsz.UUCP (Dave Taylor) writes:

>First off, I think it is important to note that X.400 and the related
>ISO/CCITT standards are indeed an up and coming standard for the 
>interchange of electronic mail in the world (certainly in Europe).  In
>fact sources from both DEC, HP, and some third party market analysts
>tell me that it is almost impossible to sell any large computer boxes
>to firms there unless they have available an X.400 mail system...

To this I agree, the X.400 protocols are quiet nice. Unfortunately the
group here responsible for maintaining the ean mail system repeatedly
tell me "the EAN implementation of the x.400 protocol package is a heap
of sh*t".

I manage the mail and wide area network for the machine Mitchel Wyle's
mail goes through. This machine has 4 gateways to disparate networks
(uucp, cipon, ean and ACSnet) and sometimes (depending on the weather)
acts as the ean-csnet gateway. ACSnet runs itself and tells me what
it's been doing once a month (it suports remote job execution, binary
transfer (on 7bit, 8bit and x25 lines), file server, remote printing,
and acts as an inter network gateway) all the others require work.

All the machines in a cluster of ~40 run uucp (over ethernet) as the
transport level with the  upas mail system (Bell Labs) doing the
routing and acting as a name server.

Running on top of that we have a modified /bin/mail, ucb/mail, mh and
sun's mailtool interface to /ucb/mail there are also a gagle of emacs
based mail programs and Mail (if anyone remembers that antique).

On the gateway machine we also have ean running. I don't administer ean
and frankly wish it would go away. I have used the system and gave up
after many complaints from correspondants who got tired of "auto
forwarding" as the non-delivery reason in the bounce messages they
received.

It also appears that there is no way in ean to do any of the usefull
mail filtering things that make email usefull in administering
machines.  I say apparently because the only documentation available is
the online help from inside the ean system, there is no machine manual
and no paper manual available to users of the system and I doubt it is
available to the administrators.

>package.  My first curious question is how long will Mitchell be able
>to use Berkeley Mail to send and receive mail there in Switzerland?  I
>can imagine in the very near future his machine suddenly not speaking
>the "RFC-822 style" mail that Berkeley Mail expects and generates.  Or,
>as an alternative, having the extra overhead of a gateway/translator
>for each message sent, even those local to his machine.  

Yes the ean-isation of Switzerland is well underway. It's a pity they
couldnt be bothered to develope their own x400 system instead of
importing a bad one from Canada.  I am also not really worried about
the translation time, I simply want a mail system that works. Most
sites understand either rfc-822 or uucp mail headers, we provide both.
We have no trouble gatewaying into ean with our rfc-822 headers.
Unfortunately the ean system can't even provide a from address to our
mailer so it can correctly set the from fields on mail coming from ean
into uucp/rfc-822. I have also been told that on the next release of
ean they will provide a date field in the header. A great leap
forward.

>standard either.  The tough fact of the matter is that it is almost
>completely irrelevant whether we like the standard or not - X.400 is
>happening now regardless.  There are already countries where, as I said
>previously, you *cannot* sell machines unless you offer a complete X.400

The point is the ean implementation of x.400, not x.400 itself. Could you
please supply some proof for your claim about x400 and computer sales.

>So with that preamble, I'd like to highlight the deficient areas of the
>EAN package, based *purely* on what Mitchell Wyle posted in his article.

Have you ever tried to use the ean package. If not I sugest you try to get
access to an ean system and see how it feels. (give me a call and I will
give you our modem number).

>The first problem that is raised is that of the data storage method.  Not
>only does EAN use a unique format for the storage of data (which, I would
>venture a guess, is related to X.408 (MHS: Encoded Information Type
>Conversion Rules) and X.409 (MHS: Presentation Transfer Syntax and Notation)
>standards if nothing else..) 

No it's because ean seems to use the cheap nasty dbm data base that comes
with 4.2 with the result that the files it creates can't be manipulated
with standard unix comands. Still I supose popple live with the Itallian
postal service (average delivery speed 6 m.p.h. and a nasty habit of
shreading the mail backlog.

>One of the stranger aspects of the X.400 suite from our anglocentric
>point of view here in the US is that it doesn't store everything in an
>English-based format.  In fact, the method by which the message
>envelope (as they say) is built up and saved is designed to be as
>*in*dependant of host language as possible.  One of the 'headers' of
>an X.400 message is in fact the language that it was composed in, so
>that the displaying system can easily choose the appropriate character
>set.  An obvious side effect of this is that the data storage format
>for the messages cannot suddenly be in a different, '822 style, format.
>So instead, you're left with the necessity of having to use various
>utilities to help maintain your data space.

All very interesting, if you could rely on your data base the it might
even work. If you could rely on your communication medium there would be no
need for uuencode/decode, binhex and innumerable other programs that
convert binary into ascii and back and you would be much further towards a
usable "communications" system. I think the reliable communication system
would bring you a lot more than selecting the language style in the mail
header.

>Given that, I would suspect that the EAN group would be more than just
>interested in hearing about problems with the reliability of their 
>system!

They already know of the problems, see my earlier quote about their summary
of the system.

> people aren't willing to work with their software vendors in situations
> such as this 

It's a little hard when the software vendor is a University on the
other side of the Atlantic and the people who developed th code have long
since graduated and moved on. 

I refer you to another article in this news
group about a commercial x400 system, source lisence only 250,000
pounds sterling. Per cpu lisence only 5000 pounds.

Summary:
There is nothing wrong with the x.400 protocols. It would be good if they
become a european standard.

The currently available x-400 implementations stink.

I would love to hear somone from the University of British Columbia defend
their system.

Ean appears to lack:
	. adequate documentation for users,
	. support for mail filtering,
	. methods of turning off stupidities (like auto forwarding as a
		non delivery reason)
	. alternate presentation system (you get the ean presentation
		system and thats all)
	. support for file transfer and remote execution which where there
		in the most primative uucp mail systems

Peter Beadle
uucp		peter@eiger.uucp
ean/csnet	peter@ifi.ethz.ch (try this one for a non 
					delivery bounce message)
uucp		mcvax!cernvax!ethz!eiger!peter
acsnet		peter@bernina.ch

Peter, just one point:
I don't think that I will try to defend the old ean version that we are
running here (got, that, John :-)) but I would wish that everybody would
document software in the way ubc did it for ean. The user documentation
is very good (there is a seperate documentation for VMS managers, Unix-
managers and simple users, there are least two quick reference cards
and we added a whole bunch of additonal information (including a
telephone hotline service and the like). In addition, a large ammount
of documentation is available on an online basis, so there is really no
reason for complaining about the documentation.

We all agree that EAN V1 has some major disadvantages but I think that 
all the people that now tend to flame ean should have
	a) spoken up earlier
	b) spoken up in a more usable fashion
	c) directed their complaints to ubc

	--Hannes

-- 
~ UUCP/Usenet   :   {known world}!seismo!mcvax!cernvax!ethz!lubich
~ CSNET         :   lubich%ifi.ethz.chunet@relay.cs.net
~ ARPA          :   lubich%ifi.ethz.chunet@csnet-relay.arpa                
The usual disclaimer : No, it wasn't me, somebody must have used my account.

Rupert Mohr replies to my comments about EAN and X.400 with some interesting
comments of his own, but at one place he misses my point entirely, alas:

>: One of the stranger aspects of the X.400 suite from our anglocentric
>: point of view here in the US is that it doesn't store everything in an
>: English-based format. [...]
> 
>What means "stranger aspects? There are countries with users, who don't
>speak English . So an language indepent Prot[ocol spec] has its merits.

I think the problem here is with the word 'anglocentric'.  I used it to
mean 'centered on the anglo/english-speaking world'.  The comment was
more to the effect of 'it is unfortunate that here in the US we're so
convinced in the ultimate value of English that we, for the most part,
view any system that is to support other languages by *not* being in
English as suspicious' (althought that isn't much clearer either!!)

In general I think that X.400 is a good thing (are we going to start
talking about the value of X.400 here??) and that since it specifies
a non-ascii-based message envelope it makes the most sense for the
messages to also be stored in that format.  (a strong case can be made
that it should be translated to the local language upon storage, though,
and I'd be interested in hearing peoples ideas on this either way...)

As I've tried to say too, however, the Unix system especially is
very much oriented around having 'flat' ASCII files and there are 
a plethora of useful and interesting tools that you can then use to
wreak havoc on these text files.  Storing X.400 mailboxes as non-ASCII
data unfortunately loses this major Unix advantage, and the X.400
vendor is then put in the position of offering their own tools to
replace and/or supplement the already-built-and-tested Unix ASCII
tools...

		six of one, half-dozen of the other....

						-- Dave Taylor
						   Hewlett-Packard Labs

In article <21683@lll-tis.arpa> kehres@lll-tis.arpa (Tim Kehres) writes:
>In article <1518@fmsrl7.UUCP> wayne@fmsrl7.UUCP(/\/\ichael R. \/\/ayne) writes:
>> 
>> 	MH is a fabulous mail handling system if you get lots of mail.
>> Having used it, I find other mailers intolerable (elm is particularly
>> infuriating).
>
>I think Dave Taylor's comments should apply here also.  If you dislike
>the way a given piece of software runs (as it appears you do), please also
>include some description of what it is you dislike about the software, and
>if possible, some suggestions for the improvement of that software.  There
>are a lot of folks running elm and from what I have heard, most are quite
>happy with it.  As with most software, there is probably some room for 
>improvement, but the best way that the developers (or maintainers) can
>decide what to improve, they many times rely on constructive feedback from
>the user community.

	Although I could probably write a 25 page response to this, it
would be useless.  The elm manual even suggests that MH is preferred if
you recieve a lot of mail (in the section discussing other mailers).  This
implies that the author is already familiar with MH, knows it's advantages
and chose not to implement them.
	I suppose that I should mention a few specific complaints.  Elm
likes to use 1 file to hold a folder, MH uses a directory (like news).
Loading a 850K folder(my inbox, for example) with elm takes a LONG
time.  Elm believes in "hiding" the header info from the user when
composing a message, assuming that you typed it in correctly when you
started.  No recursive folders (without directories, this would be
difficult), no filters (without sendmail), alias list is VERY limited
(I tried to set up a simple, 25 person mailing list and it choked), 
minimal message manipulation commands (like, how do I link, not copy,
a message into two folders?).
	In summary, elm is fine if you only get a few messages per day.
For those people who get 250+ messages over a weekend, however, it just
doesn't make it.  On a vanilla SysV box, with the 1 meg file limitation,
folders become useless real fast.  I do like the "answering service" 
feature though, I suspect that this could be implemented in MH but have
not tried.

>>                Unfortunately, the developers REALLY want you to run
>> sendmail as a transport agent.  The documentation claims that MH can run
>> without it but it doesn't really work.
>
>I have heard that it also works quite well with mmdf.  Anyone running this
>wish to comment???

	The MH installation guide suggests the following:

	sendmail - best 
	mmdf     - OK
	standalone (ie MH as a transport layer) - not recommneded

>> 	If you are on a BSD machine and you get a lot of mail, try MH.
>> If you are on a System V machine and you have sendmail, contact me (I
>> want it BAAAD) and get MH.
>
>If you have access to the arpanet, there is a copy of the sendmail sources
>on one of the Berkeley machines.

	I have source to sendmail, but it does not compile on either of my
machines and I have not had the time to really dig into it.  I have
repeatedly posted requests for sendmail running on SysV.  The only
thing I have gotten back is a LOT of requests from other people that
want it too (looks like a common problem).  One person
(mcvax!eiger!peter@uunet) sent me a shell script which is supposed to
"replace" sendmail.  I have not managed to get it to work for me,
however (although I'm still working on it).
-- 
Michael R. Wayne   ***   TMC & Associates   ***  Arpa: wayne@ford-vax.arpa
uucp: {philabs | pyramid} !fmsrl7!wayne   OR   wayne@fmsrl7.UUCP

In article <1866@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes:
>In article <21683@lll-tis.arpa> kehres@lll-tis.arpa (Tim Kehres) writes:
>>In article <1518@fmsrl7.UUCP> wayne@fmsrl7.UUCP(/\/\ichael R. \/\/ayne) writes:
>>> 
>>> 	MH is a fabulous mail handling system if you get lots of mail.

I really must agree.  The flexibility and tailorability possible is the single
most appreciated element of MH to me.

>>I have heard that it also works quite well with mmdf.  Anyone running this
>>wish to comment???
>
>	The MH installation guide suggests the following:
>
>	sendmail - best 
>	mmdf     - OK
>	standalone (ie MH as a transport layer) - not recommneded

I have never quite understood this.  I run MMDF at our site, and have used
MH since version 5 (2 1/2 years or so ago).  I think that originally the
developer/maintainer of MH was particularly familiar with MMDF and that is
where that comment came from.  The interactions with MMDF's submit process
are not exactly obvious.  Actually, if you let MMDF post mail via SMTP
(even on the local host) I don't think it matters much what your transport
system is.  This is all just my opinion, of course.

Jim <Galvin@udel.edu>
-- 
James M Galvin

In article <1866@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes:
>In article <21683@lll-tis.arpa> kehres@lll-tis.arpa (Tim Kehres) writes:
>>In article <1518@fmsrl7.UUCP> wayne@fmsrl7.UUCP(/\/\ichael R. \/\/ayne) writes:
>	I suppose that I should mention a few specific complaints.  Elm
.....
>difficult), no filters (without sendmail), alias list is VERY limited

Filter works well if you have smail with the mod's to support mail to pipes
(also known as the "Full Name mod's").

>(I tried to set up a simple, 25 person mailing list and it choked), 

Same mods to smail also handles mailing lists fine.


-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532

In article <1866@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes:
>>If you have access to the arpanet, there is a copy of the sendmail sources
>>on one of the Berkeley machines.
>	I have source to sendmail, but it does not compile on either of my
>machines and I have not had the time to really dig into it.  I have


Is sendmail available to the public, or are you required to have
a BSD license of some sort?  I always thought that a BSD source
license was required.  I mean, if the thing is the be all and
end all of address re-writing, maybe it should be fixed, or ported
to SysV.  I would be interested in having a look at it, anyways....
				Rob M.



-- 
Rob Marchand                   UUCP: {mnetor,utzoo}!lsuc!array!rob
Array Systems Computing        ARPA: rob%array.UUCP@uunet.UU.NET
200-5000 Dufferin Street       Phone : +1(416)736-0900   Fax: (416) 736-4715
Downsview, Ont CANADA M3H 5T5  Telex : 063666 (CNCP EOS TOR) .TO 21:ARY001