Hi,
I posted this some time ago here: http://www.intechcomm.net.au
<http://www.intechcomm.net.au/> as well as to this mailing list and didn't
receive any comments other than from derMouse. Would you all read this and
tell me why this wouldn't work. I have also posted a 'stepping-stone' method
of implementing this system with an easy transition and method for creating
a global whitelist at the above website under one of the comments to the
original post.
Cheers,
Joshua Leisk
iT&C
<SNIP>
I propose that we need to construct a global registry of certified
closed-relay, 'spoof'-proof email servers, married to the verified details
of the server's owner, who are possibly placed under a financial security
bond, depending on the age of the domain name and previous history, to
operate it SPAM-free and then prevent all 'registered' email servers from
receiving email from any 'unregistered' email server (or be cleaned and
filed separately - see "'Softer' Variation of the Concept"), or accepting
email client submissions from clients not using an encrypted password
authentication, eg. SPA.
The exquisite beauty of this system is that the onus is no longer on the
recipient to deal with the SPAM or viruses, but the sender to prove that it
is NOT SPAM or a virus. If SPAM, email or viruses are sent from an
unregistered email server, it is simply rejected - BEFORE the mail or virus
has been transmitted, effectively eliminating the internet traffic caused by
SPAM and viruses and freeing up bandwidth for legitimate traffic. As an
email virus could never be a registered SMTP mail server, it will be unable
to propagate through any participating mail server!
The mail server owner(s) should also enter into a contract with its users,
binding them to abide by the mail server authority's rules, or be
financially liable and publicly known, should that mail server be used for
SPAM and/or the mail server owner be 'fined' by the mail server authority
for such misuse. This three-way contract allows financial accountability
without a 'big-brother' database of every email user.
Financial accountability is required to enforce compliance with anti-SPAM
regulations. If the registration of a new mail server, for which the domain
name is less than 12 months old and if the new mail server owner was not
able to be 'sponsored' or vouched for by a number of 'trusted' registered
mail servers, required the new owner to supply a security bond of
(suggested) US$2500+, in advance, to be forfeited in the event that the mail
server was used to SPAM, coupled with the mail server being potentially
de-registered and barred from participating in the new 'secure' email system
(should the owner of the mail server be unable to identify and hold liable
the user responsible), mail server owners would take a much keener interest
in preventing unauthorized use of their systems. Mail server owners who
cannot afford the security bond or have other registered mail server owners
to sponsor them can still forward all mail, using TLS/SASL, through their
ISP's mail server.
Considering the abilities of the current mail server software available,
there is no technical excuse for any mail system to allow unauthorized email
to be relayed. MTA tags, message tracking and secure password authentication
with every sending email client provides end-user accountability and
ultimately financial liability.
Additionally, any user needing to send to more than (suggested) 50
recipients at one time, should be granted by the mail server's administrator
on a 'per-user' basis and the 'privileged' user registered with the mail
server authority, rather than permission needlessly granted to every user.
Administrator notifications and temporary account lock-outs, if a 'standard'
user send to more than 300 recipients in 24 hours, would prevent stolen
account passwords from being widely exploited. I would also suggest that any
email user that is granted elevated sending privileges should not have the
sending username stamped on the mail by the mail server, as they will
certainly be subjected to 'identify theft' attacks. Message ID tagging will
still provide user accountability to the mail server operator in the event
of an infringement.
I would also suggest 'privileged' users should be contractually obligated
NOT to store their password in their email client software, which would
prevent email client software with poor security from being exploited by
hackers, trojans, spyware or viruses - especially considering the recent
source-code leaks for Microsoft products. The same policy should probably
apply to ordinary users, but I can see this causing some difficulties.
A security bond also eliminates the occurrence of 'phoenix' SPAM servers, as
the cost of forfeiting the bond should significantly exceed the potential
profits gained from a couple of day's sales generated by SPAM, at 300 emails
per day.
A yearly registration fee for each email server would also be necessary to
fund the infrastructure costs incurred by the mail server registrar. Many
automated open-relay testing facilities already exist on the Web and prior
to a mail server being registered, it will be required to pass stringent
tests, certifying it unable to act as an open relay.
The next problem to eliminate is 'spoofing' - an illegitimate mail server
may attempt to pose as a registered mail server to facilitate transmission
of unsolicited email. Clearly this poses a considerable threat to any secure
email system.
Methods like 'SPF" and RMX are a great idea, but do not PROVE that the mail
server is the registered mail server, only that it is a mail server that is
communicating on port 25 of the public IP address for which the mail server
operates. This leaves a private network utilising network address
translation (NAT) wide open for Trojans, SPAMbots and viruses that could
easily lookup the external IP address, perform a reverse lookup and
masquerade the original mail server. This is not good.
I further propose that during a 'secure' SMTP mail server transaction,
before verifying that the sending email server ('Server 1') is registered
with the Mail Server Registrar, a connection is made by the receiving mail
server ('Server 2') to the sender's fully-qualified domain-name, as listed
in the DNS ('Server X'). This is the same host-name that was presented by
'Server 1' when connecting to 'Server 2'. A query is then sent to 'Server X'
to verify that it is indeed the same host as 'Server 1'. This would be
performed by challenging 'Server X' with a 128 character 'Session ID',
randomly generated when the original connection was made between 'Server 1'
& 'Server 2'. 'Server X' would then return only a logical 'YES' or 'NO' as
to whether as the queried 'Session ID' exists from 'Server 2'. If the
session ID does not exist, the connection between 'Server 1' and 'Server 2'
is simply dropped and the IP address of 'Server 1' is blocked for a limited
period of time. Only after satisfying itself that 'Server 1' is not spoofed
and also registered with the Mail Server Registrar will 'Server 2' allow any
mail to be received from 'Server 1', thus eliminating all email from all
untrustworthy sources, including email virus engines. After terminating the
original connection, the Session ID information is deleted.
There are those who would argue that the traffic and CPU cost of effectively
three remote database queries for each remote SMTP server connection (DNS,
Session ID, Mail Server Registrar) are too high for the average mail server
and data-pipe bandwidth. Considering the resources currently being used to
receive and process SPAM and viruses, overall traffic and CPU costs would
actually decrease - as the server load will be significantly reduced by not
having to receive and process the unsolicited traffic, or filter the SPAM
and/or viruses.
To prevent mail server performance from being adversely affected and to
prevent network outages from stopping all mail from being received, the Mail
Server Registrar will need to securely replicate the database of certified
mail servers onto 'slave' databases located at the trunks of major data
networks in each country, much the same as the DNS system.
Description of processes used in this system:
Mail Server Registration -
1) The mail server is registered in the DNS as per usual.
2) The mail server owner submits their application for registration with the
Mail Server Registrar ("MSR"), or possibly an accredited agent for the MSR
(who will then forward the details to the MSR), including host name,
registered owner's details, admin contact details and typical proof of ID.
For an individual, this would typically include:
Fully Qualified Host Name, Owner's Name, Address, Phone Number, Fax, Date of
Birth, Drivers' License Number (Photocopy), Social Security Number (if US
Citizen), Photocopy of Birth Certificate and / or Photocopy of Credit Card,
Address where mail server will be located. Email Address.
For a business, this would typically include:
Fully Qualified Host Name, Company Name, All Details of Company Directors
(as per 'individual' details), Principal Place of Business Address, A.C.N /
A.B.N. / Registered Business Number (+Photocopy / Scan of Certificate of
Incorporation), Phone Number, Fax, Address where mail server will be
located. Contact Email Address.
The admin contact details to be required are:
Name, Phone Number, Email Address, Fax, Proof of ID.
3) The details are recorded in a private database and checked against a
database of known SPAMmers (recorded during SPAM reporting) and registration
will be denied or the security bond heavily increased if a match is found.
4) The hostname on the application is subjected to an automated security
test, from multiple IP addresses, which it must pass.
5) A contract is made between the MSR and the mail server owner. The
security bond, if applicable, is collected and the applicant hostname is
added to the database, with sending privileges granted.
User Registration for a Mail Server -
User accountability needs to be maintained to protect mail servers from
habitual offenders and provide the ability to recover damages from an
offending user, but is beyond the legal scope of the MSR's contract with the
mail server owner. This is why the MSR holds the mail server liable. The
mail server owner(s) should enter into a contract or agreement with the
user, binding them to financial accountability and liability if they abuse
the terms of service, including spamming. This also circumvents the need for
any anti-SPAM laws in any particular country.
1) The user supplies all relevant identification.
2) The registered mail server owner(s) query the MSR to check if the person
is a known offender.
3) The mail server owner(s) then choose to grant conditional use of their
systems based on prior history.
Mail Exchanging -
(A more 'friendly' variation of this method is also found in "'Softer'
Variation of the Concept".)
1) The sending user ("sender") authenticates with mail server, using secure
password authentication ("SPA"), or whatever form of encryption eventually
supersedes it.
2) The sender delivers messages to mail server, using the mail server
owner's policies, including whether the sending username is stamped on the
message header, maximum amount of recipients per message, maximum amount of
messages per day.
3) The sending mail server ("Server 1") queries the DNS and finds the mail
exchanging host for the recipient's domain name ("Server 2").
4) Server 1 establishes an encrypted TCP connection with Server 2 and
supplies a randomly generated 128 character 'Session ID'.
5) Server 2 queries the DNS with Server 1's apparent hostname and resolves
an IP address ("Server X").
6) Server 2 establishes an encrypted TCP connection with Server X and
queries the server with the Session ID obtained from Server 1.
7) Server X looks up a temporary database of current connections and their
respective Session IDs and determines if a connection exists with Server 2
that has an identical Session ID. If the result is positive, then Server X
returns a logical TRUE to Server 2, the querying connection is then dropped
between Server X and Server 2 and the querying ability temporarily suspended
for a period of (suggested) 3 minutes for Server 2's IP address to prevent
brute force attacks on Session IDs.
8) Server 2 then queries the MSR database to see if the hostname exists AND
has sending privileges granted and if both return positive then the MSR
database returns a logical TRUE and Server 2 allows mail to flow from Server
1.
If the result of the first query with Server X is negative, then Server X
returns a logical FALSE to Server 2, the connection is then dropped between
Server X and Server 2 and the querying ability temporarily suspended for a
period of (suggested) 3 minutes for Server 2's IP address, again to prevent
brute force attacks on Session IDs, following which, the connection is then
also dropped between Server 1 and Server 2. If the result of the second
query (to the MSR database) returns FALSE, the connection between Server 1
and Server 2 is dropped. In either case, Server 2 will then prevent
connections being made from Server 1's IP address for a limited amount of
time (suggested 24 hours).
Spam Reporting -
If an infringement occurs, liability must be established and action taken:
1) User receives unsolicited email that does not comply with MSR policies.
2) User forwards the email 'source-code' to a designated email address at
the MSR.
3) The MSR examines the message header and identifies the hostname of the
sending mail server, the MTA message tracking ID, possibly the sending
username (if name-stamping is enabled), time and date stamping, as well as
confirming if the email does not comply with MSR policies. Further examples
from the same sender will also be searched for.
4) Automated security testing is performed on the mail server identified.
5) If the message IS SPAM, or if the mail server does not pass the security
test, action needs to be taken. The offending mail server could have its
sending privileges suspended and the security deposit forfeited. The
offending email is forwarded to the mail server owner and administrator,
along with notification of any suspension and bond forfeit, also
notification if the mail server failed the security test. The suspension
will remain in place until a new bond has been paid and the offending user
details have been supplied to the MSR, which are then placed in a database
of offenders, made available (by query) to registered mail server owners and
operators. If the mail server owner (or admin) is unable to supply details
of the offender OR if the mail server has repeated offences, the security
deposit could be greatly increased or the mail server deregistered. If no
user can be identified, the mail server owner must assume responsibility and
financial liability.
6) If applicable, the mail server recovers damages from the offending user.
Automated Testing -
In addition to the current mail server security tests freely available on
the Web, I would conduct the security tests from a private list of dynamic
IP addresses, in different network ranges, to prevent a malicious or
ignorant mail server admin from merely blocking traffic from a known
security testing IP address. I also have designed a system to help prove
whether email lists have been 'harvested'. Every registered mail server
should be obligated to provide free mailboxes for use by the Mail Server
Registrar. These mailboxes would only be used as 'collection points' for
unsolicited mail and not for any other purpose. The email addresses would
then be used on websites, forums, newsgroups and bulletin boards and any
SPAM received by these 'collection points' can be automatically considered
as illegally harvested and dealt with even more rapidly.
Implementation -
The plug-ins or upgrades to the existing SMTP engines should allow for
backwards compatibility during the cut-over period. I would suggest
launching the public awareness campaign and product, allowing for a 12 month
cut-over period, after which, the SMTP server's traditional receiving
service will no longer operate (or be altered and cleaned, see 'Softer'
Variation of the Concept.)
During the cut-over period, any mail that is sent to and from any
unregistered mail servers should have automatic replies to the sender and an
information block added to the body of the original message, both of which
inform the sender and recipient that due to mail server being unregistered,
they will no longer be able to communicate with this party after 'S-DAY' (or
be altered, see 'Softer' Variation of the Concept)
and point them towards a website with a list of registered mail servers and
ISPs, with their contact details, sorted by geographical location, so that
they may choose an alternate provider.
'Softer' Variation of the Concept -
A slight variation of the concept that still allows mail to be received from
unregistered mail servers, yet duly processed and separated from 'safe'
email, could also be effective.
This is not my preferred method of operation, but it may be more widely
accepted. This method could also be useful during the transition period to
'safe' email. Mail servers using this method will seamlessly communicate
with mail servers utilizing my original 'hardline' concept, but it gives the
mail server owner and the users a choice (and a safe way) of receiving
'unsafe' email.
Obviously this method will not eliminate all the traffic generated by SPAM
and email viruses, which is why this is not my preferred method, but it does
allow for easier marketing and could easily be 'turned off' in the future,
once market saturation has been reached.
If every mail server had 2 mailboxes for each user - one 'safe' mailbox and
one 'unsafe' mailbox, unregistered mail could still be received, processed
and stored in the unsafe mailbox. Alternatively, the subject line in the
message header could be stamped so that the mail client can further process
the message.
I would suggest that all users of the mail server must be given the option
of whether to have an 'unsafe' mailbox at all and also whether or not to
have the mail server strip all attachments and possibly HTML tags received
by the 'unsafe' mailbox - I would suggest this is should be the default
option, if the choice is given to the mail server users at all, otherwise
users will still be exposed to viral infections.
If a receiving mail server was unable to verify the authenticity or
registration of a sending mail server, all mail received from the sending
mail server would be classed as 'unsafe' and routed through to the '.unsafe'
mailbox. If the recipient on the receiving mail server has elected not to
have an 'unsafe' mailbox, the message would be rejected and a Non Delivery
Report (NDR) generated to the sending user.
Summary ~
As you have now seen, using my system, it is very easy to eliminate email
viruses and the vast majority of all SPAM. For the few isolated cases that
will remain, it will be extremely easy to identify, track and police.
Email users can still enjoy the freedom of submitting mail from an external
network. This is extremely important for mobile users and wireless
technology.
My system would easily be implemented as a plug-in, or upgrade to the
existing SMTP standard, allowing backwards compatibility, during the
cut-over period.
There are no problems caused to existing mail-routing, delivery priorities
or relative user anonymity, if so required. SMTP servers can also still
fully function using a dynamic IP address and dynamic DNS, if they need to,
unlike other recently proposed anti-spoofing techniques. Also, a registered
mail server will always be able to send to an unregistered mail server.
Accountability is still maintained, regardless of the relative anonymity.
Due to message tracking IDs (serial numbers) stamped on emails by the
sending mail server, the mail server owner can easily identify the user
responsible and the sending mail server's identity is already stamped on the
message headers and using my system, cannot be spoofed.
Law and order can be easily restored to the global email system, without
impacting on freedom, liberties, finances or functionality.
The responsibilities of the Mail Server Registrar should fall to the UN/
ITU, as this is a global policy change.
<END SNIP>