What is Communications Data?

[Quentin Campbell]

> -----Original Message-----
> From: Watkin Simon [mailto:Simon.Watkin@homeoffice.gsi.gov.uk]
> Sent: 18 November 2002 17:24
> To: 'ukcrypto@chiark.greenend.org.uk'
> Subject: RE: What is Communications Data?
>=20
>=20
[snip]
> Question: what traffic data is also content?
>=20

Simon

If you are one of the people who take the view that _any_ To:, From:,
Received:, Date:, etc, e-mail message header is "traffic data" and thus
fair game for S21(4) then I can provide a contrived but real example of
a message that answers your question and shows that some of this
"traffic data" is actually content.

The message text shown below arrived at an ISP in an e-mail message
whose envelope-To address (SMTP "RCPT TO:" address) was the subject of a
S22(4) notice served on the ISP. The message was sitting in a mailbox
that is accessed by POP when the ISP looked at it in response to the
notice.

However the ISP would only provide Plod with details of the envelope
sender and recipient (from Sendmail logs), the name/address of the
mailbox owner and all headers in the message _except_ those contained in
the text below.=20

The text that the ISP refused to hand over appeared to be pure content.
As the ISP suspected, these lines of text had been randomly selected,
modified and sent as an e-mail communication by a hand generated SMTP
session using "telnet the.ISP.mailhost 25" and cutting and pasting the
following text (between "cut here") after the SMTP "DATA" command:

---- cut here
Received: from it.linx.net ([123.456.789.101])
        by london.linx.net with SMTP id a-made-up-one for
        <ukcrypto@chiark.greenend.org.uk; Weekend, 31 June 2019 25:48:41

x-esmtp: 0 0 1
Message-ID: <1234@perry.co.uk>
To: LittleRedRidingHood
From: Woolfie@bigsofty.com
Subject: Hey there Little Red Riding Hood you sure are looking good
Date: Sun, 31 June 2019 25:34:48

Whose "content" is it anyway? This line is the body of the message.
---- cut here

and then following it with <CR LF>.<CR LF> QUIT to terminate the message
and SMTP session.
   =20
Now most MTAs will accept that text as a message and deliver it to the
mailbox that was specified (on the envelope) by the SMTP "RCPT TO:"
command. The ISP pointed out that this sham message text illustrates a
number of points:

 1. That the message To: and From: addresses can be just text strings=20
    with no bearing on where the envelope is delivered or who it is
from.

 2. That the Date: header in the message cannot be relied upon.

 3. That you cannot even rely on Received: headers in the message.

 4. That at the time this message left the orginating MTA _everything_
    in the message was _pure content_ AND had no bearing whatsoever  =20
    on where the message ended up or how it got there. All that
    information was specified in the SMTP envelope.

So why did the ISP insist that this text in the message (including a To,
a From and a Received header) was content and thus refused to hand it
over to Plod? The answer is that it is content because it is not
"communications data"!

RIPA does not define "content" but in S21(4) it does define
"communications data" so it seems reasonable for the ISP to conclude
that (for RIPA purposes)

  content =3D "the whole communication" - "the communications data"

None of the text that the ISP refused to hand over was "communications
data" because each line failed the tests in S21(4) which define
"communications data". So the ISP concluded that the text was content.
Looking at the tests in 21(4) that the ISP applied to each text line:

(a) Some of the text lines in the message appeared to be data purporting
to identify a person/apparatus/location but were clearly _not_ doing it
for the "purposes of any telecommunications system by means of which it
... may be transmitted".

To reinforce this point the ISP noted that the message had correctly
arrived in the mailbox specified by the SMTP envelope address rather
than that specified by the message-To address. The ISP also noted that
the mailbox owner had read the message via POP by connecting to the
mailbox address, not the message-To: address; the message had been
delivered without resort to any message text information. So all those
message text lines fail the test of 21(4)(a).=20

(b) The text lines also fail the tests of S21(4)(b) because they are
either _pure content_ or, alternatively, because they say _nothing_
about the use anyone made of any telecommunications service or system.
That information had been specified in the SMTP envelope and extracted
from the (Sendmail) logs and handed over to Plod along with any _new_
message headers that had been added to the communication while in
transit.=20

(c) The text lines fail the test of 21(4)(c) because, although the text
does not fall within S21(4)(a) or (b) it is _not_ information in
relation to persons to whom the ISP provides a service. Again, that
information was contained in the SMTP envelope and specified the
delivery mailbox. The ISP handed over the mailbox owners name and
address to Plod.

It seems to me that the ISP was acting very diligently but correctly in
response to the S22(4) notice in refusing to hand over some message
headers that Plod thought were "traffic data" but which he (the ISP)
could show were content.

The conclusion I draw from this (contrived but real) example is that in
relation to e-mail at least, Chapter II is so badly drafted that it may
be easier to get all the headers of an e-mail message through a PACE
production order or a Chapter I Interception Warrant than it will be
through a S22(4) notice. This latter point has interesting consequences.

  =20
Chapter II also seems to place the onus fairly and squarely on the ISP
to decide (when served with a S22(4) notice) which text lines of an
e-mail message are content and which are "communications data". It turns
out that there are no hard and fast rules that an ISP can follow to help
him determine this since the circumstances of each message in a mailbox
will likely be different.=20

RIPA offers little help to the ISP except to provide by implication the
(almost circular) definition that content is that part of the e-mail
message which is not "communications data".

Quentin
---
PHONE: +44 191 222 8209    Computing Service, University of Newcastle
FAX:   +44 191 222 8765    Newcastle upon Tyne, United Kingdom, NE1 7RU.
------------------------------------------------------------------------
"Any opinion expressed above is mine. The University can get its own."=20