Tracing Emails

Tracing Emails

So you want to find out where that virus-laden email came from, or where that annoying spam came from? Let's look at a real example, straight from my in-box a few minutes ago. Before we start, if you're not too clear on how email works, you might want to read this article on how the SMTP protocol works. You might also want to refer to RFC 822, which defines the various fields in an email header

This turned up in my email, apparently from "Delbert Burroughs", with a subject line of "Windows Critical virus update - september 9th". I don't know how spammers come up with those names, but there's something instantly recognisable about them, and besides, I don't know any Delberts at all, so I went to work on this one.

First, I exported it from my email client. I use Lotus Notes, which doesn't do a good job of preserving the full format of email delivered from the Internet, but the basic header information is retained. Here's the email:

Received: from adsl-64-160-26-41.dsl.lsan03.pacbell.net ([64.160.26.41]) by bifrost.lesbell.com.au (Lotus Domino Release 5.0.6a) with SMTP id 2004093010163953:11798 ; Thu, 30 Sep 2004 10:16:39 +1000
X_Message_Info: 8gMXfm993kQU/qvVseaUNeICscxrK4Sk
Received: from vreeland ([0.136.144.80]) by pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com (InterMail vM.5.01.05.12 104-873-312-355-439-07016053) with ESMTP id <01109546157750.VQMZ129236.gme72-mail.bluestocking.dogfish.net.cable.rogers.com@origin> for <lesbell@lesbell.com.au>; Fri, 19 Sep 2003 08:56:30 -0100
$MessageID: <737675n6qamr$5914g6k7$8398v1e2@gail>
ReplyTo: "Delbert Burroughs" <ucrccvz@iname.com>
From: "Delbert Burroughs" <ucrccvz@iname.com>
SendTo: <lesbell@lesbell.com.au>
Subject: Windows Critical virus update - september 9th
PostedDate: 19/09/2003 07:54:30 PM
MIME_Version: 1.0
$MIMETrack: Itemize by SMTP Server on Bifrost/Les Bell and Associates Pty Ltd(Release 5.0.6a |January 17, 2001) at 30/09/2004 10:16:51 AM,MIME-CD by Notes Client on Les Bell/Les Bell and Associates Pty Ltd(Release 5.0.5 |September 22, 2000) at 30/09/2004 10:34:17 AM,MIME-CD complete at 30/09/2004 10:34:17 AM
SMTPOriginator: ucrccvz@iname.com
$UpdatedBy: CN=Bifrost/O=Les Bell and Associates Pty Ltd
$Orig:
Categories:
$Revisions:
RouteServers: CN=Bifrost/O=Les Bell and Associates Pty Ltd
RouteTimes: 30/09/2004 10:16:51 AM-30/09/2004 10:16:52 AM
$MsgTrackFlags: 0
DeliveredDate: 30/09/2004 10:16:52 AM

Wired Magazine special report:
Spyware is the leading cause of PC failure and hard drive corruption.
These malicious code and scripts compromise your privacy and lead to
identity theft.
Please scan your computer

*r*e*l*e*a*s*e
yule pewterbagley soulful accommodatemarshland brewster kiddieallen
chevrolet solvegarrett caucasus isaacsoncoed inorganic
sequestrationneuralgia effie haroldgreater autoclave proclamationpalmetto
%PRIVITE_INFO %SIGNATURE_NEXT

Let's go through the header, line by line. First:

Received: from adsl-64-160-26-41.dsl.lsan03.pacbell.net ([64.160.26.41]) by bifrost.lesbell.com.au (Lotus Domino Release 5.0.6a) with SMTP id 2004093010163953:11798 ; Thu, 30 Sep 2004 10:16:39 +1000

Each MTA (Message Transfer Agent, or mail server) prepends a "Received" header line as it receives the incoming email. This one tells us that the email was received from a machine that claimed, in its HELO or EHLO SMTP exchange, to be called adsl-64-160-26-41.dsl.lsan03.pacbell.net . The MTA will take that on trust, usually, but it's simplicity itself for the sending machine to use any name that it wants, so it's best for a human investigator to ignore the name until we can prove it's correct. However, it's extremely difficult for the sending machine to forge the source IP address in the datagrams that it sends to deliver the message - it has to receive acknowledgements as part of the TCP session that it's using - and so the IP address that is recorded next by the MTA is almost certainly correct. In this case, the address is 64.160.26.41 and as you can see, that matches up pretty well with the name. A name like that, which includes the IP address, usually indicates a machine on a dial-up, ADSL or cable modem connection, and this one is almost certainly a Windows machine on a consumer-grade ADSL connection provided by Pacific Bell.

As a double-check, we could use the dig command to do a reverse lookup on the IP address:

[les@sleipnir les]$ dig -x 64.160.26.41

; <<>> DiG 9.2.1 <<>> -x 64.160.26.41
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27969
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;41.26.160.64.in-addr.arpa. IN PTR

;; ANSWER SECTION:
41.26.160.64.in-addr.arpa. 172741 IN PTR adsl-64-160-26-41.dsl.lsan03.pacbell.net.

;; AUTHORITY SECTION:
26.160.64.in-addr.arpa. 172741 IN NS ns2.pbi.net.
26.160.64.in-addr.arpa. 172741 IN NS ns1.pbi.net.

;; ADDITIONAL SECTION:
ns1.pbi.net. 172740 IN A 206.13.28.11
ns2.pbi.net. 172740 IN A 206.13.29.11

;; Query time: 2 msec
;; SERVER: 192.168.168.1#53(192.168.168.1)
;; WHEN: Thu Sep 30 10:49:49 2004
;; MSG SIZE rcvd: 169

[les@sleipnir les]$

As you can see, the ANSWER section confirms the address and name match up. On the evidence so far, this looks like a Windows zombie - that is, a machine that has been infected by a worm and is being used by a spammer to send out their nastygrams. It's quite probable that any Received lines after this one will be forged, but we'll reserve judgement for now.

