Antispam Level ONE
The second level of protection is composed by different features.
This innovative antispam system uses the implementation of the RFC protocol for the send of the emails, applies temporary REJECTs to the comunication with the error “451 4.7.1 Please try again later” and inserts in a database the famous “triplet” : ip/network , mailfrom, rcptto, for the next try that will be in future.
As the whitepaper indicates about the greylisting (http://www.greylisting.org/) , this antispam method is the most functionally, capable of block without false positive, all the RATEWARE, COMPUTER ZOMBIE and those come from the MAILFROM FAKE-RANDOM generation, forcing the spammers in retry the send after a particular time.
This technique is very effective, because the spammer cannot permit of “resend” the message, if the MAIL FROM is created randomly and he is using softwares that don't manage the outgoing queue but that directly connect on the destination server port.
So if the email is temporary rejected ,it isn't resubmitted in the indicated time of the RFC protocoll, the email is spam, as the “normal” mail servers are configured for retry the send also several times.
Let's take a look at the pros and cons of this innovative technique:
Definitely cons:
Lengthened receiving time and problems for users that use emails like instant messages.
The protocol rfc 5321, paragraph 4.5.4.1 Sending Strategy, claims that a sending server must resend a rejected email after at least 30 minutes:
"The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery."
It's also possible to insert some IPs server where don't apply the greylist delay. The feature is called "NO grey IP".
In some rare case it can happen that some SENDER server doesn't respect the RFC protocol and doesn't retry the send.
In these cases, once identified the problem, it's possible to insert some WHITE IP or range of these.
Note:
The issue of big networks, like GMail, AOL, YAHOO, Hotmail and much more, where the ip address of the sender can be always different, is already considered in Caronte Antispam,so it is not necessary to insert these big networks inside the WHITE IP list.
In the RFC 5321 comunication protocol , it is the command that activate the comunication to your MTA. This can be (HELO) or with extension (EHLO). Prescind from the demand made by the client if use or not the EHLO extension or the HELO, Caronte Antispam identifies if this HELO / EHLO is correct according to the RFC's specifications.
This Antispam control permits to identify ZOMBIE pcs, used as victims from spammers, also crossing the Reverse DNS of the IP with the presentation HELO / EHLO, it's possible to apply control rules and particular antispam algorithms.
In detail:
Invalid HELO / EHLO , according to the RFC protocol
HELO IP valid, but that don't have sense to exist gave that their reverse DNS says the contrary
Example, the client start the comunication with:
HELO [202.100.x.x] but the reverse DNS is “domainfoofoo.com”, the correct presentation should be
HELO domainfoofoo.com (or other derivative of under domain)
forged HELO
Are all the presentations that are in mirror or “forged”.
Example HELO localhost, HELO friends, EHLO yourpublicname.tld
Many "HELO" are forged, with Caronte Antispam you have the chance to value them with a score or also reject the message, if this forcing is truly excessive!!!
The forged are set automatically and their definitions derive from your public IP and from the configured local-domains. If you add new local-domains inside the configuration of Caronte Antispam the “refresh” button permits to refresh the “forged” surveyed in the database.
This antispam technique, try in its little, to forcing the spammer to use the correct RFC protocols, for a greater traceability of the calling IPs and for a better identification of the message.
The filter S.P.F. permits of determine the true sender of the email reading the TXT record of the domain DNS in “MAIL FROM”.
The brilliant idea of interrogate the TXT record of the DNS with a little framework of text instructions for determine if the send is legitimate or not, certainly makes this technique one of the most innovative in the fight against SPAM , as in its simplicity, it tries to repair all those flaws that the SMTP protocol has in its DNA.
We thank the creators of this new antispam technique, we invite all to visit the official site for more information about the functioning: http://www.openspf.org/
In respect of the Sender Policy Framework, in Caronte Antispam is possible to apply three distinct scores to the relative choosen answers that the SPF Framework can return: - SOFTFAIL
- FAIL
- PASS
With the option “Reject the email if FAIL” is possible to indicate to Caronte Antispam to close the connection with the client and reject the email with the correct RFC protocol error.
We strongly reccomend this option , as there can't be false positives, at least that there isn't errors in the TXT record of the sender DNS.
For the PASS result , the score can assume negative value or zero, this at your discretion and based on the type of spam that you receive.
We strongly reccomend to leave a ZERO score.