Subject: [Asrg] 6. Solutions - Replacing SMTP - GIEIS Analysis

From: "Mark McCarron" <[email-masked]>
Date: Sat, 05 Jul 2003 02:21:03 +0000

Thankyou for your comments.  My comments are in the body of the message 
below.  This post refers to the 'GIEIS' system currently at version 0.003.  
An update was carried out on the next 4th July 2003.  Datails of the 'CAA' 
have be released as well as details regarding the 'CICFS' filtration system. 
  'GIEIS' has an extensive list of systems to be added and they will appear 
as soon as the documentation can be written.

The 'GIEIS' system can be viewed here at:

http://homepage.ntlworld.com/giza.necropolis

Mark McCarron.

>Message: 14
>Date: Fri, 04 Jul 2003 14:08:57 -0400
>To: [email-masked]
>From: Yakov Shafranovich <[email-masked]>
>Subject: [Asrg] 6. Solutions - Replacing SMTP - GIEIS Analysis
>
>As many group members have noticed in the last few days, Mr. McCarron has
>been posting a large volume of messages to the list regarding the GIEIS
>system that he is developing. The following is my analysis of his proposed
>system and how it falls within the consent framework (current draft at
>http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html). All
>quotes are from (http://homepage.ntlworld.com/giza.necropolis/).
>
>---------
>ANALYSIS
>
>The GIEIS system seems to be a convergence of two proposals: message
>tracking and centralization. Message tracking has been proposed by John
>Fenley as part of the C/R protocol and other proposals (callback, etc.).
>Centralization is not new but is similar to the other proposals on the list
>especially Walter Dnes's "Business Email" proposal. This is also similar to
>the proposal by someone else who suggested registration of all SMTP servers
>and perhaps issuing digital certificates to them.

Mark's Response:

No.  'GIEIS' is a completely new architecture and protocol design for web 
based communications.  It is not similar to issuing digital certificates.  
'GIEIS' creates an additional layer in the net and a buffer for 
communication protocols from end users.  By securing this inner 
communications layer with a centralised system based on encrypted 
communications it eliminates any fraudulent access.

>
>Every message in the GIEIS system is stamped with a tracking number issued
>by the ISP's server (EAS). These servers are in turn authorized  or
>controlled by central entity. Thus two goals are accomplished: spam is
>traceable and action can be easily taken against spammers by kicking them
>off the GIEIS network. Within the consent framework this would correspond
>to the SOURCE TRACKING COMPONENT. The RECEIVER is assumed to have his
>CONSENT POLICY set to accept GIEIS messages, will check the tracking code
>against the central database and grant consent if the code if valid. The
>centralization aspect of the proposal is what actually prevents spam -
>action can be easily taken against the SENDERs by fining them or kicking
>them off the system.
>

Mark's Response:

It would also be a FAIL-CLOSED component.  It removes all traffic not part 
of the 'GIEIS' system.  Also 'GIEIS' does a further check with the sending 
'EAS' for a unique message ID to ensure the message was sent from that 
account.  This eliminates any possibilities of fraud.  The system is a bit 
more complex than that, but yes, it does that as well.

>There are numerous other things mentioned in the GIEIS proposal, all of
>which are either irrelevant to fighting spam such as viruses, or are
>implementation details. Many other spam-related approaches are lumped
>together as well, many of which are irrelevant and have been taken from the
>group discussions without granting credit to their authors. An example of
>that is Gordon's proposal on requiring ASCII only email.

Mark's Response:

There cannot be credits to something I haven't read.  These are simple 
enough concepts that would draw similar conclusions.  Its not rocket 
science.

>
>SUGGESTIONS TO MR. MCCARON
>
>1. Take all the BS out of your proposal and separate the main idea from the
>implementation details.

Mark's Response:

Please detail the 'BS'.

>2. Stop thinking that your system will take over the Net - any system
>implemented will need to accommodate multiple implementation details. You
>will be better off on proposing a system like Truste.

Mark's Response:

'GIEIS' would be the center of the net for completely accurate information 
of various kinds. A commercial body could never secure the Internet, it must 
be a public body.  No one needs another cert. authority what they need is a 
corner-stone behind the Internet that can be trusted.  American business is 
losing $10 Billion a year to spam if we used even £2 Billion on wages alone 
we could have a staff of over 130,000 people at £15,000 per year dedicated 
to the fight against internet fraud.

>3. CREATE A SEPARATE mailing list or discussion area for your proposal
>where you can work out the kinks like the SPF proposal's author did. Then
>present us with a draft.

Mark's Response:

Here will do just fine.  'GIEIS' has no 'kinks' to work out.  Its a complete 
working system.  The overview is being drafted in public from compiled notes 
on the system.  Special focus has been given on areas of concern and thus 
developed at a faster rate.  The GSMTP protocol is now under development.

>4. Participate in defining the consent framework.

Mark's Response:

The consent framework will consist of white and black lists.  There will be 
no greylisting.  A complete opt-out will be allowed by 'GIEIS'.

>5. Give credit where its due, when you use someone's idea - give credit.

Mark's Response:

Credit will be given where credit is due, however, the 'GIEIS' architecture 
is unique.

Mark McCarron.
http://homepage.ntlworld.com/giza.necropolis

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 05 Jul 2003 22:39:27 -0400

At 02:21 AM 7/5/2003 +0000, Mark McCarron wrote:
>...

What is essentially being created is a centralized system combined with 
messages tracking. The details are implementation.

>....

Anything not related to email. All the parts about port scanning, viruses, 
saving children, creating jobs, etc. are extra they can be detailed in the 
implementation details and marketing materials. This group is concerned 
with technical details and a concise technical draft is what we are looking 
for.

>of various kinds. A commercial body could never secure the Internet, it 
>must be a public body.  No one needs another cert. authority what they 
>need is a corner-stone behind the Internet that can be trusted.  American 
>business is losing $10 Billion a year to spam if we used even £2 Billion 
>on wages alone we could have a staff of over 130,000 people at £15,000 per 
>year dedicated to the fight against internet fraud.

Look at ICANN - its non profit - and then look at IcannWatch.com. Also, we 
are looking for a concise technical document, marketing materials are 
irrelevant - they just confuse.

>Here will do just fine.  'GIEIS' has no 'kinks' to work out.  Its a 
>complete working system.  The overview is being drafted in public from 
>compiled notes on the system.  Special focus has been given on areas of 
>concern and thus developed at a faster rate.  The GSMTP protocol is now 
>under development.

There is no need to carry the discussion on this proposal within our 
mailing list. Please create a separate list for discussion. When you have 
written a concise technical draft without all the marketing BS in it, then 
we will take a look at it. Otherwise, this is just a waste of CPU cycles.

>The consent framework will consist of white and black lists.  There will 
>be no greylisting.  A complete opt-out will be allowed by 'GIEIS'.

The group's consent framework is what we are currently working on.

>Credit will be given where credit is due, however, the 'GIEIS' 
>architecture is unique.

Yet there are numerous proposals being lumped in the current proposal which 
were not there in the original v.0.0.1 proposal and clearly come from our 
mailing list. If you want to use someone's idea from the list, give credit.

Yakov