This issue relates to "End of data sequence handling" or SMTP Injection.

Traditionally SMTP servers have been 'flexible' with line termination, however, it was recently (2024) discovered that this leads to a possible injection exploit whereby users could possibly send messages with forged content/origin by exploiting the fact that some servers will see the end of message and others wont.

To fix this problem UPGRADE TO 7.8

If a legacy client/fax system is sending LF characters, you need to whitelist them individually like this:

 g_lf_fix_list "1.2.3.4"

Legacy devices that rely on this behaviour should be exceedingly rare, and should normally be patched rather than relying on this exception setting.

This is a relatively low level security risk (so don't panic) but do upgrade at your earliest convenience.

Other references: CVE-2023-51764 postfix, CVE-2023-51765 sendmail, CVE-2023-51766 exim

The post SMTP Injection issue (crlf line termination) appeared first on SurgeMail.

G_MTASTS "True"

Enable MTA-STS ssl/tls rules. This uses DNS entries to discover if receiving server should have a signed SSL certificate"

G_MTASTS_WHITE "xyz.com,fred.com"

Domains to ignore MTA-STS rules, Whitelist for destination domains we should just send to anyway even if MTA-STS suggests otherwise.

G_MTASTS_REPORT "true"

Alert manager on MTASTS failures. Most failures will be due to something other than real hackers, so this alert helps you resolve issues, and add whitelist rules g_mtasts_white settings for problem domains

In addition you may wish to add your own MTA-STS file to your domain to enforce your own policy.

The url you need to create should be:

https://mta-sts.YOUR.DOMAIN/.well-known/mta-sts.txt" 

And in that file you should have something like:

version: STSv1
mode: enforce
mx: mail1.your.domain.com
mx: mail2.your.domain.com
max_age: 604800

If mta-sts.your.domain points to your surgemail server!, then you could place this file in the folder: (surgemail home)/www/.well-known

You must also add a dns 'txt' record for your domain:

_mta-sts.your.domain.com "v=STSv1; id=20240610T010101;"

If your policy changes you must update the id FIELD.

The post MTA-STS support appeared first on SurgeMail.

https://your.mail.server/cgi/user.cgi

The user can then specify what level of two factor authentication they wish, as imap smtp and pop were never intended to use this type of authentication it only works really well for surgeweb logins. But it can still add a layer of security for the others as well.

The user.cgi page allows users to also create or delete application passwords for legacy applications (normal desktop email clients).

Alternatively the setting g_pass_twofactor_merged "true", can be used, then the user logs into legacy applications with their regular password+twofactorcode. So lets say your password is 'secret' and your 2fa app was showing code '1232", you would enter "secret+1232" as your password, it would then work as normal for a few hours, and then it would require the password to be entered again.

Lets be blunt, legacy applications (all normal email clients) are not designed to be used with two factor authentication, so it's a question of 'which cludge do you wish to use'. Both are much more secure than not having 2 factor authentication, but not nearly as secure as true 2fa. And both add a level of inconvenience.

The post Twofactor Authentication 2fa appeared first on SurgeMail.

How to get a signed certificate

• (STOP, GO TO THE LetsEncrypt page instead of doing this!)
• Open the SSL Configure page in the Web Admin interface.
• Click on 'Create CSR', if you have never done this before, and give the details of your server.
• Click on 'Show CSR' and copy the code.
• Go to your favorite certificate registry and request a signed certificate or use LetsEncrypt (see notes below), The registry service will want this CSR .
• They will then give you a signed certificate and intermediate certificates, ask for 'Apache' or 'Other' format.
• Upload the two files using the buttons on the web interface

Warning:

If your certificate doesn't match the current private key, or is miss formatted etc, then you may loose connection to this page when you press 'save changes', instead use the non ssl admin port: http://your.server:7026, examine mail.err for  the cause, remove ssl/surge_cert.pem and restart surgemail to recreate a working unsigned certificate!

Manual Installation of Certificates - And debugging bad certificates....

You can install your certificate manually by replacing the file ssl/surge_cert.pem it should contain start with your certificate, and then it should have your intermediate chain certificates appended to the end of it.

If your certificate was created from a different private key then also replace ssl/surge_priv.pem.  If your certificate is faulty in any way ssl will not work, in that case examine mail.err to find the cause, and remove surge_cert.pem and restart surgemail to recreate an unsigned but working certificate.

If you are using g_ssl_perdomain "true" then place certifictes in ssl/mail.domain.name folders

Generally for an ssl certificate you should make sure you have url_host defined for each domain, e.g. for xyz.com url_host should be "mail.xyz.com"

If you are using a wild card ssl certificate and want it to match correctly with any sub domain used, then use the new setting ssl_wildcard "*.xyz.com" so it will match correctly.

The post Manual SSL Certificates appeared first on SurgeMail.

The SurgeVault feature allows you to define some rules (per domain) that specify when a message should be encrypted (based on subject, or content or destination etc) and then instead of sending the raw naked message the destination user is either sent an encrypted message, or a link to an encrypted message. In either case the destination user is required to login and set a password to read that and future messages. Then they are either shown the message, or given a key to decrypt the message they were sent.

How to configure/turn on SurgeVault encryption:

1. Upgrade to SurgeMail 4.2b-11 or later
2. Set the global setting G_ENCRYPT_SURGEWEB_SHOW "true" if you want the encryption icon at the top of surgeweb compose new email page to appear.
3. Set a domain level rule in surgemail.ini for each domain you want to be able to send encrypted messages (without this you can only send encryption from surgeweb)
   encrypt_rule header="subject" contains="encrypt:" method="server"
4. Send an email to someone from the domain in question, with "encrypt:" in the subject.
5. Or, in surgeweb send an email to someone and click on the encrypt icon before sending it.
6. If you wish to use the feature regularly you will need a new Key to enable this feature (sorry this is a paid add on feature), otherwise it is limited to '2' messages per day!

Inline based encryption

In this mode the message is encrypted, then sent to the destination user as an html attachment which contains javascript to 'decrypt' the message, to obtain the 'key' to decrypt the message the user must login to the sending server and request it. The first time they do this they must set a password. This means the security of 'subsequent' messages is enhanced as the password cannot be 'reset' by the receiving customer. (this applies to the server based method too)

Server based encryption

In this mode the destination user is sent a link containing a key that is needed to decode the message which is kept on the sending server. This is equally secure.

Secure Reply

In either case a secure reply can be sent once the user has logged in to fetch the key or decrypt the message.

Encoding used

AES 256 CBC mode with MD5 hash.

How secure is it - what does it protect and what doesn't it protect you from...

After the first email exchange and the password for a user has been set, then the encryption will prevent someone spying on the message in the 'middle' between your sending sever and the receiving user. It does not prevent the administrator of your server from spying on the message as they can certainly circumvent this mechanism (with some difficulty).

However it provides you with a way of being sure that no one outside your server see's the message other than the intended recipient and it also gives you an audit trail to know that the receiving user did (or didn't) view the message. You can further enhance security by using https and ssl to send the message so that no one other than the administrator on your network can spy on the message before it gets to your server.

