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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Nov 2003 06:25:16 -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?
> 
> No of course not but that does not mean that it cannot happen

On the contrary, unless you can persuade Sendmail, Microsoft, Lotus to take
notice of you your project is dead on arrival. 

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

You don't seem to be very aware of IETF history, but backwards compatibility
and support for legacy systems has a huge premium. Forget persuading
Microsoft, you are not going to persuade the IESG the need for a
discontinuous change.

IF the industry did decide to change the email protocol in a fundamental way
any new protocol would be based on the Web Services framework.

		Phill

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

---

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

> notice of you your project is dead on arrival. 

The major MTA/MUA folks are monitoring the group. If a viable proposal 
comes up, convincing them would not be that hard. The issue is proving 
that something is viable.

> wrong with it and the reason why incremental change is not possible.

Once again, the checklist in the end of the tech considerations document 
  might prove helpful.

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: Thu, 27 Nov 2003 09:35:11 +1030

> notice of you your project is dead on arrival.

you only need to convince one, the rest will adopt if not to do so will
leave them unable to connect

> 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

> any new protocol would be based on the Web Services framework.

fundamental change ?

again I refer you to my original mail

take a close look at the comparison (steps involved) between current and
proposed

---

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

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

Yakov

-------

---

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

> answered before going into minute details of implementation.

As mentioned previously

one mans spam is another mans fodder

for me its not a question of stemming spam, its a question of giving control
to the recipient, and taking it from the sender.

this can only be done if both a legislative and technical approach be used

We need to be able to identify the sender, and punish them if they step
outside of acceptable policies

A classification system or can spam or pics. Whatever is enshrined into law.

identification is a technical step
punishment is a legal one

so if we can agree on this, then what is the next step?

Again in my opinion it is to find a system that can be implemented without
disruption to the masses.

Sender verification can be achieved in many ways.

Which is the best and easiest to implement?

I don't doubt that regardless of Phill's comments if a vendor can help
reduce the impact of spam in a co-ordinated (interoperable) way they will
very quickly come aboard

would you as a vendor want to be seen as the one NOT combatting spam?

Regards
Chris

P.S.

How many spammers do you think would continue to do so if they could be
readily identified. 5% 50% 100%?

I only know of a handful of spammers that have come out of the closet. most
hide behind fake email addresses or international borders.

---

From: Scott A Crosby <[email-masked]>
Date: 29 Nov 2003 00:33:32 -0600

> 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