Subject: [Asrg] Source Tracking and Authentication idea

From: "Frank McCoy" <[email-masked]>
Date: Wed, 29 Oct 2003 20:06:17 -0500

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 29 Oct 2003 20:24:09 -0500

[Subject changed as per posting guidelines. Mod.]

Frank McCoy wrote:
> 
> 
> 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: 
> 
>    1. email originating from nonexistent domains will fail the AS
>       validation, as there will be no EAD to reply
>    2. email originating from nonexistent user names within legitimate
>       domains will fail, as the EAD will reply “false”
>    3. 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.
>    4. 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.
>    5. 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.
>    6. 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.
>    7. 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
> 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 29 Oct 2003 20:41:15 -0500

Yakov Shafranovich wrote:

>> 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.
<snip>

Many RMX-type proposals are geared towards the same goal and accomplish 
it with less trouble. See:

http://news.gmane.org/gmane.ietf.asrg.rmx