Subject: [Asrg] 'GIEIS' - The Extended Overview Released

From: "Mark McCarron" <[email-masked]>
Date: Mon, 30 Jun 2003 18:40:52 +0000

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.

_________________________________________________________________
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: "C. Wegrzyn" <[email-masked]>
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 McCarron wrote:

> '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
>
> 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.
>
>
> 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.
>
> 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 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.
>
> 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.
>
>
> 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'.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>

---

From: "C. Wegrzyn" <[email-masked]>
Date: Mon, 30 Jun 2003 15:04:03 -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.  Am I missing something here?

Chuck Wegrzyn