Re: [Asrg] Consent Proposal

> > From: "Mark McCarron" <markmccarron_itt(_at_)hotmail(_dot_)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(_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

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg