Hi,
I posted this some time ago here: 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>