## 3 Proposed Solution  
This study presents an email filtering system (LiSB) that is implemented before the MTA server, which is able to execute the filtering process during the SMTP transaction time and, therefore, decide whether the message will be accepted (or not) for delivery. The system allows different techniques to be applied concurrently to classify the message as spam or ham, and combine their results to make a single decision. In the solution, we implemented a set of simple techniques including: (i) schemes based on anomaly detection, (ii) SMTP profile-based techniques, and (iii) an ML-based scheme for content-based filtering during SMTP transactions. The available techniques can be easily extended by implementing new modules in Python (see [[https://www.python.org](https://www.python.org)]([https://www.python.org](https://www.python.org))). As a result, it will be possible to notify the sender that spam is being sent through its server and he will be able to take appropriate actions. Furthermore, as these techniques are executed during the SMTP transaction, all post-SMTP filtering tasks would be avoided, optimizing resource usage and response times.  
Anomaly detection strategies are based on checking the content of some fields of the SMTP and email headers and verifying their consistency. Some examples of consistency are: (i) the SMTP MAIL FROM command, and the _From_ and _Return-Path_ headers of the message are equal and (ii) the SMTP RCPT TO command and the _To_ and _Delivered-To_ headers of the email are the same.  
In addition, some message delivery parameters will be examined to obtain profile information about the MSA and MUA software and the configuration of different domains/users, in order to check the consistency of the information included in a particular message and the profile of the sender (user/domain) stored in the server. To build a domain/user profile, we collect some information from the messages: (i) the _User-Agent_ header that reports the message, (ii) the _Received_ headers that contain the path of the messages through the SMTP servers, and (iii) the DKIM (DomainKeys Identified Mail) [16] parameters. Since these parameters are not frequently modified, identifying changes can reveal anomalous situations which, in many cases, are associated with the sending of spam messages.  
Finally, although it seems that the application of ML techniques during SMTP transactions is impossible, in practice most of the time required is for model building rather than execution. It is also possible to run small ML models stored in RAM memory and based on a limited number of easy-to-extract features. The challenge is to find a small number of features that are easy to extract and provide a lot of information to the process. For example, a recent work [17] has highlighted the number of URLs (Universal Resource Locator) as a very relevant feature for identifying spam content. Considering the ease of counting the number of URLs that are present in a text (by simply applying a regular expression), this feature is very suitable for filtering during SMTP transactions.  
The next subsection introduces the architecture used by our proposal and summarizes the details of the software design.