Cve Hmailserver

0 views

Skip to first unread message

Mohammed Faerber

unread,

Aug 3, 2024, 5:52:15 PM8/3/24

to gaconafing

As I said, with Certify v5, I just have 3 deployment tasks that are not scripts. In the port/security UI of hMailServer, it says If you change these settings, hMailServer needs to be restarted for the changes to take effect. Which I take to mean that my choice to restart the service when re-exporting the cert/key is correct.

I noticed the current beta of hmailserver implements some new versions of some encryptions. Did you have to choose any of those in CTW? Or in hmailserver? If yes, where? And which one (encryption, version) was your choice? Or which one would you recommend if mail clients are all Outlook latest?

The welcome message is sent to SMTP clients directly after they have connected to the server. This message is normally never seen by the sender or receiver. One reason to change the welcome message is to make it harder for other people to determine what server software you are running.

It is strongly recommended that you use a max message size limit. Having no message size limits will leave your server open to different types of attacks. For example, users could send a message so big that it fills the server's hard drive, which will cause unpredictable behavior. The default maximum message size is 20MB.

This setting defines the number of times hMailServer should try to deliver an email. Deliveries may fail for a number of reasons. For example, the recipient's email server may be rebooting or your network may be temporarily unavailable. The default value is 4 retries, which means hMailServer will try a total of 5 times before giving up and returning an error message to the sender.

When an SMTP server connects to another server to send a message, the first thing that happens is that the sending server identifies itself using the hostname. Since there is no way to safely auto-detect the hostname of a computer, you have to specify this setting manually. The hostname must resolve to the IP address of the computer which is running hMailServer. Some servers will validate this and classify your email as spam if it does not resolve properly.

It does not matter what hostname you enter, as long as it resolves to the IP address where hMailServer is running. You may have 15 different host names which resolve to the IP address hMailServer is running on. If this is the case, you can enter any of these 15 different host names in the Hostname field.

Example: If hMailServer is running on a machine whose hostname is mail.domain.com, you should specify mail.domain.com as the hostname. If your machine has several public host names, such as mail.domain.com and mail.domain2.com, you may specify any of them as the hostname.

The SMTP relayer setting lets you specify which email server email messages should be delivered to. You should never set the value to "localhost" or to the hostname of your own email server. That would cause hMailServer to try to connect to itself.

When one SMTP server delivers an email to another, DNS-MX lookup is normally used. This means that if you send an email to me, at [email protected], your email server will do an MX lookup for my domain, hmailserver.com. The MX response will tell your server that it should deliver the message to mail.hmailserver.com. That communication occurs via port 25. However, it can happen that your ISP blocks outgoing traffic on the SMTP port (25) to all computers except their own email server. You can therefore not connect to mail.hmailserver.com. In that case, you should configure hMailServer to send all emails through your ISP's email server. Your ISP's email server is then your relayer. The value to enter in the relayer field is the name of your ISP's email server. For example, if you happen to use the Swedish broadband provider Bredbandsbolaget, you should specify smtp.bredband.net as an SMTP relayer.

If you don't want to relay all outgoing messages through a specific SMTP server, this field should be left empty.

If the SMTP relay server supports SSL or STARTTLS, you can configure hMailServer to use this when delivering the message. More information about this topic can be found on the connection security page.

Some spammers send emails with empty sender addresses. If you disable this option, hMailServer will treat these messages as spam. However, some legitimate email also has empty sender address, so it's strongly recommended that you do not disable this option.

According to the SMTP specification, every line in an email message should be separated by the ASCII codes 13 and 10. Some spammers send messages which are not correctly formatted. Use this setting to reject these messages. Please note that legitimate email might have incorrectly formatted line endings if the sending software contains bugs.

Using this setting you can disconnect clients which send to many invalid commands. For example, some spammers try to send emails to a lot of different addresses on your server, hoping that your server will accept at least one of them. Using this option, you can automatically disconnect clients that try to do this.

Use this setting to specify which local IP address hMailServer should use when connecting to other SMTP servers. This can be used if your server has several public IP addresses but you want to use one specific for deliveries. If this setting is not specified, hMailServer will use the Windows default, which works in most cases. An example is '192.168.0.10'.

SMTP servers may reject messages from hMailServer if there are too many recipients for a single email. This may happen if the receiving SMTP server thinks that your email message is spam because you are sending it to a large number of users. Use this setting to limit the number of recipients hMailServer uses in the same delivery. When this number has been reached, hMailServer will disconnect from the recipient server, connect again and continue with the remaining recipients.

With this option enabled, hMailServer will attempt to use STARTTLS with SSL/TLS. If the remote peer does not support STARTTLS, or if the peers can not agree on a cryptographic protocol and cipher, hMailServer will fall back to a connection with no security. If the peers agree on a cryptographic protocol and cipher, but the certificate verification fails, the connection will be used despite the failed certificate verification. In this case, a message will be logged in the debug log.

This option lets you prevent hMailServer from creating endless message delivery loops. As an example, it's possible to set up an account rule that forwards a message from one user (UserA) to another (UserB), and then another rule that forwards the message back from UserB to UserA. To prevent this from resulting in an endless loop, hMailServer limits the number of automatic forwards to the value defined by Rule loop count. (hMailServer 4.2 and later.)