On NT, type in: net start surgemail
On 95/98, type in: /surgemail/surgemail
On Unix, type in: /usr/local/surgemail/surgemail_start.sh
To start it remotely use SurgeMail monitor on http://your.mail.server:7027
Use your web browser and type in a link like this: https://your.mail.server:7025 If you are on the machine itself this link should work https://127.0.0.1:7025
*nix systems you need
to go to the shell and type
cd /usr/local/surgemail
./surgemail -password
Windows systems you
need to go to the command prompt
cd \surgemail
surgemail -password
Not normally no, the reason for this restriction is that the web interface allows you to modify config settings in a nice and safe manner, as a result the ini file needs to be re-written, and if it was composed of include files it would be difficult, dangerous and very nearly impossible to write it out correctly after a change.
However, you can do it
if you want, but if you put an 'include full_path/file.ini'
directive in surgemail.ini then any call to save the ini file
will silently fail (so your web admin will just seem to work but
won't really). Also note, if you create an ini file with 10,000
include files in it, and it takes 3 minutes to reload it, we
will not have any sympathy for you (we've seen this done before
really!)
Lets be really clear,
never do this, split domains are a dumb idea, the whole point of
the 'domain' is to allow systems to figure out where the domain
is hosted, so splitting your users between two systems with one
domain is breaking the whole principle on which email is
based. Splitting a domain will come back and bite you one
day soon, and make managing your system and tracking down faults
virtually impossible. :-). The correct solution is to
move the other users to a new domain name (e.g. fred@xxx.your.domain).
Then it's easy, and you can add some redirection rules to make
it almost invisible. e.g. people who send to
fred@your.domain will have the email automatically forwarded
to fred@xxx.your.domain for the users that exist on the other
system.
So, you still want to
do it the wrong way...... :-)
In the web manager click on the 'Register' link on the navigation pane.
Alternatively run
tellmail activate on the command line with your registration
details:
tellmail activate N123
myemail@mydomain.com
This is a bug in Netscape. It steals all the CPU while waiting for a web page to arrive but since the server is on the same system that means it responds slowly. You can fix it in task manager: set the priority for Netscape down to 'below normal' and suddenly it will work faster! Or upgrade to a fixed version of Netscape.
It should never be necessary to stop swatch manually as swatch is designed to keep running so that SurgeMail can be restarted using the web interface. But, if for any reason the SurgeMail monitor process needs to be manually stopped create the mon.exit file in the SurgeMail directory and swatch will shutdown.
The number of
concurrent users is operating system dependent and basically a
matter of how many threads and file handles the operating system
supports. Here are the approximate figures-
| Operating system | Concurrent mail sessions (these are not hard limits) |
|---|---|
| Windows NT | 1,500 |
| Linux | 500-1000 on
early versions more on recent kernals that do not have handle or thread limits |
| Solaris 7 |
500 |
| Solaris 8 | 2,000 |
In the SurgeMail directory create a file called quota.eml, something like this (this requires SurgeMail 1.3m or later):
Subject: A new quota message 4securemail.com reason: max= used= size= This is the quota message for domain: 4securemail.com ends here. |
Which will look something like this for the user:
Subject: A new quota message xxx.yyy.com reason: Quota exceeded 250000>200000 max=200000 used=190000 size=60000 This is the quota message for domain: xxx.yyy.com ends here. |
SurgeMail uses mdir format to store mail which cannot be read by mail clients that read the mail drop file directly. The "Deliver" mail delivery robot can be used to deliver mail to a drop file:
Deliver is available from sourceforge.net and can be configured in SurgeMail using a mail redirection rule in surgemail.ini as per:
g_redirect
was="marijn@mydomain.com" to="|./deliver -b
/var/surgemail/mydomain.com/hd/fg/marijn/dropfile"
SurgeMails main configuration file is surgemail.ini which is store in /etc on UNIX systems and your Windows directory on Windows systems (eg c:\winnt). This file can be edited by hand after which a "tellmail reload" would need to be issued or edited via the web interface. Backups of this file are stored in the SurgeMail directory as ini_YYMMDD.rec.
WebMail has a separate configuration file stored in surgemail/scripts/webmail.ini.
If WebMail is using
IMAP to talk to SurgeMail this can be enabled using the
following setting in webmail.ini. (This is now enabled by
default but used to be disabled by default)
enable_inbox_transfer "true"
This just means WebMail could not talk to SurgeMail. There could be several reasons. The most likely reason is that SurgeMail does not have the correct settings in the event that your domain name is different from your hostname eg mydomain.com vs mail.mydomain.com see for more detail
Check your webmail.ini file, surgemail/web_work/surgehost.ini and surgemail.ini for possible misconfiguration of individual domains.
The online help is the primary documentation this is distributed with every SurgeMail download and the latest version is available online. An automatically generated pdf version is also available.
Different WebMail templates may be installed. The Surgemail + Webmail distributions come with three template sets by default (Panel, Surge and Smooth). Several additional template sets are available but most of these have a rather out of date "look and feel" to them and or do not supply all the functionality now supplied by webmail and surgemail (these include marble, iconic, vanilla).
Several examples of the
flexibility of the webmail look and feels can be found on the
the following pages:
https://netwinsite.com/surgemail/templates.htm
https://netwinsite.com/webmail/gallery/index.htm
All that is required to
install a template set is to add the actual template files to
the directory surgemail/webmail/templatename, the images to
surgemail/www/nwimg/mail/template name and add one line to
webmail.ini defining it. eg:
tpl_set 2 E:\surgemail\webmail\marble /nwimg/mail/marble Marble
Set (Marble)
SurgeMail installs a sendmail stub. This will allow your PHP scripts and the like to continue sending mail using the same syntax they have always done. You will need to ensure SurgeMail is allowing relaying for your local IP. If it is not working pass the stub the "-debug" parameter it should create a sendmail.debug file that will give you information as to why it is not working.
This means that DNS resolution of an address failed and can be for one of several reasons:
1) Wrong server
being used
2) Server is not responding or firewall / router is blocking
TCP port 53
SurgeMail will
attempt to use the DNS settings of your operating system for
its name resolutions. If this is not working for some reason
you can manually force SurgeMail to use particular dns servers
using the setting g_dns_host setting.
eg. where the IP numbers are the ip addresses you wish to
force SurgeMail to use.
g_dns_host
"1.2.3.4,2.3.4.5"
note: You must restart SurgeMail when changing g_dns_host
SurgeMail provides status information on the DNS servers that it uses in on the status page on the web interface.
If this still fails it may be that the DNS server is faulty and is not responding or that a firewall or gateway is blocking TCP port 53 access. (some OS services only require UDP access which is why your firewall might be blocking TCP traffic on port 53) To test this telnet to your DNS server as per "telnet your.dns.server.ip 53". If this does not connect this is the problem. If this does connect then your DNS server is working fine.
Set the setting g_dns_paranoid to false i.e.
g_dns_paranoid "false"
And restart SurgeMail. If the problem persists contact surgemail-support@netwinsite.com.
Users can be added on
the command line as follows (You need to run the path etc for
your authentication module as specified in surgemail.ini)
./nwauth -path . -set username@domain password
Alternatively for a
more efficient process create a text file of nwath
commands and pipe it to nwauth as follows:
>>Start of file nwauth.in<<
set user1@domain.com password
set user2@domain.com password2
set user3@domain2.com password3
>>End of file<<
./nwauth -path . < nwauth.in
or for list of nwauth
command lin commands:
./nwauth -help
In new versions built
later than the 25th of April 2004 you can now use a tellmail
command
tellmail add_user <user@domain> <password>
This automatically uses the correct authent module etc
Yes, a pdf version of
the online help can be downloaded from:
https://netwinsite.com/ftp/surgemail/doc/surgemail.pdf
This depends on the services you wish to offer, but in principle the main ports you will need open to TCP traffic are:
53 DNS lookup for outgoing mail
110 POP3 services (Also used for mirroring)
143 IMAP services
25 SMTP services
587 SMTP Local Users
443 HTTPS
80 (or 7080 if port 80 is already in use) Webmail HTTP access
7025 Administration HTTPS access
SurgeMail also uses the following
995 Secure POP3 services
993 Secure IMAP services
465 Secure SMTP services
7110 SurgePlus
7443 Secure Webmail HTTPS access
7026 Administration HTTP access
7027 Monitor HTTP access
Note for 'firewalld' (Linux)
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>Surgemail</short>
<description>This option is for Surgemail from Netwinsite.com</description>
<port protocol="tcp" port="25"/>
<port protocol="tcp" port="106"/>
<port protocol="tcp" port="110"/>
<port protocol="tcp" port="143"/>
<port protocol="tcp" port="465"/>
<port protocol="tcp" port="587"/>
<port protocol="tcp" port="993"/>
<port protocol="tcp" port="995"/>
<port protocol="tcp" port="7025"/>
<port protocol="tcp" port="7026"/>
<port protocol="tcp" port="7080"/>
<port protocol="tcp" port="7110"/>
<port protocol="tcp" port="7443"/>
</service>
The usage is:
cp surgemail.xml /usr/lib/firewalld/services/
firewall-cmd --add-service=surgemail --zone=public --permanent
firewall-cmd --reload
SurgeMail version numbering is setup as follows <Number>.<number><letter>[optional number] - <build number> eg 1.5a - 12
Updates.htm documents changes since the last production release whenever a new version is released as a likely production release candidate.
Prior to version 1.5a this was defined slightly differently.
In surgemail/webmail.ini ensure the settings for IMAPhost and SMTPhost point to your actual server and not a domain that resolves to some other system, or doesn't resolve at all eg:
smtphost localhost imaphost localhost
Yes. In some cases it might be beneficial to run the WebMail CGI on a different machine, to do this, simply install WebMail on the other machine see the WebMail documentation on how this is done. Then in addition to the normal configuration requirements, eg: pophost smtphost etc you need to configure these WebMail settings:
use_id_autologin true friends_only trueAnd these surgemail.ini settings:
autorespond true netwin_autologin_id 0 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_load_pass&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 1 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_load_fcommon&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 2 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_load_fwd&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 4 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_spam_load&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 5 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_load_centipaid&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 6 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_sms_load&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text netwin_autologin_id 7 https://surgemail.server.com:7025/cgi/user.cgi /var/spool/webmail lcmd=user_listmb&vhost=&webmail=true& bgcolor=cust_panel_bgcolorhref_text&thcolor=#D6D6CEhref_text
g_autologin_pop "TRUE" g_webmail_url "http://other.server.com/scripts/webmail.exe"
In addition for every domain you add to SurgeMail you will now manually need to update webmail.ini with the domain details, see the WebMail documentation on "Virtual Hosts" for how this is done.
The avast installer in integrated to SurgeMail web admin interface - just press the install and uninstall button on the globals page.
There should not be
the need to manully install Avast but if necessary this can be
done by: downloading the installation package from ftp://netwinsite.com/pub/surgemail/util/avastoem.exe
running the command line:
avastoem.exe /oem "SurgeMail"
and making sure it is installed into the SurgeMail\Avast
directory.
Again there should not be the need but to manually uninistall just delete all the files and subdirectories in the \surgemail\avast directory other than surgemail\setup\setupif.dll which is required to install again via surgemail web admin. In addition you need to delete the registry key :HKEY_LOCAL_MACHINE\SOFTWARE\ALWIL Software\Avast\SurgeMail and all entries within it.
This allows SurgeMail to listen on a specified port and IP, you can add multiple IPs if you wish to listen on more than one and multiple ports also.
eg:
g_smtp_port "1.1.1.1:25, 2.2.2.2:1025"
You can check the status page and check how many viruses have been caught. You can also send a test virus through which can be got from www.eicar.org, and then of course there are the logs you can check.
In surgemail.ini add the following setting then restart.
g_bind_out "x.x.x.x"
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.
See this
page for the mirroring method (recommended)
On Windows you can just use something like winzip to copy everything, on UNIX based platforms you can use tar and gzip or whatever you prefer.
To restore a backup
If you are moving SurgeMail to a new machine you can check this guide http://www.netwinsite.com/surgemail/help/faq.htm#moving_surgemail
If you need to send your mail via another SMTP server then you can use the gateway setting. This setting lets you choose which domains to send to a server so you can send one domain to one server and another domain to another server or you can send all domains to one server. This is useful if your ISP won't allow you to connect to port 25 on remote machines or if you are on cable/DSL and domains like AOL won't accept mail from you because of this so instead you can send all your mail through your ISPs mail server.
Example 1: Sending all
mail through a differerent server
g_gateway domain="*" to="ip of server to use" relay="false"
If you need to authenticate on the server you are going to use
you can do this
g_gateway domain="*" to="ip of server to use" relay="false"
user="user to auth with" pass="password of user"
Example 2: Sending mail going to AOL via a different server
g_gateway
domain="aol.com" to="ip of server to use" relay="false"
You can add SMTP AUTHentication like in example 1.
You can find more information on using the gateway setting here g_gateway
If you have a virus scanner like Nortons installed with Auto Protect enabled, you should disable the auto protect feature which will seriously kill performance of the mail server (e.g. it may run 100 times slower). Also if you have your virus scanner enabled for incoming/outgoing mail you should disable that as well as it could easily break the mail server protocol in unexpected ways.
SurgeMail has a virus scanner option 'avast' which should be used for scanning for viruses in mail messages, it is much much more efficient as it is properly integrated.
If you have a virus scanner like Nortons installed with Auto Protect enabled, it may lock access to webmail files, this will prevent webmail from deleting the message file, this then upsets the user :-). So let me repeat, don't run a virus scanner on your mail server, instead use a scanner inside SurgeMail. (e.g. avast)
Applies to Windows 2000
PROBLEM: You can not have SurgeMail and IIS SMTP Virtual Server listening on the same TCP port 25. The IIS SMTP service listens to port 25 on all unassigned IP addresses, even though you specify a specific IP address for the SurgeMail server. You need to disable the MS IIS socket pooling feature (DisableSocketPooling). This property is not exposed in ADSI for SMTP.
This works for IIS also, just substitute SmtpSvc with the W3SVC
SOLUTION:
Usually this is one of the following
So first check that you can connect locally to the server. At the command prompt on the server type
telnet localhost 25
You should receive a
welcome message like this
220 mydomain.com SurgeSMTP (Version 3.1b-1) http://surgemail.com
If you get unable to connect then it's probably due to a firewall running on that machine that is stopping surgemail.
If you are running
SurgeMail on a Windows operating system you can restart
surgemail and then check mail.log and check it says
"03 10:32:22.89:Info:2156: Listening on (all interfaces:25)"
You can use this page
to help test sending mail to your server.
http://email-test.com
You need to check that you have the port open for SurgeMail to the DNS.
Port 53 TCP and UDP
You can test the DNS is working and SurgeMail has access to it by going to the shell or command prompt and typing
nslookup
server= <ip of DNS>
set type=MX
netwinsite.com
Don't type the angle brackets :).
You should then get a response back looking like this:
netwinsite.com MX preference = 10, mail exchanger =
mail.netwinsite.com
You can then type exit to exit the nslookup program.
Once you have tested that it works you can make sure SurgeMail is
using this DNS.
Login to the SurgeMail webadmin and in the setting search box type
g_dns_host
then edit that setting and put the ip of your DNS in there.
Then click save, then completely stop surgemail and restart it.
You should now be able to send emails without dns problems, there
will be times when you will get some dns lookup failures of
course.
Yes you can!, there are several ways in fact.
If anyone knows of a free proxy support module for IIS let us know. There is one that could be tried http://www.isapirewrite.com/ but this is commercial, however they do have a trial period I believe.
Options 1 & 3 are the recommended ones and easiest.
Here is exactly how you would do option 3
In this example we will use the domain "test.com" test.com is already running a website and we want to add a subdomain webmail.test.com which will go directly to webmail.
So you will need to edit httpd.conf which is found commonly in /etc/httpd/conf
If you skip to the end you will find the virtual domain setup, basically you would have something like this
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.test.com
DocumentRoot /var/www/html
</VirtualHost>
<VirtualHost *:80>
ServerName webmail.test.com
ProxyPass / http://127.0.0.1:7080/
ProxyPassreverse / http://127.0.0.1:7080/
</VirtualHost>
That's it, the first virtualhost block is your default domain and
should match your DocumentRoot setting in httpd.conf.
The second block is where we setup webmail.test.com and then use
the proxy module commands to forward requests to that domain onto
the SurgeMail webserver which by default listens on port 7080
If you receive a warning about cookies not getting passed in, you may need to configure the following setting too:
ProxyPassReverseCookieDomain 127.0.0.1 webmail.test.com
note: ProxyPassReverseCookieDomain does NOT take a port number.
If you are configuring multiple domains through a virtual host configuration and are having trouble with them not getting resolved you may need to use the apache configuration setting:
ProxyPreserveHost On
You can find full documentation on virtual domains for Apache here. http://httpd.apache.org/docs-2.0/vhosts/
This is very easy to do.
Now when you browse to http://webmail.test.com you should go
direct to the webmail pages
If you have any problems please email us at
surgemail-support@netwinsite.com
There are many situations where duplicate messages can occur. Specifically when one server has sent a message but before the receiving server says 'I've got it' a bunch of tests are performed, if these take too long the connection may timeout. In this situation the sending system will resend, but the receiving system believes it has the message and says "I've got it". Big delays like this should not occur normally with surgemail so would be a sign of something
There are many situations where duplicate messages can occur. Specifically when one server has sent a message but before the receiving server sais 'I've got it' a bunch of tests are performed, if these take too long the connection may timeout. In this situation the sending system will resend, but the receiving system believes it has the message and sais "I've got it". Big delays like this should not occur normally with surgemail so would be a sign of something wrong.
Also mail clients set to 'leave messages on the server' can get confused in some instances and refetch messages, this also shouldn't happen though. Examine the msg*.rec delivery logs to determine if a duplicate was delivered twice or just 'read' twice by the client.
Here are some general things to check:
Check if you have a virus scanner on your system or client, if so remove it and see if that fixes it, virus scanners regularly break the smtp protocol :-)
If your dns is sluggish surbl may be taking too long: g_surbl
name="multi.surbl.org"
stamp="sc.surbl.org,ws.surbl.org,phishing,ob.surbl.org,ab.surbl.org,jp"
Check the following settings which are all potentials for 'delays' which might cause this problem. g_badfrom... g_mx_verify...
Capture the thread in mail.log of an incoming message that takes a long time, then scan down the time stamps to find the 'biggest' gap in time, then you should see the cause.
Here are some links with things to check and notes on outlook issues:
There are several steps involved as there are various whitelists, for RBL's , ASPAM etc. RBL's & ASPAM
g_orbs_late "true" (allows
RBL based exceptions based on rctp and from address)
g_spf_skip_to "*@domain"
(applies to RBL's and ASPAM)
g_spf_skip_from
"*@domain" (applies to RBL's and ASPAM)
g_smite_skip
"*@domain.com" (applies to smite scoring and thus friends - this
is the source domain)
g_smite_skip_to
"*@domain.com" (applies to smite score & friends - this is
the destination domain)
If you know the IP's of the domain you want to whitelist you can
also whitelist based on them.
g_spf_skip "ip" - skips spf
checks for emails from this ip
g_orbs_exception "ip"
- skips RBL checks for emails from this ip
g_mfilter_skip "ip" -
skips mfilter processing for emails from this ip
g_spam_allow "ip" - skips
spam throttle limits, ideal for the ip address of a mailing list
server.
To whitelist an ip address use:
g_user_send_white "1.2.3.4"
g_gateway_allow "1.2.3.4"
g_iplimit_whitelist "1.2.3.4"
g_spam_allow "1.2.3.4"
g_con_perip_except "1.2.3.4"
SurgeMail replaces the sendmail binary with a sendmail stub, this basically pretends to be sendmail and redirects everything to SurgeMail. Your programs should not have any problems but sometimes there are.
Create a file called sendmail_surge.ini in /etc on *nix or the windows directory on Windows.
in this file add the following settings
host 127.0.0.1
debug true
Then try sending a message with the sendmail binary
/usr/sbin/sendmail -debug
From: yourusername@yourdomain
To: user@whateverdomain
Subject: test
This is a test
.
You can then view sendmail.debug to check what has happened. If
you still have problems please send us the sendmail.debug log
and also the output from a
/usr/sbin/sendmail -version (surgemail-support@netwinsite.com)
There are several ways this can occur. Basically there is a known 'issue' with smtp where a timeout/failure during the 'data' stage after the 'dot' is sent by the sender, can result in the receiving system thinking it's got the message while the sending system thinks it failed to send it so retries.
Usually this occurs due to something slightly odd going on like a virus scanner interposed in the channel which is causing a multi minute delay while it accepts the message from one end but doesn't send it on to the other end.
So, first, you need to identify where the duplication occurred, in the surgemail logs find the message id in question and you will see if it was received multiple times or not.
Then go backwards to the source till you know where the duplication is occurring, then on both systems in question (the sender or mail client and receiving mail server) look for virus scanners and smart spam filters that might have caused an issue. And increase any timeouts you can see, in surgemail the timeouts you can increase are:
G_SEND_TIMEOUT
G_SMTP_CMD_TIMEOUT
G_SMTP_DATA_TIMEOUT
Now, the one most likely to help is the data timeout, but, it's
a new one, you may need a special build to get that setting, let
me know platform and we'll send a new build you can try which
has that setting. With this type of fault I would set it up to
about 20 minutes to see if it
fixes it, e.g.
g_smtp_data_timeout "1200"
Lastly, some email clients will download messages multiple
times by mistake, this is unlikely to be the problem but worth
keeping in mind, particularly if the setting to 'leave message
on server' is ticked in the mail client. Again the msg*.rec file
should make it clear if this is a likely explanation as it will
only show one message
arriving.
AOL have some very strict policies regarding how much spam you can send them and your users can easily get your server blocked. The first thing to do is to go to http://postmaster.aol.com and open a feedback loop, this will let you know exactly how you are getting blacklisted, from there you should be able to kill the problem in SurgeMail. Often it is users that have setup redirection rules from their accounts to their AOL accounts.
You could prevent your users doing this with the following settings.
g_forward_illegal to="*@domain.com,*@domain2.com" apply="user"
will prevent users configuring forward rules to specified domains.
it will not prevent existing settings from working, if you want to find those try:
tellmail find_user domain fwd
*@domain.com
tellmail find_user domain
fwd *@domain2.com
This problem has many causes, usually a broken virus scanner, or bad dns_host entry and orbs lookups causing a problem. If you just increase the limit without first understanding why the limit is being hit, you may well make the problem worse and hide the real cause of the problem while generating more obscure problems. So unless you really expect that many sessions for some reason first read through this section and check the relevant status info.
If there are lots of pop/imap sessions then it may be an authent problem or a disk IO problem.
In any case first look at advanced 'status' and examine the state of all the channels and how long they've been idle, if they are all in the same state then it's likely the name of the state will give you a clue as to what it's doing and what is mis configured.
If you are using a virus scanner other than avast, then we recommend you change to avast, the other free or third party scanners cause endless problems, they are fine for 'little' servers but when you are running a real server you should be seriously considering getting avast to avoid the headache's :-)
The other common problem is dns/spf lookups causing a problem to fix add this setting:
g_dns_lookup "true"
This is on by default in 3.7b and later builds.
If you are really getting hit by thousands of concurrent incoming email then first try reducing the timeouts:
G_SMTP_CMD_TIMEOUT "30"
G_SMTP_DATA_TIMEOUT "62"
If that still doesn't help increase the limits g_thread_max and g_smtp_max, but not beyond 900 and 800 respectively and start lower (e.g. 500,400
Read the next section 'only' if you've eliminated all issues above.
Ok, first, read the above section, there is almost no chance you really need to increase these limits so chances are you need to fix the problems described in the above section, if you increase the limit without fixing the above problems then the problem will continue and it will be a lot harder to figure out the real cause.
To safely increase the limits do the following:
Likely culprits are
Virus scanners (on your server, or on your gateway, or on the sending server) - Remove/uninstall these nasty things :-)
On windows it might be an MTU issue, Try "DrTCP" from dslreports (http://www.dslreports.com/drtcp) , decrease the MTU to 1024.
Ok, first, don't do this :-), in general this is a bad idea, if you have the surgemail spam settings correctly configured the users won't get spam so this won't be necessary, see https://netwinsite.com/surgemail/help/spam.htm
But, there are some situations where this is worth doing, lets say you have an external spam filter tagging the messages, then possibly this might be a good idea. Do it as follows.
In the web admin tool click on accounts, go to the bottom of the page, and then click on the 'filtering' button under 'Default user settings for this domain or global.
Add a rule to move messages into the folder you want if the header/tag exists, note you can add the 'if exists' check box so it will only do it if the user has created the specified folder.
Then you may wish to add an expire rule to expire the contents of this spam folder if it has messages more than 60 days old
(for each domain add)
expire_rule folder="Spam" age=60
Let us use "mydomain.xx" as the example domain. You want to setup SurgeMail so that if the primary server that is hosting mydomain.xx goes down SurgeMail will accept mail for that domain and hold it until the primary server goes back online and then SurgeMail will deliver the mail to that server.
You need to make sure that you have a lower priority MX record for the domain pointing at your server to start with so that mail will be delivered to SurgeMail when the primary server is down. Then you just need to configure SurgeMail which is very easy.
You only need one setting.
g_gateway domain="mydomain.xx" to="ip of primary server"
The important thing is that you must NOT setup the domain on SurgeMail as otherwise SurgeMail will think that the domain is hosted locally and try and deliver the messages locally and they will of course fail as the users won't exist.
You can control the time period SurgeMail will hold these
messages for the primary server before bouncing them with the
g_retry_rule setting, by
default it will use the g_retry_limit
setting which has a default of 48 hours, so SurgeMail will
continue trying to send the messages to the the primary domain
for 48 hours and then will bounce them.
Here is a short list of some of the functions in SurgeMail listed in the order they are run. g_virus_cmd is run first.
g_virus_cmd
g_filter_pipe
aspam
mfilter
g_scan_cmd
1. Download and install the Win32 OpenSSL package from http://gnuwin32.sourceforge.net/packages/openssl.htm.
2. Create a folder c:\certs and copy the file yourcert.pfx into the c:\certs folder
3. Open a command prompt and change into the GnuWin32\bin directory:
cd %ProgramFiles%\GnuWin32\bin
4. Type the following command to convert the PFX file to an
unencrypted PEM file (all on one line):
openssl pkcs12 -in c:\certs\yourcert.pfx -out c:\certs\cag.pem -nodes
5. When prompted for the import password, enter the password you
used when exporting the certificate to a PFX file. You should
receive a message that says MAC verified OK.
Copy the resulting file to the surgemail certificate file surge_priv.pem
Install the 32bit GCC RPM then 32 bit binaries will run on your 64bit installation.
Define the mx record for 'example.com' to point to your mail
server.
In surgemail.ini define:
g_atrn_port 366
g_atrn_server domain="example.com" user="fred" pass="secret"
g_relay_to "example.com" (so that surgemail will store mail for
that domain)
g_retry_rule domain="example.com" hours="200" (keep messages for
several days)
And open port 366 on your firewall if necessary and restart surgemail.
Then the client who's domain is 'example.com' should configure his server to use atrn username "fred" password "secret" to fetch pending email on your server.
Limits to prevent guessing passwords and abusing a local account to send spam:
g_recent_bypass "127.0.0.1" # bypass limits per ip address
g_bad_login_ip_ignore "127.0.0.1" # bypass limits for bad logins
G_BAD_LOGIN_ALLOW "10" # Number of bad logins before blocking
user
G_BAD_LOGIN_IP_ALLOW # number of bad logins before blocking that
ip address
# limit users from sending out bulk email...
g_user_send_max max="2000"
g_user_send_warning "500"
G_USER_SEND_IP "true"
G_USER_SEND_WHITE "127.0.0.1,other known mailling list servers"
You can also check for weak passwords used by your users with the following command (run in the shell or command prompt)
tellmail test_weak
to find the worst accounts/passwords.
In certain situations you may want to limit certain groups of
users to not be able to send / receive mail directly from the
internet.
eg in schools or in company environments
This can be done using g_access_group with an appropriate
g_user_send_rule and g_user_receive_rule.
eg. accounts in the "local" group can only send to / receive
from other mydomain.com accounts:
g_access_group group="local" access_pop="*" access_imap="*"
access_smtp="*" access_incoming="*"
g_user_receive_rule group="local" from="*@mydomain.com"
g_user_send_rule group="local" to="*@mydomain.com"
Some RBL systems (like spamcop) blacklist servers for sending bounces. One could argue if this was valid or not, but they do it, and so we must cope with it
In general surgemail doesn't send many bounces compared to most servers but if you find your are being blacklisted due to this issue then consider using these settings:
1) Turn on the default recommended spam settings using the 'config' checker in the web admin tool
2) Set
g_spam_block "true"
3) If you have a front end mail server, or low priority mx hosts, then remove them, so mail goes directly to surgemail if possible.
4) If problems still persist then set
g_friends_check_spf "true"
g_responder_safer "true"
5) If problems still persist, panic :-)
These errors
indicate a fault external to surgemail, usually virus/spam
scanner
on the sending users pc is the problem. But let us know if you
can't find the
fault. Other potential causes include faulty network cards or
random network failures. Or a corrupt email message and faulty
sending email server.
You can identify more about the problem by testing as follows:
This message means surgmeail never got a 'data' command from the sending server. So the sending server never actually tried to send an email message, this is most common if all the recipients are rejected, or if a virus or spam filter at the sending users pc rejects the message before it can be sent. It also happens when the sending mail server/client is just trying to find out if the recipient is valid.
It has been seen once with "Symantec AntiVirus 10.0.0.359 running the Internet E-mail Auto Protect. Disable the feature."
To find lost items find the uid of the missing item.
Then search the msg*.rec logs to see what ip address deleted it
and when.
Here is an example, showing delivery, burst, and delete. The uid
is assigned during the 'burst' stage... but the 'time' of delivery
1409243025
is also useful for tracking the message.
28 11:23:45.00 [101706748] Stored 198.11.224.13
<srikan@v2xk.in> <surgemail-support@netwinsite.com>
48011 <012601cfc2d$@v2k.in> "[198.11.224.13-static.com]
Stored locally /home/.../surgemail-support/mdir/new/1409243025.31147_14202.netwin.netwinsite.co"
28 15:06:53[0] burst 127.0.0.1 .
<surgemail-support@netwin.co.nz> 0 . "burst 1409243025.31147_14202.netwin.netwinsite.co
--> u122443~2,(0,48764)[1409243025]"
28 16:36:48[0] del 122.61.185.36 .
<surgemail-support@netwin.co.nz> 48764 . "u122443~2,DS(0,48764)[1409243025](ip=122.61.185.36)"
Then you have the ip address of the culprit in theory.
The secret is
to install a better email app, we recommend Spark, see
https://sparkmailapp.com
Check your MTU
setting, if it's wrong then large network packets will fail.
This will result in closed connections during the DATA send
stage.
g_url_redirect from="http://*/surgeweb" to="https://%1/surgeweb"
ports="80"