Anybody gonna comment on this?

Regards,

More than a "wish" that should be considered a bug, jacksun is correct.

We'll be uploading a new build with the fix within the next few hours.

We had the same problem too, just doubled our a/c capacity.

Roberto, any way you can setup the honeypot so we can whitelist ips to not be affected by it?

My offsite spamfilter is forwarding mail on and somehow the honey pot is seeing email address's that the offsite found in the honey pot, tagged the subject line, but is still found my the honey pot and blocked.

PLEASE! I can't use my offsite mx anymore

Actually the only problem we have is with the honey pot, I just need to be able to tell the honey pot not to block that ip and it would work fine. I used it as it sits for awhile until I turned on the honey pot, that's where my problems started

Marco,

Just posted the following to the other thread at http://logsat.com/spamfilter/forums/forum_posts.asp?TID=5217 #6068

=============

SpamFilter should really see the original IP of the sender when procesing emails. If SpamFilter handles emails that are being relayed by a "friendly" server, then things are bound to go wrong, not just with the honeypot file. Think about the SPF filter for example... If the IP of the server connecting to SpamFilter is not listed in the SPF DNS record of the sender, the email will be rejected. And if your secondary is forwarding emails to SpamFilter, that *will* cause a big issue.

The mains solutions that come to mind are to:
(1) place SpamFilter (or any other antispam software) in front of all the servers listed as MX records,
or (2) forward the email from the secondaries directly to your main SMTP server, bypassing the main spam filter.
or (3) install a second SpamFilter on a separate IP or separate server, configure it skip ALL IP-based tests (reverse-DNS, country, SPF, MAPS-RBL, IP blacklists, MX checks etc.), and have the secondary forward emails to this lesser-featured SpamFilter.

I vote for option #2 below.  We already do this with our user's mail clients.  We have them all set to a non-standard SMTP port that bypasses our spamfilter and goes straight to our mail server.  Then we don't trust nothing that hits on SMTP 25 that claims to be from a domain that we are hosting because we already know every legitimate user should be using our proprietary SMTP port.  Puts a brick wall up on all those new worms out there and allows us to use a single public IP for both mail server and spamfilter.  We were using this method long before SPF came about and it's actually a little more effective on our own domains, as we don't trust anything being relayed out on port 25 from our own domains...even from IP's authorized in our SPF records.

Guess we can look at setting up a backup SMTP server to do the same thing by bypassing our in-house filter and just filter from the remote backup server.

LogSat wrote: Marco, Just posted the following to the other thread at http://logsat.com/spamfilter/forums/forum_posts.asp?TID=5217 #6068 ============= SpamFilter should really see the original IP of the sender when procesing emails. If SpamFilter handles emails that are being relayed by a "friendly" server, then things are bound to go wrong, not just with the honeypot file. Think about the SPF filter for example... If the IP of the server connecting to SpamFilter is not listed in the SPF DNS record of the sender, the email will be rejected. And if your secondary is forwarding emails to SpamFilter, that *will* cause a big issue. The mains solutions that come to mind are to: (1) place SpamFilter (or any other antispam software) in front of all the servers listed as MX records, or (2) forward the email from the secondaries directly to your main SMTP server, bypassing the main spam filter. or (3) install a second SpamFilter on a separate IP or separate server, configure it skip ALL IP-based tests (reverse-DNS, country, SPF, MAPS-RBL, IP blacklists, MX checks etc.), and have the secondary forward emails to this lesser-featured SpamFilter.