ietf-asrg
[Top] [All Lists]

[Asrg] Source Tracking and Authentication idea

2003-10-29 18:22:38
This may be an idea that has already been proposed.  If so, sorry for the 
duplication.  I've long been of the opinion that spam can be reduced 
significantly by denying spammers the use of forged domain identities.  I 
believe this idea will go a long way toward that goal without adding much data 
overhead to typical mail transactions between mail servers or clients.  I would 
appreciate an expert critique.
The objective of this strategy is to reduce or eliminate emails accepted for 
delivery to an electronic mail user which originate from a fraudulent sender 
identity.  In turn, attribution of unsolicited emails to a valid email sender 
identity facilitates enforcement of policies to forbid or control the sending 
of unsolicited emails to third parties. 
In essence, this strategy is comprised of two complementary modules of code.  
One set of instructions is a part of the recipient's email system, implemented 
as part of the recipient's Post Office Protocol server or as part of the email 
user's Reader or Client Browser software.  The other set of instructions 
resides on a computer designated by the Administrator of the particular sending 
email Domain as the Email Domain Authenticator (hereinafter "EDA"). 
The EDA would, for each email client or group of clients, periodically generate 
a short group of randomly-chosen letters or numbers (hereinafter "Authenticator 
String" or "AS").  A record would be kept of past AS values and the periods of 
time during which they were valid.
When an email user sends an email, the user's Browser would query the EDA and 
ascertain the currently valid AS value.  This value would be inserted into the 
email Header along with the EDA's time stamp for delivery along with the text 
content of the email.
Upon receipt of the email by a POP or Browser, the AS value time stamp are sent 
to the EDA of the originating email Domain and parsed against the EDA's history 
of valid AS and timestamp values.  If these values agree, the EDA replies with 
a statement of "true" and if not the EDA replies with a statement of "false."  
The EDA hostname would have to be provided by DNS and would, as such, be 
subject to traditional DNS security and authenticity.  An EDA type record would 
have to be added to the other host types now recognized for DNS.  An AS or mail 
message without a domain name or that refers to a dotted quad or other direct 
IP address for AS verification must automatically fail authentication at the 
POP server.
Access to the EDA to obtain a valid AS could be secured in a variety of ways, 
such as by limiting the numerical addresses to a particular range (IP address 
range), by username and password or by secure transaction protocols.  These 
strategies are already well known and widely implemented.
Access to the EDA for AS validation (to obtain a "true" or "false" as 
previously described) should be public and unrestricted.  AS values will become 
compromised, such as by the forwarding of email by others, but will remain 
valid for a finite period of time determined by the email domain Administrator. 
 This valid period might reasonably be measured in hours or days.  Thus, there 
is little advantage to gaining access to the AS.  Unless it is used quickly, it 
will be invalid. 
Finally, this can be implemented slowly across the Internet, as the user may 
determine how a failed AS is handled.
So-called "spam" can be controlled by the previously described strategy in a 
variety of ways.  Presuming a malicious email user ("spammer") seeks to send 
email to a list of email addressees and presuming the recipients employ the 
previously described AS strategy: 
email originating from nonexistent domains will fail the AS validation, as 
there will be no EAD to reply 
email originating from nonexistent user names within legitimate domains will 
fail, as the EAD will reply "false"
emails originating from falsified user names (users with valid accounts within 
legitimate email domains whose email identities have been gathered by a spammer 
for this purpose) and bearing compromised valid AS values, will only be 
effective for a limited time.  Thereafter, the EAD will reply "false" to the 
expired AS.  Spam lists would have very short lives.
Administrators may elect to set limits on the number of AS validations returned 
as "true" for a particular email account within a particular time period.  Thus 
a spammer could not make use of a legitimate email account acquired for the 
sole purpose of providing AS authentication, such as from hotmail.com.
The administrators of hotmail.com and other free email services should 
additionally create a limit on the number of account creation requests that are 
accepted from any particular IP address over a given period of time, perhaps, 
and independently validate the IP addresses given by the requesting client 
host.  For this exploit, the number of spam emails would be the product of the 
number of free addresses registered times the limit of permitted AS validations 
per email account per unit time.  Alternatively, the hotmail administrators 
could adopt a very short "time to live" (TTL) for AS values.
ISPs might find it necessary to limit the number of MAC addresses that a 
particular subscriber can register, as this might allow a subscriber to 
manually change the MAC, then re-login and get a different IP address, thus 
bypassing #5.  In any event, the total number of spams that can be sent is the 
product of the number from 6 times the number from 5 times the number from 4 
and is subject to the expiration of the AS values because of the passage of 
time and the reporting of the email addresses as sources of spam, resulting in 
shutdown.
In any event, spam could only originate from valid domains and from identified 
user identities within those domains.   This would make such emails much more 
difficult to originate, much less likely to be delivered and would make 
so-called "spam lists" largely worthless.
 
Frank McCoy