Incoming Email Verifications

At the first level, AVAS filters IPs according to Planisys Threat Intelligence to mitigate DDoS (Distributed Denial of Service) attacks, verifies that the sender domain in the Return-Path exists, and applies a series of configurable controls.

The Return-Path may differ from the From: header

Currently, the Return-Path domain must exist and have an MX or an IP address.

At a second level, Spam related to the From header is analyzed, with three possible destinations depending on the level of Spam tolerance set by AVAS and the user: - the user’s Inbox - the user’s Spam folder - the Quarantine

Basic Information

First, an AVAS consists of an avas_id, which is a word containing only letters and digits, used to form the names of the MXs and exclusive relays for AVAS.

For example, if the avasid is telco, the MXs will be avas-mx-telco-1.planisys.net and avas-mx-telco-2.planisys.net, and the outgoing relay and authentication proxy will be avas-out-telco-1.planisys.net.

The client can request more MXs and relays, which will always follow the same naming scheme, with only the number at the end changing.

Additionally, a name should be defined, ideally representing the organization, venture, or project of the AVAS, and a crm_id to associate it with the client’s identification in an external CRM.

Each AVAS consists of a maildrop or final destination for incoming emails, which can be specified either by an IP address or an FQDN (Fully Qualified Domain Name). If the FQDN resolves to more than one IP, the MXs will deliver the incoming email randomly to any of the IPs.

The type of maildrop must also be specified, which can be Corpmail (the Planisys product for hosting mailboxes), Zimbra (a product similar to Corpmail), MS-Exchange, Office365, or G-Suite.

In the cases of Office365 and MS-Exchange, RV (Recipient Verification) must be configured so that the maildrop directly rejects emails to nonexistent users, instead of accepting them and then generating a bounce or DSN (Delivery Status Notification), as this can saturate the outgoing relay with bounces that have false senders (this phenomenon is known as backscattering).

Spambot Control

Allows blocking seemingly dynamic IPs from Cablemodem or ADSL providers, from which attacks generally originate, suspected to be from hacked residential PCs, which is a very common phenomenon.

However, there is a risk of blocking MTAs (Mail Transfer Agents, i.e., mail servers) that are misconfigured, whose IPs come from a provider that does not assign a reverse DNS corresponding to the server name.

In that case, these servers will not be able to deliver the email at the first level, and therefore, they will not be found in Quarantine either, and the user will not be aware.

Strict SPF Check

When setting this check, all emails where the sender’s SPF (Return-Path) fails will be blocked. These rejected emails will not appear in Quarantine.

It is possible to specify domains as SPF Exceptions to allow emails from known domains, even if they are misconfigured.

SPF or Sender Policy Framework is a DNS record for a domain that allows defining a set of IP addresses from which emails originating from that domain come.

Force RDNS Check

This check allows blocking IP addresses of servers or PCs that do not have reverse DNS configured. This means that it forces an IP, e.g., 1.2.3.4, to have a PTR DNS record pointing to a name, e.g., server1.dominio.com, and that server1.dominio.com in turn has an A or CNAME DNS record that resolves to the IP 1.2.3.4.

It is possible to whitelist known IPs corresponding to misconfigured servers, but from which you wish to receive mail.

Spam Control

This setting allows setting the level of spam control to High, Medium, or Low. A Low Spam Control level means that there is a greater tolerance for Spam or unwanted or poorly formatted emails, or even possible phishing.

The antivirus check is performed regardless of the level of Spam Control. If a virus is detected, the email will be sent to Quarantine, regardless of the specified Spam Control level.

TLS Transport Control for PCI-DSS

If this control is set, it implies that the entire chain of mail transfer, from origin to end, must be done with the TLS encryption protocol, to be compatible with the PCI-DSS standard, which is required by many organizations to ensure that the transit of certain communications over the Internet has been encrypted, and thus, its content is protected from being exposed during transport.

If an email does not meet this specification after this control has been set, it will be rejected and will not be in quarantine.

This control also implies that only strong encryption protocols will be accepted when the sending MTA negotiates with the AVAS MX.

Different Domain Headers Check

The email protocol defines a Return-Path or origin email address, which should correspond with the SPF policy of that email’s domain.

On the other hand, a From: header must be specified, which is the sender.

The From and Return-Path can differ if a third party is sending an email on behalf of a sender.

With this check enabled, emails where the origin email and the sender differ completely can be rated with a higher Spam level, as they often come from shared email marketing platforms, but also from transactional emails.

Última actualización en |fecha|