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

From: "Chris" <[email-masked]>
Date: Sun, 30 Nov 2003 10:50:15 +1030

> 
> 
> Whether or not pull eliminates spam is besides the point.
> 
> Pull eliminates false positives which are a serious problem for email
> broadcasters. It does not matter how good some spam filter might be in
> theory, if you are on the sending side you have to deal with the rubbish
> people use, or more accurately their ISP uses.
> 
> 

I am confused Phill. this sounds like a promotion of pull ?

Regards
Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hallam-Baker, Phillip
> Sent: Sunday, November 30, 2003 9:43 AM
> To: 'Scott A Crosby'; Yakov Shafranovich
> Cc: Chris; Hallam-Baker, Phillip; [email-masked]
> Subject: [Asrg] RE: 6. Proposals - Pull System (revisited)
> 		Phill
> 
> > -----Original Message-----
> > From: Scott A Crosby [mailto:[email-masked]]
> > Sent: Saturday, November 29, 2003 1:34 AM
> > To: Yakov Shafranovich
> > Cc: Chris; Hallam-Baker, Phillip; [email-masked]
> > Subject: Re: 6. Proposals - Pull System (revisited)
> > 
> > 
> > On Wed, 26 Nov 2003 18:05:13 -0500, Yakov Shafranovich 
> > <[email-masked]> writes:
> > 
> > > Chris wrote:
> > > >>>this is a research group. we should research and then make
> > > >>>recommendations
> > > >>
> > > >>This is an engineering workgroup, not a fantasy land workgroup.
> > > >>The scope is
> > > >>control of spam. Any protocol changes have to be feasible.
> > > >>
> > > >>BEFORE you propose throwing out SMTP you have to explain 
> > exactly what is
> > > >>wrong with it and the reason why incremental change is 
> > not possible.
> > > > Please re read my original post
> > > 
> > > > I do not intend to throw out SMTP they are your words
> > > > pull *IS* smtp
> > > > with two extra steps outgoing request and incoming accept/deny
> > > > both can use the current infrastructure UNCHANGED
> > > >
> > > 
> > > 
> > > The question is how is going to help stem spam. That needs to be
> > > answered before going into minute details of implementation.
> > 
> > 
> > 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 ephemeral anymore.
> > 
> > By a pull system what I mean is a system where a sender pushes an
> > announcement that a message is ready. A recipient then 'pulls' the
> > message from the sender at a later time just as they are. The push
> > message contains a nonce for retrieval and a cryptographic digest of
> > the message.
> > 
> > With a pull system, you can 'retroactively' block access to messages
> > sent from malicious serveres, by exploiting the hours or days between
> > being sent and being read. This is because the messages have yet to be
> > distributed to a million mailboxes.
> > 
> > Whether or not this is worth a protocol change I won't say, but it is
> > another mechanism.  I hate to say it, but from reading ASRG, people
> > seem unwilling to make hard choices. 
> > 
> > Scott
> > 
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg

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

---

From: "Chris" <[email-masked]>
Date: Sun, 30 Nov 2003 10:50:13 +1030

>
> What exactly is the specific failing of SMTP which is addressed by pull
> systems?
>
> Have I missed something?

yes you have

pull forces the id of the remote server *without* rewriting the entire mail
transport system

it can be implemented gradually

i.e. mail from non pull servers are given a grace period (1-2yrs?)

after that point all non pull mail is returned with an error message

most important....

PULL DOES NOT DECIDE WHAT IS OR WHAT ISN'T SPAM.

only the receiver is in the position to do that.

thats why I recommend a "class" system be instantiated at the same time (as
pull or whatever ID system)

so the user can set rules something like
"deny all messages from unknown"
"deny class::UCE"
"accept class::UCE::hardware::electrical_tools"
"accept class::personal"
(examples only)

this is my legal + technical argument

both must co-exist to get a spam *reduction* system working

there will never be a spam prevention system

because spam cannot be defined!

Regards
Chris

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jon
> Kyme
> Sent: Saturday, November 29, 2003 10:46 PM
> To: Dag Kihlman
> Cc: ASRG
> Subject: [Asrg] Re: 6. Proposals - Pull System (revisited)
>
>
> What exactly is the specific failing of SMTP which is addressed by pull
> systems?
>
> Have I missed something?
>
>
>
>
>
>
>
>
>
>
>
> --
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2003 10:20:55 -0800

> From: Yakov Shafranovich [mailto:[email-masked]]

> It also provides full control to the receiver on whether to 
> "pull" the 
> data or not, and shifts the burden of storing the data to the 
> spammers.

It shifts that burden for all email senders.

It seems as if what you want is the ability to read just the headers of an
email message and then decide to reject it. 

This is possible in the existing SMTP deployment, just send a refusal code
and slam the connection shut as soon as you detect spam.

	Phill

---

From: "Chris" <[email-masked]>
Date: Sun, 30 Nov 2003 10:50:59 +1030

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

Please define spam

Regards
Chris