3.7 Server profiles
Server profiles under Inventory > Server profiles help to organize services of one or more servers based on the service type.
For example in case of security rules one or more SMTP servers are needed to forward the emails after processing. For this purpose a server inventory may be created collecting all relay SMTP servers. Then at the rule itself only this server profile needs to be selected.
Currently MetaDefender Email Gateway Security uses and allows SMTP and MetaDefender Core type server profiles only.
Properties
Property |
Server profile type |
Description |
||||||||||||||||||||||||||||||||||||||||||
Server profile type |
N/A |
Service type Supported service types are:
|
||||||||||||||||||||||||||||||||||||||||||
Profile name |
All |
Unique identifier of the server profile |
||||||||||||||||||||||||||||||||||||||||||
Server specifications (URI) |
All |
Service specifications in URI syntax. Multiple server specification may be added to an SMTP or MetaDefender Core type server profile. At least one server specification must exist in a server profile. Only the following URI components are used:
Server profile examples The following list contains examples for each server profile type with reasonable defaults (all use 127.0.0.1 as host).
In case of MetaDefender Core server profile types the very same URI will be used for the URLs of View scan details links on the Email details page under Dashboard > Email history, Dashboard > Quarantine and Dashboard > Failed emails. If the URI specified here is not reachable on the machine where the actual browsing of the Web Management Console happens (e.g. it is 127.0.0.1 and browsing happens on an other machine) then the View scan details link will be broken. See also the Email details section in 4.1 Dashboard. |
||||||||||||||||||||||||||||||||||||||||||
Server preference |
|
Preference order in which servers are addressed for services Possible values:
|
||||||||||||||||||||||||||||||||||||||||||
Transport level encryption |
|
Configure whether the destination server requires transport level security for connections Possible values:
|
||||||||||||||||||||||||||||||||||||||||||
Username and password |
|
If the destination server requires (machine-to-machine) user based authentication, then the credentials can be specified here As long as TLS is not configured for the Web Management Console, passwords are sent clear-text over the network. To set up TLS see 3.2 Configuring TLS. |
||||||||||||||||||||||||||||||||||||||||||
Certificate based client authentication |
|
If the destination server requires certificate based client host authentication then this checkbox must be marked MetaDefender Email Gateway Security will use the actual deployment's digital ID, for details see 3.2 Configuring TLS |
||||||||||||||||||||||||||||||||||||||||||
API key |
|
The destination Vault server will require the authorization token specified here for Email Gateway Security to be able to upload files. For details see API Authorization Tokens in MetaDefender Vault's user guides. |
||||||||||||||||||||||||||||||||||||||||||
Connection pooling |
|
To improve performance, Email Gateway Security can c ache and reuse connections towards SMTP relays. How it works At the end of the processing of an email, Email Gateway Security forwards the processed email to the next hop –that is usually the mail server for inbound emails– via SMTP. This next hop is configured in the rule matching the email, under Policy > Security Rules / Add new rule | Modify rule / RELAY / FORWARD PROCESSED EMAILS TO. The value must be an SMTP type server profile configured under Inventory > Server Profiles. When an email is forwarded to the relay, an SMTP handshake must happen while a TCP connection must be established. This is a time-consuming, resource-intensive task that can slow the email processing down, especially under a heavy load. To contain the time loss caused by establishing SMTP connections, Email Gateway Security can reuse already established connections, these are kept in the connection pool.
SMTP server limitations Please note, that most SMTP servers limit the number of parallel inbound SMTP connections. This must be taken into consideration when configuring connection pooling in Email Gateway Security. Microsoft Exchange Server For details about limitations on number of connections in case of the Microsoft Exchange Server, see https://docs.microsoft.com/en-us/exchange/mail-flow/message-rate-limits.
|
Property validation
Some of the server profile properties have cross-dependencies and as so must match.
Server profile type |
Server specifications (URI) allowed schemes |
SMTP |
smtp |
smtps |
|
MetaDefender Core |
http |
https |
|
MetaDefender Vault |
http |
https |
Server specifications (URI) scheme |
Transport level encryption allowed values |
smtp |
None |
StartTLS optional |
|
StartTLS required |
|
smtps |
Irrelevant If smtps scheme is specified then the SMTP connection is established over TLS irrelevant of the setting of TRANSPORT LEVEL ENCRYPTION. |
http |
N/A |
https |
N/A If https scheme is specified then the HTTP connection is established over TLS. |
Testing the configuration
Clicking the TEST button will test the configuration. The test consists of two steps:
-
Syntactical validation of the values
-
Connection test
If the test fails, then the server profile can not be added.
Syntactical validation
The correctness of the provided values is validated:
-
PROFILE NAME must be unique
-
The SERVER SPECIFICATIONS (URI) values must conform with the URI syntax with the restriction that only the scheme, host and port values are allowed
-
Cross dependencies must match (see the 149718360 section)
Connection test
If the syntactical validation pass, then each server specification is tested for a successful connection.
Limitations
Currently the connection is tested without using TLS (when configured at all).