This mechanism is suitable and possibly a legal requirement for some forms of email, for example when a doctor sends an email to a patient that includes test results it would be an appropriate way of doing it. Or any time someone is sending personal private information via email and must provide some assurance that the message cannot be intercepted trivially!

Relevant Settings

Full encrypt_rule settings are:

encrypt_rule header=string contains=string from=string to=string method=string

SurgeWeb integration

In addition to encrypt_rule rule based triggering, the sending of encrypted email is integrated into the surgeweb compose pane.

g_encrypt_surgeweb_show true 

Also note that there is a setting on the surgeweb customisation page that disables the SurgeVault interface in surgeweb.

encrypt_hide true

Warning replying to messages:

If you use a rule like this:

encrypt_rule header="subject" contains="encrypt:" from="" to="" noconfirm="" method="server"

And you send someone an email, lets say for some reason they cannot read it and send you a reply then you reply to their email the 'encrypt' rule will still match and the message will be encrypted again... So just be aware of that! Obviously this is normally exactly what you want so all your emails to them on this subject remain encrypted.

The post SurgeVault encryption sending to other systems. HIPAA compliant. appeared first on SurgeMail.

To enable AtRest encryption first the administrator must enable the feature

    g_atrest_enable "true"

BEFORE YOU DO THIS, BACKUP YOUR EXISTING MAIL!!! If something goes wrong with encryption it is irreversible.

