Subject: [Asrg] 6. Proposals - Let pull mail replace push mail

From: "Dag Kihlman" <[email-masked]>
Date: Wed, 1 Oct 2003 01:25:53 +0200

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.

---

From: "Bruce Brown" <[email-masked]>
Date: Mon, 29 Sep 2003 17:29:50 -0700

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
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Dag
Kihlman
  Sent: Tuesday, September 30, 2003 4:26 PM
  To: [email-masked]
  Subject: [Asrg] 6. Proposals - Let pull mail replace push mail

  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.

  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.

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 29 Sep 2003 20:31:48 -0400

At 1:25 AM +0200 10/1/03, Dag Kihlman wrote:
>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

Please search the archives.  This has been discussed before.
1. It greatly increases the traffic on the internet.
2. It greatly increases the ISP disk storage requirements.
3. It removes the store-and-forward advantage of current email.
4. It assumes that point B can always reach point A.
5. It is less reliable.
I think there were other problems, but those are the ones I recall 
off the top of my head.

>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

There's absolutely nothing preventing ISPs from scanning outgoing 
email right now.  You don't need a pull system to do that.  It can be 
done currently without an architectural change, either by filtering 
outbound port 25 connections, or by  forcing ISP users to use the 
ISPs outbound mail server.  But this has nothing to do with spam.

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

And when A is CNN and sends and CNN news alert to 100,000 people, A's 
mail server will encrypt 100,000 copies of the message, and store 
them all on the server for how long?

>IP-address, a mail identification number, a password, A's name and 
>email address and the

I certainly hope they won't use a password in that message.  If 
you're going to propose this, please use public key encryption. 
Otherwise you've just introduced a huge security hole.

>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 

Sending it UTF-8 is irrelevant to the scanning.  And a single subject 
and an email address is most certainly sufficient for some spam. 
I've gotten spam that had nothing more than that.

>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

Ummm.  Pass it to my client?  Would that be the client on my cell 
phone, my blackberry, my pager, or the UUCP connection to a place in 
the boonies.  Mail clients connect to the internet periodically. 
You'll have to queue the notification somewhere.

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

This is where we hit the unreliable part I mentioned before.

>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 remembered one of the other things I'd forgotten.  Pull systems 
don't change the spam equation at all.  Logically you've created a 
need for a remote server in order to get the spam.  Most spam 
currently needs a remote server for delivery.  It's called a web 
site.  If spammers think they can keep the web site running long 
enough to get the point of the spam across, there's no particular 
reason they won't be able to keep the new mail server running just as 
long.

Additionally, you've provided a wonderful tool to the spammers. 
They'll know exactly which addresses their spam got delivered to. 
Because your system gives them a direct mapping between email 
addresses and IP addresses, and a way of knowing exactly when you 
fetched the email.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Sep 2003 21:56:40 -0400

For certain applications such as newsletters and blogs, RSS has been 
becoming popular as an alternative to email. Therefore, for specific 
cases "push" email might be better than "pull".

Bruce Brown wrote:
> 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
> 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
> 
>     *From:* [email-masked] [mailto:[email-masked]]*On Behalf
>     Of *Dag Kihlman
>     *Sent:* Tuesday, September 30, 2003 4:26 PM
>     *To:* [email-masked]
>     *Subject:* [Asrg] 6. Proposals - Let pull mail replace push mail
> 
>     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.
> 
>     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.
> 
>     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.
> 
>     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.
> 
>     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: "Jon Kyme" <[email-masked]>
Date: Tue, 30 Sep 2003 10:06:34 +0100

> >profitable spamming 

What is the international standard minimum length for spam profitability?
Is it shorter than
"*** V I A G R A  http://www.uk-clinic.example/ ***" ?

--

---

From: "Dag Kihlman" <[email-masked]>
Date: Wed, 1 Oct 2003 11:08:04 +0200

----- Original Message ----- 
From: "Kee Hinckley" <[email-masked]>
To: "Dag Kihlman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 30, 2003 2:31 AM
Subject: Re: [Asrg] 6. Proposals - Let pull mail replace push mail

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

> 2. It greatly increases the ISP disk storage requirements.
True and wrong at the same time. It moves the storage from one server
to another. To some degree the size will grow but the ISPs will protect
themselves by putting a limit on the number and total size of outgoing
mails.
Ordinary users probably will only be able to store a couple of
hundred mails. This has the positive effect that if you hack an ordinary
user you will not get much value out of it. Especially since the user may
remove your spam messges. The hackers must turn to companies but they
will have other means of blocking and discovering hackers.

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

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

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

> ISPs outbound mail server.  But this has nothing to do with spam.
My suggestion has nothing to do with scanning. I neither prevent it
or demand it.

> them all on the server for how long?
It is up to CNN. Their programmers will find ways to deal with this problem
as you very well know.

> I've gotten spam that had nothing more than that.
Yes, you are quite right and I really was not clear enough. I meant
that the subject should not be able to contain a picture impossible to
scan.

> You'll have to queue the notification somewhere.
No problem for a programmer.

