[Asrg] (no subject)

["Mark McCarron" <[e-mail]>]

Thankyou for your comments, I have replied to everyone in a single response. 
  Please find my responses in the body of the message.

This posting relates to the 'GIEIS' system, viewable here at:

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

The site will be updated tonight or tomorrow.

Mark McCarron.

>From: Mally Mclane <[e-mail]>
>To: Mark McCarron <[e-mail]>
>CC: <[e-mail]>
>Subject: Re: [Asrg] 'GIEIS' - The Extended Overview Released
>Date: Mon, 30 Jun 2003 20:57:14 +0200 (CEST)
>
>hi,
>
> > Opposition to the Proposal
> >
> > The opposition to this proposal falls into two main categories.  Those 
>who
> > are paranoid about a centralised agency analyzing email transmissions, 
>and
> > software companies that are either based or have products based on
> > 'anti-spam' techniques.  'GIEIS' would make these products and companies
> > completely redundant on a global basis.
>
>and..
>
>3) Those people (myself included) who won't be forced to move to a
>completely new email client to send mail.
>
>I realise you have heard this before, but you are asking the entire
>internet 'world' to move across to a new system from one that already
>works.
>

Mark's Response:

As far as normal end-users go, a simple update to their email client is all 
that would be required.  Updates happen all the time.  SMTP is a dying 
protocol, imagine what it would be like in 10 years?



>Yes, it has spam within it, but tools exist to filter this out to some
>degree. I cannot see anyway how you will ever manage to get this system
>up and working enough to make it worthwhile.
>

Mark's Response:

This will be easy enough.  There will be a period of transition.  Its not as 
hard as everyone thinks.  I agree it will be a challange, but hey come on, 
its not rocket science.



>Do you have a prototype working anywhere that we can look at?
>


Mark's Response:

The system we tested it on was a private network, also, it wasn't using the 
full aspects of the 'GIEIS' design.  It was just a feasibility test and it 
responded well, in fact, 100%.



>I sincerely doubt you would get the hotmail and aol's of this world to
>adopt such a system, it's too restrictive ([i] how would you handle people
>signing up for free hotmail accounts?), and they are unlikely to literally
>hand control of their email across to a 3rd party.
>

Mark's Response:

