On Thursday 06 March 2003 10:22 am, Clayton, Nik [IT] wrote:
Reading some of the discussion here over the past few days, I'm wondering
whether we actually need to do anything.
Many of the suggestions and proposals are acknowledged as taking years
before they're widely deployed. Talk of new protocols, e-mail 'postage'
charges and the like -- all these things need to displace an incredibly
well entrenched existing protocol.
At the same time, MUAs are getting smarter. In particular, the presence
of language classifiers (Bayes, et al) in desktop-user (as opposed to
technical-user) MUAs is likely to become much more prevalent over the next
few years.
Bayesian Classifiers work fairly well if you have good training sets, but the
results will get muddy if the person has wild variation in the non-SPAM they
receive. There is another issue too, however, is that for them to work you
need to actually download the SPAM in the first place.
I do believe that the reverse MX and such are overkill. It would seem to me
that a simpler method would be to follow the lead of credit-card companies.
If you want to buy something online, you go to the creditor and get a
temporary credit card number and use it. The number lasts for a single
transaction and acts as an alias to your account.
In the world of e-mail, we could leave SMTP and the MTAs entirely untouched
and provide a simple service that handles account aliasing (mail forwarding).
It would work like this -- I'm going to give an e-mail address out, perhaps
to someone I don't trust. My MUA asks a forwarding service for a randomly
generated address to be mapped to my true e-mail address for either 1.) a
specific time period, or 2.) until I ask for it to be revoked. I then give
the temporary forwarding address to the untrusted party. Once the forwarding
address ages out or is revoked, the forwarder simply rejects emails to that
id.
Using this scheme, the filtering is simply done on the randomly generated
token that's used as an abstraction for your e-mail address. Implementation
ought to be simple, the protocol very easily speced and efficient. You could
have the Post Office provide the service for $2/month publicly and let
companies provide it to their employees, if they choose - or the ISPs to
their customers. It would take little work to implement, could be rapidly
coded up to be used by MUAs or MTAs themselves, etc.
What use would spamming be if you had to guess whether the 6-25 character
alphanumeric string represents a valid e-mail address or not? And, if so, how
long. Just set up the forwarding hosts to pause 1 sec on a connection that
attempts to send to an invalid ID. If 1 out of 1000 addresses in your list is
valid, the cost of the spam increases by 999 seconds for each one that got
through.
This would work nicely too in that it would apply to other cases of trust, and
could even support the notion of temporary vanity e-mail names (i.e., your
service could let the client a sting to be contained in the address)...
Just a thought. I'm going to look into putting together a proof of concept and
integrating it with kmail...
As soon as these become widely deployed, and the majority of recipients
have filters that are so customised that it's nigh-on-impossible for a
spammer to guarantee that their e-mail will get through, doesn't spamming
then become so uneconomical as to die out?
I realise that this could be seen as being slightly optimistic, ...
N
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg