I'll take opt-out. I had notes on that and identified 3 automated out-out
paths (sorted by type of distribution/access to such lists):
1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list. Please comment here on all
types of encryption methods that are available.
2. Opt-out server. Here a special service/server (maybe more then one) is
located somewhere. Anybody wishing to check of address is opt-out or not
can connect to that server (with proper authentication if necessary) and
check validity of particular email address.
3. Opt-out system as part of each mail server. Here new command is added
to mail server which allows to check if email is opted out or not.
Separate lists are run by every isp/every email server and are particular
only to email addresses handled by mail server. Its assumed that before or
during email connection command would be issues to verify opt-out
preferences before delivering email.
Any other distribution means I missed?
On Mon, 24 Mar 2003, Paul Judge wrote:
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
-----Part 1. Understanding the Problem:
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
-----Part 2. Propose Solutions:
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
-----Part 3. Evaluate Solutions:
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
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