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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Nov 2003 18:20:30 -0800

> there is no reason why it cannot be a generic e-mail replacement
> Implementation is relativally simple

Deployment is not. Do you have the support of any of the major providers of
email infrastructure?

The mistake many people make about the IETF is believing that the way
standards get deployed is you propose something in the IETF and the industry
then eagerly deploys it.

In practice the industry takes little to no notice of IETF activities. The
only way a protocol is going to get deployed is if you have a propagation
strategy to drive deployment. There are 3000++ RFCs and of those maybe
thirty have ever been implemented and deployed on a network wide scale.

> > RSS is the emergent protocol, it supports richer content 
> than NNTP, is
> > considerably simpler and has a significant user base even 
> though there are
> > practically no clients (!)
> 
> not relevant

If you want people to take notice of you you need to explain why your
proposal is better than an infrastructure that has five years of deployment
experience at this point and is widely implemented.

I suggest that if you want to take this further you submit a draft and see
if you can persuade people to read it.

		Phill

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

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 13:27:51 +1030

> Deployment is not. Do you have the support of any of the major

No of course not but that does not mean that it cannot happen

this is a research group. we should research and then make recommendations

I am only adding or revisiting something I think has potential and been
overlooked for reasons unfathomable
but thats why I did my "revisited" so I could fathom the reasons.

I read the priors and can truly say not much in the way of valid reasoning
was put forward just a lot of knocking.

> standards get deployed is you propose something in the IETF and

Of course not, but without properly researched alternatives, there is
nothing to deploy

> strategy to drive deployment.

Yes I have considered this, but it is too early to go into details.
lets see if the flag will fly first

> There are 3000++ RFCs and of those maybe

maybe most are passed over
propriatory systems will always be such

but when it comes to interoperability RFC's are often the starting place

Its where I turn when I want to develop some interoperable software

> experience at this point and is widely implemented.

NNTP I have spoken of in another message as to why it is an indicator of the
potential success of a "pull" mail system
NNTP most often operates pull on a newsgroup level not a message by message
basis

But I am sure many administrators of news server who do offer filtering do
exactly what is suggested.

from my understanding (limited), RSS is not e-mail, it has no relationship
to e-mail. and could not be easily implemented as e-mail

It may be a good replacement for NNTP but that's debateable. (blogs)

I believe that RSS is a one to many system is it not ? (like nntp)

To replace email with some sort of RSS would require a major change to the
way people do things and everyone would have to change their current
software.

The idea is a minimal impact system that gets the results or at least
reduces the problem to a manageable level

and I keep saying this but it is the central point...

It gives the choice to the recipient. before the actual e-mail is even sent.

> if you can persuade people to read it.

I need to know more before I do, if I do. thats why this thread.
apart from IM2000 and Brett Watsons thesis I cannot find much.

Chris

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 25 Nov 2003 21:56:39 -0500

> if you can persuade people to read it.

I would also suggest reading the following two documents which are used 
for proposal evaluation:

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt
http://asrg.kavi.com/apps/group_public/download.php/7/draft-irtf-asrg-requirements-00.txt

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"Fight spam, but keep it in perspective" (Brad Templeton)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 25 Nov 2003 22:07:45 -0500

> apart from IM2000 and Brett Watsons thesis I cannot find much.

There were some discussions a while back as well. Some folks such as 
Brett Watson himself, and some others can provide more information if 
you contact them directly. So far no one has presented pros and cons of 
pull model vs. push model in a single document, which is something that 
might be useful, especially if the evaluation model in the tech 
considerations document is followed.

However, the single overriding concern about such system is deployment. 
This is the same problem that faces anyone who wants to replace SMTP 
with a different protocol, push or pull, such as the various AMTP 
variants discussed earlier on. Majority of folks think that complete 
replacement of today's SMTP infrastructure would take too long and be 
too costly, while easier and almost as effective solutions exist.

