0919 ELSE features overview

The Official X-Itools ELSE 0.9.19 Features

Edited by Nicolas HAHN < hahnn@x-itools.com > / < hahnn@erios.org >

---

This page for version: 0.9.16 | 0.9.17 | 0.9.18

---

• ELSE main features
  • Passive features
  • Active features

ELSE main features

Here below is a summary of main ELSE features for standard users. Basically, they can be classified in two categories:

• Passive features: they don't have any impact on your postfix servers. ELSE until version 0.9.15 proposed passive features only. For example, a typical passive feature is the logs parsing.
• Active features: from ELSE version 0.9.16, active features have started to be implemented. They can have an impact on your postfix servers, in the way that postfix configuration can be modified, email traffic passing through your postfix servers can be impacted. For example, deleting all deferred emails waiting in postfix queues is an active feature.

In the descriptions below, please note that the term "Real Time" means there can be a delay of a few seconds, and it is strongly related to the processing capacity of the server on which the ELSE is installed. Please note that the term "Near Real Time" means there is a small processing delay of a few minutes (1 or 2), also depending of the processing power of the server on which the ELSE is installed.

In the descriptions below, please note that some of the highlighted features can be still under development.

Passive features

The ELSE implements and is not limited to the main passive features below:

• Web 2.0 state of the art User Interface, done using ExtJS 4.1.3
• Integrates GeoIP for IP Address geographic location
• Integrates Google Maps for IP Address geographic location
• Keep 90 days of data by default
• Able to process an extremely huge daily volume of email traffic in Real Time (depending of the processing power of the ELSE dedicated server). ELSE is designed to be able to absorb more than 2 millions emails per day and per way (>24 emails/second/way), considering the ELSE infrastructure is designed accordingly. Considering there are 2 ways (INCOMING and OUTGOING emails), ELSE can support the processing of something around 50 emails/second.
• Implement built-in static server roles (GENERIC, INCOMING, OUTGOING, MAILING LIST, SENDER ROUTERS, EXCHANGE)
• Real Time parsing of Postfix server standard logs, including postscreen logs
• Real Time parsing of Postgrey standard logs
• Near Real Time parsing of Microsoft Exchange Server 2010/2013 logs (including OWA, IIS, ...) when used as a MUA and not as a MTA+MUA
• Aggregation and correlation of Microsoft Exchange Server logs with Postfix Server logs
• Able to parse old Postfix QID log format (versions <=2.8)
• Able to parse latest Postfix QID log format (versions >2.8)
• Near Real Time capture of NDRs at Postfix server level
• Real Time capture of email headers (length of header lines limited to 200 bytes max. at this time)
• New Postfix or Exchange servers are automatically registered in the ELSE
• New GreyLSE servers are automatically registered in the ELSE
• Provides Real Time computed data and statistics at the destination of monitoring solutions (like Nagios, Cacti)
• Implement groups and users rights and permissions. That means one ELSE can be used for all your servers, and what a user can view or search in is controlled, so that different users can have access to different data without having the opportunity to see data of the others
• Provide Real Time status of Postfix servers queues without querying Postfix servers
• All Details of emails shown in Postfix servers queues can be obtained almost immediately
• Provide a set of automatic and pre-defined reports: more than 100 reports are implemented
• Reports are made available according following criteria: start and end date/time, user groups the user is member of, server role
• Reports are rendered directly using ExtJS charting library
• Reports allow ELSE users to easily and rapidly identify sources of attacks against messaging systems
• Data grids are available for each report
• Data grids as well as practically all other kind of grids can be exported as Excel *.xlsx files generated on server side
• Data grids are very flexible (columns can be moved, hidden or not, sorted, ...)
• Search by Message-ID (almost immediate answer)
• Search by Postfix QID or Exchange (ELSE self-generated) QID (almost immediate answer)
• Extended Search interface, where criteria like: start and end date/time, user group, server role, connecting client IP, next HOP IP, RFC821 and RFC822 email FROM address, email TO address, Subject, delivery status, extended delivery status can be defined.
• Extended Search interface provides operators like Exact match, Different, Domains, Contains, Does not contain on some search criteria
• "My Search Requests" window to recall any search request previously made
• Extended Search Results window can be used to immediately get in-deep details about found emails transactions
• Window showing Email details provide the following: details as a Text View or as a Graphical view.
• Text view and Graphical view email details provides: all QIDs (individual email transactions) of emails for a same message-ID.
• Text view email details provides more specifically: information about processing server, email header, information about connecting client including the location of its IP address displayed on a Google MAP, Exchange Server SMTP session details if relevant, Exchange Server dedicated information if relevant, Subject and HELO/EHLO information, details about attachments, sender related information (RFC821 and RFC822), Alerts eventually detected by the ELSE about the email transaction (Spoofing, fishing, backscattering, unmatching fields that should, ...) information about all recipient deliveries, information about NDR eventually generated by the email transaction and including the captured NDR as well as the QIDs of the NDR to perform another search based on them, information on the removal of the transaction from the queue
• Graphical view details provides an automatically generated network map of the different steps of the email transaction. A simple color code is used to immediately show if an issue resides somewhere in the email transaction (green is no issue, blue is email deferred, red is email bounced).
• ELSEre, that is the ELSE Reputation Engine. Reputation for any sender or recipient email address is given in the window displaying the email search results. Reputation is computed like in real life: it's extremely fast to destroy it, and it is extremely long to generate a good reputation. Reputation indicator goes from -100% (worst reputation) to +100% (best reputation) passing through 0 (neutral).
• ELSEre reporting showing sender and recipient email addresses reputation like an "age pyramid"
• NOQUEUE search feature, allowing a search in all emails simply and immediately rejected by Postfix Servers, or emails set on hold
• Import of Message-IDs
• Log-rebuilder to reconstruct logs (whatever they are coming from Exchange Servers or Postfix ones) in the format of Postfix logs, using practically same filter criteria as for the Extended Search
• Toolbox for testing your messaging infrastructure including: Send an email to any Postfix Server using user defined fields (RFC821/RFC822 FROM, TO, Subject, Body, ...), DNS query tool, IP Locator to show where are IP addresses on a Google MAP, Postfix Transport maps test tool, F5 BIG IP query tool
• Auto-cleaner in reporting mode only, that generates reports, graphs and data grids that can be exported as Excel files, on recipients having issues by monitoring specific senders
• ACLs module, that is a mini Checkpoint-like objects editor, allowing users to define policies of objects like hosts, networks, groups to manage the mynetworks postfix directive. It is classified as a passive feature at this time because it is not able to push policies on postfix servers for now.
• Real time Billing reports, so called because some users used this specific reporting feature to bill their customers according the volume of their email traffic. But it is used to graph in Real Time the main data regarding email flows like: sent, bounced, rejected, deferred emails, cumulative number of bytes, INCOMING and OUTGOING. Those reporting capabilities can be defined on individual servers and domains.
• ELSEMC, that is the ELSE user's personal Messaging Center. ELSEMC is a lightweight web interface allowing individual users to manage their personal greylist, blacklist, whitelist, configure auto-whitelisting of their contacts, get statistics, do searches limited to emails containing their email addresses, ...
• RTAAM, that is the Real Time Alerting and Action Module. In reporting mode only, you can do things like identify internal user workstations infected by SPAM bots, or you can know exactly what external IP address or sender email address SPAM you. You can define policies, containing rules written using a lot of different parameters, including the ones made available by the ELSEre (ELSE reputation engine). You can get and draw statistics about any individual e-mail address or IP address connecting to your Postfix servers. And more.

Active features

The ELSE implements and is not limited to the main active features below:

• Deletion of all emails in Postfix deferred queues regarding a specific sender
• Flush of Postfix queues
• ACLs module, that is a mini Checkpoint-like objects editor, allowing users to define policies of objects like hosts, networks, groups to manage the mynetworks postfix directive. But for now, it is not able to push defined policies on Postfix servers
• GreyLSE daemon, which is an implementation of a Postfix Policy Server to provide SPF checks as well as White / Grey / Black listing features, controlled by the ELSE and/or ELSEMC web interfaces. ELSE interface manage global policies, and ELSEMC interface allow any individual user to manage his own greylist, blacklist and whitelist settings
• RTAAM (Real Time Alerting and Action Module). It is able to detect the source of the attack (attackers) and the targets (focused mailboxes). To give you a picture, we could try to define it like this: RTAAM is to be seen as an E-mail flow threats detection and prevention system. Another definition could be: RTAAM is an E-mail Firewall solution. Or let's give a last definition: RTAAM is a mix of "Postfix/Anvil", "Fail2ban", "Firewall", "Monitoring", "Reporting". The RTAAM engine is able to work in near real time (NRT), because it's able to dynamically take its decisions in a 1 minute time frame minimum. With RTAAM, you can do things like identify internal user workstations infected by SPAM bots, or you can know exactly what external IP address or sender email address SPAM you. And of course you can block any email traffic generated by them. You can define policies, containing rules written using a lot of different parameters, including the ones made available by the ELSEre (ELSE reputation engine). You can implement a set of quotas on your email flows. Or you can just get and draw statistics about any individual e-mail address or IP address connecting to your Postfix servers. And more. RTAAM active features (understand: protection features) are managed by the GreyLSE daemon.
• Auto-cleaner, that provides automatic cleaning of email flows, based on delivery answers provided in the past (working with GreyLSE). This feature is extremely interesting if you host mailing lists, in the way it can automatically clean them from wrong, illegitimate, falsified subscribers generating tons of bounced and/or deferred emails that can easily blacklist your Postfix servers public IPs.
• Greylisting, including auto-whitelisting. Rules are defined in the ELSE interface, and benefit of a very powerful description language. (working with GreyLSE)
• RAWL (Recipient Auto White Listing). When your users send emails to their contacts (the recipients), those recipients are automatically white-listed as senders, in order to avoid them to be catched by GreyLSE filtering when they send answers to your users.
• Whitelisting. Rules are defined in the ELSE interface, and benefit of a very powerful description language. (working with GreyLSE)
• Blacklisting. Rules are defined in the ELSE interface, and benefit of a very powerful description language. (working with GreyLSE)
• Holdlisting. Rules are defined in the ELSE interface, and benefit of a very powerful description language. Holdlisting is just the ability to decide under what conditions emails will be set on hold in Postfix servers. (working with GreyLSE)
• SPF checks. SPF rules are defined in the ELSE interface, and benefit of a very powerful description language. SPF rules can influence the decision made by the SPF engine integrated to the GreyLSE daemon. (working with GreyLSE)

---

This page for version: 0.9.16 | 0.9.17 | 0.9.18