The following document is used to describe the first configuration steps with the REDDOXX Appliance.
Further information is linked in the corresponding sections.
The configuration steps are also available as Screencasts
These settings can be found in Webinterface => Configuration => Settings
Enter the e-mail address of the REDDOXX Appliance.
The e-mail address of the REDDOXX Appliance must be an e-mail address of a valid e-mail domain and also received by the REDDOXX Appliance. This e-mail address may not be used for other purposes
Enter the e-mail address of the administrator.
To this email address the administrator receives messages from the appliance, e.g. when the backup was not finished correctly.
If necessary, configure Proxy settings in the proxy tab
These settings can be found in Webinterface => Configuration => E-Mail Transport
If, instead of STMP Mailflow, POP3 fetching is required, see the corresponding POP3 Quick Guide.
Screencast SMTP Mailflow with MS Exchange:
Trusted Networks / Local Networks
In the Trusted Networks / Local Networks, the internal systems are specified which are allowed to send mails via the appliance.
In CIDR notation for a single host, this would be e.g. 192.168.4.6/32.
Local Domains
All domains for which the appliance is to receive e-mail are set up in the local domains.
The recipient check can also be activated so that the appliance only accepts mails for known recipients.
Recipients must either be synchronised in advance via a directory or created as local users with corresponding email addresses in the user administration.
For domains that are hosted at Microsoft 365, "enable Hosted Exchange support" can be activated here, so that the appliance then recognises from the DKIM signature of the e-mail,
that it is an outgoing email (even without a Trusted Network entry for the Microsoft 365 networks).
The prerequisite here is that DKIM must be activated for the domain (https://security.microsoft.com/dkimv2).
In addition, DKIM can also be set up for each local domain so that the appliance provides outgoing e-mails with a DKIM signature.
External Domain Policies
In the External Domain Policies, guidelines for the connection to specific domains are defined.
Here, one or more public certificates of the remote server can be selected, the TLS behaviour as well as a possible user authentication can be set as requirement.
The settings are only necessary for a few communication partners, who then also provide the corresponding certificates in advance.
External Domain Policies have priority over SMTP Transport Policies and also serve to protect against accidental misconfiguration of SMTP Transport Policies for certain domains.
In order to use the MTLs policies, it must be selected in the corresponding SMTP Receive Connector that the client certificate is requested (Request Client certificate in TLS Settings).
SMTP Receive Connectors
Adjust the settings for the receive connector here, this is bound to all interfaces and port 25 by default.
You can add more connectors, but make sure that each receive connector can only be bound to one network device.
You can configure the host name, TLS settings, authentication parameters as well as SPF, DKIM, DMARC.
RealTime Blacklists and Antispoofing can also be configured (with associated exceptions if required).
SMTP Transport Policies
Set up a new transport policy here (via Add).
Here the sender/recipient filtering in the Addresses field in conjunction with the smarthost settings from the Transport field is used to define where e-mails are to be forwarded to.
In addition, TLS settings, authentication and the FQDN can be set, which is sent via a Helo command.
The rules are processed in order
For each local domain, the transport to a SmartHost (internal mail server) should be configured accordingly, as otherwise the default transport policy would take effect without an explicit rule and the mails would be forwarded to the MX via DNS (which would then lead to a mail loop).
In addition, transport rules can be created for other domains that are to be used differently from a DNS query.
IP address filter
Here you can configure blacklist and whitelist entries for networks that prevent or allow communication with the appliance.
In addition, sender IP addresses are displayed in this filter list and blocked for 24 hours if they have attempted incorrect SMTP authentication 5 times or if they have been filtered via the RealTime Blacklist Filter.
In the administration area you can follow the Live Log and also adjust the log level (for display) via right click as well as filter for certain messages or connections.
Further searches are possible in the Log Files section, where you can search for specific processes over a defined time frame and also save the result.
The Update overview shows available updates and hotfixes. In the settings, you can define whether and in which time frame updates should be searched for and if hotfixes should be installed automatically.
Realms are used to configure a login area, which can, for example, synchronise the directory via Active Directy and thus import groups, users and permissions.
Further access restrictions (Policies) or Creating a Deputy Policy are also possible.
The login configuration is also available as a screencast:
These settings can be found in Webinterface => Maildepot
Additionally, further documentation is provided in quick guides to cover different archiving scenarios depending on the systems used in your company.
Screencast Maildepot Configuration:
Archiving can be enabled / disabled in the settings
For archving, an archiv container is required that is set as default via rightclick -> "set default"
Prior to create an archive container, a storage needs to be configured
With archive policies exceptions to archiving can be created
Categories and archive tasks are used to automatically process archived mail (e.g. add to categories or move)
Via audit sessions, revision tasks for authorized users can be created
The maildepot connectors can be used to access journaling mailboxes for archiving internal mails
The settings are located in the web interface => MailSealer
In the MailSealer Settings, the MailSealer and the Automatic Licensing can be activated, and signature and encryption settings for S/MIME and OpenPGP can be selected.
Select whether and in which order S/MIME or PGP should be used.
In the Policies area, at least one outgoing and one incoming policy must be set up for Mail Processing (e.g. sender and recipient can be selected with *).
Policies are then processed in order
Overrides can be defined for special cases in the encoding and decoding options.
With OpenPGP, private certificates can be created automatically; with S/MIME, they must be added in the Private Certificates area.
Alternatively, you can set up your own certificate authority (via Private Certificate Authorities + right-click), which then creates S/MIME certificates.
The processing when selecting several encoders at the same time (S/MIME + PGP) and depending on the selected signing and encryption variant is as follows:
Signing
Encryption
Used Methods
Force
Force
The first encoder that can sign and encrypt is used.
If possible
Force
The first encoder that can sign and encrypt is used. If no encoder is found that can do both, then the first encoder that can encrypt is used.
No signing
Force
The first encoder that can encrypt is used.
Force
If possible
The first encoder that can sign and encrypt is used. If no encoder is found that can do both, then the first encoder that can sign is used..
If possible
If possible
The first encoder that can sign and encrypt is used. If no encoder is found that can do both, then the first encoder that can encrypt is used. If no encoder is found that can encrypt, then the first encoder that can sign is used.