You can unsubscribe by sending an email to newsletter-leave@netwin.co.nz or via https://netwinsite.com:7025/list/newsletter@netwin.co.nz

As per usual much of our focus has been on stability and reliability, and fullfilling customer requests, however most of these you don't need to know about as you get the improvements simply by updating.

Be sure to check the config checker page to see new features that can be enabled as new features are rarely enabled automatically (since we insist on 100% forward/backward compatibility). Lets hilight some important/useful items:

g_phish_block

Basically this keeps track of links in email messages and any that it doesn't recognize as 'safe' it replaces with a link that goes 'through' your website, to first warn the user that they are following a link which may or may not be safe. It's a simple feature to greatly reduce the risk of users falling for phishing or other scams. (Please update to the latest release before using this!)

DKIM & SPF

Many major email providers are now requiring DKIM/SPF so if you have not yet added your own DKIM/SPF settings you should. Essentially you need to turn on dkim signing, and add the DNS entries that surgemail then tells you to add (on the dkim config page). See: https://surgemail.com/knowledge-base/sending-email-to-avoid-spam-filters-best-practices/

Config Checker tests

On the main web page, and on the config test page you will now find some links to test your server for various common config issues. This helps you quickly assess if you have your PORTS/DKIM/SPF/DNS entries setup reasonably well or not.

Smtp Smuggling - Security issue

A new type of SMTP attack was recently discovered whereby a message can be hidden at the end of a normal email message, and the hidden message will be injected into the destination email server as if it was sent by the sending email server. SurgeMail was also open to this type of attack (because we implemented the same extension to line endings followed by other major systems for compatibility).

The end result of this attack is generally not particularly significant, as it only really allows an already trusted sender to send a slightly more hidden message that may be hard to trace. It's well worth closing this loophole so please update to version 77m currently in beta release: https://surgemail.com/beta-downloads/ when it's convenient.

SSL Updates

SurgeMail includes a version of OpenSSL, and we update it in our build once every year or two, if you are running a version of surgemail more than 12 months old then it's wise to consider upgrading to fix this.

Lets Encrypt

note: If you are still paying for SSL certificates, please be aware that you really don't need to, the built in LetsEncrypt code in SurgeMail can create genuine SSL certificates for all your domains at no cost. The only requirement is that the url in question does point to the SurgeMail server and is accessable on port 80.

Unsubscribe

You can unsubscribe by sending an email to newsletter-leave@netwin.co.nz or via https://netwinsite.com:7025/list/newsletter@netwin.co.nz

You were added to this list as a customer who has installed SurgeMail at some point in the last few years. We appologize if you are not currently interested and encourage you to unsubscribe.

The post News Letter January 2024 appeared first on SurgeMail.

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.

If you have no choice, then you should use this patched version which fixes some serious performance issues. Specifically it's more efficient and has some better defaults.

note: Z-Push is not actively supported, neither is ActiveSync, these are obsolete and should be avoided.

What did we fix? (cough improve)

• Most of these faults relate to 'real' systems, with many folders, each containing thousands of messages of various sizes. On test systems these issues would not show up. On real systems it was simply broken.
• Memory setting added to override random default on the system.
• Memory headroom increased so it won't run out of memory when reading a single large message
• Setting added to define the max size message that can be safely processed.
• Messages above max size are not fetched!
• When trying to find the list of existing messages in a folder, the original implementation would scan the headers of every message in the folder. When no headers are needed!
• Built in 'incredibly inefficient' overview imap command replaced with efficient one that just lists flags and uid's.
• When updating folders the original implemenation would scan every folder on the system, (and scan the headers of every message in every folder). And then repeat that step for each block of 100 messages. Now it remembers which folder it was updating.
• Enforced more conservative timeout limits. This helps reduce the chance of multiple duplicate updates being initiated by an impatient client.
• Actual imap 'idle' command implemented so it can detect new messages in the INBOX efficiently.
• While updating once a limit is reached the next update of all folders will continue at the one it was on rather than scanning all other folders 'again' first
• We added the following php library to handle imap more efficiently: https://github.com/petewarden/handmadeimap

How to install over an existing z-push installation

wget https://github.com/chrispugmire/Z-Push/archive/refs/heads/develop.zip
unzip develop.zip
cd Z-Push

php install.php

How to install this version of z-push from scratch

mkdir /var/share/z-push
mkdir /var/lib/z-push
mkdir /var/log/z-push
wget https://github.com/chrispugmire/Z-Push/archive/refs/heads/develop.zip
unzip develop.zip

cd Z-Push
php install.php # this coppies the files to /usr/share/z-push, it doesn't overwrite existing config.php files!

# repace www-data with the account that apache runs as!
chown -R www-data /var/lib/z-push /var/share/z-push /var/log/z-push

# apache2 config ubuntu...

cp Z-Push/config/apache2/z-push.conf /etc/apache2/conf-available
cp Z-Push/config/apache2/z-push-autodiscover.conf /etc/apache2/conf-available

a2enconf z-push.conf
a2enconf z-push-autodiscover.conf
systemctl reload apache2

Adjust the config files.

cd /usr/share/z-push
edit config.php
     # add new settings
     ini_set("memory_limit","256M"); 
     define('MAX_MSG_SIZE',20); //  Units=MB

     # set backend provider inf config.php if not already set correctly...
     define('BACKEND_PROVIDER', 'BackendIMAP');

# set imap settings if not already set correct! 
edit backend/imap/config.php
     define('IMAP_SERVER', 'YOUR.MAIL.SERVER');
 

Surgemail Settings you should check

This significantly improves performance:

g_imap_status_stored "true"

Test APACHE config is working

https://[your-server-name]/Microsoft-Server-ActiveSync

Now configure Outlook to use ActiveSync

This is hard to do because it's not in the normal outlook account setup, to get to the active sync option you do this:

Control Panel/ search for Mail / choose "Email Accounts" / choose "New" / Manual / Exchange ActiveSync...

Now check the logs

cd /var/log/z-push

tail -1000 z-push.log

tail z-push-error.log

Run the monitor to see what z-push is doing

/usr/share/z-push/z-push-top.php

Commands that 'might' unjam a stuck z-push

# These two seem fairly safe and are a reasonable first thing to try...
/usr/share/z-push/z-push-admin.php -a clearloop

# commands that would reset zpush completely, (not recommended)
/usr/share/z-push/z-push-admin.php -a remove -u user@domain.name

# manually fix states (causes refetch of all messages)
/usr/share/z-push/z-push-admin -a fixstates

# completely WIPE the zpush state folders...
rm -r /var/lib/z-push/*

# If all else fails delete the account from exchange and recreate it! This often gets rid of a whole bunch of errors. 

The post Z-Push (ActiveSync) appeared first on SurgeMail.

1. Use the config checker and apply the recommended settings
2. Make sure you have g_friends_safer "true"
3. Make sure you ahve g_responder_safer "true"

In addition you should consider banning forwarding settings to problem domains, e.g.
forward_illegal to="*@gmail.com" apply="user"

This rule prevents users adding a forwarding rule to a gmail account. You might do this if gmail is seeing incoming forwarded spam from your server and blacklisting it.

The post Back Scatter (Backscatter) appeared first on SurgeMail.

This file contains only basic settings in the form:

<setting_name><space><setting_value>

e.g.

quota_default 100mb
ssl_require_login true

The post Domain defaults appeared first on SurgeMail.

g_oauth_client_id "idcode"

g_oauth_client_secret "secretcode"

g_oauth_trim "true" - Trim @domain.name from user before lookup

g_oauth_url "http://your.oauth.endpoint/oauth.php"

g_authent_lookup "true" - If set then oauth is used as password check as well as account existence.

With the above settings surgemail will use nwauth to store most details about user accounts, but will check for existence, and passwords with the oauth server.

The post Oauth 2.0 support appeared first on SurgeMail.

Create a Twilio account

https://www.twilio.com/try-twilio

(Note the above link is a referral link).

Copy your SID, Token and Phone number.

Login to your Twilio console, on the dashboard you will find:

And if you go to the phone numbers tab, you should have a phone number, if not you will need to add one:

Copy these three things into your surgemail.ini settings:

g_twilio_from "+13xxxxxxx"
g_twilio_sid "ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
g_twilio_token "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Test the SMS gateway is working

tellmail sms_test +1nnnnnnnnn (your cell phone number)

Within 30 seconds you should get a test message.

Configure your personal phone number

Lookup your account, click on 'password' and configure your SMS number, or in the admin console just fill in the 'sms_to' setting, be sure to specify your full phone number including + and international code, e.g. for U.S. numbers +1.... for New Zealand it would be +64....

https//your.server/cgi/user.cgi

Test the SurgeWeb forgot link

Now if you go to surgeweb login and press 'forgot' you should be able to use an SMS confirmation to reset your password:

http://your.server/surgeweb

Add SMS notification rules

First add user_sms "true" to each domain:

user_sms "true"

Lookup your account, go to the 'sms' config page, and add a rule.

if Subject contains Urgent

Now send yourself an email with the subject "Urgent issue". It should arrive on your phone.

Configure a quota rule

Add a default number of messages per user per day, this is a domain level setting so will need to be added to each domain:

user_sms_quota initial="10" period="24"

Typically SMS messages cost about 1 cent, so factor this into your cost structure to decide what sort of limits you need. This limit only applies to the notify feature. Password resets do not count against the users SMS quota.

The post SMS Twilio Gateway appeared first on SurgeMail.

Typical usage to move users from http to https automatically, e.g. g_url_redirect from=”http://*/surgeweb” to=”https://%1:7443/surgeweb” ports=”80,7080″

Or you may wish to change the default page to webmail, e.g.

g_url_redirect from=”/” to=”/surgeweb” ports=”443,80″

Syntax: g_url_redirect from=string to=string ports=string

The post g_url_redirect 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.