First, let me say, from the point of view of one that just submitted a
proposal, that I've been looking for such a document for days before
submitting my proposal to the list, and (once finished) this document
should definitely be cited in the faq.
I don't think that spam should be redefined in this kind of document,
since it wouldn't be of much help to prospective proposers. I don't
think that having a proposer think at whether a specific class of
messages is spam or not would help in getting better proposals,
especially since even this knowledgeable group can't agree on the term.
Said that, I don't think that the definition in the document is
appropriate, since a lot of messages, including harassment messages and
messages from some co-workers or bosses :) are messages one wouldn't
definitely like to be presented, but unfortunately they can hardly be
classified as spam :)
Some additional information in the document could help in preparing a
better proposal, e.g. a list of "cases" and "issues" to be considered: I
spent a lot of time trying to "imagine" some, but still missed e.g. the
shared address issue. Some could be:
- multiple recipients in messages;
- webmail vs. personal MUA vs. both;
- message forwarding
- mailing lists
- incoming MTA different from outgoing MTA
- legacy protocol versions
- ...
This would avoid proposals that miss some key situations where they will
break. While it is reasonable to expect that proposers are willing to
understand the difficulties and internals of email before proposing
anything, I think it's not reasonable to expect them to have a good
understanding from the beginning: it often happen that truly innovative
proposals come from people who look at a system "from the outside".
Maybe also a reference to a description of current techniques, both
implemented and failed. Many of you pointed me to e.g. different address
tagging services/proposals. While I had already seen most, I spent a lot
of time in this search too (not that this has been wasted time). But,
while I've seen that the ASRG moved to non-consent research, I didn't
find anywhere why, so I was left guessing why it happened.
Also, the critical requirement that it should reduce the effort of
managing spam for the recipient is not very clear. Many solutions may
reduce the burden for some, and increase it for others. Also, for many
it will reduce the bured of some tasks but will add some other tasks. My
discussion with Rich about MUAs, address books etc. is a clear example.
So, I suggest that being able to classify users with respect to
increase/decrease of burden, and to clearly state what additional tasks
are required, would be more useful. Also, just stating that it would
decrease the burden for the majority of users is not enough, or else
anything that works for Outlook and a couple of ESP would suffice.
Another point is the "voluntary participation", which may also be
unclear. As an example, one can "voluntarily" enable the consent
framework, but without some care this would force its correspondent to
deal with the framework too. This may seem a violation of the rule, but
many protocols have the same requirement. As an example, if I protect my
http service with TSL, users willing to access it will need to implement
TSL, and I won't usually offer the same service, and this is common to
most security protocols (e.g. VPNs). One could argue that with email,
one could not know that the security/antispam protocol until a message
is rejected. As Alessandro suggested, I'm interested especially in this
final issue.
--
Claudio Telmon
claudio(_at_)telmon(_dot_)org
http://www.telmon.org
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg