Privacy needs to be a concern here, unless this feature were
backed up by some form of authentication I would hesitate to
consider it a _good thing_, even assuming it had widespread
implementation. I would not want to see the enablement of
a way for hackers to conduct "mail-wars".
How is this problem solved for the Usenet News command "cancel"?
My guess is that only the originator of a message can obsolete
it. Possibly, also the moderator of a newsgroup or of a distribution
list should be allowed to cancel messages from that group?
For starters, the model of ownership for news is quite different from the one
for email.
Second, malicious cancellations of news articles are by no means unheard of.
There have been instances where this has been such a problem that sites have
elected to dispense with the ability to cancel articles. In other words,
just because you have not heard of problems in this area doesn't mean there
aren't any.
Third, the perceived value of a single news posting versus a personal mail
message is quite different. Netnews is the network way of material the postal
service would call "third class mail". The goal here is widespread
distribution of enormous quantities of material rather than the reliable
handling of individual items. (It is to the network's credit that these have
ended up as separate deliverables.) This translates to the cost of an improper
news article cancellation being quite low. The same cannot be said of email.
Fourth, the chances of malicious actions with news being noticed are far
higher than with email. Cancelling a single posted article at a minimum
affects an entire news server, where among all the people participating
there is a much greater chance of an anomaly being detected. With email,
a particular recipient can be singled out for an attack.
Obsoleting a message does not actually mean that the message
is removed in the system I use. Both the new and the old copy
is kept. Recipients who have already seen the old version,
will be shown the new version too. Recipients who log in
when both the old and the new version has arrived, will be
shown only the new version, but with a line in the heading
saying
Obsoletes: <Message-ID of the obsoleted message>
They can then, if they so wish, give a command to retrieve
the old version of the message.
I would say this is acceptable in some cases. I would not use this approach
when a message has been obsoleted by another message from a different source,
however.
If obsoletes is implemented in this way, I see no privacy
concerns. If you feel strongly about this, the best might
be to say that only the original author and no one else
can obsolete a message. That is the way it is defined in
X.400.
This isn't what the standards say.
The only possible privacy concern might be if someone
fakes a message with the original author as origin ator
in order to obsolete his message. But the risk for this
is not higher than the general risk of people sending
faked messages, so this should not be an argument against
an "obsoletes" feature, but rather an argument against
allowing people to send faked messages at all.
This ignores the ownership implications of the different models.
Ned