Read the warning at the bottom of this page!

Then the user must login via http://your.server/cgi/user.cgi and click on 'At Rest' on the left hand panel and enable encryption, at this time the user must provide their current password to ensure they really do know it!

As of version 7.3p we have added a new feature whereby the administrator can SET a global decryption password. This allows your files to be restored if you forget your password. The administrator MUST NOT forget this password, it cannot be changed, or reset!

To configure the admin recovery password, this cannot be changed later, if it is changed, it will not work for any existing encrypted messages!
    tellmail atrest_admin YourSecretPassword   

After setting that password you can make users data automatically encrypt next time they login, this will impact performance initially.

    g_atrest_all "true"

Again, this feature is dangerous!

To decrypt a users mail folders (e.g. if they forget their own password)
    tellmail atrest_admin_decrypt user@xyz.com YourSecretPassword
To change a users password use this command:
tellmail atrest_set_user_pass test1@book.netwin.co.nz Mytes3 secret

NOTE: Upgrade to at least version 7.4 or later before turning on!

Advantages of At Rest encryption

• If a hacker gains access to the mail file system they will not be able to see any of your email messages.
• If an administrator wants to look at your email messages they will not be able to.
• If an outside agency gains physical access by legal or illegal means to the mail server they will still not be able to decode and see your email messages.
• Files are encrypted using industry standard AES 256bit CBC.
  

Disadvantages of at rest encryption.

• If you forget your password, and you also loose the recovery code that you are given when you first encrypt your messages, then ALL your email messages will be lost forever, there is no other recovery mechanism, the administrator CANNOT reset your password and get you access to the files again. (See notes above regarding the new administrator decrypt command, which is now supported.  If you want a higher level of security then disable this feature with the setting: g_atrest_crazy "true")
  
• There is a mild performance hit as the data must be decrypted and surgeweb has to do less 'caching'.
• Saved login sessions on surgeweb will not persist as long as login credentials cannot be saved to disk.
• If you change a users password in the backend user database manually, then they will be able to login, but all their email will be invisible as the decryption will not work!  To resolve first decrypt using the atrest_admin_decrypt command noted above.
  

Limitations, what it cannot protect you from

• If your password can be guessed with a dictionary attack or brute force guessing millions of passwords, then your messages could be decoded, be sure to set a complex password that is not based on simple words etc...
  
• In some situations the server will write temporary files containing unencrypted mail messages before displaying them via imap or surgeweb, in theory an administrator could at this time spy on those files.  But only the messages you were actively reading! And it would not be easy.
  
• The administrator can enable features to keep copies of all email messages even when this feature is turned on, nothing can prevent this as the administrator controls the server.  The normal archiving feature is automatically disabled though so this will not occur by accident.
• So it's critical to 'stop' accessing your mail server if the administrator is compromised legally or otherwise.
• Your email client may have your password stored, anyone who gets access to your email client/stored password can then crack your account instantly, so if security is important to you don't allow your email client to remember your password.
  

Recovery Code

At the time the user enables encryption they are given a recovery code, this is also emailed to the user.  The user should print and save this code, if the users normal password is lost or forgotten then it's the only mechanism by which they can reset their password without loosing all their messages. This does not apply if g_atrest_all is enabled.  If g_atrest_crazy is not defined, then the admin recover password can be used

Warning

It cannot be emphasized enough, there are risks with this feature. Users WILL forget their passwords and loose their recovery codes. Even with the admin feature if you forget the admin password it cannot ever be reset or fixed!!!! Please don't enable this unless you truly understand how dangerous it is. There is almost no good reason for using this feature Unless you are actually a professional spy!

