GreyList

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."

This is almost true, many server are configured for retry the send also after 5 minutes, so we recommend of not exagerate with the “embargo” time, indicating a maximum 5 minutes. But certainly this remains the only “cons” of this innovative antispam technique.

Pros :
Zero false positives and a cut of the spam almost 80%.
Understood the mechanism of the “greylist”, we only have to configure the time of embargo and transit in the database . example 4 minutes of embargo and 24 hours of transit is a good configuration.
The transit times are essential for the next send from the sender servers, infact the triplet must be in the database and had to overcome the embargo time for go through this control.
If there is a recall during embargo time it's possible to assign a score for every “forged” of the triplet.

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.

Auto Light White List

This feature has born for suppress the "cons" of the greylisting. Infact it isn't a real "White List", that would shift the message, but a "light" white list.
The function is very simple, for every authorized send with "authentication" or as RELAY, Caronte Antispam inserts the "pair" (sender-receiver) in a database, waiting for a time ,configured by you, an incoming email , that answers to the previous email ,sended by your RELAY user or an authorized one..
This feature has reason to be enabled only when the users of the local domains use this SMTP service and this SMTP service also is the receptor for the incoming internet email.
The score must be configured in negative format.
We remind that this feature allow elude only to the GREYLIST control of the messages in answer and applies a negative SCORE for eventually false positive.

HELO / EHLO

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.

S.P.F. (Sender Policy Framework)

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.