additional requirements

Iljitsch van Beijnum <[email protected]> Sun, 8 Feb 2004 00:54:59 +0100
Newsgroups gmane.mail.ng
Message-ID <[email protected]>
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:

- 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.

- It would also be useful to have a way to imprint the company seal of 
approval to messages. This could probably be done by signing the 
message using a specific certificate that resides somewhere on the 
company mail system rather than close to / under the control of the 
actual person sending the message.

- 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.

- 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.

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

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.

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.