> This is where we hit the unreliable part I mentioned before.
Your objections are against my proposal and you do not really give it a
chance by comparing it with current system. It is possible to eavesdrop
on mail communication today. Those who can eavesdrop on current
traffic will be able to eavesdrop in my system too. The hair raising bit in
my suggestion is probably that they can read passwords and encryption
keys, but they will be unique for each mail. The only gain the eavsdropper
will have is that he or she gets the means to read the mail, but since the
eavsdropper can do it with current system the security issue has not changed
at all. As you well know the best thing to stop eavesdropping is to
encrypt the mail before it is sent and that you will still be able to do.

> reason they won't be able to keep the new mail server running just as
I am not sure if I misunderstand you or you misunderstand me. So I
will try to explain what I mean instead of answering something I maybe
misunderstand. What I mean is that a spammer either will have to have a
mail server of his own. It requires an IP address and those are handed
out in an orderly fashion in a hierarchal way. To deliver spam in a
pull system you will have to keep the mailserver running for hours. In a
push system ten minutes will be heaven for a spammer. Anyway an ISP
ought not accept mails from a local unknown mailserver. The only
real option for a spammer is to hack a company or something and
such users will be better able to fight hacking and viruses.

> addresses and IP addresses, and a way of knowing exactly when you
Again you do not compare my system with current system. If a spammer
wants to know if and when a mail has been read it can be done today
since many mail programs allow html formatted mails with pictures and
the URL of the picture contains a key telling who opened the mail. Of
course you and I prevent this but we should advocate a mail system
which is safe enough not only for you and me but also for users
unaware of the problems.

I maintain that it is wrong to maintain a system where spammers and
viruses are able to hit and run. It is better to have a system where
spammers
and viruses will reveal themselves at the source where they effectivly can
be
fought.

/DK

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 30 Sep 2003 15:23:00 +0200

On Wed, Oct 01, 2003 at 11:08:04AM +0200, Dag Kihlman wrote:
> the traffic caused by spammers, viruses not to mention radio listners and
> less interesting.

It's about that we'd have probably 1.5 times the number of connections
in the email area.

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

> I can reach it. If not I retry. At least here in Sweden the Internet is

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.

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

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 30 Sep 2003 10:44:13 -0400

>traffic caused by spammers, viruses not to mention radio listners and

If it blocks spammers and viruses.

>themselves by putting a limit on the number and total size of outgoing

Again.  ISPs can and some do limit the number of outgoing messages 
now.  Pull is not required.

>notification could also be forwarded.

The point is that I must be connected to the internet, and I must be 
able to connect to the sending machine, in order to read email.  To 
take an obvious example.  You run a web site with registered users. 
You are moving to a new ISP and will be down for two days.  You send 
email to all your users, then you go down.  None of your users can 
read the email.

>I can reach it. If not I retry. At least here in Sweden the Internet is

But we aren't talking Sweden.  We are talking the entire world. 
Large web providers deal with this by distributing their content on 
replicated servers around the world.  To make email as reliable as 
the web (which isn't saying much), you would have to do the same with 
mail servers.

>It is up to CNN. Their programmers will find ways to deal with this problem

I'm sure that's what Verisign said when they added a wildcard A 
record to the root servers.  That doesn't make it a good idea.

>No problem for a programmer.

That isn't a programming problem.  It's an architectural problem. 
You've designed a system that loses all the benefits of store and 
forward and assumes that all receivers have full internet access to 
all senders.  The real world doesn't work that way.  Please read the 
archives--this has all been covered before.

Yes pull works well for some things (primarily broadcast-only 
announcements like news).  No, it's not a replacement for email.

>traffic will be able to eavesdrop in my system too. The hair raising bit in

True.

>such users will be better able to fight hacking and viruses.

My point is that spammers already keep servers running for days--both 
their web servers and their email servers.  These servers are 
scattered around the world, consisting of compromised machines, open 
relays and virus-infected machines.  It easily takes several days to 
get one of these machines shut down, and many are never shut down. 
So you haven't introduced any problem that they don't already know 
how to deal with.

>wants to know if and when a mail has been read it can be done today

It can be done if the user's email is configured unsafely.  More and 
more email vendors are changing the default options so that remote 
graphics are *not* displayed automatically.  Your system eliminates 
that possibility.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 30 Sep 2003 17:40:11 +0200

>>  Please search the archives.  This has been discussed before.

	Indeed.

>  a big thing. Historically the argument is valid but it is getting less and

	Additional traffic is not the only problem.  What was a single 
e-mail message is now a message body that has to be stored somewhere 
reliable, plus a notification to the recipients that they can come 
pick up their e-mail at such-and-such location.  What was a single 
e-mail message now has two parts, which increases by an order of 
magnitude (or more) the problems with things breaking down and 
getting disconnected or mis-directed.

	Now all spammers would have to do is to compromise a mail silo 
server somewhere, replace all the message bodies with their spam 
content, and they can be assured that this will get past all the 
recipient filters because the original notices that went out were 
real e-mail messages from real people.

	In addition, if you've ever built a large-scale mail system, you 
know that the single biggest problem facing you is not disk storage 
capacity, but is disk I/O latency, especially with small messages. 
You're talking about taking all traffic and turning it into a message 
upload plus one or more small messages.  This is the worst possible 
thing you could do to the mail system.

	If you want to invent the Mail-Merge Transport Protocol, talk to 
Eric Allman and Bryan Costales.  We went a long ways towards 
designing this thing while I was at AOL and Bryan was at 
MercuryMail/InfoBeat.

	Problem was, we realized that this would increase the spam 
problem by many orders of magnitude -- spammers already use tools 
that send the message body once and then a list of recipients to 
which to spam that message to, we'd just be allowing them to push 
that mechanism to the end recipient.

	See the archives.  Please don't make blind proposals like this 
without having reviewed what proposals have already been made, and 
have some suggestions for how you're going to address the problems 
previously identified.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: "Dag Kihlman" <[email-masked]>
Date: Wed, 1 Oct 2003 21:36:32 +0200

----- Original Message ----- 
From: "Kee Hinckley" <[email-masked]>
To: "Dag Kihlman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 30, 2003 4:44 PM
Subject: Re: [Asrg] 6. Proposals - Let pull mail replace push mail

Thank you for your and the others comments! I am sorry to have brought up a
subject you already have discussed!

I must confess I haven't thought much about dial up connections. Here in
Sweden it is very common with faster types of Internet connections and even
if someone has a dial up connection the cost is very low.

The strongest objections concern the traffic and I guess that must be a true
obstacle, but technology is getting faster...

I think I have failed to make my point why a pull system would be effective
against spam and viruses. The main thing in my proposal actually is that a
pull system (where the mail client displays outgoing mails) will be a visual
proof that something is very wrong if the owner can see strange mails in the
outgoing arena. The user will see that he or she is hacked or infected and
remove the mails. Together with a limitation of the number of outgoing mails
I mean that the "role" of ordinary users in the spreading of viruses and
spam will be greatly reduced.

This a problem in Sweden since so many persons keep fast computers with fast
connections connected to the Internet for hours. I have examined pings
caught by Zone Alarm and I would say that 95 out of hundred comes from IP
addresses belonging to Swedish ISPs. People discover that their computers
have hosted sex sites and stuff...

The problem with hacked personal computers must be fought since it will be
so easy to circumvent any obstacle set up by SMTP or AMTP. I still think
that a pull system is worth the costs of implementing it. But i will not
trouble you further with my current favorite idea... ;-)

/DK

I am fully aware that the fight against spam on the recipients side
 My point is that every mail will "belong" to someone. If people find
outgoing mail which they have not sent they will be able to see that they
have a virus or have been hacked and remove the mails. That means that
several virus mails can be stoped before they reach their recipients.
Together with a limitation of the number of outgoing mails it will probably
greatly reduce viruses and spam mails from ordingary users.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 30 Sep 2003 15:49:35 -0400

> subject you already have discussed!

Dear Dag,

Nevertheless you have showed a willingness to help the effort! There are 
plenty of things that you can do to help the group. Contact us off-list 
for more information.

Yakov

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 30 Sep 2003 22:29:12 +0200

On Wed, Oct 01, 2003 at 09:36:32PM +0200, Dag Kihlman wrote:
> remove the mails.

No. Our mailserver currently processes at least 100000 emails a day
that are injected by our customers (leased line and dialup) that use
our mailserver as an outgoing relay. Dialup customers because they have
to (e.g. queueing for unreachable hosts) LL customers because it is
convenient.
This means we would operate the mailstore where the messages would get
pulled. So they wouldn't notice anything. And: we have customers that
operate their own mailservers, completely independant.
Sometimes we get complaints that their mailserver is relay open. We call
them and they say: "we had problems for 2 weeks now" and only after we
call them and tell them that their mailserver is relay open and abused
they look at the logfiles and the queue and find some thousand messages
there. Otherwise they ignore it and think "this surely is the XYZ
thingy again" or "our ISP is doing some bullshit, that's why it is slow".

User don't care, regardless if they have the opportunity or not. So
a pull system will change nothing to the good in this regard.

	\Maex

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 30 Sep 2003 22:43:01 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> > outgoing arena. The user will see that he or she is hacked 

<SNIP>

> a pull system will change nothing to the good in this regard.

If you want a pullsystem today, pick a random forum product
like phpBB, ultraboard and many others, post a message to the
forum and have the forum send out a notification that there is
a new message. Use it for a while and one will notice that it
is not handy and there is still a message to be delivered only
now it only contains "get your spam here" instead of the direct
link along with the content :)

Greets,
 Jeroen

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 30 Sep 2003 17:17:40 -0400

>outgoing arena. The user will see that he or she is hacked or infected and

Sure.  But you could equally well say "if everyone runs software that 
tracks outbound port 25 connections they'll be able to see that a 
spammer is using their machine for spam".  In fact, I'm sure such 
software exists.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society