Most e-mail clients benefit from a configuration wizzard that assists setting up accounts when some of the settings are unknown. Once a minimal amount of information is provided, Microsoft Outlook and Android attempt connections to the server on various ports in order to determine what services are available and how to configure an e-mail account. In doing so, e-mail clients perform a sort of "brute-force discovery" where connections are attempted to ports related to e-mail services. In case a port, related to e-mail, is open the e-mail client attempts to connect and proceeds with authentication (sometimes, even sending a test e-mail) to check whether the minimal information provided by the user can be used to set up an account. In case authentication succeeds, then the e-mail client accepts the user-provided settings and registers the account on the device. For some devices, this procedure is a "best guess" and "minimal effort" procedure where, in case the e-mail client succeeds to authenticate using the user-supplied information, then the account is set up as-is and the e-mail client does not attempt to seek "better" solutions such as equivalent yet secure services (IMAPs, POP3s).

In case a server is configued to accept connections that have not been secured, then some e-mail clients attempt a connection and, if the connectio succeeds, the e-mail clients send credentials in cleartext. This can be demonstrated using packet capture software such as tcpdump and a server that is configured to offer services that are not secure (POP3, IMAP).

Checking Mail Clients

Three mail clients have been checked:

by intercepting the traffic between the e-mail client and a server with exposed insecure ports ( using tcpdump.

Microsoft Outlook

An account ("[email protected]") that most likely does not exist on the mail server has been used to setup the Microsoft Outlook account: the configured password was set to be "PAROLAINCLAR" and the server was set to "". No other settings were made and Microsoft Outlook was left to discover the settings.

The conversation between Microsoft Outlook and the server is as follows:

21:50:08.217090 IP (tos 0x2,ECT(0),

53, id 9086, offset 0, flags
[DF], proto TCP (6), length 174) > REDACTAT.14021: Flags [P.], cksum 0x6de7
(correct), seq 124:258, ack 18, win 115, length 134
        0x0000:  0401 b782 e601 5c45 2779 0330 0800 4502
        0x0010:  00ae 237e 4000 3506 d89f c266 3a07 2e65
..#[email protected]:..e
        0x0020:  1e58 008f 36c5 1fe9 493e dc7b f730 5018
        0x0030:  0073 6de7 0000 2a20 4341 5041 4249 4c49
        0x0040:  5459 2049 4d41 5034 7265 7631 204c 4954
        0x0050:  4552 414c 2b20 5341 534c 2d49 5220 4c4f
        0x0060:  4749 4e2d 5245 4645 5252 414c 5320 4944
        0x0070:  2045 4e41 424c 4520 4944 4c45 2053 5441
        0x0080:  5254 544c 5320 4155 5448 3d50 4c41 494e
        0x0090:  2041 5554 483d 4c4f 4749 4e0d 0a76 3867
        0x00a0:  6b20 4f4b 2043 6170 6162 696c 6974 7920
        0x00b0:  636f 6d70 6c65 7465 642e 0d0a            completed...

21:50:08.304497 IP (tos 0x2,ECT(0), ttl 63, id 16152, offset 0, flags
[DF], proto TCP (6), length 89)
    REDACTAT.14021 > Flags [P.], cksum 0xe1cc
(correct), seq 18:67, ack 258, win 257, length 49
        0x0000:  0000 5e00 0166 0401 b782 e601 0800 4502
        0x0010:  0059 3f18 4000 3f06 b35a 2e65 1e58 c266
[email protected]?..Z.e.X.f
        0x0020:  3a07 36c5 008f dc7b f730 1fe9 49c4 5018
        0x0030:  0101 e1cc 0000 7638 346d 204c 4f47 494e
        0x0040:  2022 7469 636b 6574 3235 3840 656c 692d
."[email protected]
        0x0050:  6e70 2e72 6f22 2022 5041 524f 4c41 494e"."PAROLAIN
        0x0060:  434c 4152 220d 0a                        CLAR"..

As can be observed from the transcript, the password is sent in cleartext PAROLAINCLAR as well as the account name [email protected].

Android KitKat E-Mail Client

Much easier to configure than Microsoft Outlook only an account name was provided to the KitKat e-mail client [email protected], a password androidparola and the server name was set to mail.eli-np.

22:19:58.469461 IP (tos 0x0, ttl 255, id 29423, offset 0, flags
[none], proto TCP (6), length 171) > REDACTAT.49064: Flags [P.], cksum 0xb0bc
(correct), seq 124:255, ack 15, win 5826, length 131
        0x0000:  4500 00ab 72ef 0000 ff06 9e50 c266 3a07
        0x0010:  ac10 018f 008f bfa8 65c1 7010 0f7d f40e
        0x0020:  5018 16c2 b0bc 0000 2a20 4341 5041 4249
        0x0030:  4c49 5459 2049 4d41 5034 7265 7631 204c
        0x0040:  4954 4552 414c 2b20 5341 534c 2d49 5220
        0x0050:  4c4f 4749 4e2d 5245 4645 5252 414c 5320
        0x0060:  4944 2045 4e41 424c 4520 4944 4c45 2053
        0x0070:  5441 5254 544c 5320 4155 5448 3d50 4c41
        0x0080:  494e 2041 5554 483d 4c4f 4749 4e0d 0a31
        0x0090:  204f 4b20 4361 7061 6269 6c69 7479 2063
        0x00a0:  6f6d 706c 6574 6564 2e0d 0a              ompleted...

22:19:58.497219 IP (tos 0x0, ttl 255, id 29424, offset 0, flags
[none], proto TCP (6), length 40) > REDACTAT.49064: Flags [.], cksum 0x54ed
(correct), seq 255, ack 206, win 5635, length 0
        0x0000:  4500 0028 72f0 0000 ff06 9ed2 c266 3a07
        0x0010:  ac10 018f 008f bfa8 65c1 7093 0f7d f4cd
        0x0020:  5010 1603 54ed 0000                      P...T...
22:19:58.621495 IP (tos 0x0, ttl 255, id 29425, offset 0, flags
[none], proto TCP (6), length 70) > REDACTAT.49064: Flags [P.], cksum 0x6206
(correct), seq 255:285, ack 206, win 5635, length 30
        0x0000:  4500 0046 72f1 0000 ff06 9eb3 c266 3a07
        0x0010:  ac10 018f 008f bfa8 65c1 7093 0f7d f4cd
        0x0020:  5018 1603 6206 0000 2a20 4944 204e 494c
        0x0030:  0d0a 3220 4f4b 2049 4420 636f 6d70 6c65
        0x0040:  7465 642e 0d0a                           ted...

Although these are not credentials the information is still sent in cleartext.

For completeness, and even if the capture does not illustrate all the information sent to the server, Android 4.4.2 has been found in other experiements to send a complex identifier: the name of the android email package, the operating system android, the Android version (in this case) 4.4.2, the vendor (brand, BlackBerry, etc.), the device model, the mobile net operator (x-android-mobile-net-operator) an AGUID parameter that looks like a Base64 encoded string.

22:19:58.624632 IP (tos 0x0, ttl 63, id 7615, offset 0, flags [DF],
proto TCP (6), length 85)
    REDACTAT.49064 > Flags [P.], cksum 0xeb8f
(correct), seq 206:251, ack 285, win 65535, length 45
        0x0000:  4500 0055 1dbf 4000 3f06 73d7 ac10 018f
[email protected]?.s.....
        0x0010:  c266 3a07 bfa8 008f 0f7d f4cd 65c1 70b1
        0x0020:  5018 ffff eb8f 0000 3320 4c4f 4749 4e20
        0x0030:  7469 636b 6574 3235 3840 656c 692d 6e70
[email protected]
        0x0040:  2e72 6f20 2261 6e64 726f 6964 7061 726f
        0x0050:  6c61 220d 0a                             la"..

As can be seen the account name [email protected] and the password androidparola appear in cleartext.

Android KitKat E-Mail Client

Apple Mail, on the most recent tested version on MacOS Catalina seems to refuse to connect to non-secured mail ports and has been observed to not send any sensitive information. Instead, the Apple Mail client attempts to connect to the secure ports and authenticate. In case authentication failes, then Apple Mail gives up.


Unfortunately, given how networks are designed, each computer has to send its packets to the next upstream gateway. Each gateway, in turn, will relay the packets further upstream to its gateway. This process carries on until the destination is reached (or until the packet TTL expires, the packet is dropped by the receiving intermediary gateway, and has to be retransmitted).

As a relatable analogy, you can see this as a relay race where each racer has to hand the packet over to the next racer. Encryption is commonly used to encrypt the contents of the packets such that each racer cannot find out what the packets contain. If the packets are not encrypted, then any racer that receives the packet can look inside and determine its contents. Furthermore, in case packets are not encrypted, then all the racers from the sender to the destination are able to peek inside the packet.

Coming back to computer security, when a client initiates a connection with a server, as demonstrated in the previous section, then all gateways between the e-mail client and the server are able to see the same conversation illustrated in the previous contents. Regrettably, this means that cleartext passwords become known not only between the e-mail client and the server and just a single upstream gateway, but by every single gateway on the network path.

To illustrate a single route across the Internet, a trace can be carried out that illustrates the gateway between a server at DigitalOcean and the server:

# traceroute -n
traceroute to (, 30 hops max, 60 byte packets
 1  REDACTED  13.265 ms  4.147 ms  13.187 ms
 2  0.833 ms  1.171 ms  0.752 ms
 3  0.695 ms  0.608 ms  0.629 ms
 4  1.441 ms  1.302 ms  1.296 ms
 5  52.089 ms  51.996 ms  52.144 ms
 6  53.766 ms  53.335 ms  53.256 ms
 7  54.216 ms  54.202 ms  54.137 ms
 8  53.173 ms  52.749 ms  52.684 ms
 9  56.229 ms  54.120 ms  55.046 ms
10  55.426 ms  67.258 ms  67.054 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Assuming that an e-mail client is placed at REDACTED (1), and connects to (30), then all the intermediary hops between (1) and (30) will be able to obtain all the data including the account name, the password  and the entire contents of the e-mail (headers, body, etc.). Some routes are shorter, others longer, depending on where the e-mail client is positioned relative to the mail server on the network (in this case, the Internet).

Worse is that e-mail is increasingly used to store a lot of private information: bank statements, other credentials, account names, etc. and in case users transfer the e-mails (via POP) or just click on them in an e-mail client (implictly via IMAP in case the message is unread) then that information will be observable on the entire network path.

As the terminology stands, if an account has had its credentials leaked over the network then that account has been compromised. Out of all the gateways in the path illustrated above, it is sufficient for just one of the gateways to log or store Internet traffic (for instance, ACTA required traffic to be stored for a number of days, by law). Once the account is compromised, anything can be assumed; damages including. A lot of ongoing scam e-mail traffic (such as extortion spam e-mails) is due to various data breaches: one can assume anything; perhaps nobody on the path was listening or perhaps someone was listening.


Companies and institutions provide a number of services to users and, ultimately, it is up to the user to pick what users desire to use. For instance, if a user chose to use, say, a web-mail frontend instead of using an IMAP or POP3 client, and additionally the web server hosting the e-mail frontend was secured via SSL/TLS, then the user's data has not been compromised since the entire session between the e-mail client and the server is encrypted.

Hence, all the above only applies to users that have been using e-mail clients such as Microsoft Outlook, Android (only one version was explicitly tested), etc. and does not apply to a user that would have used a secured web-mail frontend.


The blame is two-fold: obviously system administrators should not offer services that are not secure but the problem lies deeper with e-mail clients that use automated setup wizzards. Some e-mail clients have no problem connecting to insecure services and configuring an e-mail account to send and receive mail over insecure ports. Once the account has been configured and the e-mail client completes the setup, then the e-mail client will continue using the account just as it is and perform authentication or send and receive mails in plaintext.

Stop-gap Measures

At the very least, but more about protecting the server itself than the users (since not all private information is repudiable but passwords may be), the password for all accounts should be reset. By resetting the account password and having users choose a different password, a would-be observer that has recovered the password will not be able to use the pasword in order to access the account.


A solution that should seem trivial is to not offer any services that are not secure or are known to use protocols that are not secure. Retrieving mail over POP3 or reading mail over IMAP instead of their secure counterparts (POP3s, IMAPs) seems reckless. If a connection is not established to a server then no data, except the connection attempt, is sent over the network.

On the other hand, e-mail clients should refuse to use POP or IMAP when using the automatic account setup wizzard. Instead, if need be, and for whatever debugging reasons, POP or IMAP could be offered as an option. Apple Mail can explictly be configured to use insecure services but the setup wizzard does not attempt to set up the account without SSL or TLS without the user having to manually reconfigure the account settings.


Checking an arbitrary server on the IFIN-HH network for insecure e-mail ports to see if such cases exist, for instance, attempting to connect to POP3:

# telnet 110
Connected to
Escape character is '^]'.
+OK Dovecot ready.

then checking IMAP:

# telnet 143
Connected to
Escape character is '^]'.

Also to make sure that the ports are not open only inside the network but that there are cases where insecure ports are exposed to the Internet:

It is unclear why ELI-NP was found to be running a server (Dovecot) with insecure services such as IMAP or POP3 since even the internal security guide specifies explictly that secure services have to be used in favor of their insecure counterparts.

More than likely, the ports for IMAP and POP3 were opened by mistake, yet it is difficult to tell for how much time the ELI-NP mail server had been running with services that are not secure or how many users have been accessing their e-mail accounts using e-mail clients.

The ELI-NP mail server had the secure coutnerparts available (IMAPs and POP3s) but, since some e-mail clients perform a "least effort guess", the secure services may have ended up not being  used by the e-mail client when users configured their accounts (or used new devices to configure accounts on).

Personal Experience


Up to this date I am unware of any ongoing password resets for the user accounts, whether the users have been made aware that their e-mails might have leaked, nor did I receive any additional information. Online port checkers indicate that the ports remained closed so I did not request further explanations, especially given how the events unfolded.