The post Atrest encryption appeared first on SurgeMail.

Set g_dkim_sign "true"

On the web admin interface search for "Create DKIM" then click on the Configure link.

Add the DNS setting it suggests for your domains(s).

Also add the suggested DMARC settings, (this requires a recent version of surgemail)

See https://surgemail.com/knowledge-base/sending-email-to-avoid-spam-filters-best-practices/

How it works:

DomainKeys is a cryptographic method that allows a receiving server/client to verify that the From/Sender header was accurate and not forged.

It does this by looking up the senders _domainkey.domain.name dns record to get the public key which it uses to check the signature in the message headers is correct.

SurgeMail makes use of this information to avoid grey bouncing a message when no SPF information exists. And may in future score signed messages differently.

SurgeMail can also 'sign' outgoing email, this helps your email get delivered to servers that use this information to further verify a message. And this makes it harder for spammers to forge your domain successfully.

There is a button in surgemail to generate your private/public keys. This creates the file domainkey.pem, if you have several servers sending email for your domain you will need to copy this file to each server.

As well as entering your public key into your dns you will define your policy in the txt dns record default._domainkey.your.domain and _domainkey.your.domain, this policy defines if you are testing or not, and if you sign all or some of the messages from your domain. A receiving system 'should' use this information to determine what action is valid if a signature does not exist or fails to verify.

The post DKIM / DomainKeys DMARC appeared first on SurgeMail.

g_ssl_per_domain "true"
g_ssl_auto "true"
g_webmail_port "80,7080" 

Then issue the command:

tellmail ssl_update

(or use tellmail ssl_update_test to check your settings first, too many failures will cause a lockout for a day)

That's it.

NOTE: It's essential that you are running SurgeMail on port 80 and NOT some other web server! (or use the notes below about IIS/APACHE)

But also check your other ssl settings are enabled:

g_ssl_allow "*" 
g_ssl_try_out "*" 
g_ssl_perfect "true"  
# You may also want to disable older ssl protocols, e.g.
g_ssl_disable "tlsv1,tlsv1_1,sslv2,sslv3"

Requirements for Lets Encrypt.

• SurgeMail version 7.3j2 or later
• Your server must be accessable on port 80 directly to surgemail (not apache or IIS)
• Each domains url_host setting must point at your server. e.g. url_host "mail.fred.com"
• Ensure each domains 'url_host' setting is the name you want to use to refer to that domains server, typically mail.domain.name, e.g. for 'fred.com' you would usually use 'mail.fred.com', this dns entry must exist!
• Add aliases you want to also work in each domain with the ssl_alias setting, e.g. ssl_alias "webmail.fred.com"

Forcing SSL connections

If you wish to force the use of SSL use the following settings:

# Block imap/pop/smtp logins without SSL enabled for all ip addresses.
g_ssl_require_login "*"

# Redirect users to the https url automatically.
g_url_redirect from=”http://*/surgeweb” to=”https://%1/surgeweb” ports=”80″
g_url_redirect from=”http://*/user.cgi” to=”https://%1/user.cgi” ports=”80″

Exclude some domains

Use this setting:

g_ssl_lets_exclude "xyz.com"

To exclude one or more domains, then copy their certificates into the ssl folders.

copy surgemail\ssl\xyz.com\*.pem surgemail\lets\xyz.com

Windows IIS on the same system.

If you have IIS or Apache running on the same mail server, and it's assigned port 80 then you need to define this setting so surgemail knows where to put the challenge file:

Remove port 80 from g_webmail_port, restart surgemail and IIS.

Set in surgemail: g_ssl_lets_path "c:\surgemail\wellknown"

And in IIS create a virtual path ".well-known" and map it to c:\surgemail\wellknown

Then on IIS add a file extension of type "." with mime type text/xml

1. Open IIS Manager and right click on the website, select “Add Virtual Directory…“
2. For the Alias Entry field, enter .well-known and for the Physical Path field enter the location of the new well-known folder you created.
3. Press OK to save the input and make the file accessible on the website.
4. Test it by placing a file in c:\surgemail\wellknown\test and check you can view it via http://your.web.server/well-known/test Now test tellmail ssl_update and it should work

Linux/Apache on same system

If you are running apache on port 80 then you can do this, correct the path to be whatever you have used for apache's web path...

(In surgemail.ini add)

 G_SSL_LETS_PATH "/var/www/html/.well-known"

(Then)

  mkdir /var/www/html/.well-known/acme-challenge
   chown mail /var/www/html/.well-known/acme-challenge

Using reverse proxy insetad with apache (alternative)

If you have Surgemail on port 7080 (g_webmail_port = "7080") and then put the following in default virtual server configuration (using the actual server and domain name):
ProxyPass /.well-known http://servername.mydomain.com:7080/.well-known
ProxyPassReverse /.well-known http://servername.mydomain.com:7080/.well-known

Then "tellmail ssl_update" should work just as if surgemail was on port 80...

Manual SSL certificates

Alternatively you may wish to configure ssl certificates Manually if so click here.

The post Enable SSL (LetsEncrypt) appeared first on SurgeMail.

This setting controls which connecting IP numbers are permitted to use SSL on POP and IMAP. They will see TLS in the protocol extension command (ETRN for SMTPor CAPA for POP). Typically, to enable SSL you set this to "*" after getting a certificate. If you don't have a valid certificate then turning this on can cause problems as mail clients will try to use SSL and fail. 

Syntax: g_ssl_allow string

g_ssl_allow_fix - Disable incoming ssl on ssl failure from an ip

This setting has no further documentation currently available

Syntax: g_ssl_allow_fix bool

g_ssl_allow_imap - IP Wild card list to allow SSL encryption from for imap

This setting controls which connecting IP numbers are permitted to use SSL on IMAP.

Syntax: g_ssl_allow_imap string

g_ssl_auto - Generate letsencrpt ssl certificates automatically for all domains

This setting has no further documentation currently available

Syntax: g_ssl_auto bool

g_ssl_ciphers - List permitted ciphers

This can be used to enhance security, not recommended but is useful if you are trying to pass a security audit of some kind. A value of MEDIUM:HIGH is probably what you want to set it to. It is case sensitive. If your list exceeds 800 bytes use g_ssl_ciphers_add for the second half

Syntax: g_ssl_ciphers string

g_ssl_ciphers_add - More permitted ciphers (added to g_ssl_ciphers)

This can be used to enhance security, not recommended but is useful if you are trying to pass a security audit of some kind. A value of MEDIUM:HIGH is probably what you want to set it to. It is case sensitive.

Syntax: g_ssl_ciphers_add string

g_ssl_ciphers_web - List permitted ciphers for web

This list is for web connections only, restart surgemail after changing

Syntax: g_ssl_ciphers_web string

g_ssl_disable - Disable protocols tlsv1,tlsv1_1,tlsv1_2,sslv2,sslv3

This setting has no further documentation currently available

Syntax: g_ssl_disable string

g_ssl_disable_des - Disable DES ciphers, breaks outlook on XP

This setting has no further documentation currently available

Syntax: g_ssl_disable_des bool

g_ssl_disable_port25 - Prevent ssl on port 25

May help virus fire walls to detect viruses, that's the theory anyway...

Syntax: g_ssl_disable_port25 bool

g_ssl_disable_sslv2 - Obsolte, Disable ssl 2.0 support for enhanced security

Disables one of the older ssl protocols which slightly increases security and decreases compatibility with older clients. Use g_ssl_disable and g_ssl_disable_web instead

Syntax: g_ssl_disable_sslv2 bool

g_ssl_disable_sslv3 - Obsolte, Disable ssl 3.0 support for enhanced security

Disables one of the ssl protocols which slightly increases security. Use g_ssl_disable and g_ssl_disable_web instead

Syntax: g_ssl_disable_sslv3 bool

g_ssl_disable_tlsv1 - Obsolte, Disable tls 1.0, not recommended

Use g_ssl_disable and g_ssl_disable_web instead

Syntax: g_ssl_disable_tlsv1 bool