The problem with SMTP is not unique to that protocol itself, it is also 
found in other protocols and the structure of the Net itself - every 
user on the Net is inherently trusted by the network. That allows spam, 
trojans, viruses, DDOS attacks, etc. That problem need to be though 
through not just for spam, but for the Internet as whole.

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 15:12:10 +1030

> too costly, while easier and almost as effective solutions exist.

This is one of the main reasons I am for a "pull" system based on smtp
rfc821
it is do-able, requires limited software replacement and can be achieved in
a reasonable time frame (2yrs?)

If software vendors (and I agree with Phill, this is an *if*) get on board
it can be a part of their next "upgrade"

it does not require any fundamental change to the system

just some additional commands on top of the already functioning system

Remember my version does not require the POP client to do any work.
All work is done by the SMTP hosts.
the recipient (client) does not pull the messages the smtp host does that.

the POP client e.g. ms outlook needs no modification

For an example on the uptake of similar technology, how many server
implementations still use http/1.0?

Pull retains the "openness" of the current system. but ultimately flips the
coin from push to pull
and delivers the choice to the recipient not the sender.

Spammers can still spam to their hearts content.

if they follow the rules their mail will get delivered to those who want it.

if they don't follow the rules they receive a reminder of what the rules are
(message denied).

if they continue to cause problems legislators can use the "class"
header/command as the basis for drafting laws designed to stop mail abuse.

e.g. porn vendors sending unsolicited e-mail that ends up in childrens mail
boxes

So an SMTP PULL server configured for a child would have a "class/adult deny
all" setting
if the sender classifies the pornographic email as a "class/general" then it
could be actioned and a conviction sought and got.

> through not just for spam, but for the Internet as whole.

This is most definately true.

Chris

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 00:44:43 -0500

> just some additional commands on top of the already functioning system

The question is not making the change, rather justifying it. You need to 
show how this system will reduce spam and by how much, in order to 
justify change to the entire Internet email architecture.

Yakov

-------

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 16:56:23 +1030

> justify change to the entire Internet email architecture.

Confused! how is this a "change to the entire Internet email architecture."

It is a modification or even a "grafting"

from

1.   SPAM AND CONSENT
...
its definition varies from
"unsolicited commercial email" to "any email the
recipient does not want".  Often there are no technical
differences between spam and "acceptable" email.
...

by this definition spam has no definition

so its about choice, the recipients choice because it is he who ultimately
decides what is spam for him(her)

Therefore by empowering the recipient to control from whom he receives
e-mail then in fact we obliterate it from the face of the earth.

because what is left is acceptable to the recipient.

the very first and most powerful application is the ability to deny mail
from forged sources
this is without a shadow of a doubt the source of most "objectionable"
e-mail

and this is achieved automatically the source MUST identify itself or it
won't get the call back

Chris

P.S.

I am surprised no one has raised one particular flaw
that is ISP's who host scripts that are open to abuse e.g. some versions of
formmail

I am mentioning it now so people don't go "ah ha you missed that one didn't
you"

by virtue of the fact that the ISP get's an automatic reject message. ISP's
should pick this up early and correct the problem

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 17:12:10 +1030

Actually I would to clarify one point

No system can get rid of all spam

my mentioning of formmail is just the tip of the iceberg

viral spam systems will of course send mail from legitimate and verifiable
addresses
no system can stop this unless we manage to stop the spread of trojans and
virii

....

thats next weeks assignment

Chris

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 01:50:58 -0500

> It is a modification or even a "grafting"

I am kind of lost here. The current infrastructure does not require 
"pull", your will require "pull". Even though its running on top of SMTP 
and POP3, nevertheless you will require all clients to do "pull" in 
order to get email. This looks to me as a major change.

> and this is achieved automatically the source MUST identify itself or it

What about the users that force the email to be pulled, just like the 
users who click on links in spam today?

Yakov

-------

---

From: "Chris" <[email-masked]>
Date: Wed, 26 Nov 2003 22:44:06 +1030

> order to get email. This looks to me as a major change.

pop3 is unchanged the sytem does not alter pop3 at all

The difference is in the host server(s) (which may happen to be on the
recipients/senders machine)

for example one possible method...

The sender sends a "pull request"
this can be in the form of shortened e-mail no body just headers

the recipients host smtp server accepts that mail as it does now but instead
of queueing it for collection it processes the request and chooses to accept
or deny.

it then sends an accept or deny message to the remote senders machine (smtp
server)

the accept message has a onetime identifier which the remote senders server
attaches to the email and then forwards it to the recipients smtp server
which checks the identifier and queues it for collection (pop3) as normal

So apart from a couple of extra commands there is little change to the
current system and it is compatible with the existing infrastructure.

At some future point e-mails sent without a properly formatted pull message
get returned as not accepted using standard failure codes and an additional
explanation message.

> users who click on links in spam today?

Doesn't really apply if the email has made it to the users machine it has
passed all initial tests which is mainly that the source can be traced.

again spam is in the eye of the beholder. if the recipient chooses to accept
the email then so be it.

Chris

---

From: Mark Baugher <[email-masked]>
Date: Wed, 26 Nov 2003 05:17:14 -0800

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt 
calls the idea of replacing smtp "appealing" for a number of reasons.  I 
think this long-range idea is within the scope of this group.  In fact, I 
recall that there is some work to evaluate smtp security in light of other 
types of systems.  So, it seems that this idea should not be taken out and 
shot but should be considered along with other long-range approaches to 
electronic mail.

Mark

---

From: Bill Cole <[email-masked]>
Date: Wed, 26 Nov 2003 11:50:34 -0500

>to e-mail. and could not be easily implemented as e-mail

You need to do more research or maybe just a bit more pondering.

The problem of spam is the application of email to a one-to-many 
model for which it is ill-suited, in part because it has weak 
permission and authentication infrastructure. Any sender an impose 
his message on many recipients, and that is also true for your "pull" 
thumbnail in which there are notifications sent. Those notifications 
of available messages are as much a problem as actual messages. They 
are a push from senders who have every incentive to hit as many 
targets as possible without regard to how many of those targets want 
it.

The relevance of RSS is that it is a better alternative medium for 
the people currently (mis)using email as a one-way broadcast medium, 
without any mechanism for anything like spam. Much of the effort and 
hand-wringing and arguing over spam control mechanisms is really 
focused on not interfering with truly solicited broadcast email, and 
RSS gives those senders an alternative which does not have any 
exposure to side-effects of whatever might be retrofit onto email to 
stop spam.

-- 
Bill Cole
[email-masked]

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 26 Nov 2003 17:04:10 +0000

Bill Cole <[email-masked]> writes:

[...]

> exposure to side-effects of whatever might be retrofit onto email to

RSS is one, HTTP is another.  The web browser that I use (and I
presume most others) provides a convenient way to automatically report
changes in specific web pages.  If current spammers wanted to use
better mechanisms, they could just go ahead.  

The reasons they don't are partly cost, but partly they use email
(presumably) *because* it's the wrong medium---like snail bulk
mailers, they want their commercial or other messages to look like
personal messages so that people are more likely to read them.

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.  However, I suspect even that market wants
their valuable marketing messages to look like email, and so would
resist changing.  It'll be interesting to see how successful ADV:
turns out to be in reality.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 26 Nov 2003 12:14:07 -0500

> and delivers the choice to the recipient not the sender.

Personally I don't mind hearing about new ideas, but you have to
explain why the new ideas are any better or different from the old
ones.  A free-form debate on a mailing list may or may not do it:
reference to a detailed document or description would be better.  For
instance:

 - What can "pull" do that "push + sender-system-validation" can not?

My imagination may be limited, but I can't think of anything other than
that "pull" introduces a whole nother round-trip conversation.  (Now,
"pull" might be able to have other interesting things layered on top
of it, such as issuance of tickets or acceptance criteria or
redirections, but that's a more extended conversation).

 - What can "push + sender-system-verification" do that "pull" can not?

Again with my limited imagination, it seems to me that
"push+validation" supports other things in the requirements document
(such as roaming) a lot better than "pull" -- and also supports
multiple sender systems better.

(Note that I am not really looking for answers here, just pushing fodder
for any potential document.)

> could be actioned and a conviction sought and got.

   5xx

mm

---

From: Bill Cole <[email-masked]>
Date: Wed, 26 Nov 2003 13:28:07 -0500

At 5:04 PM +0000 11/26/03, Bruce Stephens wrote:
>changes in specific web pages.

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

>If current spammers wanted to use

I see no reason to attempt to accommodate spamming or intentional 
spammers in any way. One of the problem areas in dealing with spam is 
the collateral damage caused by every approach. As long as the only 
real difference between spam and some non-spam is whether the 
recipient asked for it and we lack any reliable deployed means of 
making that determination programmatically, every mechanism for 
stopping spam from being delivered will be fuzzy and stop some 
non-spam. Getting the non-spam broadcast material out of email 
altogether (email never having been a really suitable medium for it 
in the first place) reduces the risks of anti-spam measures 
clobbering material that is not really abusive.

>personal messages so that people are more likely to read them.

Right. Spammers use email because it is a medium that is open to 
spamming. Unfortunately, the most direct ways for stopping spam tend 
to catch all broadcast email even if it is desired by the recipients. 
If all the non-spammers doing broadcast email move to other media, 
the only people doing broadcast email will be spammers, and it will 
be open season. :)

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

>However, I suspect even that market wants

Tagging subject headers in SMTP mail is a losing proposition. It is 
legally questionable in the US and the 'You CAN SPAM" act's mandate 
for it almost surely will see a legal challenge from someone serious 
enough to put that piece on hold long enough that it won't ever make 
a difference.

-- 
Bill Cole
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:33:48 -0500

> for any potential document.)

I would second some of these points. Before going into the technical 
details of how it works, lets figure out why would this make things 
better. It might be useful if you use the checklist in the end of the 
technical considerations document.

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"And this too shall come to pass"
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:43:36 -0500

Bill Cole wrote:
> 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.
> 

Does RSS itself present a perfect consent system? The readers choose 
what to subscribe to, and when to unsubscribe, with the them having 
complete control over consent to read or not read certain 
communications? If complete consent control can be created in email, 
with the sender in charge at all times, then that would solve spam, 
since the sender must actively subscribe to something to receive it. 
That is one of the motiviations behind pull systems, where a hybrid 
approach of push and pull is used.

Yakov
-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"One who watches the wind will never sow, and one who keeps his eyes on 
the clouds will never reap" (Ecclesiastes 11:4)
-------

---

From: Bill Cole <[email-masked]>
Date: Wed, 26 Nov 2003 16:43:15 -0500

At 3:43 PM -0500 11/26/03, Yakov Shafranovich wrote:
>Does RSS itself present a perfect consent system?

It seems so to me. RSS is strictly a client-initiated pull system. In 
essence it is a layer of XML metadata describing resources which are 
primarily transferred via HTTP at the request of the client.

>The readers choose what to subscribe to, and when to unsubscribe, 
>with the them having complete control over consent to read or not 
>read certain communications?

Yes.  The reader's RSS software (usually referred to as an 
'aggregator') regularly updates whatever 'feeds' the user subscribes 
to in order to present whatever might be new in those feeds. The 
critical mass for RSS has come from weblogging software and sites 
that provide RSS feeds. The RSS 2.0 spec is at 
http://blogs.law.harvard.edu/tech/rss and there is a somewhat 
competitive RDF-based RSS 1.0 that I gather has some serious 
adherents as well.

>If complete consent control can be created in email, with the sender 
>in charge at all times, then that would solve spam, since the sender 
>must actively subscribe to something to receive it. That is one of 
>the motiviations behind pull systems, where a hybrid approach of 
>push and pull is used.

I think that pull systems are less 'email' the more purely they 
follow 'pull' models. The example of the blogging universe 
predominantly using RSS as the means of content providers getting 
material to readers rather than the traditional mailing list with all 
of its clunkiness is a good sign.

Email may be the 'killer app' of the Internet that can be made to do 
everything, but it is not designed to do everything well, and it may 
simply be time to start narrowing what email is allowed to do in 
order to push the traffic into more suitable media: many-way 
discussions to NNTP, serial broadcast to RSS.

-- 
Bill Cole                                  
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 17:33:26 -0500

....
>> must actively subscribe to something to receive it. That is one of the 
>> motiviations behind pull systems, where a hybrid approach of push and 
>> pull is used.
> 
> 
> I think that pull systems are less 'email' the more purely they follow 
> 'pull' models. The example of the blogging universe predominantly using 
> RSS as the means of content providers getting material to readers rather 
> than the traditional mailing list with all of its clunkiness is a good 
> sign.
> 
> simply be time to start narrowing what email is allowed to do in order 
> to push the traffic into more suitable media: many-way discussions to 
> NNTP, serial broadcast to RSS.

Can we connect the two: can mailing lists be distributed via RSS, with 
an ability to receive them in an MUA, and ability to respond to them via 
email.

Yakov

-------

---

From: "Chris" <[email-masked]>
Date: Thu, 27 Nov 2003 09:35:13 +1030

> primarily transferred via HTTP at the request of the client.

To get a RSS "notification system" up and running to replace bulk email
would require a huge investment

You would have to get every one to load a seperate application to their
machine to monitor the rss feeds
or hope they log on to their secured RSS fed web page, and who would host
these fed pages?

And why would a webmaster like myself turn to a system like that?
I know I would not, at the most I would implemented it beside my normal mail
system.
and then send an e-mail message "please look at your RSS feed new info is
available"

Isn't it better to try and fix what everyone already has

if you can do it without requesting that the masses learn a new program then
thats the way we should move

So whether it be a pull system or a dns based sender verification system
(which pull is without the structural changes)
or some new sender identification system.

As long as it enables people to continue using the software they have
familiarised themselves with.

Regards
Chris

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 18:07:21 -0500

> or hope they log on to their secured RSS fed web page, and who would host

We are not talking about a notification system, rather we are talking 
about having the *bulk* email content for things like mailing lists 
delivered via RSS itself. A person would have a plug-in for his MUA that 
checks periodically just like POP3 and have the option to reply via 
email (Paul Judge mentioned in a different thread that these programs 
already exist).

Yakov

-------

---

From: Bill Cole <[email-masked]>
Date: Wed, 26 Nov 2003 19:17:31 -0500

At 5:33 PM -0500 11/26/03, Yakov Shafranovich wrote:
>>>If complete consent control can be created in email, with the 
>>>sender in charge at all times, then that would solve spam, since 
>>>the sender must actively subscribe to something to receive it. 
>>>That is one of the motiviations behind pull systems, where a 
>>>hybrid approach of push and pull is used.
>>
>>
>>material to readers rather than the traditional mailing list with 
>>all of its clunkiness is a good sign.
>>
>>Email may be the 'killer app' of the Internet that can be made to 
>>do everything, but it is not designed to do everything well, and it 
>>may simply be time to start narrowing what email is allowed to do 
>>in order to push the traffic into more suitable media: many-way 
>Can we connect the two: can mailing lists be distributed via RSS, 
>with an ability to receive them in an MUA, and ability to respond to 
>them via email.

'Can' is a fuzzy word. I am sure that such things are possible, but I 
am not familiar with any particular implementations.  After all, the 
90's brought us single clients that handle SMTP, POP3, IMAP, and NNTP 
so seamlessly that many people have no concept of news and mail being 
different things or of the fact that there are different protocols 
involved in sending and receiving mail. The place to look for how 
people are using RSS and creating end-user tools for it is in the 
blogging world. I am not familiar with all the available tools, but 
since Mr. Judge says that MUA-integrated aggregators exist and it 
seems a natural integration, I assume that they do.

