Subject: [Asrg] Re: 6. Proposals - Pull System (revisited)

From: "Dag Kihlman" <[email-masked]>
Date: Sat, 29 Nov 2003 12:44:33 +0100

I agree with Scott: people seem unwilling to make hard choices. The SMTP
protocol is old, ideal for spammers and inefficient. Any textbook covering
communication between tiers have one basic rule: avoid communication as much
as possible. The ideal solution is to send all at once and if necessary
receive a receipt containing the data you want or an error message. Any new
standard ought to be built on this simple principle. Why HELO? Send
everything and let the receiving server go through the sender's data
returning the appropriate answer.

To implement a pull system you do not need a concensus among mail server
administrators. A pull server ought to send a notofication all at once. If
an error message is returned the mail is sent using SMTP.

If a client hails a pull server with a special code the communication is
done using a pull protocol otherwise it is done using SMTP/POP.

To implement a pull system (client and server) would take at most two weeks
full job. Actually my students are going to test the idea in a final lab in
a web service course. Using web service technologies is probably not the
most efficient way but to test the idea it is sufficient.

/DK

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

---

From: Scott A Crosby <[email-masked]>
Date: 29 Nov 2003 06:16:31 -0600

On Sat, 29 Nov 2003 12:44:33 +0100, "Dag Kihlman" <[email-masked]> writes:

> I agree with Scott: people seem unwilling to make hard choices.

That wasn't the comment I was making. More so that it seems that
there's two threads:

  1. Email servers should be authenticated and authorized to send
  messages to prevent abuse.

  2. Anyone should be able to make their own email sending server --
  there shouldn't be some sort of oligopoly of those allowed to send
  email, with all others forbidden.

#1 includes techniques like public key crypto, dial-up blacklists,
hash-cache, and other micropayment or pseudo-micropayment schemes.

#2 includes things like anonymous email. No centralized control the
ability for anyone to make their own legitimate mailing list.

These constraints seem to be almost constantly in conflict. Which of
the two properties is more important? I have problems keeping up with
the traffic here, so if there is already a consensus, I apologize for
the spam.

If control and locked down mail servers is the most important, what
proposals are consistant with that but maximize freedom to set up ones
own mailinglists or own servers.

If egalatarian servers are is the most important, what is the maximum
security we can do to lock them down without impacting that?

> The SMTP protocol is old, ideal for spammers and inefficient.

I rather like SMTP. Its a good protocol and suitable for layering
other protocols on top of. Tweaks may be needed, but I think its
fairly good.

Scott

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 29 Nov 2003 12:16:14 +0000

What exactly is the specific failing of SMTP which is addressed by pull
systems?

Have I missed something?

--

---

From: "Dag Kihlman" <[email-masked]>
Date: Sat, 29 Nov 2003 16:31:58 +0100

Why Pull instead of SMTP (push) / authentication or freedom to put up own
servers

The failing of SMTP is that it allows the sender to cheat or lie. Any
authentication in SMTP is just authentication in an academic sense. In
reality spammers will hack even more than today and send using fully
authenticated mail servers.

A pull system can be designed in many ways. My proposal is that the mail
client communicates with the mail server letting the user see any outgoing
mail. This way the user can detect outgoing mails containing viruses or spam
and remove them. This will make it harder for viruses to infect through
mail. It will also make it less attractive to hack someone to send mail
since the mail can be deleted. In a push system it is common to put a limit
on incoming mails "full mailbox". In a pull system it will make good sense
to put a limit on outgoing mails. This is a good thing since it will make it
even harder for viruses and less attractive to hack someone to send mail.

In short: By moving the storage from the recipient to the sender we will
make it harder to spam, less attractive for a spammer to hack, harder for
viruses to infect and harder to lie about your identity.

You could also skip all those ridiculous messages sent between servers in
SMTP. In a pull system you send a notification containing all information
but the body of the mail. In turn you receive an OK (In my proposal the OK
contains an encryption key which the senders server uses to encrypt the
mail...) If something is wrong you get an "error:xxx" message. Just call and
return as any textbook on n-tier design advocates.

The opponents will say that it is easy for a spammer to put up pull servers
of their own. Yes it is true but they must be reached through a given
IP-address, making them vulnerable to blacklisting. Actually it is not a
very interesting argument since a push system is even more vulnerable. If no
authentication is needed anyone can put up a mail server and spam. If
authentication is needed noone could put up a push or pull server. So it is
really not a valid argument against pull...

Scott raised the issue on what is most important: authentication or the
possibility to put up mail servers of their own. I think there is a middle
way. Servers containing mails in a pull system should be reached through
certain ports. No ISP should allow traffic to those ports if the IP-address
is dynamic. Mail servers should use static IP-addresses and this way they
can be identified and blacklisted. Actually it would make good sense for an
ISP to prohibit all traffic to clients using those ports. The ISP ought to
charge a small amount for opening the ports to static IP-addresses. This way
something like 99,9% of home users with static IP-addresses will be useless
for a hacker forcing the hacker to successfully hack 1000 computers to find
one useful. If virus programs or even the operating system warned about
these ports being opened it will become even less attractive for spammers to
hack.

/DK

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Nov 2003 10:58:57 -0500

> What exactly is the specific failing of SMTP which is addressed by pull

  I'm working on a document which addresses SMTP's failures.

> Have I missed something?

  Reasons.  As in, none given for pull systems, other than "we think
they'll work".  They will work, of course, but whether or not they'll
stop spam is another question.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Nov 2003 11:05:14 -0500

> authenticated mail servers.

  Pull systems do not change this behaviour.  See recent spammer
behaviour of hosting web sites on trojaned machines.  They could just
as easily host mail for a "pull" system on the trojaned machine.

  The benefits of a pull system are different.  It allows recipients
to do things like wait 12 hours to pick up mail from unknown senders,
at which point the trojaned machine probably has a different IP, and
thus can't send the spam.

  Alan DeKok.

---

From: Bill Cole <[email-masked]>
Date: Sat, 29 Nov 2003 15:02:03 -0500

>What exactly is the specific failing of SMTP which is addressed by pull

SMTP for RFC822-format mail is essentially the only 'push' system in 
wide use on the net where data is sent to individual end users 
without requiring their prior consent. Yet for historical reasons, it 
operates on a source-trusted model. Traditionally, none of the source 
identification data in RFC822 mail or used in SMTP are authenticated 
in any way, but rather they are accepted no matter what they are. In 
the case of the HELO argument it is even unwise to do basic sanity 
checks because  misuse is so widespread among legitimate senders: 
unless the sending side claims an unambiguous identity which the 
receiving system knows as its own, refusing mail based on a 
validation failure will result in some legitimate mail being 
rejected. Being a push system makes email more subject to spamming 
than 'pull' systems, and the historical ways that Internet email has 
been run without any sort of sender validation have led to even 
non-spam using mechanisms that break any serious attempt at sender 
authentication.

Pull systems have a reduced need for sender authentication because 
the recipient is asking the sender directly for the content. This is 
why systems like the web almost never authenticate content providers, 
only doing do when the data being received has some significant 
intrinsic value. Note that I do NOT consider the one model proposed 
here for a new variation on SMTP to be accurately called a 'pull' 
system because it involves pushed unsolicited notices of availability 
of pullable messages, and in the end that's just as many pointers to 
spam as we currently have spam. A true 'pull' system for bulk 
messaging could do for spam  what the web did for gopher. If the only 
reason a bulk sender would chose SMTP is to support unsolicited 
messaging, the problem of filtering essentially all spam without 
filtering out non-spam becomes a whole lot easier.

-- 
Bill Cole
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 29 Nov 2003 18:52:31 -0500

> the traffic here, so if there is already a consensus, I apologize for

Phil Baker mentioned previously that authetication domains, instead of 
individual email addresses can help things. Especially, when the 
authentication is done via DNS, without any external parties involved. 
In that case, there is a less of a conflict.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 30 Nov 2003 09:06:29 +0000

> non-spam using mechanisms that break any serious attempt at sender 

Yes, alright, don't go on... lack of sender validation. OK, now fix sender
validation (see the many proposals to this end). What's wrong with SMTP?

--