Please provide a more detailed description of how you believe the system is 
'too restrictive', just making that statement is very unclear.  Also, MSN 
(who owns hotmail) has changed its email system 3 times in the last 6 years 
alone.  For those of you who remember MSN started out as an x.25 network 
without any pop3 servers.  If I remember correctly they were a form of IMAP 
(I'll check this out), it didn't even support MIME, you had to download the 
'decode shell extension'.  Then they moved to pop 3, then they moved on to 
web based servers.  Hotmail has excellent anti-spam policies and in business 
terms, it would a lot of send sense for a 3rd party to protect their email 
systems.  They outsource their technical support already.  Also, nobody said 
anything about handing over control to anyone.



>It would be nice to live in a world free from spam, but not a restrictive
>world.

Mark's Response:

Please explain this comment.


>From: Mally Mclane <[e-mail]>
>To: <[e-mail]>
>Subject: Re: Fwd: Re: [Asrg] Consent Proposal
>Date: Mon, 30 Jun 2003 21:02:34 +0200 (CEST)
>
>hi mark,
>
>whats the url of the website you used below?
>
>m

Mark's Response:

http://www.ciphertrust.com


>
>
>On Mon, 30 Jun 2003, Yakov Shafranovich wrote:
>
> >
> > >X-Originating-IP: [62.252.200.188]
> > >X-Originating-Email: [[e-mail]]
> > >From: "Mark McCarron" <[e-mail]>
> > >To: [e-mail]
> > >Subject: Re: [Asrg] Consent Proposal
> > >Date: Mon, 30 Jun 2003 18:33:33 +0000
> > >X-OriginalArrivalTime: 30 Jun 2003 18:33:34.0102 (UTC)
> > >FILETIME=[1CD52360:01C33F36]
> > >
> > >
> > >I believe the answer is yes.  I just used a calculator at Paul Judge's
> > >website and I put in the values of 1000 employees with an average 
>salary
> > >of $15,000 and recieving 20 spam messages a day.  It calculated that it
> > >would cost the business $31,250 per year.
> > >
> > >The issue is not going to come down to end-users, but business
> > >losses.  Add to this the financial damage caused by virus', worm's,
> > >trojans and hoax emails this cost just skyrockets per annum.  The 
>future
> > >is only set to get worse, especially with more eastern block countries
> > >expanding their networks without the proper legal frameworks.
> > >
> > >Mark McCarron.
> > >
> > >
> > >>From: Yakov Shafranovich <[e-mail]>
> > >>To: "Mark McCarron" <[e-mail]>,[e-mail]
> > >>Subject: Re: [Asrg] Consent Proposal
> > >>Date: Mon, 30 Jun 2003 14:26:28 -0400
> > >>
> > >>This raises an interesting issue for the group in general. If the 
>current
> > >>spam problem is not fixed, would there be a move to proprietary
> > >>alternative email solutions such as this one?
> > >>


>From: Mally Mclane <[e-mail]>
>To: Yakov Shafranovich <[e-mail]>
>CC: Mark McCarron <[e-mail]>,  <[e-mail]>
>Subject: Re: [Asrg] Consent Proposal
>Date: Mon, 30 Jun 2003 21:03:29 +0200 (CEST)
>
>hi,
>
>On Mon, 30 Jun 2003, Yakov Shafranovich wrote:
>
> > This raises an interesting issue for the group in general. If the 
>current
> > spam problem is not fixed, would there be a move to proprietary 
>alternative
> > email solutions such as this one?
>
>No.
>
>It's too much hassle and too much outlay.


Mark's Response:

If you add up the cost of spam, virus', trojans, worms, and email hoaxes to 
business it would far exceed (in one year alone) the cost of implementing 
the 'GIEIS' system.



>From: "C. Wegrzyn" <[e-mail]>
>To: Mark McCarron <[e-mail]>
>CC: [e-mail]
>Subject: Re: [Asrg] 'GIEIS' - The Extended Overview Released
>Date: Mon, 30 Jun 2003 15:03:47 -0400
>
>Why not just use a VPN - point to point - and I can reject any connection 
>that I don't like! This seems to not require a centralized anything.
>
>Chuck Wegrzyn
>


Mark's Response:

I don't think you quite understand the difference between email and a VPN.  
A VPN (Virtual Private Network) is for connecting remote computers to a 
private network as though they were physically located on that network.  
Also, your machine would need to be on anytime someone wanted to connect to 
you to share files, etc.  The overhead, in terms of bandwidth, is 
substantial for a VPN.


>
>Mark McCarron wrote:
>
>>GIEIS - Global ISP Email Identity System - The Ultimate Anti-Spam System
>>a.k.a. - The Digital Reaper
>>
>>Copyright, including intellectual copyright, Mark McCarron 2003.
>>
>>
>>Introduction
>>
>>'GIEIS' has a global range in its application and is a hybrid 
>>consent/force model for prevention of fraudulent email.  'GIEIS' deals 
>>with both sender and recipient and acts as a 'gate-keeper' to the networks 
>>under its protection.  'GIEIS' is not just a method of eliminating spam 
>>but also, virus transmission, worm transmission, trojan transmission, 
>>chain-mail, email hoaxes and all non-compliant mail.  The 'GIEIS' system 
>>is designed in such a manner that bypassing the system is impossible.
>>
>>
>>Architecture Overview
>>
>>'GIEIS' is a new architecture for email.  It extends the SMTP protocol 
>>currently in use and requires the establishment of a centralised structure 
>>for email verification.  'GIEIS' utilises the common point in all email 
>>transmission from any source, the ISP.  The proposed system will route all 
>>email from an ISP's customer base through a special server known as an 
>>'Email Authentication Server' (EAS).  At this point, special encrypted 
>>codes are appended to the header that identify the account, the 'EAS' 
>>server, and the  ISP from which the email was sent.  A random encrypted ID 
>>code is also appended and these details are stored to the 'EAS''s 
>>database.  From here, the email is then distributed to the recipients 
>>'EAS'.  The recipient's 'EAS' then contacts the 'GIEIS' central servers 
>>and 'GIEIS' confirms the special encrypted codes held in the header of the 
>>email.  'GIEIS' achieves this by communicating with the sender's 'EAS', 
>>confirming the database entry against codes received, deleting the 
>>database entry (or marking confirmed), and relaying the results via 
>>encrypted transmission to the recipient's 'EAS'.  This will result in one 
>>of two possible actions; either the email is sent to the recipient's email 
>>inbox or is deleted.
>>
>>
>>Encryption
>>
>>This would most likely be a modified form of OpenPGP.  It would be based 
>>on a combination of ciphers rather than just one.  Ciphers being 
>>considered are TripleDES, CAST and Twofish.  RSA encryption has been 
>>deemed to weak for this purpose.  Codes and encryption passphrases will be 
>>changed frequently automatically.  Updates to 'EAS' will also be 
>>automated.
>>
>>
>>Abuse of Domestic Accounts
>>
>>To prevent such abuses of these accounts several measures will be put in 
>>place.  A limit on the amount of recipient's will be imposed per email, 
>>any email which exceeds the limit will be automatically spanned as 
>>separate emails by the clients software.  The 'EAS' will refuse any 
>>non-compliant email.  A limit will be imposed on the amount of emails that 
>>may be sent daily from any account.
>>
>>There are currently several proposals to limit the rate at which emails 
>>can be sent.  The first proposal is to have the sender validate each email 
>>by entering text based on a downloaded graphic.  This suggestion has 
>>limitations in respect to the visually impaired and blind members of the 
>>Internet.  This could be replaced by a simple puzzle, such as a question, 
>>for example how many days are there in a week?  This would be very 
>>difficult to automate.
>>
>>A second proposal, that may include the first proposal, is that a delay of 
>>5 to 10 seconds be imposed for each email sent.  The 'EAS' would control 
>>the rate, not the client software.
>>
>>The third proposal, which we believe to be the most acceptable, is an 
>>incrementing delay based on the volume of emails sent.  Every 3 emails 
>>queued would result in an additional one second delay added.  For example, 
>>if 33 emails were queued, the first batch of 3 would be sent and a then 
>>pause of one second.  The next 3 emails would then be sent and a pause of 
>>2 seconds would occur.  By the time we get to 30 emails there would be a 
>>10 second delay before the next batch of 3 emails were sent.  As you can 
>>see this delay would continue to grow in respect to the amount of emails 
>>queued.  This would force spammers to have a large amount of accounts and 
>>the machines to connect to them.  The time of opening new accounts 
>>manually and the cost (machines and time) would be prohibitive.
>>
>>
>>Business Accounts
>>
>>There has been some concern over how 'GIEIS' will handle business email 
>>and large volume traffic.  All businesses will have to register with their 
>>ISP and provide company registration details.  These details are then 
>>passed to the 'GIEIS' centre where a business code will be issued.  The 
>>business' email will then be routed through the ISP's 'EAS'.  The process 
>>of sending bulk email will be transparent.  The software will compile a 
>>list of domains that it will require access bulk access to and the amount 
>>of emails to be sent.  This list will be transmitted to the ISP's 'EAS'.  
>>The ISP's 'EAS' will then contact the 'GIEIS' central servers transmitting 
>>the encrypted business code and the list of domains. 'GIEIS' will then 
>>contact the domains on the list an authorize a bulk reception from the 
>>transmitting domain and the amount of emails to be received, again via 
>>encrypted message. 'GIEIS' waits until it receives an acknowledgement from 
>>each domain and then transmits a ready signal to the ISP's 'EAS' (may also 
>>include a list of down servers).  The ISP's 'EAS' then contacts the 
>>business' email software and requests a begin of transmission.  Any errors 
>>are relayed back to the business.
>>
>>
>>Mailing Lists and Discussion Groups
>>
>>Mailing lists must contact 'GIEIS' directly for setup and must be 
>>associated with a bonafide website domain.  This domain will be checked by 
>>'GIEIS' representative and the hosting company contacted for further 
>>information.  A credit card will be required and a $1 (£1, 1 euro) charge 
>>will be made to it.  The card details must match those to which the domain 
>>is registered.  Also, a mailing address and telephone contact information 
>>would be required.  They will receive a written copy of the 'Terms of 
>>Service' which they must sign and send back to 'GIEIS'.  Upon reception 
>>'GIEIS' will implement the account with their ISP.
>>
>>The emails then sent by the mailing list will be analyzed by heuristics.  
>>Each message will also be parsed for HTML code, such as IMAGE tags and 
>>jpg, bmp images.  As the majority of mailing systems use either ASCII or 
>>UNICODE text only, spam can be detected, blocked and the offender's credit 
>>card billed with a fine, or the offender prosecuted.  Heuristic analysis 
>>will not be a permanent feature, it will most likely be a feature that 
>>will only be in place for the first 6 months of any new mailing list 
>>request.  On successful completion of this 6 month 'trial period', the 
>>account will be deemed 'secure', heuristics will be stopped and the system 
>>will then use end-user reports only.
>>
>>Technically, the account will operate in a similar manner to business 
>>accounts and allow for bulk transmission.
>>
>>
>>Virus/Worm/Trojan Protection
>>
>>As 'GIEIS' can trace email sending directly to account level.  Any form of 
>>attack launched on remote machines can be minimised and the perpetrator 
>>tracked immediately.  Each 'EAS' system will have built-in anti-virus 
>>scanning software that will scan all outbound email attachments.  Any 
>>infected file will be bounced back to sending system with information of 
>>the virus.  This will prevent spread of 'address book' virus' that have 
>>become common place within the last few years.  The senders 'EAS' will 
>>inform the user when their daily limit has been reached, it will also 
>>inform them that if they have not sent this volume that their machine may 
>>be infected or have been hacked.  There will be information on to take 
>>steps to resolve the problem.
>>
>>A further extension, under consideration, is the flagging of executable 
>>attachments and their spread.  This would assist in rapidly identifying 
>>new virus'/worms/trojans and 'GIEIS', upon confirmation of a new 
>>infection, would be able to seal those accounts until updated anti-virus 
>>patterns were installed to all 'EAS's.
>>
>>A further suggestion, is linking a reporting service from 'GIEIS' directly 
>>to the computer fraud departments of Police forces globally.  This would 
>>assist in taking immediate action against offenders.
>>
>>
>>Period of Introduction
>>
>>Until a sufficient amount of ISPs are 'GIEIS Compliant' the 'GIEIS' system 
>>will be in a test mode.  This will most likely be a period of 6 months, to 
>>1 year.  A specific date will be chosen from when the system will become 
>>fully operational.  After that date, only 'GIEIS' compliant systems would 
>>be able to send email to those domains protected under 'GIEIS'.  This 
>>would force a global update, or many would find their customer base 
>>rapidly shrinking.
>>
>>In order to speed the process.  'GIEIS' would be setup in partnership with 
>>the world's largest providers of ISP and email services.  No company could 
>>afford to be excluded from their domains and adoption would become rapid.  
>>These companies have the legal right to take all steps necessary to 
>>protect their networks and customer base.
>>
>>
>>Account and Domain Blocking
>>
>>The 'GIEIS' system will have the ability to suspend email service at 
>>account level and domain level.  Any blockage will be in accordance with 
>>the 'Terms of Service Agreement'.
>>
>>
>>Terms of Service Agreement, Guidelines and Dispute mechanisms
>>
>>These will be determined by the members of the IRTF and IETF and conform 
>>to International law.
>>
>>
>>Charges and Fines
>>
>>Setup fees will be charged for business users.  Fines can be imposed, as 
>>per the 'Terms of Service Agreement' and services restricted until fines 
>>are paid in full.
>>
>>
>>'GIEIS' Centre's Legal Status
>>
>>The 'GIEIS' centre will be a non-profit organization.  Its dispute 
>>mechanism and complaints procedure will be completely transparent and all 
>>disputes will be posted to the centre's website.  There will be no closed 
>>door policy.  The 'GIEIS' system will not be accessible by any company and 
>>will be completely independent.  It will also not be a government agency 
>>of any form, it will be a public body.
>>
>>
>>Privacy Concerns
>>
>>'GIEIS' does not and will not analyze the majority of email transmission, 
>>unless specifically requested to do so, or when breaches of the 'Terms of 
>>Service Agreement' have been made.  Also, government agencies already have 
>>the ability, and the funding, to analyze emails on a global basis.  
>>'GIEIS' would not be able to compare to the supercomputers used by the 
>>NSA/CIA (US) and the GCHQ (UK).  'GIEIS' will have a legally binding 
>>'privacy agreement' and will never distribute, share, or sell any personal 
>>information.
>>
>>
>>Opposition to the Proposal
>>
>>The opposition to this proposal falls into two main categories.  Those who 
>>are paranoid about a centralised agency analyzing email transmissions, and 
>>software companies that are either based or have products based on 
>>'anti-spam' techniques.  'GIEIS' would make these products and companies 
>>completely redundant on a global basis.
>>
>>Copyright, including intellectual copyright Mark McCarron, 2003.

_________________________________________________________________
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband


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