|
Re: [Asrg] 'GIEIS' - The Extended Overview Released
2003-06-30 12:06:34
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
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.
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
_______________________________________________
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
|
|