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.

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.

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.

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.

nft flush ruleset
systemctl mask nftables.service

systemctl stop firewalld
systemctl disable firewalld

service iptables stop
service iptables disable

service ipchains disable
service ipchains stop

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X

cfx -x

reboot - then test if you have succeeded with telnet

telnet netwinsite.com 25

The post Disable your Firewall appeared first on SurgeMail.

%s has %d post office messages
Translation of: %s has %d post office messages
%s password wrong or not a valid user
Translation of: %s password wrong or not a valid user

NOTE CAREFULLY:

1. Never remove any variables (e.g. %s, %d) from a translation, nor change the order in which they appear. This would cause incorrect display of messages, and instability of the product.
2. A language file need not specify all phrases generated by the product. If you don't wish a certain phrase to be translated, simply comment it out or delete it.
3. Never change the original phrase line of any pair, only the translation line. For example, in the default language file, you would only change lines like:Translation of: %s has %d post office messages

How Do I Use Language Translation With DLIST?

When creating your lists.dat file, simply add a language_file setting to each list you want translated. This setting specifies the location of the language file to use for that list. For example:

list newproducts
  title Discussion of new products
  language_file german.dat

The language file to use: dlist_lang.dat

The post DList language translation appeared first on SurgeMail.

Installation instructions:

Install ffmpeg !!!

Install python 3.7 or later (if not already installed). See: https://www.python.org/

python3 --version

Install the google speech api.

Windows: pip install --upgrade google-cloud-speech  
Linux: pip3 install --upgrade google-cloud-speech
Linux: pip3 install --upgrade google-api-python-client

Download the two scripts you need here:

wget https://netwinsite.com/ftp/surgemail/speech.tar.gz
cd /usr/local/surgemail
gunzip speech.tar.gz
tar -xvf speech.tar

Extract and place in your surgemail folder. Then change the line in speech_run.cmd (for windows) to point to your python installation:

APATH=c:\anaconda

On linux: chmod +x speech_cmd.sh speech_submit.py

Add settings to surgemail.ini

Windows: g_speech_cmd "\surgemail\speech_run.cmd"

Linux: g_speech_cmd "/usr/local/surgemail/speech_run.sh"

Limit the conversion to messages from a particular source adderss:

g_speech_from "*@xyz.com"

Create google cloud account

1. Create a google cloud project and grant access to the speech to text API. https://console.cloud.google.com
2. Go to the top of the page, use the drop down menu to create a new 'project'.
3. Go to the top again, and select the new project
4. Click on 'API's and services' then 'Credentials' then +Create Credentials
5. Choose 'Service Account'
6. Select role 'Service Owner'
7. Create credentials, save in surgemail folder.
8. Click on Google Cloud Platform 'top left'
9. Click on API's and Services/ Library
10. Search for 'speech', select Clound speech to text api
11. Click 'enable'

Testing it

First run the python test script to see if your configuration is valid and credentials in your speech.json file are correctly setup.

windows:  speech_run.cmd speech_sample.wav 
Linux: ./speech_run.sh speech_sample.wav

Now examine speech_sample.wav.txt to see if it was created. If not examine speech_sample_wav.err

Things you will need to fix!

• Add full path to ffmpeg command in speech_submit.py if command not in path
• Ensure the google api is installed for user 'mail'.

Next send a message with an attached .wav file, then grep the logs for 'speech' to see how it went. The wav file must be of the correct format (mono wav file).

The post Speech to text conversion 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.

There are two ways of doing this, one is basically copying all the files to the new machine. The second is by setting up a mirror and letting SurgeMail mirror itself over to the second machine.

Automatic method, using Mirroring feature

When upgrading hardware or changing operating systems you can use mirroring to move your installation without disrupting users.

1. Install surgemail on the 'new' system
2. Setup mirroring settings on both systems, the existing system will be 'master' the new system will be 'slave'
3. On the master issue the commands:
   1. tellmail resync_config
   2. tellmail resync_nwauth
   3. tellmail resync_mkdir
   4. tellmail resync
4. Carefully check the new system is working and has all accounts/messages. Use: tellmail mirror_analyze 
5. Move the license key, activate your key on the new system. Best done earlier by emailing netwin with the registration number.
6. Move the users across. e.g. change your DNS or IP addresses so users now connect to the new system.
7. Stop both servers and swap the master/slave settings so the new system is the master.
8. To ensure aliases are working on the slave copy domuser.dat from master to slave manually!

Manual method to move SurgeMail

1. Install SurgeMail on new machine
2. Setup anything you tailored on the original system (e.g. authent modules)
3. Stop SurgeMail on new machine
4. tellmail deactivate on old machine
5. Stop SurgeMail on old machine
6. Copy surgemail.ini from old machine to new machine /etc/surgemail.ini or \windows\surgemail.ini
7. (note all other paths you need are defined in surgemail.ini, particularly g_home and mailbox_path)
   
8. Copy the SurgeMail directory, the mail directory and the database over to new machine.
   Check surgemail.ini for the paths to copy for the mail directory (g_mailbox)
   The default database is nwauth which will be stored in the surgemail directory but consists of the files (nwauth.add, nwauth.txt). The exact file paths depend on your system search for "mailbox_path" and "g_home" in surgemail.ini to find the paths in question.
9. Check surgemail.ini and check everything is located correctly. Change all the paths if necessary
10. Chown -R mail files (if on UNIX) for all mail folders etc...
11. Start surgemail on new machine, check logging in etc
12. tellmail activate on new machine
13. If you have moved from one OS to a different OS then you should run the installer on the new server again so that it places the correct binaries on the new system.

Merging one or more domains from one SurgeMail server with Another:

1. The Vdomain sections for each domain from the old system and append to surgemail.ini on the new system.
2. copy mailbox_path directory tree for each domain from old to new system.
3. grep nwauth.add and nwauth.txt for the domain(s) in question, and append those lines to nwauth.add on the new system.
   grep xyz.com nwauth.txt nwauth.add >nwauth.append (then copy and append that file)
4. If you have dlist mailing lists on the old system:
5. append dlist/lists.dat from old to new system.
6. Copy existing dlist/listname folders and contents from old to new system.

For a large active system you might use rsync or multiple copy commands to get the two exactly in sync before the changeover (for mailbox_path data).

Moving an existing mirror pair

In this situation you must first turn off mirroring to the existing slave, remove access to it, and then commence with the regular instructions above to create a new mirror in the new system. Then finally create a new 'mirror' from the mirrored system after setting it as the master:

• Upgrade the existing system to the current surgemail release
• Install surgemail on the new master server
• Disable failover/user access to the existing SLAVE system, shut it down to be sure!!!
• On the existing master point g_mirror_host at the new master server ip address.
• On the new 'master' server configure it as a slave to the existing master:

g_mirror_nossl "TRUE"
g_mirror_mode "secondary"
g_mirror_host "MASTER.IP.ADDRESS"
g_mirror_secret "MUSTMATCHMASTER_SECRET" 
g_mirror_config "true"
g_mirror_live "true"

• Start mirroring from the existing master to what will 'become' the new master:
• tellmail reload
• tellmail resync_config
• tellmail resync_nwauth
• tellmail resync
• tellmail resync_mkdir
• tellmail resync_folder train
• tellmail resync_folder lets
• tellmail resync_folder dlist

Wait for the mirroring to complete.

Use: tellmail mirror_status to watch progress, then when it's complete use: tellmail mirror_analyze to check mirroring is complete.

Test the new system to ensure it's working, manually check an account.

• remove g_mirror settings from OLD master system, and then shut it down.
• set g_mirror_host on the NEW master system to point to the NEW slave.
• set g_mirror_mode on the NEW master to "primary" and restart surgemail.
• re-assign ip addresses to move users onto the new master system.

Now add the new 'mirror' server. See instructions https://surgemail.com/knowledge-base/mirror-setup/ for adding a mirror.

The post Moving or Migrating SurgeMail to a new system appeared first on SurgeMail.

This provides surgemail standalone CalDAV calendaring support (including calendar sharing) for mobile devices and desktop clients.

If it needs to be specified the full caldav url is:

http://yourserver.com/cal/principals/email@domain.com

or some servers may expect:

http://yourserver.com/cal/calendars/email@domain.com

Username needs to be full email@domain.com and password is your normal email account password. Configuration walkthrough of some sample clients below:

SurgeWeb as a CalDav calendar client

SurgeWeb now supports CalDav integrated "drag and drop" calendaring from the surgeweb ajax interface. Provided this is enabled on surgeweb customisation page, no surgeweb configuration is needed

Key features include:

• Calendar synchronisation with mobile clients
• Calendar sharing between mutiple accounts
• Define multiple additional calendars
• Configure alerts that will trigger on mobile devices
• Repeat event support

(click screenshots to enlarge)Additional features include:

• Support for: Day, week, month and year views
• Customise display color per calendar
• Point & click / drag & drop event manipulation
• Single key stroke switching between: date range and scale (one or more modifier keys plus arrows)

Configure Calendar Sharing using SurgeWeb

Surgemail CalDAV calendaring will allow you to specify one or more calendars for each email account. Each of these calendars may be shared with other caldav users on the same system. Sharing is configured using the surgeweb interface (surgeplus calendaring page).

Calendars can be shared with the following permissions, and displayed to the person you are sharing it with as:

• read / write access: displayed as "Calendar Name | Owner (RW)"
• read access: displayed as "Calendar Name | Owner (R)"
• free / busy access: displayed as "Calendar Name | Owner (B)"

iOS Client Configuration

Standard account configuration under iOS should simply be a case of adding a new calDAV account and correctly filling out the server, fully specified email address as user name and the password:

In addition you may need to accept non ssl based connections if you do not have a CA signed SSL certificate and specify the server port if this is non standard :

iOS will automatically detect the full caldav url, and automatically detect any calenders you have already got defined under the server on your account. Any calendars others have shared with you will also be automatically detected and displayed in your list of calendars.

OSX iCal Desktop Client Configuration

iCal will also automatically detect the full caldav url and all calendars based on valid username, password and server address settings. Again you may need to confirm acceptance of non ssl based connections if the server does not have a valid SSL certificate setup.

Windows Lightning Thunderbird Extension Configuration

Lightning has been tested and seems to work well as a free windows desktop CalDAV client with surgemail CalDAV calendaring. Setup is slightly more involved as it does not seem to autodetect the caldav url or calendars. (there may be ways around this - let me know if you find them)

To connect to existing calendars, use the surgeweb interface to copy the full url of any of your available calendars (or create / share calendars as needed), then add this as a new network calendar in Lightning:

Android calendaring client

Android "CalDAV-Sync" (no endorsement for this particular product and netwin is not affiliated with the developer in any way) has been tested to successfully allow surgemail CalDAV calendars to be used using the native android calendar client.

To configure, just login using the url of http://yourserver.com:port/cal as the url and email address and password and all existing calendars should get detected.

Other CalDAV Clients

A variety of other CalDAV clients are available and may suit your needs better than the above listed clients.

For administrators also see caldav server configuration.

The post CalDAV client configuration appeared first on SurgeMail.