mirror of
https://git.proxmox.com/git/pmg-docs
synced 2025-05-08 14:04:27 +00:00

Commandline/command line/command-line where being used interchangeably, which is not correct (see: https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/command-line). use command-line when it is an adjective (e.g. "command-line interface") and use command line when it is a noun (e.g. "change the setting from the command line") Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com> [S.I.: fix a stray ' ' introduced with this commit] Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
285 lines
9.2 KiB
Plaintext
285 lines
9.2 KiB
Plaintext
Introduction
|
||
============
|
||
|
||
What is {pmg}?
|
||
--------------
|
||
|
||
Email security begins at the gateway, by controlling all incoming and
|
||
outgoing email messages. {pmg} addresses the full spectrum of
|
||
unwanted email traffic, focusing on spam and virus detection. {pmg}
|
||
provides a powerful and affordable server solution to eliminate spam and
|
||
viruses, and block undesirable content from your email system. All
|
||
products are self-installing and can be used without deep knowledge of
|
||
Linux.
|
||
|
||
image::images/Proxmox_Mail_Gateway_Mailprocessing_final_1024.png[]
|
||
|
||
Features
|
||
--------
|
||
|
||
[[intro_spam_detection]]
|
||
Spam detection
|
||
~~~~~~~~~~~~~~
|
||
|
||
{pmg} uses a wide variety of local and network tests to identify spam
|
||
mail. Here is a short list of used filtering methods:
|
||
|
||
Receiver Verification::
|
||
|
||
Many of the junk messages reaching your network are emails to
|
||
non-existent users. {pmg} detects these emails on the SMTP
|
||
level, before they are transferred to your network. This
|
||
reduces the traffic to be analyzed for spam and viruses by up to 90% and
|
||
reduces the working load on your mail servers and scanners.
|
||
|
||
Sender policy framework (SPF)::
|
||
|
||
Sender Policy Framework (SPF) is an open standard for validating
|
||
emails and preventing sender IP address forgery. SPF allows the
|
||
administrator of an internet domain to specify which computers are
|
||
authorized to send emails with a given domain, by creating a specific
|
||
SPF record in the Domain Name System (DNS).
|
||
|
||
DNS-based Blackhole List::
|
||
|
||
A DNS-based Blackhole List (DNSBL) is a means by which an internet
|
||
site may publish a list of IP addresses, in a format which can be
|
||
easily queried by computer programs on the Internet. The technology is
|
||
built on top of the Domain Name System. DNSBLs are used to publish
|
||
lists of addresses linked to spamming.
|
||
|
||
SMTP Whitelist::
|
||
|
||
Exclude senders from SMTP blocking. To prevent all SMTP checks
|
||
(Greylisting, Receiver Verification, SPF and DNSBL) and accept all
|
||
emails for analysis in the filter rule system, you can add the
|
||
following to this list: Domains (Sender/Receiver), Mail address
|
||
(Sender/Receiver), Regular Expression (Sender/Receiver), IP address
|
||
(Sender), IP network (Sender).
|
||
|
||
Bayesian Filter - Automatically trained statistical filters::
|
||
|
||
Certain words have a higher probability of occurring in spam
|
||
emails than in legitimate emails. By being trained to
|
||
recognize those words, the Bayesian filter checks every email and adjusts the
|
||
probabilities of it being a spam word or not in its database. This is
|
||
done automatically.
|
||
|
||
Black- and Whitelists::
|
||
|
||
Black- and Whitelists are an access control mechanism to accept,
|
||
block, or quarantine emails to recipients. This allows you to tune the
|
||
rule-system by applying different objects like domains, email address,
|
||
regular expression, IP Network, LDAP Group, and others.
|
||
|
||
Auto-learning algorithm::
|
||
|
||
{pmg} gathers statistical information about spam
|
||
emails. This information is used by an auto-learning algorithm, meaning the
|
||
system becomes smarter over time.
|
||
|
||
Spam URI Real-time Block List (SURBL)::
|
||
|
||
SURBLs are used to detect spam, based on the URIs in the message body (usually
|
||
websites). This makes them different from most other Real-time
|
||
Blocklists, because SURBLs are not used to block spam senders. SURBLs
|
||
allow you to block messages that have spam hosts which are mentioned
|
||
in message bodies.
|
||
|
||
Greylisting::
|
||
|
||
Greylisting an email means that unknown senders are intentionally temporarily
|
||
rejected. Since temporary failures are part of the specifications for mail
|
||
delivery, a legitimate server will try to resend the email later on. Spammers,
|
||
on the other hand, do not queue and reattempt mail delivery. A greylisted email
|
||
never reaches your mail server and thus your mail server will not send useless
|
||
"Non Delivery Reports" to spammers. Additionally, greylisted mail is not
|
||
analyzed by the antivirus and spam-detector engines, which saves resources.
|
||
+
|
||
A mail is greylisted if it is the first mail from a sender to a receiver
|
||
coming from a particular IP network. You can configure which IP addresses
|
||
belong to the same network, by setting an appropriate netmask for greylisting.
|
||
|
||
SMTP Protocol Tests::
|
||
|
||
{postfix} is able to do some sophisticated SMTP protocol tests (see
|
||
`man postscreen`). Most spam is sent out by zombies (malware on
|
||
compromised end-user computers), and those zombies often try to
|
||
maximize the amount of mails delivered. In order to do that, many of
|
||
them violate the SMTP protocol specification and thus can be detected
|
||
by these tests.
|
||
|
||
Before and After Queue Filtering::
|
||
|
||
{pmg} can be configured to either accept the mail, by sending a response
|
||
of '250 OK', and scan it afterwards, or alternatively inspect the mail
|
||
directly after it has the content and respond with a reject '554' if the
|
||
mail is blocked by the rule system. These options are known as After Queue
|
||
and Before Queue filtering respectively (see
|
||
xref:pmgconfig_mailproxy_before_after_queue[Before and After Queue Scanning]).
|
||
|
||
Configurable NDR policy::
|
||
|
||
In certain environments, it can be unacceptable to discard an email, without
|
||
informing the sender about that decision. You can decide whether you want
|
||
to inform the senders of blocked emails or not.
|
||
|
||
Virus detection
|
||
~~~~~~~~~~~~~~~
|
||
|
||
{pmg} integrates {clamav}, which is an open-source (GPL) antivirus
|
||
engine, designed for detecting Trojans, viruses, malware, and other
|
||
malicious threats.
|
||
|
||
It provides a high performance, multi-threaded scanning daemon, command-line
|
||
utilities for on demand file scanning, and an intelligent tool
|
||
for automatic signature updates.
|
||
|
||
|
||
Object-Oriented Rule System
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The object-oriented rule system enables custom rules for your
|
||
domains. It’s an easy but very powerful way to define filter rules by
|
||
user, domains, time frame, content type and resulting action. {pmg}
|
||
offers a lot of powerful objects to configure your own custom system.
|
||
|
||
WHO - objects::
|
||
|
||
Who is the sender or receiver of the email?
|
||
|
||
WHAT - objects::
|
||
|
||
What is in the email?
|
||
|
||
WHEN - objects::
|
||
|
||
When was the email received by {pmg}?
|
||
|
||
ACTIONS - objects::
|
||
|
||
Defines the final actions.
|
||
|
||
Every rule has five categories FROM, TO, WHEN, WHAT and ACTION. Each
|
||
of these categories can contain several objects and a direction (in,
|
||
out or both).
|
||
|
||
Options range from simple spam and virus filter setups to
|
||
sophisticated, highly customized configurations, blocking certain types
|
||
of emails and generating notifications.
|
||
|
||
Web-based Management Interface
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
{pmg} makes email security and filtering simple to manage. The web-based
|
||
management interface allows you to set up and maintain even a complex mail
|
||
system with ease.
|
||
|
||
[thumbnail="pmg-gui-dashboard.png"]
|
||
|
||
There is no need to install a separate management tool. Any modern internet
|
||
browser is sufficient.
|
||
|
||
Spam Quarantine
|
||
~~~~~~~~~~~~~~~
|
||
|
||
Identified spam mails can be stored in the user-accessible Spam Quarantine.
|
||
Thus, users can view and manage their spam mails by themselves.
|
||
|
||
|
||
Tracking and Logging
|
||
~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The innovative Proxmox Message Tracking Center tracks and summarizes
|
||
all available logs. With the web-based and user-friendly management
|
||
interface, IT admins can easily view and control all
|
||
functions from a single screen.
|
||
|
||
The Message Tracking Center is fast and powerful. It has been tested on
|
||
{pmg} sites which process over a million emails per day. All log
|
||
files from the last 7 days can be queried, and the results are
|
||
summarized by an intelligent algorithm.
|
||
|
||
The logged information includes:
|
||
|
||
- Arrival of the email
|
||
- Proxmox filter processing with results
|
||
- Internal queue to your email server
|
||
- Status of final delivery
|
||
|
||
|
||
DKIM Signing
|
||
~~~~~~~~~~~~
|
||
|
||
{pmg} offers the possibility to optionally sign outgoing emails with
|
||
xref:pmgconfig_mailproxy_dkim[DKIM].
|
||
|
||
|
||
High Availability with Proxmox HA Cluster
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
To provide a 100% secure email system for your business, we developed
|
||
Proxmox High Availability (HA) Cluster. The Proxmox HA Cluster uses a
|
||
unique application-level clustering scheme, which provides extremely
|
||
good performance. It is quick to set-up and the simple, intuitive
|
||
management interface keeps resource requirements low. After temporary failures,
|
||
nodes automatically reintegrate without any operator interaction.
|
||
|
||
LDAP Integration
|
||
~~~~~~~~~~~~~~~~
|
||
|
||
It is possible to query user and group data from LDAP servers. This may be
|
||
used to build special filter rules, or simply to provide authentication services
|
||
for the Spam Quarantine GUI.
|
||
|
||
|
||
Fetchmail Integration
|
||
~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
{pmg} allows you to fetch mail from other IMAP or POP3 servers.
|
||
|
||
|
||
Flexible User Management
|
||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The administration interface uses a role-based access control scheme,
|
||
using the following roles:
|
||
|
||
Superuser::
|
||
|
||
This role is allowed to do everything (reserved for user 'root').
|
||
|
||
Administrator::
|
||
|
||
Full access to the mail filter setup, but not allowed to alter the network
|
||
setup.
|
||
|
||
Quarantine Manager::
|
||
|
||
Is able to view and manage the Spam Quarantine.
|
||
|
||
Auditor::
|
||
|
||
Has read-only access to the whole configuration, can access logs and
|
||
view statistics.
|
||
|
||
Helpdesk::
|
||
|
||
Combines permissions of the 'Auditor' and the 'Quarantine Manager' role.
|
||
|
||
|
||
Your benefit with {pmg}
|
||
-----------------------
|
||
|
||
* Open-source software
|
||
* No vendor lock-in
|
||
* Linux kernel
|
||
* Fast installation and easy-to-use
|
||
* Web-based management interface
|
||
* REST API
|
||
* Huge, active community
|
||
* Low administration costs and simple deployment
|
||
|
||
|
||
include::getting-help.adoc[]
|