• Feature: PAY NOW button added to generated invoices within Client Area
• Bug Fix: Update to the rounding used when calculating amount to process
• Bug Fix: Updated validation on data sent to ANZ, specifically checking for spaces in card number
• Bug Fix: Updated validation to ensure the card CCV is within the expected CCV field as opposed to WHMCS “Card Issue Number” field

Disclaimer: Myself, nor anyone else associated with this gateway work for ANZ or WHMCS. I, nor any associated party will be held liable for any data loss, leaked financial data including but not limited to Credit Card numbers or incorrect data being processed by your merchant facility.

Download:
• Download File Here
• Extract tar (tar -xvf anzegatewhmcs.tar)
• Move anzegate.php to your WHMCS payment gateways directory
• Configure your merchant information from the Payment Gateways section of the WHMCS admin area

1.    Grab a copy of the package you wish to upgrade to, from mailscanner.info
2.    Stop any MailScanner processes
3.    Extract the file with ‘tar –zxvf MailScanner-X.X.X.rpm.tar.gz’ and enter the directory
4.    Start the upgrade by simply running the ‘install’ script within – this will take 10 or so minutes
5.    Change dir to /etc/MailScanner
6.    Run ‘upgrade_MailScanner_conf MailScanner.conf MailScanner.conf.rpmnew > MailScanner.new’
7.    Optionally view what has been changed with ‘diff -w MailScanner.conf.rpmnew MailScanner.new’
8.    mv MailScanner.conf MailScanner.old
9.    mv MailScanner.new MailScanner.conf
10.  Restart MailScanner
Simple.

Scenario – CentOS 5, Apache 2.23, PHP 5.1.6, compat-libstdc++-33, PHP-Devel and Zend Optimizer v3.3.3
Note: The St George IPG will not compile on 64 Bit operating systems, St George have advised that a 64 Bit version is in development.

1. Download, extract and compile SWIG from www.swig.org as per IPG documentation
2. Extract the IPG webpayPHP tar
3. Copy libwebpayclient.so to both /usr/lib/ and /usr/lib/php/modules
4. Within the webpayPHP directory, run make to compile webpay_php.so. The errors I have seen here are all relatively self explanatory, either SWIG didn’t compile correctly, your on a 64 bit system, PHP Devel or Zend are unavailable
5. Copy the newly compiled webpay_php.so to /usr/lib/php/modules/
6. Either set enable_dl = on within your PHP configuration and then restart Apache (Note that enabling dl() imposes major security risks if you have customers hosted on this server) or statically load libwebpayclient.so – You will need to update your actual gateway to reflect this change
7. The following symlinks needed to be created on a clean CentOS 5 install in order for libwebpayclient.so to meet its dependencies

ln -s /lib/libcrypto.so.0.9.8a /lib/libcrypto.so.4
ln -s /lib/libssl.so.0.9.8a /lib/libssl.so.4
You should now be able to utilise the St George test scripts (After updating test.php to use your Merchant ID, Password, Certificate and correct server address) to confirm it is working correctly.

# php test.php
Starting webpay Transaction
Successfully communicated with the WTS
————————————–
——– TRANSACTION APPROVED ——–
————————————–
Transaction Reference : [2230000001188765]
Result : [0]
Auth Code : [585599]
Response Text : [APPROVED (TEST TRANSACTION ONLY)]
Response Code : [00]
Error Message : []
————————————–
If you receive an error advising that test.php was unable to open libwebpayclient.so run ‘ldd libwebpayclient.so’ to ensure any additional dependencies have been met.

I wish you the best of luck should you actually attempt to contact St George for support, their knowledge of how IPG actually works, let alone their understanding of PHP is severely lacking.

There was very little documentation however the solution I found was to simply deselect the Analogue Output from the Audiophile config app.

The M-Audio site also advises the following;
The use of USB Audio Devices on the Right-Hand USB Port Is Not Recommended.

The 15″ MacBook Pro models have 1 USB port on the left side, and one USB port on the right side.
The 17″ MacBook Pro models have 2 USB ports on the left side, and one USB port on the right side.

Due to the current USB configuration of the MacBook Pro under OS X, use of USB audio devices is supported on the left-hand USB ports only (the port or ports next to the power adapter cable). Use of such devices on the right-hand USB port is not advised because it may cause audio interrupts and/or dropped samples. However, the use of an iLok on the right-hand port has been qualified and is fully supported.

To monitor the performance of the server and to allow for some pretty spiffy looking reports we are making use of MailWatch. MailWatch will also form the base of our end user interface which is currently a work in progress.

One important change we have made to the MailScanner configuration is switching to using a ClamAV Perl module to scan email. When utilising the executable ClamAV we found the servers load average to be constantly sitting around 25 and mail delays upto an hour and a half. You can change this within /etc/MailScanner/MailScanner.conf as follows;

• Virus Scanners = clamavmodule

You will need to restart MailScanner for this change to kick in. Providing you used the SA / ClamAV RPM I linked to in the initial article to install ClamAV, this Perl module will already be available to you.

We are now running this solution on a Dell PowerEdge SC1435 AMD Opteron, 2GB Ram and 160GB SATAII Hard Drives in a RAID0 configuration. I believe the hard disks were the primary bottleneck on our initial server and as such the decision was made to run in RAID0. The server stores no customer data so data redundancy is not an issue.

The servers load average now sits around 1.5. On average over the last few days we are processing 100000 emails a day, 47% of being tagged as spam, and another 2% being tagged as virus.

Based on the concept of Project Gamera from Atomic Rocket Turtle we have developed an in house Spam and Virus filtering solution that scales well, effectively scans and allows the user to manage their own settings.

This server acts as a mail gateway, sitting in front of our Plesk servers. Customers domains have two MX records configured as follows;

• Priority 10 – antispam_server.ourdomain.com
• Priority 30 – plesk_server.ourdomain.com

Upon scanning the email, it is then passed to the Plesk server the customer is hosted on, based on Relay lists described further on in this guide. The dual MX records allow for the gateway to go offline due to fault or load and customers will still receive their email.

Initial lab testing of this configuration successfully tagged 100% of spam email with zero false positives. During our production environment testing we were seeing close to a 98% success rate with zero false positives.

As described further in, this system is currently offline while we await the installation of new hardware due to performance issues.

From a clean installation of Linux through to a completely working Anti-Spam gateway this guide should have you running within 3-4 hours.

Originally we tested pre built packages including Project Gamera and dspam. While both packages were fairly straight forward in installation and use it made more sense eventually to take a look at their features and put something together that fits in with what we wanted.

• A system independent of Plesk that was white label allowing it to be resold also to customers on non PSA servers
• A system that would scan for both Spam and Viruses
• A system that would eventually allow customers to manage the way their spam is handled on at least a per domain level
• A system that could cope with several thousand domains, and at least double that figure in mailboxes, allowing it to easily expand into a second server in the future

The complete system utilises Postfix, SpamAssassin, ClamAV, MailScanner and MailScanner-MRTG for graph monitoring. This system was initially configured on CentOS 4.4 on an old Pentium 4 Server with a single 7200RPM 80GB HDD and 1GB of RAM.

The following steps are taken from the installations I completed and should work without fault. This is a summarised version, however is fairly self explanatory. While a huge amount of text follows, if you are familiar with Postfix you can probably skip some detail.

1. I’d recommend not running a GUI on this server as it will simply utilise resources that MailScanner could otherwise be using. Complete your distro installation. It is handy to include the standard development tools so you have access to gcc and a handful of other niceties
2. As sendmail is included by default you will want to stop it, and disable it from starting in the future. You could remove it completely if you so wish. We have no use for it
3. Being a Red Hat based distro, I utilised yum to install Postfix as we have no need to patch the source. Run yum install postfix
4. We need to put Postfix into a chroot jail. There is a handy shell script called LINUX2 that takes all the work out of this for us. It is included with the source, or you can grab a copy from here. Chmod the script so it has execute permissions and run it as root. Unless Postfix is running when LINUX2 is run, the script will fail. When the script has completed you should be able to see ‘etc’ ‘usr’ and ‘lib’ directories in /var/spool/postfix
5. Now we start on the initial Postfix configuration. The Postfix configurations are well commented and its worth flipping through them, even if its to just get an understanding of how everything works. First we need to edit /etc/postfix/main.cf
6. I kept the initial configuration files however you may like to clean them up. A such any of the following directives we add may already exist and just need to be edited or uncommented so search for them first.
7. Add / Edit the following (main.cf)

• header_checks = regexp:/etc/postfix/header_checks
• myhostname = server.yourdomain.com
• mydomain = yourdomain.com
• mynetworks = 202.X.X.X/24
• inet_interfaces = all
• relay_recipient_maps = hash:/etc/postfix/relay_recipients
• transport_maps = hash:/etc/postfix/transport
• relay_domains = $transport_maps
  

Save and exit main.cf.

Create the file /etc/postfix/header_checks and enter the following into it

• /^Received:/ HOLD

This tells Postfix to move all inbound email to the Hold queue for processing by MailScanner.
Note that the next time you reload Postfix your server will open Port 25 to the outside world. Its important that you don’t put * records into your transport or relay_recipient files as this will result in you acting as an open relay and getting blacklisted. Being blacklisted is a horrible experience and you only make this mistake once.

Now we configure the destination of mail. This is achieved by editing /etc/postfix/transport and /etc/postfix/relay_recipients. This is fairly easy process. These fies simply say which domains we accept mail for, and once we have scanned said mail where do we send it.

relay_recipients lists the domains we are in control of. It must be in the format of

• @domain.com dummy
• @domain2.com dummy

As these are converted to Hash files each entry must be in a name/pair combination hence the word ‘dummy’. For all Postfix cares you could put ‘panda’ in there. As long as its a single word.
The transport file is a little more complex however follows the same format. It should look as follows;

• domain.com smtp:[10.0.0.1]
• domain2.com smtp:[10.0.0.2]

Where 10.0.0.1 and .2 is the IP of the destination mailserver. It is very important you leave the square brackets [ ] in place. I originally made this mistake and spent hours wondering why mail was bouncing, complaining about a loop. These square brackets tell Postfix to not attempt a MX lookup and to instead just send mail straight on.

After updating these files you have to feed them to Postfix manually by running postmap transport and postmap relay_recipients.

As we run this server in front of multiple Plesk servers that have domains added and removed daily we have scripted this process. In simple terms, we pull the list of domains from the PSA database on each server, note which server the list came from and then build these files. The list is checked for duplicates and we are emailed in the event it finds any. The two postmap commands are then run to refresh Postfix. This runs every 10 minutes.

Now we move onto the installation of MailScanner, SpamAssassin and ClamAV. The rest of this guide is much more straight forward, I promise

1. Download the latest RPM MailScanner release from the MailScanner site here.
2. Download the latest RPM ClamAV / SpamAssassin release from the MailScanner site here.
3. Extract the tar archives somewhere convenient and execute the included install.sh
4. Accept all defaults where prompted
5. You will need to edit your /etc/MailScanner/MailScanner.conf. As per psotfix.conf its probable these directives already exist so search for them first

• Run As User = postfix
• Run As Group = postfix
• Incoming Queue Dir = /var/spool/postfix/hold
• Outgoing Queue Dir = /var/spool/postfix/incoming
• MTA = postfix

You will also need to ensure Postifx can write to the MailScanner queue directories;

chown postfix.postfix /var/spool/MailScanner/incoming

chown postfix.postfix /var/spool/MailScanner/quarantine

Now would be a very good time to test your configuration and make sure email gets through your Postfix server, through MaiLScanner and to the destination server. Restart Postfix and run check_MailScanner to start MailScanner. Using a domain that has been configured in the Postfix relay and transport files and has its MX records configured to pass through your new mail gateway, send a test email. You can view its progress through the mail gateway by watching the mail log tail -f /var/log/maillog

Congratulations, you should now have a working Anti-Spam Anti-Virus mail gateway. Next we move onto “tweaking” MailScanner and configuring some graphs so you have some statistical information.

The main configuration file for MailScanner, /etc/MailScanner/MailScanner.conf is commented very well and explains everything in very simple terms. I am only going to point out the configuration options you really need to pay attention to, however I strongly recommend you go through the entire file. Note that all these directives exist in the default file, search for and edit them as required.

• %org-name% = One_word_company_name
• %org-long-name% = Your Company Name
• %web-site% = www.youdomain.com
• Max Children = 5
• Queue Scan Interval = 2
• SpamScore Number Instead Of Stars = yes See a number instead of ****

It is suggested you set Max Children to 5 per CPU. However this will vary greatly depending on your hardware specs, you queue scan interval and you messages per batch directives. Its also important to remember that SpamAssassin settings are controled from within MailScanner.conf and changes directly to SA configs will have no effect.

To restart MailScanner you should run check_MailScanner, take not of its process ID’s then kill them. To start MailScanner again rerun check_MailScanner.

As MailScanner uses a standard SpamAssassin installation I would recommend you take the time to install Pyzor, Razor and DCC. all three are easily installed and there is very simple step by step instructions in the SpamAssassin wiki. I would also recommend you collect any Spam that gets through and run sa-learn on it frequently. ClamAV will require its virus definitions to be updated regularly and you can automate this by adding /usr/local/bin/freshclam –quiet >/dev/nul 2>&1 to the crontab. We run ours every 13 hours.

MailScanner-MRTG is a package that automatically generates the configuration to build MRTG graphs for your MailScanner installation, graphing information including total emails, captured spam and spam ratio. These graphs not only please your manager but also help you identify how your gateway is handling the load of emails filtered, if there is a sudden spike in email traffic and how effective SpamAssassin really is.

MailScanner-MRTG requires httpd, net-snmp and net-snmp-utils. You can install this with yum install httpd net-snmp net-snmp-devel net-snmp-utils. YUM will take care of your dependency problems for you. MailScanner-MRTG comes in a nice simple to install RPM. A source version is also available. By default the RPM will install the graphs to /var/www/html/mailscanner-mrtg. If you would like to customise this at installation time you will need to use the source. You can find MailScanner-MRTG here.

This is as far as I will go with this guide. I will shortly add a guide on how to allow your customers to manage their own rulesets. We are yet to iron out the bugs in this ourselves.

As a side note the original server we configured did not cope with the load we put on it. I am expecting a replacement server to be put in later today. I will post some performance details when we have some more information.