mail-ng
[Top] [All Lists]

Re: additional requirements

2004-02-08 06:14:07

On 8-feb-04, at 4:15, Hector Santos wrote:

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

Maybe that's what the lawyers think. If a spammer can claim to be any company they want, then certainly any employee with unempeded IP can bypass company mail servers when they want to, especially when they're on the road.

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

I talked about explicitly setting up relationships earlier. Obviously one part of that could be the mutual recognition of each other's disclaimers. A few standard disclaimers would also be helpful, then you could create a header indicating the disclaimer governing the message rather than quote the whole thing (and people who don't agree to the disclaimer can have these messages rejected automatically). For the more complex stuff you could use an external reference (URL).

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

I'll pretend I didn't read this.

- Integration with book / record keeping. So there must be standard
ways to express reference numbers rather than "keep this in the
subject".

Could a "Message-Id:" handle this?

No, because there could be more than one message regarding a single transaction.


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

??? Never heard of it. (Except if you mean by hand.)

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?

Whatever gets the job done.  :-)

- 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? :-)

If this is successful, stuff like (star|ms) office will integrate support for it.

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 I'm not making myself clear here. What I want is that Joe User gets to say "I don't want to receive any messages from my mother in law except one at thanksgiving and two at christmas" and that his software creates a script and uploads it to his ISP's mail server. The mail server then runs this script whenever there is a message for Joe and when there is a message from nana(_at_)oldbats(_dot_)org on july 3rd the message is rejected.

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?

Not necessarily, but that would be one mode of operation, yes.

If we're going to discuss Fidonet in this amount of detail we should probably invite Randy Bush, he seems to have some free time on his hands these days.

(For those who weren't there and those who were and don't regret it too much: http://riverbbs.net/fido/history/ )

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.

Also, many people who want to keep control over their content (and ads!) may no be opposed to distributing headers.


<Prev in Thread] Current Thread [Next in Thread>