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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2003 10:48:24 -0800

> Yes, but that HTTP trick has a lot of built-in failure modes, which 
> is really why RSS came about.

Absolutely, the HTTP infrastructure is designed to support caching. It is
not a change notification system and was never intended to be. At this point
in the Web I am not sure that anyone really uses caching in the network. We
are not working at 28.8K anymore...

The HTTP protocol is intended to support use as a gateway protocol to a data
source. There is no way that the HTTP server can require change notification
from that data source.

> >For the respectable end of the market (the confirmed opt-in, or
> >whatever the current phrase is), I agree completely---there's a space
> >for some use of RSS or something much more appropriate than email.
> >Actually, I suspect HTTP with perhaps some automated browser
> >configuration (to switch on monitoring of the relevant web 
> page) would
> >be easier to get going.
> 
> That's a technique with 8 years of hard failure modes behind it. It 
> would be nice if there was a reliable lightweight standard way for 
> web browsers to detect significant changes of HTTP-accessible 
> documents, but there isn't. There's about an 80% solution, and the 
> ways that it does not work are non-trivial to solve.

Hence RSS, it is a fairly widely deployed solution at this point. I do not
see the reasoning behind creating a new protocol that has the same
structure. I do not see the value of research that is intended to duplicate
what is deployed.

It would be quite easy to configure a client so that it allowed automatic
subscription to RSS feeds. Probably the thing that is missing is a URL to
identify the protocol so that the browser knows what to do with the link
when you click on it. 

		Phill

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2003 11:12:15 -0800

> 3) How long must my server hold mail for you to pick it up? 
> (balance of
> burdens)

What happens if I try to push mail at you and you then respond by trying to
pull it off my server and it is down?

Do I have to retry? - leads to potential DDoS attacks.

Do I just fail at first attempt? - leads to fragile and unreliable email
transfer.

		Phill

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 29 Nov 2003 15:55:31 +0000

> > What exactly is the specific failing of SMTP which is addressed by pull
> > systems?
> 
> 
> Pull might help stop spam. Right now, a sender system only has to
> exist to inject a single message for it to get through. With a pull
> mechanism, the sender must remain at a stable IP address for at least
> a few hours to a few days. Sending systems can't be as ephemeral anymore.
> 
> 

Is this a weakness? And anyway, can't this "flaw" be resolved by any of the
RMX / permitted sender DNS type proposals? It seems a very weak argument to
me.

> 
> > 
> > Have I missed something?
> > 
> 
> See the grandparent message by me.
> 
> 
No - I saw that.

--

---

From: "Dag Kihlman" <[email-masked]>
Date: Sun, 30 Nov 2003 12:03:54 +0100

Some opposition against a pull system is not really well founded.

1. "People are mobile - a pull system is slow!"

No, not at all. When you have a telephone modem the delays are caused by
viruses, attached documents and so forth. In a pull system only the
notifications are pushed and they will be less than say 200 characters long.
If you are concerned about mail on mobile equipment - pull is the solution
for you!

Chris wants his mail server to do the pulling. I think it could be an option
if you work in an organization where a lot of data is sent.

2. "Blacklists tend to run at the whim of the blacklist owner"

Well, Chris! What is the problem with that? I would not subscribe to the
"young boys with motorbikes' blacklist", but I guess young boys with
motorbikes will love it. I would subscribe to the Swedish University Network
blacklist and whitelist. I guess that will not be interesting to you since
you are interested in Australian sewing machines. A blacklist can actually
be made using your classification idea. Have you thought about that? ;-)

3. "People will misuse the [Delete spam] button casting a vote "spammer" on
innocent people and organizations."

True. But the [Delete spam] button is the way for a user to instruct the
program to delete notifications from that address. I do not suggest that
everyone should be included in a voting system. But there are organizations
contain people who can use the classification system and use the [Delete
spam] button properly. Perhaps the Swedish University Network (SUNET) would
find it a good idea to implement a voting system, a blacklist and a
whitelist. If  SUNET does impement a blacklist and a whitelist it is up to
me if I am happy subscribing to it. If you think blacklists is a lousy
idea - fine! Do not use them but let me use them!

4. "Spammers will lie about their classification"

True. But if some organizations blacklist spammers it is better for them to
be honest. That is why Chris needs blacklists even if he does not like them!

The main advantages with a pull system, as I see it, is:

1) to allow pull servers only on static IP addresses where the owners have
asked for the ports to be opened. This way spammers will find it really hard
to find unprotected computers.

2) the mail client will coopererate with the notification server making
virus and spam mails visible allowing the user to remove them.

3) it will be an excellent choice for mobile equipment.

4) it will make it easier to construct blacklists

5) it will makie it easier to enforce a mail classification system