Print Page | Close Window

Possible-feature requests for the Next ve

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
Printed Date: 21 January 2019 at 6:52pm

Topic: Possible-feature requests for the Next ve
Posted By: atifghaffar
Subject: Possible-feature requests for the Next ve
Date Posted: 14 September 2006 at 4:00pm
Hello Roberto,

I see in the thread about the new features about the upcoming version /5788&PN=1

so here are some (lots) of my requests.

1. LDAP lookup for allowed Email addresses. Currently I have to create this file on the central server in different formats and push to several servers. Since you already have the LDAP code in, I guess this might be easy to implement.

2. Destination routing per domain or per email address.
Again this can be done via LDAP query or a database.
Currently I have the SF-incoming->Postfix (for LDAP lookup and Mail routing to internal mailbox server) -> SF-outgoing -> Outgoing server.
If I can do the mail routing on the SF box, I can get rid of the mail server in between and put more nodes running SF.
Example mail routing. (a mix of the two docs should do it.)

3. Ability to assign some rules for the SMTP Auth'ed users.
Your design for the SMTP auth assumes the role of outgoing server and white-list everything coming from a authenticated user.
In an Enterprise that may be the case but at the ISPs, the authenticated users can be as bad as the un-authenticated connections.
Example: Worm on your computer using your outlook settings to send spam as u, using your credentials via your ISP.

This makes more work for our Outgoing SF (3rd in the row) to get rid of this SPAM.

4. This one should make you __MAD__.
  A scripting engine? or a plugin possibility where the administrators can add / change some functionality? For example if you provide a hook to the logging feature, I am sure someone will write a plugin to log to syslog. Example: see qpsmtpd (

5. Ability to run as a helper application to other mail server.
   For example (postfix and amavisd-new). Ok, I take this one back.

6. Transport over LMTP to internal mail servers. Ok.. this one is too much too.

I will bug you with more feature requests as I get more ideas.

best regards


Posted By: atifghaffar
Date Posted: 14 September 2006 at 4:08pm
2. Destination routing per domain or per email address.
 I read my post and this was not clear so I try to put some more info.

Currently SF forwards all clean mails to a pre-defined IP address.
With LDAP/Static-File lookup it will just forward the mails to a differernt server in the answer given by the LDAP server.

For the email addresses/domains there is no answer, then the pre-defined ip is used as the fall-back.

This will allow me to connect a few of incoming-SF boxes with a few of outgoing-SF boxes and whatever is in between goes to the real mail-store servers. (Cyrus) 

I understand that this was not the main purpose of the spamfilter application but it can be very helpful.

Some other filtering solutions that I have used in the past allow this funtionality (barracuda)


best regards


Posted By: LogSat
Date Posted: 14 September 2006 at 4:20pm
Hi Atif,

#1 has been added to the wishlist. It won't quite make it right away in the next release, but it will be considered later.

For #2, that can already be done! Please see this section in the readme.html file:

Local Domains - SpamFilter will only deliver email to the domains listed here. Wildcards (* and ?, same rules as DOS wildcards) are allowed. You can also use file:///C:/My%20Documents/Delphi%20Projects/SpamFilter/readme.html#Bayesian%20Statistical%20Filtering - Regular Expressions (RegEx). If the domain in the  RCPT TO email address is listed as a local domain, then the recipient is accepted. This is done to prevent spammers to use SpamFilter to relay email to third party email addresses/servers. It is very important to add your own domains to the local domain list. If not, you will not be able to receive email. If you need to have any domain listed here forward its destination email to a different server than the default destination server, you can specify so here. You can override the default destination server by appending the forwarding mail server and port to any domain in this list. The syntax should be as follows:

DomainName:DestinationServer:DestinationPort - ex.

For #3, can you be more specific on what kind of options you'd like to see?

#4, 5, and 6 instead are pretty unlikely to be implemented any time soon, sorry!

Roberto Franceschetti" rel="nofollow - LogSat Software" rel="nofollow - Spam Filter ISP

Posted By: atifghaffar
Date Posted: 14 September 2006 at 7:30pm
Hello Roberto,

Okay for the #4, #5 and #6.


Thanks for the tip for #2. Didnt realize that it was there.
Its half-way there already. Now only if this option was available on per email address.

half of the work is to know which server the mail should be forwarded to and the other half of it is to know which user to.

for example should go to roberto_franceschetti@ should go to some_other_mailbox@
* should to some_other_mailbox@


Same rules for authenticated user such as SURLBL checks, max rcpt-to test etc. Perhaps we can skip the ip address/country block but other checks do makes sense.
With these checks in place we will still be able to give the green light to some users by putting them in the unfiltered list.

best regards


Posted By: Web123
Date Posted: 15 September 2006 at 6:31am

Could also use this one !



for example should go to roberto_franceschetti@ should go to some_other_mailbox@
* should to some_other_mailbox@



Print Page | Close Window