Rich Kulawiec wrote:
Maybe I'm not saying this very well. Let me try examples: Fred
doesn't know Barney, but gets a request for consent: it looks plausible,
so he grants it. But the request *wasn't* from Barney, it was from
the malware on Barney's laptop, and now Fred not only has to deal with
the spam, he's got to revoke the consent.
This is a very good example, and I'm really happy to read it, since this
is exactly the kind of problems that lets me put "non FUSSP" in the
subject. In order to answer to your example, I must take advantage of
existing antispam techniques.
A consent request is a message with some syntax limits, but it's not
just that: it is... well, a request for consent. If it looks like spam,
current antispam tools could deal with it at least as good as they do
with other messages (including DKIM, blacklist, check on the envelope,
etc., but on a simpler and smaller message). If it doesn't look like
spam, then Fred reads it: it is not spam, but now it must also be a
convincing request specifically for Fred, so that he may be willing to
believe it. Now, let's get to Fred: he receives a convincing request for
a contact, whatever "convincing" means to him. Should he take the risk
of granting a token?
Answers:
1. No. It then just doesn't accept consent requests: whoever wants to
contact him must manage to obtain a token through some other channel,
e.g. a common friend. Somebody won't be able to contact him: Fred's choice.
2. Yes. Well, if a software on Barney's laptop manages to pass all the
other antispam protections, and also passes the "Turing test" of
mimicing Barney so good to be able to provide a request that is
convincing for Fred, what can we do about it? The fact is, it shouldn't
be that easy to get to this point, but we can't put limits on spammer
talents :).
3. Yes, but with a trick. I wrote the trick in the "Additional fields in
the MTA database" section. I don't like it, since it requires the MTA to
be able to write in the database, which increases implementation
complexity, but anyway: Barney is provided a token with a counter. When
a message is received with that token, the MTA decreases the counter.
When the counter is zero, the token is invalidated. Should Barney (or
his personal zombie) abuse of the token, he could do so for a very
limited number of messages. Should Barney actually be Fred's good fiend,
he would be provided a new token. All this can be automatically managed,
Fred would be asked by the MUA to choose if to set a counter when
answering to the consent request, and could then answer "Yes" when,
while reading Barney's messages, the MUA proposes to grant an unlimited
token.
This is at least how I conceived to deal with the problem.
I don't think so: there is no "local". Take for example, the members
of this mailing list: presuming that all of us use a mail client which
maintains an "address book" (and I don't) I'm certain that every one
of us has at least one entry in it that nobody else on this list has.
Most of us probably have *many* entries that nobody else on this list has.
And some of those entries are mailing lists which forward to many people.
Consider the extent of the damage that could be done if one of our
systems started spewing -- and how many spam recipients would have to
individually act in order to fully mitigate it. (Because A and B
revoking their consent to mail from Z does not help C, D, E...)
I don't think that much action would be needed. If my system is
compromised, the tokens I have were compromised. My friends would
complain (the "local" blame that works), and the spammer would have a
token for the mailing list, the one I use, so it would be able to send
spam to the list. While this wouldn't avoid spam to the list and its
recipients, it wouldn't increase the risk/damage with respect to the
current situation. The list (not me) owns tokens for its subscribers,
and would forward the spam to these users with these tokens. These
tokens wouldn't be compromised, since me and my personal zombie cannot
access them. You would complain with the list owner: not with me, you
don't have a token for it and in any case I wouldn't care (the "non
local" blame). The list owner invalidates the token me and my personal
zombie use in order to send messages to the list. End of the game. In
the meantime, since my friends threaten me not to grant me tokens any
more, I will probably clean up my system. If I don't, they will either
stop communicating with me, or accept my little problem, the same way it
usually goes with personal relationships. The mailing list will not.
(Which raises another scalability question: how would those of us who
have hundreds or thousands of correspondents find the time to manage
all this? And any of us participating in any mailing list have many more
potential correspondents: anyone on any of those lists might write to us
off-list. Same for anyone with a web site or blog or running any other
resource. A quick check of my personally-addressed and valid inbound mail
-- that is, not including mailing lists, not including spam or phishes --
suggests that I've had over 11,500 correspondents in the past few years.
That's a lot of tokens to keep track of. And that's just *me*.)
Dealing with the framework without an address book would be actually
impossible. With respect to numbers, I cannot answer. People and
software explicitly dealing with large lists of addresses/subscribers
would usually need to deal with an equal (well, double) number of
tokens. People like you, dealing, if I understand correctly, with a
large number of occasional correspondents, would need to do the same.
Note however that probably in these cases, most of the token exchanges
would be automated (you receive a token through a consent request, put a
token in piggyback in your first answer) and handled by the MUA, you
wouldn't even see these tokens. You would however need to collect some
through other means. I cannot make any guess on numbers, nor would I
take me or people I know as a reference on how many correspondents
people has (did anybody ever publish any statistics on this?), but it
would all turn down on how strict you are when accepting consent
requests, and how strict your correspondents are. At one end, you answer
to every contact request: this would end up with no consent protection,
no limits to communications with you, and in some cases to useless
messages (note that a consent request wouldn't be usually a useless
message, it just must be short and text). You could then disable the
consent protection on your address. At the other end, you do not accept
consent requests, and end up with a private network. The same for your
correspondents. Between these extremes, you select your correspondents,
and the same do they, and still enjoy the protection of antispam tools,
especially on consent requests.
Moreover, "informing the owners" has already proven to be a badly-losing
strategy. *If* the owners actually receive such communication
(telling them their system is probably compromised), they tend to
either disbelieve it, ignore it, classify it as a phish--often correct,
deny it, or act ineffectively to remedy the situation.
Do you feel that the same would be true if the communication were not an
automated communication but a communication from correspondents, not by
email, and maybe implying the (temporary) inability to communicate with
some of them? This would actually severely limit the usability of the
scheme.
No anti-spam
scheme which requires effective, clueful participation by end-users has
any chance of working: if they existed (in very large numbers) then we
wouldn't have such a large spam problem because (a) their systems would
be compromised in huge numbers and (b) they would have learned by
now to never respond to any spam.
I don't know. Me, as probably each of us, I'm often asked by friends to
"reinstall" their systems because they are full of garbage. My email
address probably got collected also through their systems, but I never
considered blaming them, as I couldn't show any evidence of the fact.
Should I receive spam using their token, I could be much more aggressive
than I've been until now, and maybe others would do the same. This kind
of blame usually works with other communication channels (again, people
disseminating phone numbers), why shouldn't it work with email? People
usually don't care of ineffective blame, but don't like to be considered
stupid by their friends.
--
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