Previously, iMessage.to kept all the about to be sent and sent messages in a common message pool. The only thing that differentiates between these 2 types of messages is a STATUS FLAG.
Previous Architecture : Message Pool comprises of both Sent and About to be Sent Messages
Well, this architecture worked fine when the amount of messages in the pool are small. But as the messages accumulate to the millions… the Email Sending Thread started to encounter performance issues. To sieve out the messages to be sent amidst a mountain load of messages in a pool consumed virtually 100% of a server’s CPU.
It was time for an architecture revision. For a start, we decided to split the messages into 2 separate pools. A MessageQueue for messages to be sent an a MessageArchive for messages that have been sent. By doing it this way, the MessageQueue will always be small in size and will allow the Email Sending Threads to retrieve the relevant messages to be dispatched quickly.
Sent messages will need to be kept in the MessageArchive to ensure that Bounce, Unsubscription, Update and Statistics Tracking operations can be performed on the dispatched email.
New Architecture : The messages are split into separate pools for better performance
Glad that a simple architectural change has greatly improved the performance of the product!
Well, if you have read the previous post of Reverse DNS Issue, you will realize that computers which have been compromised by viruses and trojan horses have kind of been weeded out of the email spamming industry.
You would have think that we have finally won the war over the hackers and spammers. Truth be told… that was only the beginning…. As hackers found that compromised drones with dynamic IP addresses were no longer effective in their email spamming efforts, they turned their attention to …
servers with static IPs.
The Origin
A couple of years ago, it did not really mattered how DNS was configured. Mails just went through. 
Those were the easy days… before SPAM came into the whole.
What happened was that some brilliant hacker discovered that sending unsolicited emails pushing drugs like Viagra, Enlargement drugs, etc… was very profitable business even if the response rate was dismal. They worked by the laws of large numbers…. Spammers understood that even with very low response rates, they just need to send larger and larger quantities of emails to generate the necessary responses and $$$.
Soon, hackers began running their home office like data centers. They have several computers with a high bandwidth. These computers served only one person – to dish out emails at an ever more ferocious rate….
However that was not fast enough yet. The numbers had to get larger… and that is when they decided to leverage on the resources of computers not belong to them. Trojan horses and viruses started to come into the picture… these viruses upon inflicting hapless computers will render these computers at the will of the spammer… to send emails! In fact, one prominent hacker at a time had over half a million drones at his control. By issuing a few simple commands, he could totally flood the network of his victims. This flooding of a victim’s network became known as a Denial-of-Service attack.
Most of the time though, the hacker will use these drones as a way to dispatch more emails to anonymous strangers. That prompted ISPs to look into using reverse DNS to authenticate the origin of emails….
When reporting SPAM problems for whitelistings, they will often require you to specify your IP address.
This is how you can check your imessage.to IP address
Click on configuration > settings
Under software info there is a line called IP Address. That is your IP address.
When your email is sent out there is a few kind of situation, imessage.to will indicate the status in the messaging queue.
How do you check the delivery status in imessage.to?
Click onto the “messaging queue” link of the newsletter that you have sent out, you will see a ‘Status’ column.
In this article, we are going to explain the different kinds of status and how we should go about handling them.
Paste from words - an add on function to the editor function.The editor functions allows the easy editing of words directly on our system into the newsletter template.
Knowing the number of customer who draft out their newsletter contents with the Microsoft Office Word, we have implemented this new function.
Simple and fast.
All you have to do is Copy (ctrl+c) your contents from the words document, open up the editor, click on ‘paste from words’ button and (ctrl+v) into the editor.
It will automatically update the newsletter and the newsletter will be ready to go with your contents !
Did u know that you could send off emails directly from your Windows Command Prompt without any email clients like Microsoft Outlook or Outlook Express?
Well, the email clients do not have any additional functionality other than providing a nice user interface to a backend smtp server. Accessing your emails involve a 2 part process:
- Identifying the SMTP server
- Sending email through the SMTP server
SPF stands for Sender Policy Framework, it is an extension to the SMTP protocol. Though it is still at Experimental stage, most of the major email providers have already adopted it (Hotmail, a MS product, is using SenderID). While SenderID can be considered an extension of the SPF framework, in fact, the keyword it uses in the record is “spf2.0”.
How it works
Sender email address present in the SMTP session
There are several sender email addresses present in a normal SMTP session.
- The most important one is the “mail from” or Return Path or “mfrom” in the senderID framework. it is the email address provided by the sending server to the receiving server in the first SMTP command after the handshaking “HELO/EHLO” command. 2.
- The “From” header field. 3.
- The “Sender” header field (in the case of multiple email present in the “From” header field).
- Other header fields has the sender email information including “Resent-From” “Resent-Sender”
The first one is normally the most important, it is where the email will be returned if it cannot be delivered. In fact, SPF framework only checks the “mail from”.
For sender ID frame work, it extract out another sender email other than “mail from” from item 2, 3, 4 listed above. Being called “PRA” (Purported Responsible Address), it is being selected in the following order:
- From
- Sender
- Resent-From
- Resent-Sender
Work flow of SPF and SenderID
Once a SMTP session starts, the receiving server will obtain the sender email address from the SMTP session.
Basically, a SPF / SenderID checking is checking if the current connecting sending server is a match with the server of the sender email address in the message. The workflow is illustrated in the figure below.
The major difference between the two is SPF only checks the email address provided by the “Mail From” SMTP command, but SenderID also checks the PRA obtained from the data of the email.
SPF / SenderID Record format
SPF /SenderID record are actually DNS records. It can be added in the DNS management page.
The spf record and senderID record share a similar format. It’s content will be illustrated by examples below.
1.SPF Record
example.org. IN TXT "v=spf1 a mx 123.45.67.89 -all"
For this line, it means for domain “example.org” there is a “TXT” record in the DNS record. The value of the “TXT” record is “v=spf1 a mx -all”.
While the line “v=spf1 a mx –all” means:
- “v=spf1” Version 1 of SPF framework record.
- “a mx”, if the current connecting server matching the “A” record of the server from the “mail from” command, it is considered passed. If it does not match, it would check against the “MX” record, if it matches it is a pass as well.
- “123.45.67.89” is actually an IP address, if the current connected sending server matches this IP address, the test is passed.
- “-all” Means if all the previous tests fails, for all the rest will results in a fail status in the SPF check.
2.SenderID record
example.org. IN TXT "spf2.0/mfrom,pra a mx 123.45.67.89 -all"
We can see it is very similar to SPF record except “v=spf1” is being replaced by “spf2.0/mfrom, pra”.
“spf2.0” is the version, and “mfrom, pra” means the receiving server should not only check the “Mail From” email address, but also the PRA email address obtained form the email data. While the checking procedure is the same as SPF record.
It is possible to spicify only checking the “Mail From” email, then the line would be:
example.org. IN TXT "spf2.0/mfrom a mx 123.45.67.89 -all" And if the sending server want only PRA be checked the line should be similar to: example.org. IN TXT "spf2.0/pra a mx 123.45.67.89 -all"
Recently the Singapore Government finally passed the Spam Control Bill - after a lot of consultation and reviews. The bill will have little effect on the SPAM situation in Singapore since most of the SPAMs originates from overseas, marketing products like viagra, nigerian scams, etc….
However it is a good first step. But how will this affect legitimate local SMEs who would like to leverage on email marketing to promote their products to the mass audience?
For those of you who likes reading legal bills, here you go, a link to the Spam Control Bill. Honestly, it was a tough read. After quite a bit of struggling with the legal jargon, I picked up the phone and give Boon Kiat of IDA a call at 62111907 to clarify the few remaining issues.
For the rest of you lazy buggers, read on:
Recently, a prospect asked if our system supports both hard bounce and soft bounce detection. Well, the answer is a definite yes! However, we would just like to take this opportunity to educate our users on the difference between these 2 types of bounces.
Hard Bounce occurs when a user sends an email to an invalid email address. Soft Bounce occurs when a user sends an email to a server which is currently not available for receiving mails. In the case of Hard Bounces, we need to immediately stop sending to these recipients. ISPs have been known to blacklist people who send their mailers to a large proportion of invalid email addresses (So for people who go about acquiring databases.. be forewarned!).