Re: additional requirements

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email protected]>
To: "mail-ng mailinglist" <[email protected]>
Sent: Saturday, February 07, 2004 6:54 PM
Subject: additional requirements

> If I were a large company, I might require some or even all of the
> following:
>
> - All mail must flow through a predefined set of servers, so it can be
> archived. This means recipients must (be able to) reject email from the
> domain in question if it came from somewhere else, so:

For a company (atleast in the USA), employees have no control of mail,
including privacy. The employers own all resources, including user email.
Employers are the exception to the ECPA laws.

> - It must be possible to express and publish policies. This should also
> help autmate those dreaded disclaimers so they don't have to be added
> to each individual message anymore.

You mean put them into headers?    Adding the disclaimers is required by law
so that the intent of the message is "well defined" and not dependent on the
software/transport or the presentation software looking for specific
"display attributes."

> - It would also be useful to have a way to imprint the company seal of
> approval to messages.

This is good if it can standardized and supported at all ends.  That is why
the disclaimers are required.  There is ECPA based case precedent for this
where intent was expected by the author/sender but was broken either by
system or the recipient.

> - Integration with book / record keeping. So there must be standard
> ways to express reference numbers rather than "keep this in the
> subject". Whenever a message costs or makes money, we probably want to
> track this in an automated way. For instance, when an employee orders
> something, there should be something in the message that says: "this
> message contains a transaction <transaction number> that will cost
> <number> <currency>". This allows for automated checks on expenditures
> and lots of other stuff.

Could a "Message-Id:" handle this?

> - The next step would be transmitting forms back and forth through
> email rather than HTTP. Email is much more suitable for this as unlike
> web, it allows for unfinished work to be saved and resumed later, and
> you get to keep copies of exactly what is sent out and received. It
> would also be relatively trivial to forward forms so several people can
> each put some of the information in.

This is already done today.  But this defines a new requirement for "Form
Processing."  If you are talking about using HTML, then you are talking
about a client WEB browser component.  Are you are talking about some other
special mail-ng based form processing language?

> - Both the person filling out a form and the one eventually receiving
> it may want to have certain information included automatically.

I think we are really going beyond what is necessary.   What you are talking
about here is a MUA design as well - a complete OFFICE system,  well --- 
hello?  What is this system going to compete with Microsoft and StarOffice
or whatever it is called?    :-)

> And now for something completely different...
>
> Assuming the basic idea of a server that receives email on behalf of a
> user and a user who then collects it when convenient isn't going away,
> would it be useful to have some kind of simple scripting language that
> can be used by end-users (or their software) to push their mail
> policies onto the server? The advantage of this would be that mail can
> be rejected or parameters can be negotiated _during_ mail transfer
> rather than after the fact.

Not so completely different come current systems already doing it :-) using
mail driven event technology.  Listservers offer similar ideas.

> I think it's a good idea to explicitly look at mailing lists as part of
> this effort, for several reasons: uniform interface and efficiency, but
> also robustness: whenever there is a significant network outage there
> is always trouble with the mailinglists because their centralized
> nature makes them vulnerable. As I remarked a while ago on NANOG, NNTP
> would be better for this than current mailing list technology. I wrote
> some text about how NNTP could be improved. Some of this also applies
> here, so here's the URL: http://www.muada.com/projects/usenet.txt
>
> However, we shouldn't lose sight of the fact that many mailing lists
> are pretty small and it should be possible for anyone to start a simple
> mailinglist without too much trouble.

Good write up in usenet.txt.  I was particularly tickled with your term
"whelms."  This concept is very close to the Fidonet network "EchoMail"
concept and its "AreaFix" and "FileFix" concepts:

When a message is posted into a "echo" conference, it is automatically
"echoed" to systems who subscribed to the echo.  I believe your idea is to
echo the "reference" information only, right?

AreaFix was Mail Echo Management language that can be used to subscribe,
list, get statistics, etc.

Fidonet was also a File Distribution system with "EchoFile" 100% similar in
"EchoMail" for distribution.  Post a file into a "EchoFIle" conference, and
it was echoed to other subscribed systems.

In the same vain, FileFix was a File Echo Management language system to
subscribe, list, get statistics, etc.

I think in the ideas for Public Conferences (Mail or file) of distributing
references only information is good. After all, currently a news client will
initially just download headers anyway before getting the complete articles.
This would be a major fundamental network bandwidth improvement.

But it would have to be coupled with a echo concept.  This way a client can
pick a location nearest to him.  This implies that the reference information
also includes what fidonet called a "Seen-By" which list all the systems
that received copy of the message.  That might be prohibitive in a large
echo network for popular echos as was the case in Fidonet.  So developers
introduced something called "Tiny Seen-bys" which listed only this systems
that were put of Zone or Net or region, i.e, no need to list the European
nodes if you are in north america and can get the mail locally.

The only issue I think would be client speed related.  Hmmmm, I have to
think how this will affect our wcNews.exe pull/push gate software and how it
would effect our ISPs who are hosting news for other people as well.

Off hand probably not much, but one thing for sure, it would be a major
across the board design change. :-)  Right now, our mail system offers
support for the legacy FIdonet network.  We still support it but stopped
development a few years back.  I know for sure that automated networking of
systems will definitely come back, in what form, I don't know. :-)

If interested, if just to get some "ideas" for mail-ng, here is a link to
get a good sources of Fidonet information:

http://www.ftsc.org  (Home of Fidonet Technical Standards Commitee)
http://www.writebynight.com/fidonet.html   (good verbose, descriptions)
http://www.fidonews.org
http://www.terminate.com/fidonet
http://b.webring.com/webring?home&ring=fidonet

I guess these are maintained by older fidonet veterans who only reason for
still leaving is probably to keep "fidonet" alive. :-)

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com