Mailing List Message #97776
From: Nicolas Hatier <>
Subject: Re: Feature request: a way to get CGP's expected response to a message envelope
Date: Tue, 14 Apr 2009 14:37:43 -0400
To: CommuniGate Pro Discussions <>
Sorry to bring that up again, but I still think this would be a good idea.

Maybe not an SMTP extension, but a CLI command would do too, for instance:


To be simpler, the authentication part of the SMTP protocol could be ignored in this test, the test being run as if the sender is not authenticated. The goal here is to get the result of protection settings (blacklist, SPF, RBL) on a given IP with given recipients. There is currently no function for that in the CLI. This function could as well give global router result for the given sender and recipients.

Once this is implemented, CGP could also implement the client version of this function when it's used as backup. Backup servers are often the weakest point of the protection against spam and viruses, and spammers knows that. This would probably be a step in a good direction.


Nicolas Hatier wrote:

I'm just wondering if this feature has been considered for CGP. It would be really helpful for backup servers and mail proxies.

Nicolas Hatier

Nicolas Hatier wrote:

I'm asking for a "dry run", but not for the whole process. Only for what is happening before the DATA command in a SMTP session. This way, an external service can ask CGP "what if this IP tries to send you a message". If the result is positive, the external service will allow the message to be relayed to CGP.

I'm trying to solve a simple problem. If an external service accepts a message and then relays it to CGP, CGP will see the message as coming from the external service IP. Protection settings such as blacklist, SPF, RBL, etc, will not be applied as if the message was coming from the real IP the message initially came from.

Nicolas Hatier

Technical Support wrote:

You are asking for a "dry run" through all the stages while a message is being received, since protection settings ae not applied in one single stage. But such a "dry run" is hardly possible, as besides those three parameters SMTP Input module has the entire environment to process and that optionally includes states of accounts, authentication, external plugin responses etc. The result of a "dry run" may be not the same as the result of an actual delivery attempt.

Nicolas Hatier wrote:

A CLI command, named for instance GetEnvelopeResult - there is surely a=20
better way to name this but I can't find one, please continue reading.

This command would take a few parameters: source IP address, return-pat= (email address), envelope-to (email address, maybe more than one)

CGP would process those three parameters as if it was a message coming =
from the specified IP address, with this return-path, this or these recipients, and the response would be the status of this supposed message according to all protection modules of CGP happening before the=20
DATA command of the SMTP session.

This would include (in no particular order) RBL status, blacklisting according to network settings, client IP status, SPF, temporary blacklist, whitelist, whitelist by dns, unknown recipient, authentication required, and other possible errors or warning flags happening at this state.

This feature would allow mail proxies or backup mail servers to query the CGP server and ensure a consistent protection of the mail flow, without duplicating the settings or reimplementing them. This would als= allow external filters to be outsourced to separate servers to reduce the load, as these filters could be enhanced with a simple SMTP proxy and that would perform this command before relaying.

Unfortunately the current CLI commands does not allow to get the result=20
of many protection settings without reimplementing most of them and transferring a lot of data between servers.

Another way to implement this feature would be to add a new command to =
the SMTP session, such as
FROM IP:xx.xx.xx.xx
MAIL FROM:test@example.ext
RCPT TO: user@local

The CGP server would then process the email as if it was coming from th= said IP. As a simple security measure, CGP would test each protection setting with the real IP the connection is coming from and with the provided IP, and would report the "worst" of the two results.

Thank you.
Nicolas Hatier


*Nicolas Hatier* <>
/Niversoft idées logicielles/



Nicolas Hatier
Niversoft idées logicielles


Nicolas Hatier <>
Niversoft idées logicielles -

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster