ETSI TS 102 233 V1.2.1 (2004-05)

SLOVENSKI STANDARD
01-maj-2005
=DNRQLWRSUHVWUH]DQMH/,±6WRULWYHQRVSHFLILþQHSRGUREQRVWL]DVWRULWYH
HOHNWURQVNHSRãWH
Lawful Interception (LI); Service specific details for E-mail services
Ta slovenski standard je istoveten z: TS 102 233 Version 1.2.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Lawful Interception (LI);
Service specific details for E-mail services

2 ETSI TS 102 233 V1.2.1 (2004-05)

Reference
RTS/LI-00012
Keywords
email, handover, interface, IP, lawful interception,
security, traffic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2004.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 102 233 V1.2.1 (2004-05)
Contents
Intellectual Property Rights.5
Foreword.5
Introduction .5
1 Scope.6
2 References.6
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 General.8
4.1 E-mail services.8
5 System model.8
5.1 Reference network topology.8
5.2 Reference scenarios.9
5.2.1 E-mail send failure.9
5.2.2 E-mail send success .10
5.2.3 E-mail download detail.11
5.2.4 E-mail send detail .12
6 E-mail events.13
6.1 Introduction.13
6.2 E-mail send event .13
6.2.1 Introduction.13
6.2.2 E-mail Send captured content .14
6.2.3 E-mail send IRI.14
6.3 E-mail receive event.14
6.3.1 Introduction.14
6.3.2 E-mail receive captured content.15
6.3.3 E-mail receive IRI.15
6.4 E-mail download event.15
6.4.1 Introduction.15
6.4.2 E-mail download captured content .16
6.4.3 E-mail download IRI .16
7 E-mail attributes.16
7.1 E-mail protocol ID.16
7.2 E-mail address.16
7.3 E-mail recipient list .17
7.4 E-mail sender.17
7.5 Total recipient count.17
7.6 Message ID.17
7.7 Status.17
7.8 Server and client port .17
7.9 Server and client octets sent .17
Annex A (normative): SMTP .18
A.1 SMTP introduction.18
A.2 SMTP HI2 events .18
A.2.1 E-mail login event .18
A.2.2 E-mail send event .18
A.2.3 E-mail receive event.18
A.3 SMTP HI2 attributes .19
ETSI
4 ETSI TS 102 233 V1.2.1 (2004-05)
A.4 SMTP HI2 event-record mapping .19
Annex B (normative): POP3 .20
B.1 POP3 introduction.20
B.2 POP3 HI2 events .20
B.2.1 E-mail login event .20
B.2.2 E-mail download event.20
B.3 POP3 HI2 attributes .21
B.4 POP3 HI2 event-record mapping .21
Annex C (normative): IMAP4.22
C.1 IMAP4 introduction.22
Annex D (normative): E-mail ASN.1.23
Annex E (informative): E-mail LI requirements.25
E.1 HI2 requirements.25
E.2 HI3 requirements.26
E.3 General requirements.27
E.4 Requirements mapping.27
Annex F (informative): SMTP characteristics .28
F.1 SMTP service characteristics .28
F.2 SMTP protocol characteristics .28
Annex G (informative): POP3 characteristics.29
G.1 POP3 service characteristics .29
G.2 POP3 protocol characteristics .29
Annex H (informative): Discussion of webmail interception.30
H.1 Webmail network topology.30
H.2 Webmail protocols.30
H.3 Webmail interception.31
Annex I (informative): Discussion for Driving HI2 of HI3.32
I.1 Introduction.32
I.2 Discussion.32
I.2.1 Introduction.32
I.2.2 IP packets.33
I.2.3 TCP packets.33
I.2.4 SMTP packets.33
I.2.5 E-mail messages.33
I.3 Conclusion.34
Annex J (informative): Change Request History.35
History .36

ETSI
5 ETSI TS 102 233 V1.2.1 (2004-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI).
Introduction
The present document describes what information is required for the handover of intercepted IP-based E-mail traffic
from a Communications Service Provider to an LEMF. The present document covers a stage 2 description of the data,
but does not specify any functionality within the scope of TS 102 232 [3].
The ITU-T Recommendation I.130 [6] method for characterizing a service will be used as a general framework for the
present document. The modified concept of a "stage 1" will be called the "attributes" of the interface. The attributes of
the interface are the sum total of all the constituent attributes that an interface may need to communicate. The modified
concept of a "stage 2" will be called the "events" of the interface. The events of the interface define the rules of the
relationships between the attributes that are required to arrange the disjoint attributes into meaningful information for an
E-mail service interaction.
The present document is intended to be general enough to be used in a variety of E-mail services. It should be
recognized that a side effect of this approach is some IRI fields identified may be difficult to extract or non-existent
depending on the E-mail service being intercepted. In such cases it may be completely reasonable that the delivered IRI
contain empty fields or fields with the value 0.
ETSI
6 ETSI TS 102 233 V1.2.1 (2004-05)
1 Scope
The present document contains a stage 1 like description of the interception information in relation to the process of
sending and receiving E-mail. The present document also contains a stage 2 like description of when Intercept Related
Information (IRI) and Content of Communication (CC) shall be sent, and what information it shall contain.
It is recognized that "Instant Messenger" and "Chat" applications are another way of exchanging electronic text
messages. While the present document may be applicable to such applications it is in no way a goal of the present
document to address these methods of electronic text messaging.
The definition of handover transport and encoding of HI2 and HI3 is outside the scope of the present document. Refer
to TS 102 232 [3].
The present document is designed to be used where appropriate in conjunction with other deliverables that define the
service specific IRI data formats. The present document aligns with TS 133 108 [5], ES 201 671 [4], TS 101 331 [1]
and TR 101 944 [2].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
[1] ETSI TS 101 331: "Telecommunications security; Lawful Interception (LI); Requirements of law
enforcement agencies".
[2] ETSI TR 101 944: "Telecommunications security; Lawful Interception (LI); Issues on IP
Interception".
[3] ETSI TS 102 232: "Telecommunications security; Lawful Interception (LI); Handover
specification for IP delivery".
[4] ETSI ES 201 671: "Telecommunications security; Lawful Interception (LI); Handover interface
for the lawful interception of telecommunications traffic".
[5] ETSI TS 133 108: "Universal Mobile Telecommunications System (UMTS); 3G security;
Handover interface for Lawful Interception (LI) (3GPP TS 33.108 version 5.5.0 Release 5)".
[6] ITU-T Recommendation I.130: "Method for the characterization of telecommunication services
Supported by an ISDN and network capabilities of an ISDN".
[7] IETF RFC 0822: "Standard for the format of ARPA Internet text messages".
[8] IETF RFC 1939: "Post Office Protocol - Version 3".
[9] IETF RFC 2821: "Simple Mail Transfer Protocol".
[10] IETF RFC 3501: "Internet Message Access Protocol - Version 4 rev1".
[11] ITU-T Recommendation X.680/ISO/IEC 8824-1: "Information technology - Abstract Syntax
Notation One (ASN.1): Specification of basic notation".
ETSI
7 ETSI TS 102 233 V1.2.1 (2004-05)
[12] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions - Part 1:
Country codes".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
E-mail Address: ARPANET E-mail address
NOTE: As described in RFC 0822 [7], clause 6.
IMAP4: protocol used to manipulate mailbox parameters on a server
NOTE: Described in RFC 3501 [10].
mailbox: destination point of E-mail messages
POP3: widely used protocol for downloading E-mails from a server to a client
NOTE: Described in RFC 1939 [8].
recipient: E-mail address of a destination mailbox for an E-mail being transmitted
NOTE 1: Each E-mail may contain one or more recipients.
NOTE 2: In this definition there is no distinction made between E-mail addresses on a "To:" line and E-mail
addresses on a "Cc:" or "Bcc:" line. They are all "recipients" of the E-mail.
sender: E-mail address of the mailbox that originated an E-mail being transmitted
NOTE: Each E-mail contains only one sender.
SMTP: widely used protocol for transferring E-mails between computers
NOTE: Described in RFC 2821 [9].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
APOP POP3 authentication message
ASN.1 Abstract Syntax Notation One
CC Content of Communication
CPE Customer Premises Equipment
HI2 Handover Interface port 2 (for Intercept Related Information)
HI3 Handover Interface port 3 (for Content of Communication)
HTTP Hyper Text Transfer Protocol
IMAP4 Internet Message Access Protocol version 4
IP Internet Protocol
IRI Intercept Related Information
ISDN Integrated Services Digital Network
ISP Internet Service Provider
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Facility
MF Mediation Function
MTA Mail Transfer Agents
NWO Network Operator
POP3 Post-Office Protocol version 3
PSTN Public Switched Telecommunication Network
ETSI
8 ETSI TS 102 233 V1.2.1 (2004-05)
RETR POP3 Retrieve message
SMTP Simple Mail Transfer Protocol
SP Service Provider
TCP Transmission Control Protocol
4 General
4.1 E-mail services
E-mail services are those services which offer the capability to transmit or receive ARPANET text messages. The
following description is taken from RFC 0822 [7]:
"In this context, messages are viewed as having an envelope and contents. The envelope contains whatever information
is needed to accomplish transmission and delivery. The contents compose the object to be delivered to the recipient".
E-mail service, in general, can be divided into two categories: those services which allow a computer to transfer a
message to another computer; and those services which allow users to manipulate their mailbox by doing such things as
downloading messages from the mailbox and deleting messages from the mailbox. Both of these categories of E-mail
services can be of interest to Law Enforcement Agencies (LEAs) and are therefore within the scope of the present
document.
NOTE: When using IP-packet delivery, control level packets that are associated with the targeted E-mail may be
delivered as content. Control level packets are those packets that are used by the E-mail transfer protocol
to set-up the E-mail communication and to terminate the E-mail communication and are outside of the
traditional RFC 0822 [7] formatted E-mail. This allows for different interception solutions without
burdening the Mediation Function (MF) with the responsibility of "cleaning" up said differences in input.
5 System model
5.1 Reference network topology
The network topology shown in figure 1 is intended to represent the many relationships that may exist between the
entities involved in E-mail communications. Actual scenarios using this diagram are enumerated in clause 5.2. The
following should be considered when viewing figure 1:
• The term "Mail Server" is used to represent a logical entity that relays mail for its mail clients, receives and
(temporarily) stores mail for its mail clients, and allows mail clients access to the aforementioned stored mail
and the ability to delete it from the mail server.
• The term "Mail Client" is used to represent a logical entity that either injects mail into the network or removes
mail from the network or reads mail from the network.
• Mail Client and Mail Server numbers are used to indicate what entities share a client-server relationship, so
Mail Client1 is a client of Mail Server1, etc.
• A Mail Server may communicate with any other Mail Server within figure 1.
NOTE: Web access to mail is commonly used; web mail is addressed in annex H.
ETSI
9 ETSI TS 102 233 V1.2.1 (2004-05)
Mail Mail
Server Server
1 2
Log Log
IP Network IP Network
CPE
CPE
Mail
Mail
Client
Client
Customer
CPE
IP Network IP Network
Mail
Client
3a
Mail Mail CPE
Server Server
Mail
4 3
Client
Log Log 3b
Customer
Figure 1: Reference network topology
5.2 Reference scenarios
5.2.1 E-mail send failure
It may occur that E-mails sent into the Internet do not reach their intended target. The most common reason for this
would seem to be a mistaken E-mail address, but could also be problems contacting the receiving mail server or other
server issues. Note that a failure reply message is not always generated and if a failure reply message is generated, it is
generated by the Mail Server that first experiences problems transferring the mail message.
a) Client3a sends an E-mail to nobody@MailServer4.com and gives the E-mail to the clients' server, Mail
Server3.
b) Mail Server3 fills in part of the E-mail envelope and routes the E-mail to Mail Server4.
c) Mail Server4 replies to Mail Server3 that the recipient is unknown.
d) Mail Server3 creates a "reply" message to Mail Client3a stating that the recipient was unknown, and either
pushes that message to the client or stores it in the clients' mailbox for later retrieval.
ETSI
10 ETSI TS 102 233 V1.2.1 (2004-05)
Mail
Mail
Server
Server
Log Log
CPE
IP Network IP Network
CPE
Mail Mail
Client2 Client1
Customer
CPE
IP Network IP Network
a
c
Mail
Client3a
d
b
Mail
CPE
Mail
Server
Server
Mail
Client3b
Log
Log
Customer
Figure 2: E-mail send failure
5.2.2 E-mail send success
This scenario represents what is likely to be the most common case of an E-mail send. While it is unclear how many
E-mails go directly from a clients E-mail server to the destination E-mail server, it is clear that routing of E-mails
through Mail Transfer Agents (MTA) is not uncommon and as such is the scenario represented here. The direct routing
scenario is a subset where the middle mail server is removed. Note also that the client sending the E-mail is not on the
same administrative network as its mail server.
a) Client1 sends an E-mail to client3b@MailServer3.com and gives the E-mail to the clients' server, Mail
Server1.
b) Mail Server1 fills in part of the E-mail envelope and forwards the mail to Mail Server4 for forwarding.
c) Mail Server4 attaches its information to the E-mail envelope and forwards the mail to Mail Server3.
d) Mail Server3 either pushes the message to the Mail Client3b or stores it in the clients' mailbox for later
retrieval.
ETSI
11 ETSI TS 102 233 V1.2.1 (2004-05)
Mail Mail
Server Server
1 2
Log Log
b
IP Network
a
IP Network
CPE
Mail
CPE
Client1
Mail
Client2
Customer
IP Network IP Network
CPE
Mail
Client
3a
c
d
CPE
Mail
Mail Mail
Client
Server Server
3b
4 3
Log
Log
Customer
Figure 3: E-mail send success
5.2.3 E-mail download detail
This scenario enumerates the processes that must take place in any E-mail download process. It is assumed that some
set of E-mail is already resident on the Mail Server3 in the mailbox for Mail Client3a.
a) Mail Client3a sends login credentials. This may take several messages or may be accomplished in a single
message depending on the mailbox access protocol. What is protocol invariant is that this login process will
contain some form of authentication process.
b) Mail Server3 sends an "authentication success" message to indicate to the client that the login process is
complete. At this stage Mail Server3 may push down mailbox state to the client, or may wait for the client to
request mailbox state. Using POP3, however, Mail Server3 will not push down messages until the have been
explicitly requested by the client.
c) Mail Client3a may request a message or a set of messages to be downloaded, however this step may be
bypassed in some protocols.
d) Mail Server3 downloads the requested messages to Mail Client3a.
e) After the mail has been downloaded the server may delete the message as the result of a request.
ETSI
12 ETSI TS 102 233 V1.2.1 (2004-05)

