ietf-asrg
[Top] [All Lists]

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

2003-07-03 13:08:32
This is very like a closed use (sender) group where new members can be
introduced by any existing member. It is clearly very effective when a
CU(S)G is what you want - not quite as effective as insisting all incoming
email is encrypted with a key you provide (since sniffing the messages you
receive will eventually provide enough data to deduce the consent string)
but a lot simpler than that and likely to have far fewer deployment
difficulties.

Unfortunately, if a closed user group is not what you want, it's not very
helpful because you can never receive mail from a stranger.

The big problem with the consent paradigm is how to define consent in the
non-closed case, and what mechanisms can then be used to express it and to
police it:  how do I express which mail arriving from a stranger has my
consent and which has not?

Tom


-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]On 
Behalf Of
Madscientist
Sent: 03 July 2003 19:02
To: asrg(_at_)ietf(_dot_)org
Subject: RE: [Asrg] 2. Problem Characterization - Defining spam within
consent paradigm

<snip>

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


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg