BAD NEWS :( Government amendments reinforce Big Browser
Quentin Campbell
Q.G.Campbell at newcastle.ac.uk
Mon, 12 Jun 2000 15:43:42 +0100 (GMT)
On Fri, 9 Jun 2000, David Swarbrick wrote:
> In message <Pine.SOL.4.21.0006080808400.1508-100000@finan.ncl.ac.uk>,
> Quentin Campbell <Q.G.Campbell@newcastle.ac.uk> wrote:
> >On Wed, 7 Jun 2000, Caspar Bowden wrote:
> >
> >[snip]
> >> The amendement to S.2 below seems absolutely to clarify that comms data
> >> INCLUDES signals for the actuation of apparatus, i.e the full http string,
> >> and therefore that conduct in relation to it DOES NOT constitute
> >> interception - therefore no warrant is required.
> >
> >Caspar et al
> >
> >In clarifying what is meant by "communications" data the ammendment makes
> >even less certain what can be strictly classed as "content". My special
> >interest is electronic mail and in this context I make the following
> >observations.
>
> How does this apply to e-mail messages which request an acknowledgement
> of receipt?
> Or a message sent to a mailing list. One message is sent but actuates
> the apparatus to re-transmit it to all members.
>
> Or a cancel message sent to a newsgroup.
David
This is a considered reply to your questions and is rather longer than
may first appear necessary. For that I apologise but I hope it also makes
my point as to why the amendment is so dangerous and confusing. :)
For your first type of message there is no standard way of requesting an
acknowledgment or a receipt.
Some mail readers provide this facility but it only works when two mailers
of the same sort are talking to each other. One sends the other a special
message header, for example "X-acknowledge-receipt: <sender address>", and
the other end responds to this. The thing doing the responding is
actually the final recipient host, usually a PC in the case of "receipt"
messages.
No one has yet suggested that this (final destination) PC should be
classed as "apparatus" in a "telecommunications system" so it is not
affected by the amendment.
Now to reach this final recipient host, the message probably passed
through one or more mail relays or Message Transport Agents (MTAs).
There appears to be concensus that MTA software such as "sendmail", "MS
Exchange", "mercury", etc, are "apparatus" in a "telecommunications
system" because they "switch" and "relay" messages based on addresses
("communications data") so the ammendment applies to them.
If the "signalling" to this "apparatus" is only done with message headers,
not by the body of the message, there is not a problem. The distinction
between "communications data" (the message headers) and "content" (the
message body) is preserved and the amendment has no effect.
So what of your second class of message? That is, messages sent to mailing
lists. At first sight it appears to be straight forward.
In the case of messages to a mailing list, the "signalling" to the
"apparatus" is again done by the message headers, but this time it is the
envelope "To" header that is the key. The body of the message is not
involved in any way in determining who the new recipients are and is
simply copied and re-sent to the new recipients. Thus again no problem.
BUT ...
... a problem arises with mailing list software on MTAs that accepts
commands such as "subscribe", "unsubscribe", "list", etc, as a text string
by itself in the body of the message. In this case the "signalling" to the
"apparatus" is being done by the body of the message (the "content") as
well as the message headers so in this case the whole message, headers +
body, appears to be "communications data" by the definition implied in the
amendment.
So if there is any possibility that the "apparatus" has to look at the
body of the message, rather than just the headers, in order to determine
the disposition of the message (that is to "switch/relay" it) then it
seems that the whole message has become "communications data" at that
point.
All sorts of MTA functionality falls into this category including virus
checkers, pager systems, FAX gateways, compliance monitors in banks as
well as list expanders.
Cancel messages to News groups, even if the "cancel" command is in the
body of the message, probably fall outwith all of this because it is not
the MTA that responds to the "cancel" message but the application (INN,
etc) that is the ultimate end-point of the posting. The MTAs have simply
acted as transparent relays of the cancel message.
Quentin
--
PHONE: +44 191 222 8209 Computing Service, University of Newcastle
FAX: +44 191 222 8765 Newcastle upon Tyne, United Kingdom, NE1 7RU.
-------------------------------------------------------------------------
"Any opinions expressed above are mine. The University can get its own."