Subject: Re: [Asrg] email pull (was RE: Authentication )

From: mathew <[email-masked]>
Date: Tue, 1 Apr 2003 09:06:47 -0500

On Monday, Mar 31, 2003, at 23:11 US/Eastern, Chuq Von Rospach wrote:
> On Monday, March 31, 2003, at 07:22  PM, mathew wrote:
>>> Or if the network between us is down, or if the server is overloaded 
>>> because someone who didn't know any better something to everyone in 
>>> his address book 100 times.
>>
>> If the network between us goes down, then the mail doesn't get 
>> delivered until the network goes up again. Just like if the network 
>> between the sender's SMTP server and my mail server goes down with 
>> the present system, the mail doesn't get delivered.
>
> But now, with MX records, when a connection comes up, the servers 
> coordinate delivery. As I understand it, the system you're proposing 
> is doing it at the client level, so updates only happen when the user 
> is asking for them. For an unstable connection, that reduces the 
> likelihood of successful delivery significantly.

Well, it may be significant in mathematical terms, but if it's changing 
the probability from 0.01% to 0.02% I think most people could live with 
it. That's why I think any arguments about reliability effects of push 
vs pull will need to involve some actual modeling and simulation.

>> If an idiot sends something 100x to everyone in his address book, 
>> that's unsolicited bulk e-mail, so the fact that I don't receive it 
>> is a feature.
>
> but it still causes network and server prolems, so dealing with the 
> side effects is necessary. Systems can't assume perfect conditions.

It's necessary now, too. There are any number of ways for enterprising 
idiots to cause server overload. That doesn't mean the protocols that 
allow them to do so are flawed.

>>>  What server (if any) keeps the message for future reference?
>>
>> What server (if any) keeps my e-mail for future reference now?  None, 
>> that I know of.
>
> anyone currently on an IMAP server, or on POP with "leave on server" 
> turned on. So, would a user require to pull it and copy it to "my" 
> server, or does it stay on that server, like it would on a USENET or 
> IMAP server?

There are three possibilities:
1) Leave it on the remote server.
2) Move it to my local server.
3) Move it to my local machine.

1) is clearly bad, so I imagine 2 and 3 would be chosen.

>>>  What if it's a person who never deletes his e-mail?
>>
>> Then his hard disk fills up.
>
> not if the email he's never deleting lives on your server, because 
> that's where it was accepted from and still stored.

Right, and this is a problem with current e-mail systems, hence it's 
not a problem specific to email pull.

>>>  Or reads it 1000 times (DOS attack?).
>>
>> Yes, if he has a broken mail client that doesn't download and cache 
>> the mail, he might fetch it lots of times. Just like a broken web 
>> client might fetch the same image every time it's included on any web 
>> page on your site.
>
> okay, so you're seeing this as some client-driven version of a suck 
> feed. you could make it work, but it's not how I'd do it. You're 
> better off layering on what we already have, using some variation of 
> the ETRN command -- but then you still have to have some way to tell 
> the other side there's mail waiting to receive. so aren't we simply 
> setting up a system to send email to tell someone there's email being 
> sent?

Kind of, yes. The point is that the distributed hard-to-stop 
message--the "I have e-mail for you" message--cannot contain an 
advertisement, because it's just a unique identifier of some kind. To 
get the actual message requires that there be a verifiable route back 
to the originating messaging account. This provides us with several new 
ways to fight spam, including 1) cancelling spam en masse after it has 
been sent, and 2) shifting of the costs of spam onto the people who 
provide spammers with access (whether deliberately or accidentally).

mathew

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Apr 2003 13:26:58 -0800

> At 11:21 AM -0800 4/2/03, Hallam-Baker, Phillip wrote:
> >The way I see it, the collapse of Usenet for serious purposes
> >has resulted in a lot of the functions tradtionally associated
> >with news being transferred to email. RSS has a real and strong
> 
> I'm not sure I buy that.  Most of the early high-volume newsgroups 
> were in fact email lists gatewayed to News.  But in any case, I think 
> RSS is out of the scope of this group.  We can come out and have a 
> big announcement that says that the solution to fixing email is to 
> stop using it.

No, it is one solution to the problems caused by spam solutions.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Apr 2003 17:14:59 -0800

> On Wed, Apr 02, 2003 at 10:44:15AM -0800, Chuq Von Rospach wrote
> 
> > which is where a lot of this stuff is starting to move. If you can
> > get some of this content out of the SMTP stream, it's effectively
> > whitelisted, so we don't have to worry about blocking it any more,
> > making our job on other stuff marginally easier.
> 
>   This actually sounds very workable.  *AND YOU DON'T NEED A BRAND NEW
> PROTOCOL* !!!  APOP or NNTP or webmail over SSL would all work just
> fine.

NNTP would work OK up to a point. the problem here is that the protocol
and the clients are built on the assumption that there is one true Usenet
and getting them to recognize multiple servers is hard.

The other problem is guilt by association with Usenet.

RSS is actually getting a lot of use and has been arround for some time.
The problem is that it is defined in RDF rather than XML syntax.

		Phill