FIPR amendment on "comms data"
Quentin Campbell
Q.G.Campbell at newcastle.ac.uk
Thu, 1 Jun 2000 13:42:38 +0100 (GMT)
On Wed, 31 May 2000, Charles Lindsey wrote:
> > I labour this point because I believe it neatly illustrates that
> > everything in an e-mail message being transmitted, *except* the envelope
> > recipient address, is content rather than communications data.
>
> No, communications data is anything in the headers that an ISP might
> look at in order to trace the source of some email about which there
> had been some complaint. A good spammer will leave no trace in any of
> those headers, but not all spammers are that good, and a competent ISP
> can deduce quite a lot from careful header scrutiny. I think Plod can
> reasonably expect to be able to try the same thing.
Charles
Why stop there? You could extend your argument to include the text of the
message as well. Then the whole message becomes "communications data".
A line has to be drawn somewhere.
Since the original message headers need have no relationship at all to the
*actual* envelope sender and recipient they are no business of Plod.
If you want to stretch the point then at the most Plod should only have
access to the "Received:" headers since they are not "original" message
headers or text.
However I would argue a more restrictive definition and suggest that in an
SMTP exchange between any two relay hosts, *everything* that comes after
the DATA statement should be treated as content. This would include
progressively more "Received:" headers as the message traversed relay
hosts.
The key issue here is that none of this is used, nor effects in any way,
the ability of the transmission system to effect delivery of the message
(to the next relay host). I thought I saw this as a condition that defines
"communications data" in RIP?
Forgetting the "Received:" headers for the moment, what comes after the
DATA statement are the orginal message headers plus the text of the
message plus attachments. This can all be considered message content
because the only thing that distinguishes message headers from the message
text is a single blank line. Move that blank line and headers become
message text or message text become headers.
Thus if a relay host inadvertently manages to add a blank line between two
message "header" lines (for example when it is adding a "Received:"
header) then that blank line and every line following it becomes part of
the *text of the message* as far as the recipient mailer is concerned.
There are some caveats to what I assert above but I believe it to be
essentially correct.
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."