ietf-asrg
[Top] [All Lists]

[Asrg] Hello- and my 2 cents

2003-04-22 02:22:20
Thank you, everyone who is participating in ASRG. This has reiforced my faith 
in technological innovation- which has become a casualty to commercialization 
and politics, far too often these days.

I firmly believe that none of the anti-spam companies are out there with any 
serious desire to prevent spam, but simply to profit from the problem. Nothing 
wrong with that- that's the American way.
But it's also the American way to innovate, and that's why I'm heartened to 
find it alive and kicking, here.

I'll get out of my soapbox now, and share my thoughts with you. 
If it's been said before (perhaps many times?), please accept my apologies.

I agree with the principles underlying this group, namely that taking on spam 
requires three components:
Consent Expression, Policy Enforcement, and Source Tracking.

Here's what I'd like to see in these components.
1. Consent Expression:
        - a potential sender must "request" "permission" to send to a receiver
        - the "request" and the "permission" **should not** be emails- 
                instead they should be a API-based feature of the protocol, 
like 'ping'
            % implications:
                $ since there would be *no message* included in the request, 
                            there's no value in it for the spammer, and
                            there's no pain for the receiver.
                $ the number of times a request can be made again should be 
configurable- never, once in a month or year, etc.
                    (to allow for email that one may not want today, but may be 
open to later)
                $ the "permission" would function similar to the "request"
2. Enforcement & Source Tracking:
        - It is critical that a globally unique identity scheme be accepted and 
implemented- 
                % perhaps out of the scope of ASRG.
                        $ digital signatures, PGP-like encryption may work, but
                        $ a global identity- the digital equivalent of a 
unique-SSN should be required for all email communication
                               ~ it's critical to effectively implement the 
"request" and "permission" semantics
                               ~ the protocol should make it impossible to 
forge- 
                                        combining a unique identity and 
built-in PGP-like encryption

These are my first thoughts. 

Any comments?


Regards,
Murali Krishna Devarakonda