|
There
are times (like times of civil oppression) where I may not want a
means
of
tracking e'mail back to me...less I find the secret police at my door. I
suspect
that
this will lead them right to me. I also noticed that you are encrypting
and
decrypting along the way...this can be quite a drain on resources at 100
msg/sec
which
is what some e'mail systems need to run at...there is also the little
goodie
that
in some countries the mere encrypting of mail is a state crime -- again
those
"protocol" officials will show up at your door. Breaking the forward
model of e'mail
may
have consequences that need careful thought with regard to protecting
the
ability of those that need e'mail as a voice of opposition to continue to
use it.
--
Bruce
SMTP is a
push mail system, a great thing if you are a commander in a nuclear war, if
you want to infect computers with viruses or if you want to send a couple of
million mails about magic pills. Just throw the mail out on the Internet and
let the recipients take all administrative costs.
Today the Internet
and computers are fast enough for a pull system. In short my proposal is the
introduction of a new kind of mail program and mail system based on pull
technology. Of course this is a drastic step but I think a drastic step is
much better than numerous patches to a system ideal for misuse. I realise that
the reader will be very sceptical and see numerous problems, but I hope that I
have foreseen most problems and hopefully the most sever objections will be
answered in this proposal.
I will present my proposal while describing
a mail from A to B.
When A sends a mail it goes to the mailserver owned
by A's Internet Service Provider where the mail is stored. A's mail client
interacts with the ISP's mailserver and A can see any mail that has not
reached the recipient. If the mail was sent by a virus or by a hacker A will
be able to discover the intrusion and remove the mail. This means that viruses
and hackers will not be able to hide and viruses can be stoped, which means
that viruses' ability to multiply is greatly reduced.
As soon as A's
ISP's mailserver (mailserver A) receives the mail a notification is sent to
B's ISP's mailserver (mailserver B). Mailserver B replies with a random
encryption key and Mailserver A encryptes the mail, stores it and delets the
encryption key.
The notofication message from Mailserver A contains
Mailserver A's IP-address, a mail identification number, a password, A's name
and email address and the mail subject. Each piece of information is too short
to be used for profitable spamming and it will be sent in UTF-8 format making
it easy to scan and validate.
When B connects to Mailserver B the
mailserver will pass the notification to B's mail client together with the
encryption key. B can filter the notification. When the mail is opened B's
mail client connects to Mailserver A using the IP-address, the mail id and the
password in the notification. Since the IP-address must be valid any other
certificate or verification is unnecessary. When the mail is received the
encryption key is used to decrypt it and a new filtering can be
made.
As soon as the mail is delivered it will be removed from
Mailserver A. If B wants to share the mail among several computers B must save
it on Mailserver B.
From a programmer's point of view my proposal is no
difficult task. The problem is that it is a huge revolution in the way mails
are treated. However it can co-exist with SMTP for a while since a mailserver
which supports the new system will be able to store a SMTP mail and create a
notification on the fly. It is also possible for a mailserver to detect what
kind of mail client the receiver has. If the mailclient does not support the
new system the mailserver can pass the message the old way.
I hope that
I have not troubled you with an unrealistic suggestion and I am eager to hear
any comments.
|