No trouble in the sitting area yet :)

im thinking of a dedicated backtracing relay system in front of the spamfilter, with enough resources to do extensive tracing, right after it passes the mails on to the filter. Which in turn handles them as usual.

Not a toy i will be allowed to own though :/

but imagine such a system with automated hostmaster notification on spamming network users.... Not all of those would give a h00t ofcourse, but i bet quite a lot would take actions against the offending users..

Anyway, kspare said it, having a honeypot whitelist would fix our problems. Your suggestions are even better Dan, but i'm afraid it would take some serious effort in getting that to work, but i do hope logsat is willing to give it a try.

Marco,

Yet another part of a conversation I am having with LogSat:

One option that may help, but is rather tricky would be a method of testing for how many hops a message takes.   I am not sure I would trust this as more and more systems use several hops to deliver mail.  Our system does.  So determining a value for "Max Hops" could be an issue.

Aren't I just a Royal Pain in the you know what!

Regards,

adding in a "TrustIP" JUST for honeypot in this case would solve my problem too. I think in Marco's case and mine, we could write a script to parse the honeypot ip's list, but that isn't real efficient.

Just to be clear, we just want to be able to whitelist ips against the honeypot list...that's it.

it would ROCK if possible!

It would make the filters 100% operational in my described situation.

Im also thinking now about backtracing to the origin, or at least the next after the originating ip, in case of spoofing.

If at all possible that would make spammer's lifes pretty miserable.

nah, i'm starting to rant now :)

Marco wrote: Marco, Forgive me ... I have not been thinking real clearly after our disatrous weekend but ... I think things happen like this: the secondary mailservers of the ISP (mail1, mail2) are only receiving the inbound mails when the primary is unavailable. For some reason the relay's ip's are beeing put in the mail headers as beeing the originating ip. So when inbound mails got buffered and were using honeypot adresses, the relay's ip's got blacklisted. The reason is that it IS the originating IP so that is correct. Resuming; the honeypot is blacklisting the relay1, relay2 ip's, because of mail that is sent to us, gets buffered on mail1/mail2 , and is using honeypot adresses. Understood. My first thought was to make a script that checks the honeypotblockededIP.txt file for presence of those 2 ip's and remove if found, But that isnt a very elegant solution, and would cost additional CPU load. Not elegant but EXACTY what I do.

Now,  Since my last post, I was emailing Roberto directly and realized what you were getting at ... and I have the same issue but dealt with it as above.  However, here is part of what I wrote to Roberto while thinking on this issue:

I think, but am not sure, what Marco and several others are asking for is a "TrustIP" list that would not allow relay but would prevent the honeypot from triggering if the IP was in the trust list.  So, rather than seeing "Bypassed all rules" scenario, you would see a "Bypassed SOME rules" situation.  Did I get this right?

Yet another stupid idea I had, and I think it is either impossible or real hard is to have a filter list that looks at the *next to the last* IP that was used to deliver the message.  If enabled, this list would contain a list of filters to use against the previous IP.  So, if the list looked like:

dnsbl
rdns

This would instruct the software to use *not* the connecting IP but use the IP before that for the above tests.   THis would add huge overhead I believe and would probably break every rule in the book BUT it would kill several birds with one stone.

Hows that for a hair brained thought?

Regards,

Thanks for thinking along Dan, appreciate it.

ok, i did some researching on our MX entries (The ISP is also running the primay DNS) .

It is set up like this:

preference: 10 : mail.ourdomain.com

20: relay1.ISPdomain.net

20: relay2.ISPDomain.net

30: mail1.ourdomain.com

30: mail2.ourdomain.com

Only the mail.ourdomain.com is under my control.

I think things happen like this: the secondary mailservers of the ISP (mail1, mail2) are only receiving the inbound mails when the primary is unavailable. For some reason the relay's ip's are beeing put in the mail headers as beeing the originating ip. So when inbound mails got buffered and were using honeypot adresses, the relay's ip's got blacklisted.

Resuming; the honeypot is blacklisting the relay1, relay2 ip's, because of mail that is sent to us, gets buffered on mail1/mail2 , and is using honeypot adresses.

My first thought was to make a script that checks the honeypotblockededIP.txt file for presence of those 2 ip's and remove if found, But that isnt a very elegant solution, and would cost additional CPU load.

does this make sense to you?

I don't know the exact configuration of the relay servers, since they are managed externally, by our ISP.

But as far as i know they act as gateways when our smtp server is responding, and the incoming mais are relayed 'as is' to our smtp host (the spamfilter).

However, when our smtp host is unavailable (due to a crash or overload) all incoming mails are forwarded to the secondary , and this secondary keeps trying to deliver the mails on regular intervals.

I have no control over the secondary, and cannot place a spamfilter in fron of it.

90% of all mails are delivered to the primary, but for some reason, mails get directed to the secondary as well even when the primary is up and running.(usually during the night).

(Maybe some of the spammers deliberately send mail to secondary server ip's)

I can live with the fact that all ip based checks will be worthless in this case, but i DO want the mails to be passed thru whatever filters that are still valid. (keywords, surbl, authedTOlist, bayes, honeypot)

All in all, spamfilter is allready doing a GREAT job, it catches 95% of all spam (even under the conditions described above)

I would really like to use the honeypot as well, since it WOULD actually catch some flies, and it allready caught some. All i'm asking for is the option to prevent *some* ip's from beeing added to the honeypotblacklist when its active.

Regards,

Marco