Re: Inexpensive anti-spamware/anti-verminware tactic

Jon Ribbens <[email protected]>
Newsgroups gmane.mail.im2000
Message-ID <[email protected]>
In article <[email protected]>, Jonathan de Boyne Pollard wrote:
> You haven't demonstrated that.  You've hardly discussed UBM from a
> recipient's perspective, at all.  Most of your discussions about UBM have
> centred upon the cost to senders, and have missed the point.

I've been following this discussion with interest. It seems to me that
IM2000 would be at best have no effect on the problem of UBE, and at
worst it would benefit spammers. I would like to explain why, and I'd
like to hear counter-arguments. I apologise in advance if anything
I say has been done to death in the past.

Firstly, "cost to sender". UBE only exists because the cost to sender
is low. Clearly if the cost of sending an email were somehow increased
sufficiently, UBE would become unprofitable and the problem would be
essentially solved. IM2000 does not seem to help here at all, in fact
it may make things worse. Sending IM2000 message notifications to
users is clearly easier than sending an entire message to them. (Yes,
the spammer does not get any benefit unless he sends the message too,
but see below.)

Furthermore, since the spammer will clearly be operating their own
message store, they receive the great benefit of knowing who has
decided to read their messages. Bear in mind that it is highly
unlikely the spammer would be running "proper" message store software.
The spammer wants to send the *same* message to a large number of
people, so the message store will only have one copy of that message
and just return it to any client that asks for a message, regardless
of the message identifier.

Secondly, "cost to recipient". UBE is only a *problem* because the
cost to recipient is high. If the cost to recipient was low (i.e. your
computer could somehow correctly detect and filter out UBE) then it
wouldn't matter if people sent UBE or not, because it would not bother
the recipients. I think storage space is a complete red herring here.
Disk space is very cheap. It is the *time* the recipient has to take
manually identifying and deleting UBE messages that is the "cost".

It seems me that IM2000 increases the cost to the recipient. The
recipient has less information about the message to make their
decision as to whether or not the message is something they want to
read. They still have to look at just as many potential messages
(list of received message notifications) and identify the wanted
messages, i.e. there is still a cost to the recipient even if they
never read the message itself. If they decide they should read a
message, there is then a (potentially indefinite) delay while it is
fetched from its remote message store. In fact UBE messages are likely
to frequently have delays at this point because the spammer's message
store has been detected and taken off-line. So the process of
extracting your good messages from the UBE in your mailbox is more
complicated and takes longer than under the current mail system.

Finally, sender authentication. This is the problem that things like
SPF try to address. While there is no guarantee that sender
authentication would solve the UBE problem, I suspect it would help
greatly. It is also useful in its own right (it would help against
phishing, for example). IM2000 does not address this issue in any way
so far as I can see. I think that sender authentication is the area
that is most promising and should receive the most investigation.

In summary, I think IM2000 makes it easier for spammers to send their
spam messages, makes it more difficult for recipients to sort out the
spam from their real correspondence, and diverts attention away from
more promising approaches to the problem. I would be interested to
hear reasoned arguments to the contrary, however please try to avoid
blanket statements of "you're missing the point" or vague references
to "the web site".

Cheers


Jon
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.