The objective of the MECSA platform is twofold. On one hand, its objective is to obtain a general overview of the security and privacy that email providers apply when they deliver and/or receive emails. In particular, the platform focuses on email communications between email servers (MTAs).
To achieve its objective, the MECSA platform will evaluate 8 different features (StartTLS, x509 Certificate validation, SPF, DKIM, DMARC, DANE, DNSSEC), previously identified as standards related to email security that can contribute to strengthen the security and privacy of MTA to MTA email communications.
On the other hand, the MECSA platform aims to become a tool used by end-users and sys admins alike. To end-users, it aims to raise awareness of the importance of security and privacy in MTA to MTA email communications, by allowing end-users to assess their email providers and obtain a comprehensive report on the results. To sys admins, it aims to become a tool to help them to improve the level of security and privacy offered by their services.
You can send your comments and questions to :
jrc-mecsa@ec.europa.eu
The Confidential Delivery score assesses the capacity of email providers to protect the messages, sent and received, from being read by third parties that could be listening the communication channel or impersonating the recipient.
The Phishing and Identity Theft score measures the capacity of email providers to facilitate the identification of email messages sent from unauthorized domains (These messages are most likely to be fake).
The Integrity of Messages score assess the capacity of email providers to facilitate the detection of modified messages (content received differs from content sent), and the generation of evidence that messages have not been modified.
In an email communication there are different parties involved. At least: sender, recipient, sender User Agent (UA), recipient UA, sender Mail Transfer Agent (MTA) and recipient MTA. In some occasions we might even need MTAs from other parties to reach the destination. The UA is the application used by email users to send/receive emails (outlook, thunderbird, etc.), whereas the MTA is the email server itself.
In most cases, sender and recipient are in control of the UA. There are different configuration options that can be set and affect the security and privacy of their email communications, e.g. end-to-end encryption, implicit or explicit TLS, etc. But the end-users do not have information on the security measures their email providers apply when delivering and receiving emails, i.e. MTA to MTA email communications.
Following we have a list of examples of different attacks related to the features evaluated by the MECSA platform. It is not a comprehensive list, but an example of situations in which an attacker might take advantage.
The email system assumes that all the actors involved in the communications, as well as the communication links can be trusted and are secure. In reality this is hardly the case. For example, the communication between SMTP servers for email delivery takes place through the public Internet and it is susceptible to be intercepted by third parties.
In practice, this means that in the absence of very specific security measures, such as StartTLS, emails sent and received, including the files attached, could be read and copied by third parties. There is no certainty that the communication is private.
Phishing - Identify theft is one of the main vulnerabilities inherent to the design of the email system. In an identify theft attack an adversary is able to impersonate the identity of a legitimate email user and send emails to third parties on his behalf.
In most of the attack scenarios the legitimate user will never realise that someone has impersonated his/her identity. Even a basic identity theft attack could be very hard to detect by the average user, since the email appears to be indistinguishable from what could be a legitimate one. However, very advanced users and security professionals could determine that the source email address was spoofed by analysing the email headers inserted by the SMTP servers involved in the communication.
Similarly to the scenario of the identity theft, an attacker could also abuse the lack of protection of the integrity of the data to modify the content of legitimate emails that are sent or received by users.
Even if no identity theft is performed and the email received by the user was actually sent by the recipient, it is still possible for its content to have been modified by an attacker. Moreover, this holds true both for the content of the email, as well as for any possible attachments that the email might contain, such as a PDF file.
