Fwd: Re: [Asrg] Consent Proposal

Yakov Shafranovich <research@solidmatrix.com> Mon, 30 June 2003 18:43 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10348 for <asrg-archive@odin.ietf.org>; Mon, 30 Jun 2003 14:43:41 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UIhEi04745 for asrg-archive@odin.ietf.org; Mon, 30 Jun 2003 14:43:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3cQ-0001EM-6J for asrg-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 14:43:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10327; Mon, 30 Jun 2003 14:43:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3cM-0003Rw-00; Mon, 30 Jun 2003 14:43:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X3cG-0003Rq-00; Mon, 30 Jun 2003 14:43:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3cD-00018I-0p; Mon, 30 Jun 2003 14:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3c0-000176-O8 for asrg@optimus.ietf.org; Mon, 30 Jun 2003 14:42:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10318 for <asrg@ietf.org>; Mon, 30 Jun 2003 14:42:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3bx-0003RW-00 for asrg@ietf.org; Mon, 30 Jun 2003 14:42:45 -0400
Received: from 000-235-455.area5.spcsdns.net ([68.27.158.252] helo=68.27.158.252 ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19X3bf-0003RH-00 for asrg@ietf.org; Mon, 30 Jun 2003 14:42:29 -0400
Message-Id: <5.2.0.9.2.20030630144152.00ba85f0@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Fwd: Re: [Asrg] Consent Proposal
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Mon, 30 Jun 2003 14:41:59 -0400

>X-Originating-IP: [62.252.200.188]
>X-Originating-Email: [markmccarron_itt@hotmail.com]
>From: "Mark McCarron" <markmccarron_itt@hotmail.com>
>To: research@solidmatrix.com
>Subject: Re: [Asrg] Consent Proposal
>Date: Mon, 30 Jun 2003 18:39:09 +0000
>X-OriginalArrivalTime: 30 Jun 2003 18:39:09.0572 (UTC) 
>FILETIME=[E4C9CC40:01C33F36]
>
>
>I am not refering to constructive critism, this is most welcome.  However, 
>I am fully aware of people's agendas on this matter, this is what I am 
>refering to.  Also the group will be the ones deciding the guidelines for 
>the 'GIEIS' system, this is its main reason for inclusion.  Not technical 
>input, as there seems to be very few who can go that deep.  It would be 
>most welcome.
>
>I'm afriad that all enquiries are kept confidential due to partnerships 
>with current anti-spam solution providers.
>
>Mark McCarron.
>
>
>>From: Yakov Shafranovich <research@solidmatrix.com>
>>To: "Mark McCarron" <markmccarron_itt@hotmail.com>,asrg@ietf.org, "Paul 
>>Judge" <paul.judge@ciphertrust.com>
>>Subject: Re: [Asrg] Consent Proposal
>>Date: Mon, 30 Jun 2003 14:31:44 -0400
>>
>>
>>>>From: "Mark McCarron" <markmccarron_itt@hotmail.com>
>>>>Subject: Re: [Asrg] Consent Proposal
>>>>Date: Mon, 30 Jun 2003 18:21:09 +0000
>>>>
>>>>The 'GIEIS' system is not designed to be backwards compatible.  There 
>>>>is no possible way for any solution to arise using the current 
>>>>system.  If it could be achieved it would have happened by now.
>>>>
>>>>I am completely unconcerned with objections.  As I said before, I not 
>>>>designing a system to win a 'popularity' contest.  I am concerned with 
>>>>only one thing, complete effectiveness.  Nothing else.
>>
>>Then why are you participating in the group? If you are not here to ask 
>>for our opinions, why waste our time and effort on this? This group is 
>>intended for people to discuss the spam issue and get opinions, comments, 
>>and objections, so the kinks in different proposals can be worked out 
>>before they are implemented.
>>
>>>>I looked at the systems you from the links you provided.  They can all 
>>>>be bypassed without too much effort.
>>>>
>>>>It will not be an alternative, the system will not be active until the 
>>>>patner companies are ready.  Then it will become exclusive.
>>
>>Can you name a few partners?
>>
>>>>I read mike's proposal, its slightly different from my system.  You 
>>>>will understand this within the next hour or so.
>>>>
>>>>Mark McCarron.
>>>>
>>>>
>>>>
>>>>>From: Yakov Shafranovich <research@solidmatrix.com>
>>>>>To: "Mark McCarron" <markmccarron_itt@hotmail.com>,asrg@ietf.org
>>>>>Subject: Re: [Asrg] Consent Proposal
>>>>>Date: Mon, 30 Jun 2003 13:54:33 -0400
>>>>>
>>>>>At 05:06 PM 6/30/2003 +0000, Mark McCarron wrote:
>>>>>
>>>>>>Thankyou for your reply.  I have not been posting this conversation 
>>>>>>to the group.  You can if you wish, you have my full permission to do so.
>>>>>>
>>>>>>Sorry, I wasn't refering to you personally about selling anti-span 
>>>>>>solutions, that was just a general comment.  'The Ultimate Spam 
>>>>>>System' may be too hard to handle, but that is an accurate 
>>>>>>description of the system.
>>>>>
>>>>>There are numerous other proposals that seek to change the underlying 
>>>>>infrastructure - YOU ARE NOT ALONE. Example of this would be Walter 
>>>>>Dnes's proposal, another example would the AMDP protocol 
>>>>>(http://www.amdpmail.com/), MTP protocol 
>>>>>(http://www.danisch.de/tmp/draft_mtp.txt), etc. Also take a look at 
>>>>>this list message 
>>>>>(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00882.html) 
>>>>>that lists objection to new systems.
>>>>>
>>>>>>Also, as you learn within the next few hours, the system will be near 
>>>>>>impossible to hack based upon its architecture.  I have complete the 
>>>>>>overview today, and it will be released in the next coming hours to 
>>>>>>the mailing group.
>>>>>>
>>>>>>I feel that change to the architecture is the magic bullet 
>>>>>>solution.  I am not claiming this will be easy, but it is certainly 
>>>>>>far from impossible.
>>>>>
>>>>>We know as a group that changing the architecture will significantly 
>>>>>reduce the spam problem. However, moving over and implementing such 
>>>>>change is extremely hard as Alan DeKok and many other pointed out. Our 
>>>>>goal is to create a cohesive framework for anti-spam solutions with 
>>>>>short, medium and long term solutions.
>>>>>
>>>>>>This will not be an alternative email system that will reside along 
>>>>>>side the current one.  It will replace it completely making it 
>>>>>>entirely redundant.
>>>>>
>>>>>However until it does, it will operate side by side with the regular 
>>>>>SMTP. Thus, its alternative.
>>>>>
>>>>>>The US military is instigating a change to IPv6 in mid 2004 or 2006 
>>>>>>(I'll clear that date up, the source is at Reuters, I read it a few days ago).
>>>>>>This will have a global impact, I believe that 'GIEIS' would be 
>>>>>>implemented at this stage also.
>>>>>
>>>>>IPv6 is backwards compatible with IPv4 UNLIKE your system, Walter 
>>>>>Dnes's proposal and many others have accounted to backwards 
>>>>>compatibility, you have not yet as seen from this quote:
>>>>>
>>>>>"What would happen if this system was implemented and I tried to send 
>>>>>spam or even an email from an older server?
>>>>>The message would not be received by those protected by 'GIEIS'."
>>>>>
>>>>>>Also, my system would inform users when a limit was reached.  Users 
>>>>>>would know if they sent this volume of email and the system would 
>>>>>>have information of those who suspect their machine was infected or hacked.
>>>>>
>>>>>This idea has been proposed before by Mike Rubel 
>>>>>(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg04616.html).
>>>>>
>>>>>>Mark McCarron.
>>>>>>
>>>>>>
>>>>>>>From: Yakov Shafranovich <research@solidmatrix.com>
>>>>>>>To: "Mark McCarron" <markmccarron_itt@hotmail.com>
>>>>>>>Subject: [offlist] Re: [Asrg] Consent Proposal
>>>>>>>Date: Mon, 30 Jun 2003 12:29:09 -0400
>>>>>>>
>>>>>>>The consent framework is not a specific solution - its a framework. 
>>>>>>>Various anti-spam tools and proposals including yours will fit into 
>>>>>>>this framework. It is more of a bird-eye view of all anti-spam solutions.
>>>>>>>
>>>>>>>As for your specific proposal, first of all my company does not 
>>>>>>>write or distribute anti-spam software so I do not have "financial 
>>>>>>>considerations" here. I also do not like the name calling between 
>>>>>>>different group members - it causes a feeling of discord. 
>>>>>>>Additionally, calling your system "the ultimate anti spam system" is 
>>>>>>>a bit too much for most members to handle. I would like to see 
>>>>>>>everyone to stay away from name calling while keeping in mind that 
>>>>>>>this is a technical list.
>>>>>>>
>>>>>>>As for the technical considerations of your proposal, what you are 
>>>>>>>proposing essentially is an alternative email system along side of 
>>>>>>>the current one. This is similar to the system being proposed by 
>>>>>>>Walter Dnes except that his system does not rely on cryptographic 
>>>>>>>methods (see 
>>>>>>>https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05683.html). 
>>>>>>>The problem with this system is three fold - one is the fact that 
>>>>>>>everyone has to change in order to use it which is also a problem 
>>>>>>>with Walter's proposal. The second problem is privacy - what you are 
>>>>>>>essentially proposing is that every single email message will have a 
>>>>>>>tracking number that can be traced to the sender. This creates 
>>>>>>>potential for abuse. Third, inter-operability with existing email is 
>>>>>>>a big problem as well since no one would want to use an alternative 
>>>>>>>system unless many people will switch over to it and many people 
>>>>>>>will not switch to it until others use it. If you look through the 
>>>>>>>mailing list archive somewhere there is a list of requirements by 
>>>>>>>Eric Williams. I asked him to email me the most recent copy which I 
>>>>>>>will forward to you. Among those requirements, deployment and 
>>>>>>>inter-operability rank pretty high up.
>>>>>>>
>>>>>>>It is obvious that creating an alternative email system will cut 
>>>>>>>down on spam since its the open nature of the Net that causes it. 
>>>>>>>But as I mentioned before, cell phone companies build their SMS 
>>>>>>>systems based on email (at least in US) and SMTP, so you can see how 
>>>>>>>pervasive existing standards are. Additionally, as Barry Shain has 
>>>>>>>mentioned many times before, much of spam is being sent via hacked 
>>>>>>>computers. Even with your rate limits in place, spammers can 
>>>>>>>probably be able to coordinate many hacked computers to send spam 
>>>>>>>from legit GEIS/EAS senders.
>>>>>>>
>>>>>>>Among the various discussions over the last few months, many of the 
>>>>>>>group members have reached a conclusion that there is not magic 
>>>>>>>silver bullet that will stop spam overnight. Rather, a combination 
>>>>>>>of various solutions and proposals will start cutting into the spam 
>>>>>>>flow until it stops.
>>>>>>>
>>>>>>>Yakov
>>>>>>>
>>>>>>>P.S. I am replying to you off-list since the message that you sent 
>>>>>>>me was not CCed to the group list. Please let me know if this is 
>>>>>>>correct because I would rather have discussions in public so we can 
>>>>>>>get comments from other people.
>>>>>>>
>>>>>>>At 03:23 AM 6/30/2003 +0000, Mark McCarron wrote:
>>>>>>>
>>>>>>>>Paul is an excellent poster, he has the subject matter clearly defined.
>>>>>>>>I see he has broken the issue down to two major catagories, local 
>>>>>>>>and global.
>>>>>>>>The consent system is going to be difficult to implement, I haven't 
>>>>>>>>seen anything that actually deals with issue of how to prevent sending spam.
>>>>>>>>The 'GIEIS' system would be on the middle ground in terms of 
>>>>>>>>consent and its application would be global.  It forces the 
>>>>>>>>erasure/stoppage of all fraudulent email but also allows the 
>>>>>>>>end-user the whitelist options.
>>>>>>>>
>>>>>>>>There has been a lot of confusion on the system and I have been 
>>>>>>>>compiling all the postings in one file so that I can clearly 
>>>>>>>>address all concerns.
>>>>>>>>Also, there seems to be quite a bit of opposition to the idea of a 
>>>>>>>>centralised angency and a lot of paranoid responses to it.  The 
>>>>>>>>more I post on the subject, and the clearer the system has become, 
>>>>>>>>concerns have dwindled.  The main opposition now comes from those 
>>>>>>>>advocating 'anti-spam software' and this is just to protect 
>>>>>>>>financial considerations.
>>>>>>>>
>>>>>>>>'GIEIS' is the only proposal I have ever seen that can stop all 
>>>>>>>>fraudulent email.  Are you aware of any others?
>>>>>>>>
>>>>>>>>I'm am in the process of designing an Internet draft of the system.
>>>>>>>>It is a major task as there is a lot to go through.  I have 30 
>>>>>>>>pages of comments alone to address, however, all the comments have 
>>>>>>>>a resolution within the 'GIEIS' system.  I will post a complete 
>>>>>>>>accurate proposal of the system in the next few days once I have 
>>>>>>>>compiled all the information together.  It will refer to both 
>>>>>>>>local, global, consent and forced issues.
>>>>>>>>
>>>>>>>>Mark McCarron.
>>>>>>>>
>>>>>>>>
>>>>>>>>>From: Yakov Shafranovich <research@solidmatrix.com>
>>>>>>>>>To: "Mark McCarron" 
>>>>>>>>><markmccarron_itt@hotmail.com>,research@solidmatrix.com
>>>>>>>>>Subject: Re: [Asrg] Consent Proposal
>>>>>>>>>Date: Sun, 29 Jun 2003 22:52:34 -0400
>>>>>>>>>
>>>>>>>>>Take a look at today's message from the chair, Paul Judge, on this 
>>>>>>>>>subject 
>>>>>>>>>(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05968.html). 
>>>>>>>>>The consent framework that we are discussing is not limited to 
>>>>>>>>>end-users only. The generic proposal that I put forth concentrated 
>>>>>>>>>specifically on the end-user and this is probably what is throwing you off.
>>>>>>>>>
>>>>>>>>>Yakov
>>>>>>>>>
>>>>>>>>>At 02:46 AM 6/30/2003 +0000, Mark McCarron wrote:
>>>>>>>>>
>>>>>>>>>>This I understand very well.  What I am asking is, have you been 
>>>>>>>>>>able to overcome any of the limitations I mentioned?
>>>>>>>>>>
>>>>>>>>>>Mark McCarron.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>From: Yakov Shafranovich <research@solidmatrix.com>
>>>>>>>>>>>To: "Mark McCarron" <markmccarron_itt@hotmail.com>,asrg@ietf.org
>>>>>>>>>>>Subject: Re: [Asrg] Consent Proposal
>>>>>>>>>>>Date: Sun, 29 Jun 2003 22:41:54 -0400
>>>>>>>>>>>
>>>>>>>>>>>First of all take a look a the group's charter 
>>>>>>>>>>>(http://www.irtf.org/charters/asrg.html). As the charter states 
>>>>>>>>>>>we are seeking to define an overall consent framework and fit in 
>>>>>>>>>>>all the different spam proposals into it. The proposal below was 
>>>>>>>>>>>put forth to solicit opinions and ideas from people on consent 
>>>>>>>>>>>in general and the consent framework in particular.
>>>>>>>>>>>
>>>>>>>>>>>Yakov
>>>>>>>>>>>
>>>>>>>>>>>At 01:20 AM 6/30/2003 +0000, Mark McCarron wrote:
>>>>>>>>>>>
>>>>>>>>>>>>Yakov,
>>>>>>>>>>>>
>>>>>>>>>>>>This system is very similar, in fact almost identical, to the 
>>>>>>>>>>>>current one employed by Hotmail.  It is not effective in 
>>>>>>>>>>>>eliminating spam, the end user still recieves it and has to 
>>>>>>>>>>>>deal with it.  Also, it does not address the main issue about 
>>>>>>>>>>>>spam and that is the roughly 30% band-width absorbed across the 
>>>>>>>>>>>>Internet by it.  All this seems to do is sort it at the recieving end.
>>>>>>>>>>>>
>>>>>>>>>>>>I also read something about a confirmation being sent back from 
>>>>>>>>>>>>the server, this is just an adaptation of challange response.
>>>>>>>>>>>>
>>>>>>>>>>>>It also does not address the issue of spammer's who use their 
>>>>>>>>>>>>own mail servers.
>>>>>>>>>>>>Can you clear any of these problems up?
>>>>>>>>>>>>
>>>>>>>>>>>>Mark McCarron.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > > > > -----Original Message-----
>>>>>>>>>>>>> > > > > From: Yakov Shafranovich 
>>>>>>>>>>>>> [mailto:research@solidmatrix.com]
>>>>>>>>>>>>> > > > > Sent: Thursday, June 26, 2003 11:23 AM
>>>>>>>>>>>>> > > > > To: asrg@ietf.org
>>>>>>>>>>>>> > > > > Subject: [Asrg] Consent Proposal
>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>> > > > > I would like to provide a generic proposal for
>>>>>>>>>>>>> > > consent-based system
>>>>>>>>>>>>> > > > > as per
>>>>>>>>>>>>> > > > > charter:
>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>> > > > > 1. Users and/or ISP define rules and filters to=20
>>>>>>>>>>>>>filter incoming=20
>>>>>>>>>>>>> > > > > email. Rules/filters are decided by end users and ISPs,
>>>>>>>>>>>>> > > and are not
>>>>>>>>>>>>> > > > > mandated.
>>>>>>>>>>>>> > > > > Every user/ISP can define its own policies ranging=20
>>>>>>>>>>>>>from banning=20
>>>>>>>>>>>>> > > > > all email not digitally signed to blocking HTML.
>>>>>>>>>>>>> > > > > 2. For each email user, the MUA or the ISP maintains a
>>>>>>>>>>>>> > > > > whitelist of trusted
>>>>>>>>>>>>> > > > > senders, blacklist of blocked senders and a graylist of
>>>>>>>>>>>>> > > > > unknown senders.
>>>>>>>>>>>>> > > > > Whitelisted senders go the inbox, graylisted senders 
>>>>>>>>>>>>> go to
>>>>>>>>>>>>> > > > > the bulk folder,
>>>>>>>>>>>>> > > > > and blacklisted senders are either in the spam folder or
>>>>>>>>>>>>> > > > > erased. 3. Whitelists are not only a list of email 
>>>>>>>>>>>>> addresses
>>>>>>>>>>>>> > > > > of trusted senders,
>>>>>>>>>>>>> > > > > but to avoid sender spoofing also have additional 
>>>>>>>>>>>>> features
>>>>>>>>>>>>> > > > > such as digital
>>>>>>>>>>>>> > > > > signatures, certificates, passwords, tokens, etc.
>>>>>>>>>>>>> > > > > 4. Additional automatic whitelist rules are defined 
>>>>>>>>>>>>> as such
>>>>>>>>>>>>> > > > > email from
>>>>>>>>>>>>> > > > > trusted senders (e.g. Habeas) is automatically goes 
>>>>>>>>>>>>> to the
>>>>>>>>>>>>> > > > > inbox unless
>>>>>>>>>>>>> > > > > blacklisted, etc. C/R systems are also integrated and 
>>>>>>>>>>>>> upon
>>>>>>>>>>>>> > > > > receiving a
>>>>>>>>>>>>> > > > > positive response automatically whitelist the sender.
>>>>>>>>>>>>> > > > > 5. Additional automatic blacklist rules are defined 
>>>>>>>>>>>>> such as
>>>>>>>>>>>>> > > > > email coming
>>>>>>>>>>>>> > > > > from known open relays is blocked.
>>>>>>>>>>>>> > > > > 6. Whitelists, graylists and blacklists are stored 
>>>>>>>>>>>>> hashed or
>>>>>>>>>>>>> > > > > encrypted to
>>>>>>>>>>>>> > > > > protect privacy.
>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>> > > > > Any thoughts?
>>>>>>>>>>>>> > > > >
>>>>>>>>>>>>> > > > > Yakov
>>>>>>
>>>>>>_________________________________________________________________
>>>>>>It's fast, it's easy and it's free. Get MSN Messenger today! 
>>>>>>http://www.msn.co.uk/messenger
>>>>
>>>>_________________________________________________________________
>>>>Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile
>>>
>>>
>>>_______________________________________________
>>>Asrg mailing list
>>>Asrg@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/asrg
>
>_________________________________________________________________
>Stay in touch with absent friends - get MSN Messenger 
>http://www.msn.co.uk/messenger


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg