Re: [Asrg] 2. Problem Characterization - Defining spam within consent paradigm

["C. Wegrzyn" <[e-mail]>]

Seems like a lot of what you get with a cert. This is almost the 
approach I took with the design I did. I can tell you it works and works 
well.

Chuck Wegrzyn


Madscientist wrote:

>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On 
>>Behalf Of Bob Wyman
>>Barry Shein wrote:
>>    
>>
>>>Although reasonable-sounding these descriptions [of consent]
>>>are starting to remind me of those long-ago Artificial Intelligence 
>>>seminars where you'd get to ponder why some seemingly simple 
>>>human behavior was so difficult to code into a program. 
>>>      
>>>
>>	We've had precisely the same issue with software 
>>    
>>
>
><snip>
>
>  
>
>>detect identity. The machine can only detect the use of things 
>>which are assumed to indicate identity. (i.e. When if someone 
>>says "Only Bob can send mail" what the machine needs to hear 
>>is "Only someone using Bob's private key can send mail." For a 
>>person, "identity" is an attribute of being. For the computer, 
>>identity is a property which is assumed belong to users of 
>>certain proofs of identity. 
>>	But, this is all getting a bit philosophical. Barry has 
>>a point. As we get into dealing with the issues of expressing 
>>and managing consent, we must all be careful to ensure that 
>>people understand the inherent limitations of machines in this 
>>realm. There is only so much that the machine can do for you.
>>
>>		bob wyman
>>    
>>
>
>There are some simple and effective mechanisms for the scenario of
>identifying consent, though they may not be applicable in some cases.
>
>Here is one that is not a complete solution, but is very effective and
>solves the problem of expectation and identification in many of the most
>critical scenarios (such as children and grandmothers avoiding porn
>spam):
>
>Simplified: 
>
>1. The recipient issues a secret code (PL code) of their choice to each
>of the people they wish to communicate with.
>
>1.1. The secret code _should_ be cryptographically secure but _may_ be
>anything unique enough to be effective for that user's purpose.
>
>1.2. The user in this case _may_ be broadly defined as a group of users
>such as a family, or a special team in a corporate environment.
>
>2. The user filters out / rejects all messages that do not contain the
>secret code in the body of the message.
>
>2.1. The secret code becomes a mechanism of explicit consent.
>
>2.2. In some cases (such as juvinile accounts) the ability to change the
>code or adjust the filtering may be restricted.
>
>3. Trusted users who receive the code may freely distribute the code to
>other users whom they wish to include in the group. In this way the
>"authority" to transmit messages to members of the group can naturally
>extend to appropriate senders in a "viral" manner with very little
>administration.
>
>3.1. Kids will naturally share their PL code with their friends.
>3.2. Parents will share/register the code with teachers and extended
>family members.
>
>4. If the PL code is compromized then it can be easily changed because a
>new code can be generated and transmitted to everyone in the group (or
>at least a large collection of them). If this mechanism is automated in
>some way then the system can be very secure an lightweight.
>
>5. Attempts to send to members of this group withou the appropriate code
>can be used to detect attempted abuse - and these statistics can be used
>to drive other mechanisms such as black lists or statisitical training
>systems.
>
>This mechanism can be implemented right now and is extremely effective.
>
>The user's expectations are precise: If someone has the code I can hear
>from them. If they do not have the code I should not hear from them.
>
>The system's responses are precise: If the code exists then the message
>passes, if it does not then the message does not pass. (The PL code may
>be implemented with stronger controls such as placement in specific
>message headers or other specific rules, however it generally works well
>when simply included in the body of the message like a signature or some
>kind of "inside joke").
>
>The system is extremely secure because anonymous senders are not
>generally able to extract or guess these PL codes and if they do then
>the codes are easily changed.
>
>The system can be extended to support legitimate mailing lists because
>special codes can be provided to the mailing list author at the time of
>subscription by the subscriber as part of the normal customization data
>provided by the user. One variant of this is to subscribe to the list
>using a cryptographic alias that can be turned off if it is ever abused.
>A more secure implementation would require the author of the list to
>include the code provided as part of the customized portion of the
>subscriber's messages (customization is often the norm these days anyway
>such as including the subscriber's name and so forth).
>
>This mechanism naturally extends a COT model (Circle Of Trust) because
>is a good example of that paradigm. COT systems provide for effective,
>lightweight authentication mechanisms without a centralized authority.
>
>This mechanism is not proprietary, not centrally controlled, represents
>very little cost, and does not preclude any other mechanisms that might
>also be enforced as part of a local policy.
>
>Extended implementation example:
>
>The mechanism can also be aggregated and driven forward within the
>systems of a given provider such that individual users might register
>their authorized codes with the provider (using some standardized format
>established by the provider), those codes could then be aggregated into
>a hash table, and message content reaching a border MTA could examine
>incoming messages against the hash tables during the SMTP conversation
>by scanning for the appropriate codes in the data segment before
>accepting a message. If the message does not contain the code and also
>does not satisfy an alternative policy evaluation then the message would
>be rejected and incident recorded as abuse forcing a period of
>rejections at the envelope level for some period of time (consistent
>with the local policy of course).
>
>A system such as the above might be implemented as a "Special Service"
>for families with children on the internet. - This means low cost, high
>value, and profit potential (so it's likely to be adopted), plus a
>significant impact on spam reduction.
>
>I recommend that this should be included in a suite of protocols and
>practices that are part of the final solution.
>
>Sorry for the length.
>I hope this is helpful.
>_M
>
>PS: PL = Private Listening, from a common radio meachanism (PL tones). I
>posted infromation about this in another thread I believe so I'm not
>repeating it here.
>
>PPS: We recommend and use this mechanism with great success, though I
>don't have hard statistics to show. Hopefully it is logically obvious
>how effective this solution can be in many scenarios. A TINY bit of
>automation can go a very long way with this one also.
>
>
>
>_______________________________________________
>Asrg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/asrg
>
>  
>



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