[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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg