Fwd: Re: [Asrg] Consent Proposal

> From: "Mark McCarron" <markmccarron_itt(_at_)hotmail(_dot_)com>
> To: research(_at_)solidmatrix(_dot_)com
> Subject: Re: [Asrg] Consent Proposal
> Date: Mon, 30 Jun 2003 18:21:09 +0000
> X-OriginalArrivalTime: 30 Jun 2003 18:21:10.0073 (UTC) 
> FILETIME=[615B5290:01C33F34]
>
>
> 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.
> 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.
> 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(_at_)solidmatrix(_dot_)com>
> > To: "Mark McCarron" 
> > <markmccarron_itt(_at_)hotmail(_dot_)com>,asrg(_at_)ietf(_dot_)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(_at_)solidmatrix(_dot_)com>
> > > > To: "Mark McCarron" <markmccarron_itt(_at_)hotmail(_dot_)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(_at_)solidmatrix(_dot_)com>
> > > > > > To: "Mark McCarron" 
> > > > > > <markmccarron_itt(_at_)hotmail(_dot_)com>,research(_at_)solidmatrix(_dot_)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(_at_)solidmatrix(_dot_)com>
> > > > > > > > To: "Mark McCarron" 
> > > > > > > > <markmccarron_itt(_at_)hotmail(_dot_)com>,asrg(_at_)ietf(_dot_)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(_at_)solidmatrix(_dot_)com]
> > > > > > > > > > > > > > Sent: Thursday, June 26, 2003 11:23 AM
> > > > > > > > > > > > > > To: asrg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg