On Wed, Oct 01, 2003 at 11:08:04AM +0200, Dag Kihlman wrote:
1. It greatly increases the traffic on the internet.
If you mean more connections that is true, but if you make a calculation
you will find that the increased traffic is nill and nothing compared with
the traffic caused by spammers, viruses not to mention radio listners and
video viewers. Compared with this traffic the traffic argument is not really
a big thing. Historically the argument is valid but it is getting less and
less interesting.
It's about that we'd have probably 1.5 times the number of connections
in the email area.
3. It removes the store-and-forward advantage of current email.
This argument is a puzzle to me. Any mail could be forwarded... The
notification could also be forwarded.
But how does the user get the message?
Think of mail gateways (e.g. in big companies or at ISPs) and all the like.
So you would have to have two protocols. One to allow the MUA to upload
the message to a mailserver and that mailserver would have to accept it
no matter what. And that mailserver would then use a different protocol
to spread the messages ...
But now, I have a big company and they have a lot of mailservers and
they have two or three "gates". Now I have the situation
MUA -> CM-1.A -> CM-1 -> MailGate
CM-1.A and CM-1 (Cluster Mailserver, 1-A = faculty 1, section A) would
have to forward only the messages until they reach MailGate and MailGate
would have to store them, to make them retrievable, as CM-* are
firewalled for security reasons.
4. It assumes that point B can always reach point A.
This is quite true, but hey I have an Internet bank at that also assumes
I can reach it. If not I retry. At least here in Sweden the Internet is
stable enough.
See above. We have lots of users that run their sending MTA behind a
dialup line (with static IP). They connect, send mail poll our mailserver
(which is MX) via ETRN and disconnect. This would no longer be possible.
5. It is less reliable.
In some aspects yes but a system perfect for spammers and
virus designes is not really reliable either. It depends on what
aspects you want to be reliable.
This won't work for virus prevention, and I doubt it will be effective
for spam prevention.
If could work viri wouldn't spread that fast as they do these times.
The problem is the social factor. They get a message from someone they know.
That's why they open it and that's why they get infected. Now they'd get a
notification from someone they know and it says "Anna Kournikowa nude
pictures". Do you really think they'll not pull it? Or if it says
"Microsoft security update" then they think their friend will forward
them some urgent patch. Do you think they'll not pull it?
This will not change a thing, it will only create much overhead and time
delay.
For me the worst problem with spam is, that I have to look at the
subject lines and delete the message. What would be different from a
pull proposal, were I have to read the notification and request a
message or not. In case of a spam notification I delete it also.
So the only difference is that I didn't get a fuill featured spam
message (which I never read anyway) but a notification, which I have to
read(!) and delete anyway. Nothing saved but a few bytes of traffic, and
that is irrelevant, as you have stated above ;-)
Another disadvantage is that you no longer have timely delivery.
Usually on the weekend I dial in to my account, skim through my mailbox,
look at some mails that may be an indication of problems and disconnect.
This would no longer be possible.
I'd have to spend nearly the same time requesting the real messages from
the message store and come back some minutes/hours later, when the
messages probably have arrived (maybe even not) to actually read the messages.
Btw: Your proposal looks much like Dan Bernsteins' IM2000 concept:
http://cr.yp.to/im2000.html
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg