Honey pot email addresses, best practice?

New features and ideas to improve MailCleaner

Moderators: Pascal, mentor, FlorianB, bourgeois

Posts: 12
Joined: Wed Jan 14, 2015 3:54 pm
How did you hear about Mailcleaner: peer

Honey pot email addresses, best practice?

Postby cgrayHappyMac » Wed Jun 24, 2015 6:51 pm

I am seeing UBE from IPs which *eventually* appear on a RBL, but only after they have sent spam to many email accounts on servers I manage. I'm trying to figure a way to get ahead of them, and I keep coming back to honey potting.
* the spam is sent from the same throwaway server instance (which has SPF, DKIM, RDNS, and other authentic looking features)
* the spam is individually sent TO many separate mailboxes, including former employees, dictionary box names, &etc

There are two other brief discussions in the Features request forum which address honey pot email addresses, and they advocate adding a spamassasin rule to highly spam rank email using custom rules which look for honeypot email addresses in the TO field, then forward this to bayesian analysis so that subsequent identical emails are identified by content. This does not seem as useful as just blacklisting the IP as it relies on content analysis, when I already know the sending IP is malicious.

I am thinking a better solution would be to:
* blacklist the IPs of any servers sending email to specially designated (invalid) email addresses

but I can't think of a way to implement this without some elaborate mojo, with some honeypot solution which:
* receives all honey pot email
* identifies the sending server IP address
* provides a local DNS-based RBL service
* add a check to this service to the MailCleaner SMTP connection checks RBL stage
And provide some sort of aging to automatically remove the IPs after n days of inactivity (IP pool self-healing)

This would allow me to quickly identify and block known malicious servers before they are identified by Spamhaus et al RBLs.

I've googled around, but haven't found anything which would be useful in this fashion.
It seems like this would be a nifty addition to mailcleaner: a local honeypot RBL...

Is there SOME OTHER WAY to better address this kind of problem?
Is this a stupid idea and am I missing something obvious?
Posts: 291
Joined: Thu Mar 07, 2013 2:12 am
How did you hear about Mailcleaner: google

Re: Honey pot email addresses, best practice?

Postby cglmicro » Sun Jun 28, 2015 4:06 am

Good Line of thinking !
I'm tired of doing this manually, and some spams are getting through before I add the IP.
Posts: 44
Joined: Thu Apr 30, 2015 3:02 am
How did you hear about Mailcleaner: Web search through forums

Re: Honey pot email addresses, best practice?

Postby Bookworm » Sun Jun 28, 2015 7:43 pm

Well, the simplest way to implement it, at least that I can think of, is to have a 'honeypot' address box be built in with a forward to a _local_ machine mail account (/var/spool/mail/honeypot, for example). Any honeypot addresses would forward to the same local mbox or maildir.

That way you can seed your web site, or other sites, with invisible spam addresses, and they'll drop in there. Every minute, a process would scrape through and look for the sending IP, and drop it into the blacklist. You'd probably have to adjust the blacklist filter process to reload that blacklist more frequently than the normal 'reload', however, as the spammers can pound out hundreds of send attempts in just a minute or two.
Posts: 12
Joined: Wed Jan 14, 2015 3:54 pm
How did you hear about Mailcleaner: peer

Re: Honey pot email addresses, best practice?

Postby cgrayHappyMac » Tue Jul 14, 2015 7:42 pm

We are getting a ton of spam which just is not being effectively filtered out. It seems that this spammer is getting very good at avoiding servers which the major RBLs are monitoring, and by the time they eventually do get listed, we've already been deluged by dozens of spams across all mailboxes from single IPs. When those IPs get listed, they spin up others. These fake servers have SPF and DKIM records, correct reverse DNS lookups, and for-the-moment clean IP addresses. To MailCleaner, these spam servers smell clean.

I am thinking a spamtrap or honeypot would be especially useful to quickly identify and avoid connections from relays which send email to local email addresses which only receive spam. I figure we could reduce spam entering real local mailboxes by 75% or more.

Rough outline:
* Setup new local mailbox in Exim to receive all honeypot email
* Setup aliases so that email to each spamtrap address is routed to the local spamtrap mailbox; skip local 'Recipient verification' for these addresses at SMTP phase.
* Script to extract from email the IP of connecting mail server, store IPs in blacklist, delete mail from mailbox
* Script to remove IPs from blacklist after (user defined) period of time, so blacklist self-prunes
* Set cron job to call scripts
* Tie in to as either an additional SMTP checks option, a custom spamc rule, or perhaps a new Anti-spam module
* Provide UI to manage and edit spamtrap aliases, edit TTL on table entries, view table of listed IPs, view stats

This begs to be a new Anti-spam Module within MailCleaner. I am leery to try to reverse engineer / integrate something like this without development documentation, which I'm not seeing on this site, and when there doesn't seem to be (any on-going) development of this mature solution.

Any thoughts from the current MC developers whether something like this would be welcome? Are you receptive to outside code contributions?
Posts: 12
Joined: Wed Jan 14, 2015 3:54 pm
How did you hear about Mailcleaner: peer

Re: Honey pot email addresses, best practice?

Postby cgrayHappyMac » Thu Nov 03, 2016 1:03 pm

Dealing with email from snowshoe spammers continues to be a daily chore. It's coming to the point where small businesses simply cannot host their own email anymore. MailCleaner Community Edition is no longer up to the task, and it's sounding like crickets on any interest to plug the holes.

Return to “Features request”

Who is online

Users browsing this forum: No registered users and 1 guest