-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One problem with text filters of various kinds is that the spammer is
unaware that the spam won't be delivered. There is no incentive for the
spammer not to continue to send mail to an address which is filtering,
possibly even discarding all such spam.
Blacklists, at least those which operate at the time connection is made,
at least offer some notice to the spammer that resources are being
wasted. They also allow the possibility of an additional legal measure:
it could be legislated that a spammer which continues to send to an
address after some proper connection refusal might be guilty of a theft
of service of some kind, which could have civil and criminal penalties.
At least one hashcash system (http://ssl.dizum.com/hashcash/) adds a new
header to the e-mail:
X-Hashcash: <token>
This has a similar problem to that of text filtering: the spammer isn't
aware that the mail is unwelcome.
Properly implemented, an ephemeral address (expiring after a short
period), a single-user address, or a signed address can work at the time
connection is made or attempted, giving notice to the spammer that the
mail is not wanted, and reducing resource use in subsequent operations.
It should be possible to combine these mechanisms in a way which works
with current mailers, and still preserves some compatibility in case the
protocols are extended. For example, the current systems allow mail
addresses of the form
<username>@<dnsname>
These addresses are seen at the time SMTP connections are established,
in MAIL and RCPT messages. Suppose we define some new tokens, so an
address becomes
<prefix><mechanism><value><separator><username>@<dnsname>
This should be done in such a way that the combination
<prefix><mechanism><value><separator><username>
is a valid <username> by itself.
<prefix> can be some unusual sequence, and can even be done on a domain-
by-domain basis. Suppose we use "AAA", assuming that no ordinary
username in our domain begins with "AAA".
<mechanism> is the type of additional information used. For example, we
might have
HC hashcash
EP ephemeral prefix
SU single user address
and so on.
<value> is whatever is required, as long as it is not the separator, and
consists of valid username characters.
<separator> can be a simple sequence; assume an underscore for this
example.
An address with an added hashcash value might be
AAAHC01234567_joe(_at_)domain(_dot_)com
This could be deemed equivalent to adding the header
X-Hashcash: 01234567
to the body of the e-mail, where the "normal" recipient might simply be
joe(_at_)domain(_dot_)com(_dot_)
Of course, this is clumsier than changing the protocols, but it can be
made to work by simple modifications to existing software. It is fairly
easy to get the MAIL and RCPT addresses at connect time; that is how
most blacklists work. In time, there could be a migration to a better
protocol, but this could work quickly as in interim solution, and
wouldn't break existing software.
The error message passed back to the sender could make it clear what
would be required for the mail to go through. (The sender might be
directed to prefix a hashcash value, use an ephemeral address, or use
a one-time key.)
An ISP or systems administrator could implement this automatically
without work by the users: the prefix/mechanism/value could be added and
parsed by the MTA without the user seeing it. The policy could be
selective, based (for example) by finding the sender on a blacklist or
greylist, or by being able to authenticate the sender. The MTA might in
some circumstances learn the mechanism/value by looking through the
headers (for X-Hashcash, for example).
The sender's MTA could also implement automatic recovery. If an e-mail
were rejected for lack of postage (hashcash), the MTA might
automatically retry sending the message after computing the proper
value, and the sender need not be aware of the operation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+ZDlo3fFKt0vOYhYRApuVAKC5WrYkNdMDIwjfAwa1wfC34+tsNwCfQ/tw
1+OVpGnMOfYkYIIm6DgEIfI=
=MJ9p
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg