IP Relay

You can insert a single IP address or an IP RANGE.
Warning, this feature enable the full proxy transparency and the message will be fully managed by your MTA of cooperation, circumventing also the answer “550 5.7.1 Relaying denied” of Caronte Antispam. Remember also that all the Antispam controls are circumvented !!!!

If you don't want to manage the IP RELAY, Caronte Antispam has the feature of “catch” the AUTH LOGIN on the MTA of cooperation.
We recomend of don't enable the RELAY of the service, if your MTA of cooperation supports the authentication extension of the RFC protocol.

Max session number of IP

Many times the mail server is assaulted by single IP that try to deliver the messages with multi-session connections at the same time.
The RFC protocol doesn't say anything about the max number of sessions that a single ip can make at the same time to a MTA, but it's sure that such behaviors could cause malfunction of the MTA, that falls back, when overloaded, with the error “421 BUSY”.
Caronte Antispam succeding in save the IP session, can discipline such behaviors;
making go the first call and then responds automatically to that IP and only to that IP, with the error “421 BUSY”, if the IP overcomes the number of allowed sessions.
We remember that the error “421” of the RFC protocol is not a fatal error, infact the calling server must recall after 30 minutes.
This feature discipline the calls that come both from a good server or bad one, it isn't an antispam system, but a safeguard for your mail server.
The max sessions for IP are autonomously customizable, we suggest 5, but it's only an indicative value.

Warning, this mechanism isn't valid for IP considered RELAY, both "IP RELAY" than as "AUTH LOGIN MTA", infact we could have a LAN network with a dedicated server for the outgoing messages and this could open many sessions and connections, but it's right!

Max errors for message

Normally a MTA of cooperation has already this “feature” in its configuration.
If your MTA doesn't have, you can configure it in Caronte Antispam, if is reached the limit during the comunication of deliver of the message, the connection will be dropped.

Max NOOP commands

The command NOOP is expected by the RFC protocol, and it's used to know the state of running of the client or the server during the comunication. Usually it's used only for control if the service is running, infact the MTA has to respond always “250 OK “
Many times this command is used “improperly” for attack your MTA. Caronte Antispam “closes” the connection if it is an abuse of this command , without send any error message.

TimeOut client

This type of control is valid only in the case of sending message from client . It's considered as timeout time, the "inactivity" expressed in BYTE during the comunication of protocol. The timeout is reset every time a client send a byte.

IP addesses to the hell

Could not miss in this context, a clear reference to the Dante's hell, the term “hell” as reference identifies a place where store the IP addresses that have made something truly harmful to our mail system.
Caronte Antispam refuses ,at connection level, all the IP stored in this database, called “hell”, for the time that you choose.
It's possible to enable the automatic insert of the IPs in the hell from the Antivirus plugin, but with the awareness that the send of a virus from a determinated IP address doesn't involve that it will send all the future messages as virus. May happen to ban also a big network, so if you enable the auto-insert feature, we suggest to not exaggerate with storing time of the IPs in this place called hell !!!