This is really getting back to what some people (including me) have 
been saying for a long time: the solution to spam cannot come from 
more engineering, because the problem is not a technical one. 
Restricting broadcast email (by which I mean messages sent via SMTP) 
is not all that difficult, and there are working examples of systems 
that do an extremely effective job of it. Unfortunately, broadcast 
email is not currently all spam, so whacking broadcast email 
altogether would be a bad thing. If the *social* change can be 
effected of getting non-spammers who now use SMTP for broadcasting to 
use other available mechanisms like RSS, the technical aspects of 
eliminating the spam (i.e. all broadcast email that can't migrate to 
RSS or some other pure-pull mechanism) are  not quite trivial, but 
are certainly straightforward.

Bringing in another subthread to this: the advantage of ordaining RSS 
as the preferred protocol/medium for one-way or heavily asymmetric 
broadcasting (i.e. most marketing and news materials) as well as for 
guided/led/facilitated discussions (i.e. like most weblogs that take 
reader comments) and NNTP as the preferred mode for multi-way 
ownerless discussion group is that unlike the approach of building an 
all-new mail protocol or hacking more extensions onto SMTP, there 
isn't a new protocol needing a flag day, and early adopters can get a 
benefit. As proof, note that we have people making the move away from 
SMTP mail NOW because of the fallout from the spam wars. Spamcop runs 
a news server, not a listserver. Blog sites offer users updates via 
RSS, not email notification.

-- 
Bill Cole                                  
[email-masked]

---

From: J C Lawrence <[email-masked]>
Date: Wed, 26 Nov 2003 19:23:31 -0500

On Wed, 26 Nov 2003 18:07:21 -0500 
Yakov Shafranovich <[email-masked]> wrote:

> delivered via RSS itself. A person would have a plug-in for his MUA
> that checks periodically just like POP3 and have the option to reply
> via email (Paul Judge mentioned in a different thread that these
> programs already exist).

To state the obvious, this requires IP connectivity between the feed
site and the consumer, something that is frequently enough not true
currently.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email-masked]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 19:43:26 -0500

Bill Cole wrote:
> 
> This is really getting back to what some people (including me) have been 
> saying for a long time: the solution to spam cannot come from more 
> engineering, because the problem is not a technical one. Restricting 
> broadcast email (by which I mean messages sent via SMTP) is not all that 
> difficult, and there are working examples of systems that do an 
> extremely effective job of it. Unfortunately, broadcast email is not 
> currently all spam, so whacking broadcast email altogether would be a 
> bad thing. If the *social* change can be effected of getting 
> non-spammers who now use SMTP for broadcasting to use other available 
> mechanisms like RSS, the technical aspects of eliminating the spam (i.e. 
> all broadcast email that can't migrate to RSS or some other pure-pull 
> mechanism) are  not quite trivial, but are certainly straightforward.
> 
> Bringing in another subthread to this: the advantage of ordaining RSS as 
> the preferred protocol/medium for one-way or heavily asymmetric 
> reader comments) and NNTP as the preferred mode for multi-way ownerless 
> discussion group is that unlike the approach of building an all-new mail 
> protocol or hacking more extensions onto SMTP, there isn't a new 
> protocol needing a flag day, and early adopters can get a benefit. As 
> proof, note that we have people making the move away from SMTP mail NOW 
> because of the fallout from the spam wars. Spamcop runs a news server, 
> not a listserver. Blog sites offer users updates via RSS, not email 
> notification.
> 
> 

Do you think that we can get some folks together and produce an 
evaluation document outlining the pros and cons? This would be very 
useful for further discussion.

Yakov

-------

---

From: Bill Cole <[email-masked]>
Date: Wed, 26 Nov 2003 21:21:45 -0500

At 7:23 PM -0500 11/26/03, J C Lawrence  imposed structure on a 
>site and the consumer, something that is frequently enough not true

True. The 2 common cases that come to my mine would be:

1. Intermittent connectivity. In this situation users would do 
essentially what they do now with intermittent connectivity for 
newsgroup access: connect to pull the current RSS file and connect to 
pull whatever content they want or sent any comments/replies.

2. Disjoint connectivity, i.e. behind a strong firewall. In this case 
the RSS updates could be proxied in the same way as web access is 
proxied in such environments.

-- 
Bill Cole
[email-masked]