[Asrg] (no subject)
2003-06-30 18:20:24
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 <mally(_at_)mally(_dot_)net>
To: Mark McCarron <markmccarron_itt(_at_)hotmail(_dot_)com>
CC: <asrg(_at_)ietf(_dot_)org>
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 <mally(_at_)mally(_dot_)net>
To: <markmccarron_itt(_at_)hotmail(_dot_)com>
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: [markmccarron_itt(_at_)hotmail(_dot_)com]
> >From: "Mark McCarron" <markmccarron_itt(_at_)hotmail(_dot_)com>
> >To: research(_at_)solidmatrix(_dot_)com
> >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 <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 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 <mally(_at_)mally(_dot_)net>
To: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
CC: Mark McCarron <markmccarron_itt(_at_)hotmail(_dot_)com>,
<asrg(_at_)ietf(_dot_)org>
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" <wegrzyn(_at_)garbagedump(_dot_)com>
To: Mark McCarron <markmccarron_itt(_at_)hotmail(_dot_)com>
CC: asrg(_at_)ietf(_dot_)org
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Asrg] (no subject),
Mark McCarron <=
|
|
|