In tackling the definition of spam, perhaps it would be useful to
have a somewhat different view in which spam is considered
a symptom of a deeper problem.
Here is a statement I have been using to motivate e-mail research
work here at SFU.
"Current e-mail standards create an imbalance between senders
and recipients, providing senders with the power to capture the
attention of any recipient they so desire, while giving recipients little
control over what appears in their inbox. The imbalance becomes
most severe when the sender is a computer program sending out
bulk unsolicited e-mail (spam)."
The notion of sender/recipient imbalance then becomes a theory
that at once helps explain spam and also predicts that the
problem of spam may be mitigated by addressing the imbalance.
The two general ways of doing this are: (a) reducing the power of
senders and (b) increasing the power of recipients. Most
anti-spam proposals can be characterized as addressing one
or both of these objectives, typically at the MTA or network
infrastructure level for approach (a) or at the MUA level for
approach (b).
Focussing on the sender/recipient imbalance may help avoid
value judgments/arguments as to whether a particular instance
of annoying e-mail is or is not spam. As many have pointed
out, there is a large grey area. Care must be taken to avoid
moving into this grey area in deploying MTA or network-level
approaches that either classify messages as spam or senders
as spammers. But if these classification approaches are
augmented by other means that address the sender/recipient
imbalance, then there may be no need to move into the
grey area at the infrastructure levels.
Personally, I am interested in approach (b): empowering recipients
through increased automation at the MUA. I see challenge-response
systems as a first step in this automation, but consider that there may
be other benefits to MUA-level automation that ought also to be explored.
For example, one scenario in our work is that C/R systems can
be leveraged to perform other useful functions such as automated
change-of-address negotiation (whitelist/address book updating).
Nevertheless, it is very important that MTA and network-based
approaches also be developed. In the short term, MUA-based
approaches will not help with network traffic reduction.
Over the long term, we will continue to need asynchronous
text-based messaging. But we will need to ensure that the
great power of automation that senders may employ in generating
messages is matched by a corresponding power of recipients
to automate responses when and as appropriate.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg