** Update - May 2009 **
New antispam measures in place
We have recently noticed a surge of spam mail arriving at ouremail server, which the old anti-spam measures were not able to cope. Inlight of this, an extensive review has been undertaken and the anti-spammeasures have undergone a major overhaul. We are now able to stop mostof the spam mail at the server level, thus alleviating our users needsto filter them at the email client end. We now tackle spam using thefollowing approach:
1) The mail server's IP address (SMTP) that has sent the incomingemail is checked against a database of known suspected IP address. Mostof the spam mail are sent via dynamic IP addresses, e.g. unsuspectingPCs which have been infected by virus.
2) The incoming email is virus scanned. If a virus is detected,the incoming email will be rejected. The end user will not receive anotification about this, the reason being a lot of spam mail alsocarries attachments that are really viruses or malware.
3) The content of the incoming email is scanned and analysed. Ifit is deemed to be spam, it will be marked and delivered to youraccount's "Spam" folder.You will not be able to see the email if you usea email client to retrieve the email, but you can go to one of ourwebmail programs to examine emails in the Spam folder.
Please note that you do NOT need to make any changes to youremail client to retrieve email. All the changes will happen on theserver side.
Frequently Asked Questions (FAQ)
1) Someone sent me anemail and it took a long time to come through to my inbox, but this onlyhappens occasionally, why is that?
With the new anti-spam measures in place, when ever the spamfilter sees an email with a new "triplet" (sender address, receipientaddress and sending mail server IP address), it will intially send adeferred signal to the sending mail server. A legitimate mail servershould normally attempt to deliver the email again to our mail servicesin a few minutes (but theoretically can be up to 30 minutes, dependingon the configuration of the sending mail server). The next time youreceive email from the same triplet, it will no longer be deferred (soyou should get the email very quickly). This will hold true as long asthe same triplet sends you an email once every 35 days (i.e. no deferralnecessary).
2) Someone sent me an email but I could not receive it, whyis that?
At the email server level, the only occasions where an incomingemail will be dropped are:
a. the IP address of the email gateway (SMTPserver) that is used to send the email does not have a reverse DNSrecord. The vast majority of legitimate email gateways has a publishedreverse DNS record, whilst spammers' email gateway will not (to hidetheir identity). This is a common spam filtering technique.
For moreinfo, please refer tohttp://en.wikipedia.org/wiki/Anti-spam_techniques_(e-mail), undersection "PTR/Reverse DNS checks"
b. that the virus scan detected theemail contains a virus
c. that the email has been sent by a virus /malware application on a compromised PC, where the PC's IP address(dynamic IP address) has been blacklisted.
d. the sending mail server isnot listed by the sender domain's published SPF (Sender PolicyFramework) record.
e. the content of the email has been analyzed andmarked as spam. The email will end up in your remote Spam folder and notthe Inbox, so if you use an email client to retrieve email, it will notbe downloaded.
As a sanity check, whenever you can't receive an email,please firstly check your email client's "spam" folder, and then checkyour remote Spam folder using one of our webmail service.
3) A largequantity of "Undeliverable Message" email are landing in my Mailbox, butthese emails were not caused by the mail I sent out. What should I do?
Starting in March 2008, we have received enquires from clientsregarding significant increase of back-scatter spamming. Back-scatterspam a certain kind of mail you receive that you didn't ask to receive.If you've ever received a “Your mail could not be delivered” bouncenotification, a “Your mail contained a virus” notice, or a request toconfirm your signup request for a mailing list you've never heard of,you've probably received backscatter. The backscatter problem isinherently linked to the spam problem, as most backscatter received isdue to somebody else on the internet doing something bad andspam-related.
The core of the back-scatter problem is that it is trivialto forge the sender address of an email. In normal Internet email, thereare no protection mechanisms to authenticate the sender's claimed emailaddress. When a spammer chooses to forge your email address as thesender of his spam, you end-up receiving hundreds or thousands ofundeliverable notifications / vacation messages / mailbox full messages,etc -- even though you never sent the original message. That isback-scatter.
Spammers don't want to deal with backscatter, and theydon't want complaints coming back; so they forge the sender address inspams they send out. However, while there are no truly standard anduniversal mechanisms to authenticate a sender's claimed email address,there are mechanisms to validate an email address. So, the simplestsolution for the spammer is to forge the sender address to be not hisown, but still a valid email address. The spammer simply chooses arandom valid email address and uses that. If that random valid emailaddress happens to be yours, however, the result is a huge amount ofback-scatter (non-deliverables, vacation messages, etc) directed to youraccount. The sheer volume of back-scatter can overwhelm mail systems,and use up mailbox storage quota.
For an ordinary person, unfortunately,very little can be done to protect against this. Once you are targetedby a spammer in this way, you will start to receive hundreds orthousands of back-scatter messages each day. Changing your email addressis often the only way to solve the problem.
Internet ServiceProviders(ISPs) can also adopt systems such as SPF, which attempt toprovide some spoof protection by clearly listing where your outboundmail is coming from (or digitally signing it). However, these rely onthe receiving mail server honoring these protocols and they are notcurrently universally adopted - so at best such a solution would onlyreduce the volume of back-scatter.