g_ssl_disable_tlsv1_1 - Obsolte, Disable tls 1.1 support, not recommended

Use g_ssl_disable and g_ssl_disable_web instead

Syntax: g_ssl_disable_tlsv1_1 bool

g_ssl_disable_tlsv1_2 - Obsolte, Disable tls 1.2 support, not recommended

Use g_ssl_disable and g_ssl_disable_web instead

Syntax: g_ssl_disable_tlsv1_2 bool

g_ssl_disable_web - Disable protocols for web only

This setting has no further documentation currently available

Syntax: g_ssl_disable_web string

g_ssl_dmalloc - Enable dmalloc tracking in ssl

This setting has no further documentation currently available

Syntax: g_ssl_dmalloc bool

g_ssl_fips - Enable FIPS mode crash if not available (DO NOT USE)

For future use

Syntax: g_ssl_fips bool

g_ssl_honor - Honor server cipher order

Maybe useful to force certain types of security/encryption

Syntax: g_ssl_honor bool

g_ssl_lets_exclude - Domains urls to not update, user must copy from ssl to lets folder

The certifictes must be coppied from the ssl to the lets folder manually!

Syntax: g_ssl_lets_exclude string

g_ssl_lets_path - Path to webservers /.well-known folder for letsencrypt

Use this if you have a webserver that is running on port 80 but you still wish to generate ssl certificates automatically. Folder must be writeable by user 'mail' on linux

Syntax: g_ssl_lets_path string

g_ssl_per_domain - Create/use an SSL certificate for each domain

SurgeMail can be set to use a single SSL certificate for the server or individual certificates on a per domain basis.

SurgeMail will create private key / certificate pairs if required on startup. Alternatively these can be created using the 'SSL Config' link on the global settings page. These can be replaced with your own trusted signed certificates using the web admin interface or by placing the appropriate private key and certificate pem files in the following location: <surgemail>/ssl for a single certificate for the whole server and under <surgemail>/ssl/<vdomain> for per vdomain certificates.

Some mail clients and web browsers will complain if the certificate domain does not match the domain they are connecting to.

Changing g_ssl_per_domain will require surgemail to be restarted to take affect. Changes to certificates using the web admin interface now take affect immediately.

Syntax: g_ssl_per_domain bool

g_ssl_perfect - Apply good SSL settings, best to remove g_ssl_ciphers setting too

Just an easy way of setting the ciphers etc for perfect forward secrecy

Syntax: g_ssl_perfect bool

g_ssl_require - IP Wild card of connections to require to use SSL

This forces all matching IP addresses to use SSL for SMTP, POP and IMAP connections. Typically you would use this for non local connections to increase security local connections might be comparatively safe in un-encrypted mode. 

Syntax: g_ssl_require string

g_ssl_require_imap - IP Wild card of connections to require to use SSL for IMAP

This forces all matching IP addresses to use SSL for IMAP connections.

Syntax: g_ssl_require_imap string

g_ssl_require_in - Local domains that must only receive SSL messages

This setting has no further documentation currently available

Syntax: g_ssl_require_in string

g_ssl_require_login - IP wildcard of connections fur users needing to use SSL

This setting forces all matching IP addresses to use SSL for any action that requires a user login. eg: POP, IMAP and SMTP authentication but not plain SMTP. So this is ideal if you want all users to use SSL but still want email to come in from non SSL SMTP servers.

Syntax: g_ssl_require_login string

g_ssl_require_out - Other machines we only send to using SSL

This forces all matching IP addresses to use SSL for SMTP outgoing connections. Typically you would use this for outgoing connections to increase security. 

Syntax: g_ssl_require_out string

g_ssl_require_web - Require https for most web features (excluding blogs file sharing and surgeplus)

This setting has no further documentation currently available

Syntax: g_ssl_require_web bool

g_ssl_retry_seconds - Second to try and establish ssl connection, default is 5

Best not to change generally

Syntax: g_ssl_retry_seconds int

g_ssl_sha1_sign - Obsolete, sha256 is now always used

This will probably be made the default in the near future

Syntax: g_ssl_sha1_sign bool

g_ssl_test_fail - Break ssl to test auto downgrade

Break ssl for outgoing sends

Syntax: g_ssl_test_fail bool

g_ssl_throttle_renegotiation - Slow renegotiation to prevent simple dos attack.

GEnerally this shouldn't be used unless you have to keep some paranoid security scan happy

Syntax: g_ssl_throttle_renegotiation bool

g_ssl_try_from - Try and start ssl mode if from this user, e.g. *@xyz.com

Must also match the g_ssl_try_out rule, this lets you only do ssl when the email is 'from' certain domains/users

Syntax: g_ssl_try_from string

g_ssl_try_not - Skip ssl for these hosts

If the hosts match then SurgeMail Does not try ssl even if g_ssl_try_out matches.

Syntax: g_ssl_try_not string

g_ssl_try_out - Try and start ssl mode to these hosts

If the hosts match then SurgeMail tries to start SSL security on the SMTP session. Note that this may cause failures if the link is dropped by the receiving server.

Syntax: g_ssl_try_out string

g_ssl_warn - Send users weekly reminder if they keep using non SSL logins

This setting has no further documentation currently available

Syntax: g_ssl_warn bool

g_ssl_warn_ignore - Don't give warnings if user is from this trusted host

This setting has no further documentation currently available

Syntax: g_ssl_warn_ignore string

g_ssl_warn_text - Last line of email warning sent to user if SSL not used

This setting has no further documentation currently available

Syntax: g_ssl_warn_text string

The post Global settings g_ssl appeared first on SurgeMail.

Useful if you must have weak passwords for some reason

Syntax: g_hack_detect_disable bool

g_hack_msg - Message to send to users with a weak password

Message to send to users with a weak password

Syntax: g_hack_msg string

g_hack_noemail - Disable weak password reports

This setting has no further documentation currently available

Syntax: g_hack_noemail bool

g_hack_report - Address to send weak password reports to

This setting has no further documentation currently available

Syntax: g_hack_report string

g_hack_touser - Send warnings about hacking directly to users

Send warnings directly to users

Syntax: g_hack_touser bool

g_hack_url - Url for users to change password

Url to your server for users to change password, if not given the user.cgi url will be generated

Syntax: g_hack_url string

g_hacker_alert - Email manager if address is locked out

This setting has no further documentation currently available

Syntax: g_hacker_alert bool

g_hacker_days - Days to keep ipaddress locked out, default 7

This setting has no further documentation currently available

Syntax: g_hacker_days int

g_hacker_fwd - Email manager if user sets fowarding rule

Useful to identify a spammer trying to set a bounce address to pickup incoming email

Syntax: g_hacker_fwd bool

g_hacker_max - Login guesses for one ip address before we lockout the ip address

Stops hackers from guessing passwords every day until they find one, use tellmail unlock ip.number to unlock, or whitelist it...

Syntax: g_hacker_max int

g_hacker_more - Be more restrictive, don't allow /24 netblocks based on loginip

This setting has no further documentation currently available

Syntax: g_hacker_more bool

g_hacker_password - If hacker attempts to login with account name as password, then blacklist ip

Good for stopping robots guessing accounts

Syntax: g_hacker_password bool

g_hacker_passwords - Failed logins that use these passwords will lockout the ip address

List commonly guessed passwords, e.g. 12345678

Syntax: g_hacker_passwords string

g_hacker_poison - Poison accounts. Instantly blacklist ip address e.g. root@*

If user tries to login with this account then their ip address is blocked from further logins. Give full domain name or wild card, e.g. root@your.domain,staff@*

Syntax: g_hacker_poison string

g_hacker_weak - If user tries weak password, lockout ip address

If someone is 'guessing' weak passwords their ip address will be locked out

Syntax: g_hacker_weak bool

g_hacker_whitelist - Ip addresses to avoid guessing issues

Whitelist for gateways or other systems that you expect multiple failed logins from (e.g. webmail host)

Syntax: g_hacker_whitelist string

The post Global settings g_hack appeared first on SurgeMail.