CPE
IP
Network
Mail Client3a
CPE
Mail Server3 Mail Client3b
Customer
Log
Figure 4: E-mail download detail
5.2.4 E-mail send detail
This scenario enumerates the processes that must take place in any E-mail send process. In the scenario the relationship
between Mail Server3 and Mail Client3a is such that the mail is first sent to Mail Server3, which then forwards the mail.
While this process seems universally true it need not be true. Mail Client 3a could send the mail to the terminating mail
server.
a) Mail Client3a sends introduction. This may take several messages or may be accomplished in a single message
depending on the mailbox access protocol. The authentication features and capabilities is protocol dependent
and authentication may be used in some protocols and not in others.
b) Mail Server3 sends a "login success" message to indicate to the client that the login process is complete.
c) Mail Client3a initiates a send by including the sender E-mail address, the list of recipient E-mail addresses,
and the text body of the message.
d) Mail Server3 sends a response indicating that the mail has been successfully received. At this point Mail
Server3 begins the process of determining the correct mail servers for each of the recipients, updating the mail
text to include information in the envelope, and forwarding the mail.
ETSI
13 ETSI TS 102 233 V1.2.1 (2004-05)

a
IP Network
b CPE
c
d
Mail Client3a
Mail Server3 CPE
Mail Client3b
Customer
Log
Figure 5: E-mail send detail
6 E-mail events
6.1 Introduction
This clause contains the high level definition of the content and the IRI messages associated with different E-mail
communication "events". An "E-mail communication event" is a way of expressing different points in an E-mail
transfer where a target may become active. All E-mail communication events are represented by one or more IRI
records and potentially content. Clause 6 does not specify how the information is encoded but specifies what
information shall be encoded.
This clause only lays out which fields shall be present in each event and what requirement is fulfilled by the field. The
definition of each field is either in another document or in clause 7.
6.2 E-mail send event
6.2.1 Introduction
The E-mail send event is represented in clauses 5.2.2 and 5.2.4. This event is represented by a set of IRI and content
associated with an E-mail being sent by a target. Each E-mail sent during a session between an E-mail client and an
E-mail server must be considered a separate E-mail send event.
There is currently no IRI specified specifically for E-mail send "attempts", and no indication of E-mail send "success"
or "failure". E-mail failures often occur a few servers down from where the initial E-mail is sent, and notification of said
failure is optional and difficult to automatically correlate when it does occur.
This set of IRI fulfils requirement [E.1.1].
ETSI
14 ETSI TS 102 233 V1.2.1 (2004-05)
6.2.2 E-mail Send captured content
The target may have been matched for an E-mail send by the E-mail address of the sender, login name of the sender, or
the IP address. Due to the wide array of intercept options and possible E-mail protocols the captured content maybe just
the equivalent of the RFC 0822 [7] E-mail envelope and text or, at the other extreme, the captured content may be the
whole E-mail session. What must be present is the RFC 0822 [7] E-mail envelope and text for E-mails sent by the
target.
This clause fulfils requirement [E.2.1] and [E.2.2].
6.2.3 E-mail send IRI
The following information may be present in E-mail Send IRI. The availability of this information will depend on the
implementation and national regulations.
Table 1: E-mail send IRI information
Field name Requirement fulfilled Where defined
Server IP [E.1.7] ES 201 671 [4], IP address
Client IP [E.1.7] ES 201 671 [4], IP address
Server Port [E.1.7] Clause 7
Client Port [E.1.7] Clause 7
E-mail Protocol ID [E.1.10] Clause 7
E-mail Sender [E.1.3] Clause 7
E-mail Recipient List [E.1.3] Clause 7
Total Recipient Count [E.1.5] Clause 7
Server Octets Sent [E.1.7] Clause 7
Client Octets Sent [E.1.7] Clause 7
Message ID [E.1.12] Clause 7
Status [E.1.11] Clause 7
Note that in this case, both Octets Sent fields are indicators of the amount of communication occurring. Due, however,
to differing laws and interception capabilities it is not specified exactly what these byte counts are, only that they
accurately represent the amount of information being transferred by the target. That is to say, these byte counts can not
be the byte count of an entire E-mail session in which many E-mails are sent but only one of those E-mails was sent by
the target entity as the numbers would no longer be representative of the amount of information being transferred by the
target. Similarly these byte counts can not be taken to be a one-to-one match of the number of bytes in an E-mail as they
may include the control traffic to set-up the E-mail or may include some filing system overhead.
Finally it is worth noting that if the intercept capability is not done based on a protocol but instead based on information
on a file system, the Server Octets Sent could be 0 if that accurately represents that the server sent little or no
information back to the client.
6.3 E-mail receive event
6.3.1 Introduction
The E-mail receive event is best represented in clause 5.2.3 and represents a set of IRI and content associated with an
E-mail being received by a target mailbox. Each E-mail received during a session between an E-mail client and an
E-mail server must be considered a separate E-mail receive event.
There is currently no IRI defined for E-mail receive "attempts", and no indication of E-mail receive "success" or
"failure". The reason for this decision is because it is deemed an excessive burden on all the parties involved in an
intercept for the amount of information that can be obtained.
This set of IRI fulfils requirement [E.1.2].
ETSI
15 ETSI TS 102 233 V1.2.1 (2004-05)
6.3.2 E-mail receive captured content
The target may have been matched for an E-mail receive by the E-mail address of the recipient, login name of the
recipient, or the IP address of the client. Due to the wide array of intercept options and possible E-mail protocols the
captured content maybe just the equivalent of the RFC 0822 [7] E-mail envelope and text, or, at the other extreme, the
captured content may be the whole E-mail session. What must be present is the RFC 0822 [7] E-mail envelope and text
for E-mails received by the target.
This clause fulfils requirement [E.2.1] and [E.2.2].
6.3.3 E-mail receive IRI
The following information may be present in E-mail receive IRI. The availability of this information will depend on the
implementation and national regulations.
Table 2: E-mail receive IRI information
Field name Requirement fulfilled Where defined
Server IP [E.1.7] ES 201 671 [4], IP address
Client IP [E.1.7] ES 201 671 [4], IP address
Server Port [E.1.7] Clause 7
Client Port [E.1.7] Clause 7
E-mail Protocol ID [E.1.10] Clause 7
E-mail Sender [E.1.3] Clause 7
E-mail Recipient List [E.1.3] Clause 7
Total Recipient Count [E.1.5] Clause 7
Server Octets Sent [E.1.7] Clause 7
Client Octets Sent [E.1.7] Clause 7
Message ID [E.1.12] Clause 7
Status [E.1.11] Clause 7
Note that in this case both Octets Sent fields are indicators of the amount of communication occurring. However, due to
differing laws and interception capabilities it is not specified exactly what these byte counts are, only that they
accurately represent the amount of information being transferred to the target. For instance, these byte counts may not
be the byte count of an entire E-mail session in which many E-mails are transferred but only one of those E-mails was
destined to the target entity. In that case the session byte count would no longer be representative of the amount of
information being transferred to the target. Similarly these byte counts could not be taken to be a one-to-one match of
the number of bytes in an E-mail as they may include the control traffic to set-up the E-mail or may include some filing
system overhead.
Finally it is worth noting that if the intercept capability is not done based on a protocol but instead based on information
on a file system, the Client Octets Sent could be 0 if that accurately represents that the client sent little or no information
back to the server.
6.4 E-mail download event
6.4.1 Introduction
The E-mail Download Event is best represented in clause 5.2.3 and represents a set of IRI and content associated with
an E-mail being downloaded from a target mailbox. Each E-mail downloaded during a session between an E-mail client
and an E-mail server must be considered a separate E-mail Download Event.
There is currently no IRI defined for E-mail download "attempts". The reason for this decision is because it is deemed
an excessive burden on all the parties involved in an intercept for the amount of information that can be obtained.
This set of IRI fulfils requirement [E.1.2].
ETSI
16 ETSI TS 102 233 V1.2.1 (2004-05)
6.4.2 E-mail download captured content
The target may have been matched for an E-mail Download by the E-mail address of the recipient, login name of the
recipient, or the IP address of the client. Due to the wide array of intercept options and possible E-mail protocols the
captured content maybe just the equivalent of the RFC 0822 [7] E-mail envelope and text, or, at the other extreme, the
captured content may be the whole E-mail session. What must be present is the RFC 0822 [7] E-mail envelope and text
for E-mails received by the target.
This clause fulfils requirement [E.2.1] and [E.2.2].
6.4.3 E-mail download IRI
The following information may be present in E-mail Download IRI. The availability of this information will depend on
the implementation and national regulations.
Table 3: E-mail download IRI information
Field name Requirement fulfilled Where defined
Server IP [E.1.7] ES 201 671 [4], IP address
Client IP [E.1.7] ES 201 671 [4], IP address
Server Port [E.1.7] Clause 7
Client Port [E.1.7] Clause 7
E-mail Protocol ID [E.1.10] Clause 7
E-mail Sender [E.1.3] Clause 7
E-mail Recipient List [E.1.3] Clause 7
Total Recipient Count [E.1.5] Clause 7
Server Octets Sent [E.1.7] Clause 7
Client Octets Sent [E.1.7] Clause 7
Message ID [E.1.12] Clause 7
Status [E.1.11] Clause 7
7 E-mail attributes
The availability of the information described in this clause will depend on the implementation and national regulations.
7.1 E-mail protocol ID
This attribute can be used to identify the E-mail application or protocol that was used at the point of interception to
transfer the E-mail. This should identify which appendix should be looked at for encoding rules. A full enumeration of
this attribute is provided in annex D, however a brief list should help provide an example for the definition. This
attribute shall contain values including, but not limited to:
• SMTP;
• POP3.
7.2 E-mail address
All E-mail address attributes are text strings that indicate an E-mail address in the form that it was intercepted in. E-mail
addresses may be fully qualified, however many points of interception will not provide fully qualified E-mail addresses.
The above definition of an E-mail Address fulfils requirement [E.1.4].
ETSI
17 ETSI TS 102 233 V1.2.1 (2004-05)
7.3 E-mail recipient list
This is a list of one or more E-mail address of the intended recipients of an E-mail. Note that this list may not be
complete and only contains those recipient addresses that can be intercepted by the interception equipment. SMTP can
be used as an example, where only a proper sub-set of the recipients can be seen within the protocol itself.
NOTE: The amount of information which can be retrieved from the SMTP protocol depends on the choice of
where the interception equipment is placed in the network.
7.4 E-mail sender
This is a single E-mail address representing the intercepted address of the sender of a targeted E-mail.
7.5 Total recipient count
This attribute is an integer representing the total number of recipients that the interception equipment noticed, even if all
those recipients could not be explicitly enumerated in the E-mail Recipient List.
7.6 Message ID
This attribute is used, when available, to relay a message identifier with a message. Applications which communicate
primarily through message ID's may use this attribute to relay this information to the LEMF. When present, this
attribute and its exact meanings will be highly dependent on the E-mail application and will be specified in the
application specific appendix.
7.7 Status
This attribute identifies the status of th
...