Continuing through the first Received: line, we can see that the email was received by bifrost.lesbell.com.au, which claims to be Domino 5.0.6a server (it isn't, but security by obscurity gives a slight edge). It was allocated an SMTP ID number, which is of no significance, and was received at Thu, 30 Sep 2004 10:16:39 +1000 - that last +1000 indicates that our timezone is 10 hours ahead of GMT.

Next, we see

X_Message_Info: 8gMXfm993kQU/qvVseaUNeICscxrK4Sk

which is a completely meaningless line, unless - perhaps - it is a unique key which will let the spammer identify the recipient of the email if the header is ever returned to them.

Next, another Received: line:

Received: from vreeland ([0.136.144.80]) by pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com (InterMail vM.5.01.05.12 104-873-312-355-439-07016053) with ESMTP id <01109546157750.VQMZ129236.gme72-mail.bluestocking.dogfish.net.cable.rogers.com@origin> for <lesbell@lesbell.com.au>; Fri, 19 Sep 2003 08:56:30 -0100

Now, this line should have been generated by the machine that relayed the email to us, so its name should be adsl-64-160-26-41.dsl.lsan03.pacbell.net - but it's now claiming to be pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com. Alarm bells are starting to ring - there's probably no such machine and this line is forged. Let's check - first, use the host command to see if it has a DNS entry:

[les@sleipnir les]$ host pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com
Host pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com not found: 3(NXDOMAIN)
[les@sleipnir les]$

It doesn't even look like a proper fully-qualified domain name. The name and IP address of the host it claims to have received this from is another clue: vreeland ([0.136.144.80]) . vreeland is not a proper hostname, and the IP address claims to be in network zero, which is not a valid network address. The rest of this line, including the obviously-concocted ESMTP ID, and the fact that the timestamp is ten days in the past, all add up to the obvious conclusion: this line is a complete fabrication, and was generated by the sending machine, under control of the spammer, in an attempt to throw us off the scent and perhaps have us complaining to someone at rogers.com - who are innocent bystanders.

The next line is also irrelevant:

$MessageID: <737675n6qamr$5914g6k7$8398v1e2@gail>

and the next two just provide a fake name and email address for the spammer

ReplyTo: "Delbert Burroughs" <ucrccvz@iname.com>
From: "Delbert Burroughs" <ucrccvz@iname.com>

The SendTo: line (Lotus Domino appears to convert To: to SendTo:) is the email address of the recipient, in this case:

SendTo: <lesbell@lesbell.com.au>

but it quite often isn't - and there's an interesting reason for this. The receiving MTA will always go on what is in the RCPT TO: exchange part of the SMTP conversation it has with the sending machine, and this will over-ride whatever is in the RFC822 To: header. So the email header could actually say almost anything, and the mail will still wind up in your in-box. The Subject: line just is what it is, but the PostedDate: field (which is Domino's parsing of the RFC822 Date: field) is obviously wrong. This email didn't hang around in some kind of Internet Twilight Zone for ten days before being delivered.

The stuff that follows in the header is all Lotus Domino information and isn't relevant here.

The header is followed by a blank line, then the body of the email

Wired Magazine special report:
Spyware is the leading cause of PC failure and hard drive corruption.
These malicious code and scripts compromise your privacy and lead to
identity theft.
Please scan your computer

*r*e*l*e*a*s*e
yule pewterbagley soulful accommodatemarshland brewster kiddieallen
chevrolet solvegarrett caucasus isaacsoncoed inorganic
sequestrationneuralgia effie haroldgreater autoclave proclamationpalmetto
%PRIVITE_INFO %SIGNATURE_NEXT

What's not visible is that Lotus Notes stripped out some HTML tags and links while exporting this email. As you can see, there's also some garbage text which is there to fool spam-filtering software by reducing the proportion of spam-identifying keywords in the entire email.

Using SpamCop

One way of automating the above analysis is to paste the email - header alone, or header plus body - into a form at SpamCop (http://www.spamcop.net). Here's what SpamCop made of the above email:

Parsing header:

Received: from adsl-64-160-26-41.dsl.lsan03.pacbell.net ([64.160.26.41]) by bifrost.lesbell.com.au (Lotus Domino Release 5.0.6a) with SMTP id 2004093010163953:11798 ; Thu, 30 Sep 2004 10:16:39 +1000
64.160.26.41 found
host 64.160.26.41 = adsl-64-160-26-41.dsl.lsan03.pacbell.net (cached)
host adsl-64-160-26-41.dsl.lsan03.pacbell.net (checking ip) = 64.160.26.41
Possible spammer: 64.160.26.41
Received line accepted

Received: from vreeland ([0.136.144.80]) by pud45-mail.bordeaux.acrylic.appalachia.cable.rogers.com (InterMail vM.5.01.05.12 104-873-312-355-439-07016053) with ESMTP id <01109546157750.VQMZ129236.gme72-mail.bluestocking.dogfish.net.cable.rogers.com@origin> for <x>; Fri, 19 Sep 2003 08:56:30 -0100 $MessageID: <737675n6qamr$5914g6k7$8398v1e2@gail>
0.136.144.80 found
host 0.136.144.80 (getting name) no name
64.160.26.41 not listed in dnsbl.njabl.org
64.160.26.41 listed in cbl.abuseat.org ( 127.0.0.2 )
Open proxies untrusted as relays
Tracking message source: 64.160.26.41:
Routing details for 64.160.26.41
[refresh/show] Cached whois for 64.160.26.41 : abuse@pacbell.net
Using abuse net on abuse@pacbell.net
abuse net pacbell.net = abuse@pacbell.net
Using best contacts abuse@pacbell.net
Yum, this spam is fresh!
Message is 1 hours old
64.160.26.41 not listed in dnsbl.njabl.org
64.160.26.41 not listed in dnsbl.njabl.org
64.160.26.41 listed in cbl.abuseat.org ( 127.0.0.2 )
64.160.26.41 is an open proxy
64.160.26.41 not listed in query.bondedsender.org
64.160.26.41 not listed in iadb.isipp.com
Finding links in message body
Parsing text part
no links found

This pretty much backs up our earlier analysis.

Another Example:

Here's another example:

Received: from dvalin.lesbell.com.au ([192.168.168.252]) by bifrost.lesbell.com.au (Lotus Domino Release 5.0.6a) with ESMTP id 2004093010504552:11811 ; Thu, 30 Sep 2004 10:50:45 +1000
Received: from 203.35.202.157 (unknown [62.68.83.17]) by dvalin.lesbell.com.au (Postfix) with SMTP id 2C75F1B833 for <lesbell@lesbell.com.au>; Thu, 30 Sep 2004 10:50:30 +1000 (EST)
Received: from 233.202.78.84 by 62.68.83.17; Wed, 29 Sep 2004 20:50:27 -0500
$MessageID: <RICKGKFFSXXMGWIJHZIDF@msn.com>
From: "Morris Mckay" <YSFDKINAG@hotmail.com>
ReplyTo: "Morris Mckay" <YSFDKINAG@hotmail.com>
SendTo: lesbell@lesbell.com.au
Subject: Unbelievable 0ffers Lesbell
PostedDate: 30/09/2004 10:50:30 AM
$MIMETrack: Itemize by SMTP Server on Bifrost/Les Bell and Associates Pty Ltd(Release 5.0.6a |January 17, 2001) at 30/09/2004 10:50:45 AM,MIME-CD by Notes Client on Les Bell/Les Bell and Associates Pty Ltd(Release 5.0.5 |September 22, 2000) at 30/09/2004 11:26:38 AM,MIME-CD complete at 30/09/2004 11:26:38 AM
SMTPOriginator: YSFDKINAG@hotmail.com
$UpdatedBy: CN=Bifrost/O=Les Bell and Associates Pty Ltd
$Orig:
Categories:
$Revisions:
RouteServers: CN=Bifrost/O=Les Bell and Associates Pty Ltd
RouteTimes: 30/09/2004 10:50:45 AM-30/09/2004 10:50:45 AM
$MsgTrackFlags: 0
DeliveredDate: 30/09/2004 10:50:45 AM

User ID: 6 bitch
Date: Wed, 29 Sep 2004 22:48:27 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--180587507295901797"

----180587507295901797
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

Why pay more when you can enjoy the best and cheapest pills online?
Nearly 80 types to choose which makes ours pharmacy the largest and the
best available.

No Appointments.
No Waiting Rooms.
No Prior Prescription Required.

See why our customers re-order more than any competitor!

http://www.iggh<URL obscured>sent.net/2/?wid=200007

This is 1-time mai|-ing. No rem0val are re-qui-red
E4Ngk8n8DMEEPBOX6MmnqDSHfTGXS1o4xyxTVvzHOI3h1A

----180587507295901797--

If you read through the Received: header lines, you'll see that this one was delivered from dvalin.lesbell.com.au, on the IP address 192.168.168.252. Now, bifrost.lesbell.com.au is our email gateway, but dvalin.lesbell.com.au is our backup mail exchanger (MX) with a preference value of 20. Normally, mail would be delivered to bifrost (preference: 10) but the spammers know that there is often spam filtering software on primary MX's, but no filtering on backup MX's - so they will deliberately deliver their mail to the backup MX.

(In particular, primary mail servers are often on-site and have access to LDAP directories, so that they will refuse to accept email for non-existent mailbox addresses. However, backup mail servers are often provided by the upstream ISP and so they don't know the mailbox names at the final server - they have no choice but to accept the email in good faith).

So, dvalin.lesbell.com.au obligingly took the email and forwarded it on to bifrost.lesbell.com.au. Let's now look at its Received: line:

Received: from 203.35.202.157 (unknown [62.68.83.17]) by dvalin.lesbell.com.au (Postfix) with SMTP id 2C75F1B833 for <lesbell@lesbell.com.au>; Thu, 30 Sep 2004 10:50:30 +1000 (EST)

Hmm. In the SMTP conversation, the sending MTA claimed to be "203.35.202.157", an IP address, rather than a name, and to add insult to injury, it's the IP address of dvalin.lesbell.com.au itself! Now, normal mail servers just don't do this, and it's a pretty clear indication that the machine is running some spamming software and is under control of a spammer. However, it can't fake its IP address so easily, and so we know it is at 62.68.83.17. A reverse DNS lookup reveals no name for that IP address, hence it's shown as "unknown".

The next Received: header line looks suspiciously simple:

Received: from 233.202.78.84 by 62.68.83.17; Wed, 29 Sep 2004 20:50:27 -0500

A dig -x lookup on that address reveals no name; however there is good reason to believe this line is forged:

A real MTA puts the IP address of the sender in square brackets

There's no indication of a HELO hostname, or an attempt to reverse lookup the name

We already suspect that this machine is under control of the spammer

So, we can reasonable dismiss 233.202.78.84 as an innocent bystander in all of this. We can therefore conclude that this spam originated from 62.68.83.17, and we therefore use the whois command (or a variant, jwhois) to find out who owns that address:

[les@sleipnir les]$ jwhois 62.68.83.17
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Whois secondary server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

inetnum: 62.68.64.0 - 62.68.95.255
org: ORG-CA23-RIPE
netname: GR-COMTONET-20000615
descr: Com-ToNet
descr: Provider Local Registry
country: GR
admin-c: MK7382-RIPE
tech-c: GB834-RIPE
tech-c: DR525-RIPE
status: ALLOCATED PA
notify: noc@com-tonet.gr
notify: noc@com-tonet.com
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: MNT-C2N
mnt-routes: MNT-C2N
mnt-domains: MNT-C2N
changed: hostmaster@ripe.net 20000615
changed: hostmaster@ripe.net 20000925
changed: hostmaster@ripe.net 20040622
changed: hostmaster@ripe.net 20040622
changed: hostmaster@ripe.net 20040914
changed: hostmaster@ripe.net 20040921
source: RIPE

route: 62.68.64.0/19
descr: COMTONET
origin: AS12653
mnt-by: COMTONET-RIPE-MNT
changed: t.kontogiannis@com-tonet.gr 20010629
source: RIPE

organisation: ORG-CA23-RIPE
org-name: Com-ToNet
org-type: LIR
address: Com-ToNet
Aididon 13 & Seneka
Kifissia, Attiki 14564
Greece
phone: +302106249600
fax-no: +302106206850
e-mail: karasm@si-eu.com
e-mail: noc@com-tonet.com
e-mail: noc@com-tonet.gr
admin-c: MK7382-RIPE
admin-c: MK7382-RIPE
admin-c: MT6945-RIPE
admin-c: GB834-RIPE
admin-c: DR525-RIPE
mnt-ref: MK7382-RIPE-MNT
mnt-ref: RIPE-NCC-HM-MNT
mnt-by: RIPE-NCC-HM-MNT
changed: hostmaster@ripe.net 20040415
changed: bitbucket@ripe.net 20040622
changed: bitbucket@ripe.net 20040622
source: RIPE

person: Max Karasso
address: Com-ToNet
address: Aigidon 13 & Seneka
address: Kifissia, Attiki 14564
address: Greece
phone: +302106249600
fax-no: +302106206850
e-mail: m.karasso@com-tonet.gr
nic-hdl: MK7382-RIPE
notify: m.karasso@com-tonet.gr
changed: karasm@si-eu.com 20020429
source: RIPE

person: Gerasimos Bonanos
address: Aigeidon 13 & Seneka, Kifisia
phone: +302106249600
fax-no: +302106206850
e-mail: g.bonanos@si-eu.com
nic-hdl: GB834-RIPE
notify: support@com-tonet.gr
mnt-by: MNT-C2N
changed: karasm@si-eu.com 20020429
changed: ripe-dbm@ripe.net 20040429
source: RIPE

person: Manolis Drougas
address: Aigeidon 13 & Seneka, Kifisia
phone: +30106249600
fax-no: +30106206850
e-mail: drman@com-tonet.gr
nic-hdl: DR525-RIPE
notify: support@com-tonet.gr
mnt-by: MNT-C2N
changed: karasm@si-eu.com 20020429
changed: ripe-dbm@ripe.net 20040429
source: RIPE

[les@sleipnir les]$

As you can see, the address is owned by an ISP in Greece, Com-ToNet, and we should direct any complains to them. There doesn't seem to be any "abuse@" address, although I'd give it a try, and if that failed, pick one or two of the people listed.

On Windows, a lot of the investigation can be done using Sam Spade ( http://www.samspade.org/ssw/ ) a network query tool which can perform traceroutes, DNS lookups (forward and reverse), whois lookups, check whether IP addresses are in the various "black hole" lists and even perform header analysis.

Sam Spade is shown in Figure 1.

And here's the SpamCop analysis:

Parsing header:

Received: from dvalin.lesbell.com.au ([192.168.168.252]) by bifrost.lesbell.com.au (Lotus Domino Release 5.0.6a) with ESMTP id 2004093010504552:11811 ; Thu, 30 Sep 2004 10:50:45 +1000
192.168.168.252 found
host 192.168.168.252 (getting name) no name
192.168.168.252 discarded

Received: from 203.35.202.157 (unknown [62.68.83.17]) by dvalin.lesbell.com.au (Postfix) with SMTP id 2C75F1B833 for <x>; Thu, 30 Sep 2004 10:50:30 +1000 (EST)
62.68.83.17 found
host 62.68.83.17 (getting name) no name
Possible spammer: 62.68.83.17
Received line accepted

Received: from 233.202.78.84 by 62.68.83.17; Wed, 29 Sep 2004 20:50:27 -0500 $MessageID: <RICKGKFFSXXMGWIJHZIDF@msn.com>
233.202.78.84 found
host 233.202.78.84 (getting name) no name
62.68.83.17 not listed in dnsbl.njabl.org
62.68.83.17 not listed in cbl.abuseat.org
62.68.83.17 not listed in dnsbl.sorbs.net
62.68.83.17 is not an MX for dvalin.lesbell.com.au
62.68.83.17 is not an MX for dvalin.lesbell.com.au
62.68.83.17 not listed in dnsbl.njabl.org
Possible spammer: 233.202.78.84
host 62.68.83.17 (checking ip) = 62.68.83.17
62.68.83.17 not listed in dnsbl.njabl.org
62.68.83.17 not listed in cbl.abuseat.org
62.68.83.17 not listed in dnsbl.sorbs.net
Looks like a forgery

Tracking message source: 62.68.83.17:
Routing details for 62.68.83.17
[refresh/show] Cached whois for 62.68.83.17 : m.tsigaras@com-tonet.gr m.karasso@com-tonet.gr
Using last resort contacts m.tsigaras@com-tonet.gr m.karasso@com-tonet.gr
Yum, this spam is fresh!
Message is 0 hours old
62.68.83.17 not listed in dnsbl.njabl.org
62.68.83.17 not listed in dnsbl.njabl.org
62.68.83.17 not listed in cbl.abuseat.org
62.68.83.17 not listed in dnsbl.sorbs.net
62.68.83.17 not listed in relays.ordb.org.
62.68.83.17 not listed in query.bondedsender.org
62.68.83.17 not listed in iadb.isipp.com

Finding links in message body
Parsing text part

Resolving link obfuscation
http://www.igghsent.net/2/?wid=200007
host 221.234.25.108 (getting name) no name

Tracking link: http://www.igghsent.net/2/?wid=200007
[report history]
Resolves to 221.234.25.108
Routing details for 221.234.25.108
[refresh/show] Cached whois for 221.234.25.108 : abuse_hb@public.wh.hb.cn spam_hb@public.wh.hb.cn
Using abuse net on abuse_hb@public.wh.hb.cn
abuse net public.wh.hb.cn = abuse_hb@public.wh.hb.cn, postmaster@public.wh.hb.cn, postmaster@dc.wh.hb.cn, spam_hb@public.wh.hb.cn, postmaster@wh.hb.cn, anti-spam@ns.chinanet.cn.net
Using best contacts abuse_hb@public.wh.hb.cn postmaster@public.wh.hb.cn postmaster@dc.wh.hb.cn spam_hb@public.wh.hb.cn postmaster@wh.hb.cn anti-spam@ns.chinanet.cn.net
anti-spam@ns.chinanet.cn.net bounces (102 sent : 23203 bounces)
Using anti-spam#ns.chinanet.cn.net@devnull.spamcop.net for statistical tracking.

References and Further Reading

...........................