Re: Honeypot email addresses
Excellent feature - I look forward to using it.
It does lead me to another question however. Using a spam honeypot would
lead to a large corpus of SPAM. My corpus of HAM, but its very nature,
would be much smaller. Are there any negative implication to training
the Bayesian filters with thousands (or tens of thousands) SPAM message
but only a couple hundred HAM messages?
Kind Regards,
David
David Flanigan
Mobile: +1.513.560.8231
E: daveatflanigan.net W: http://www.flanigan.net
On 2015-01-08 18:13, David B Funk wrote:
On Thu, 8 Jan 2015, Alex Regan wrote:
How about using a domain specifically for creating a honeypot, of you only
need an email@address no point in registering a domain soley for this, some
might think its better, but I see no real advantage to it over using a well
known existing domain, infact if you examine your logs you might see one
already there you can use, for example, I use a few
This represents the largest problem I have, because any well-known
existing domain has zen running at SMTP level, which makes it impossible
to whitelist for a specific account. I'd have to disable RBLs at SMTP
connect time, as well as greylisting...
In sendmail, there's the delay_checks feature which if enabled
will postpone the RBL/blacklist milter checks until after the 'RCPT
to:'
SMTP phase. This enables things such as 'SPAMFRIENDS' filters
in your access DB making it possible to use RBL/blacklists/milters and
still let all senders get messages to specific selected recipients
(EG postmaster or selected spamtrap/honeypot addresses).
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.edu College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
--
Re: Honeypot email addresses
Am 09.01.2015 um 02:01 schrieb David Flanigan: Excellent feature - I look forward to using it. It does lead me to another question however. Using a spam honeypot would lead to a large corpus of SPAM. My corpus of HAM, but its very nature, would be much smaller. Are there any negative implication to training the Bayesian filters with thousands (or tens of thousands) SPAM message but only a couple hundred HAM messages? a perfect bayes has at least 50/50 percent, more ham in doubt is better, i would in any case re-view the messages before train them, most are open-relay-tests or 100% identical crap not worth to taint the bayes 1000 times with the same copy and such crap here below my current bayes-counts the 1,3M bayes_seen is for sure a bug becuse it contains random message parts which leads also in not recognized already trained messages, hence a find with a 24 hour limt since i save the corpus forever [root@mail-gw:~]$ sa-learn.sh Replacing Subject: [SPAM] with Subject: (case sensitive) (partial words matched) Replacing Subject: [SPAM] with Subject: (case sensitive) (partial words matched) 09-01-2015 02:32:19: Proceed SPAM Samples 09-01-2015 02:32:19: Proceed HAM Samples 09-01-2015 02:32:19: Done 0.000 0 3 0 non-token data: bayes db version 0.000 0 7511 0 non-token data: nspam 0.000 0 7565 0 non-token data: nham 0.000 01015029 0 non-token data: ntokens 0.000 0 993467899 0 non-token data: oldest atime 0.000 0 1420765927 0 non-token data: newest atime 0.000 0 1420765955 0 non-token data: last journal sync atime 0.000 0 0 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count insgesamt 27M -rw--- 1 sa-milt sa-milt 13K 2015-01-09 02:30 bayes_journal -rw--- 1 sa-milt sa-milt 1,3M 2015-01-09 00:59 bayes_seen -rw--- 1 sa-milt sa-milt 39M 2015-01-09 02:12 bayes_toks -rw--- 1 sa-milt sa-milt 98 2014-08-21 17:47 user_prefs On 2015-01-08 18:13, David B Funk wrote: On Thu, 8 Jan 2015, Alex Regan wrote: How about using a domain specifically for creating a honeypot, of you only need an email@address mailto:email@address no point in registering a domain soley for this, some might think its better, but I see no real advantage to it over using a well known existing domain, infact if you examine your logs you might see one already there you can use, for example, I use a few This represents the largest problem I have, because any well-known existing domain has zen running at SMTP level, which makes it impossible to whitelist for a specific account. I'd have to disable RBLs at SMTP connect time, as well as greylisting... In sendmail, there's the delay_checks feature which if enabled will postpone the RBL/blacklist milter checks until after the 'RCPT to:' SMTP phase. This enables things such as 'SPAMFRIENDS' filters in your access DB making it possible to use RBL/blacklists/milters and still let all senders get messages to specific selected recipients (EG postmaster or selected spamtrap/honeypot addresses) signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On Thu, 8 Jan 2015, Alex Regan wrote:
How about using a domain specifically for creating a honeypot, of
you only need an email@address no point in registering a domain soley
for this, some might think its better, but I see no real advantage to it
over using a well known existing domain, infact if you examine your logs
you might see one already there you can use, for example, I use a few
This represents the largest problem I have, because any well-known existing
domain has zen running at SMTP level, which makes it impossible to whitelist
for a specific account.
I'd have to disable RBLs at SMTP connect time, as well as greylisting...
In sendmail, there's the delay_checks feature which if enabled
will postpone the RBL/blacklist milter checks until after the 'RCPT to:'
SMTP phase. This enables things such as 'SPAMFRIENDS' filters
in your access DB making it possible to use RBL/blacklists/milters and
still let all senders get messages to specific selected recipients
(EG postmaster or selected spamtrap/honeypot addresses).
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: Honeypot email addresses
On 01/07/2015 02:31 PM, Reindl Harald wrote: Am 07.01.2015 um 20:23 schrieb Alex: I'm also wondering what exactly you're taking from these messages that are received? Are you blocking based on IP? Creating header/body rules? Those are usually transferable to other systems, but what about bayes? How can you use it for bayes when that doesn't transfer very easily to other systems? depends how you build your bayse mine is a phyiscal ham and a spam-folder with raw-mails and a script calling sa-learn which makes it easy to transfer to other systems as well as maintain the corpus over years It's not necessarily an issue with the bayes database itself, but rather the content of the database - emails comprising your ham database may not constitute ham for my company, for example. Thanks, Alex * no databases * no magic * no auto learning * just a global bayes with a corpus of 15000 hand-selected mails in the last 5 months with a nearly perfect hit-rate and zero false-positives highly scored
Re: Honeypot email addresses
How about using a domain specifically for creating a honeypot, of you only need an email@address no point in registering a domain soley for this, some might think its better, but I see no real advantage to it over using a well known existing domain, infact if you examine your logs you might see one already there you can use, for example, I use a few This represents the largest problem I have, because any well-known existing domain has zen running at SMTP level, which makes it impossible to whitelist for a specific account. I'd have to disable RBLs at SMTP connect time, as well as greylisting... Thanks so much for your help. I see now there were like 60 messages in this thread, so I probably should have started a new thread. Thanks, Alex
Re: Honeypot email addresses
Am 08.01.2015 um 22:57 schrieb Alex Regan: On 01/07/2015 02:31 PM, Reindl Harald wrote: Am 07.01.2015 um 20:23 schrieb Alex: I'm also wondering what exactly you're taking from these messages that are received? Are you blocking based on IP? Creating header/body rules? Those are usually transferable to other systems, but what about bayes? How can you use it for bayes when that doesn't transfer very easily to other systems? depends how you build your bayse mine is a phyiscal ham and a spam-folder with raw-mails and a script calling sa-learn which makes it easy to transfer to other systems as well as maintain the corpus over years It's not necessarily an issue with the bayes database itself, but rather the content of the database - emails comprising your ham database may not constitute ham for my company, for example. your opinion mine is * if it is ham and handselected than it is ham * if it is spam and handselected than it is spam hence the *global* bayse i maintain for a few months for 1500 users with very different businesses with the help of some of them works that much better than the previous light maintained global and the mostly completly useless user-bayes which don't reach the 200/200 balance or are trained by people not understand how a bayes works at the end of the day you need *as much as possible* samples for ham and spam where you trust the classification - currently newsletters are not marked as spam while a lot of similar *looking* messages are trustable blocked at milter level * no databases * no magic * no auto learning * just a global bayes with a corpus of 15000 hand-selected mails in the last 5 months with a nearly perfect hit-rate and zero false-positives highly scored signature.asc Description: OpenPGP digital signature
RE: Honeypot email addresses
How about using a domain specifically for creating a honeypot you only need an email@address no point in registering a domain soley for this, some might think its better, but I see no real advantage This represents the largest problem I have, because any well-known existing domain has zen running at SMTP level, which makes it impossible to whitelist for a specific account. I'd have to disable RBLs at SMTP connect time, as well as greylisting... That's one big plus for a dedicated spamtrap(sub)domain, you can move it anywhere without postscreen/rbl's/spamassassin/whatever. Just plain mta, accept everything and throw it in the analyzer. :) /MJ
Re: Honeypot email addresses
On 08/01/2015 05:23, Alex wrote: I have an old domain with a number of dormant accounts that I'd like to use. The domain also uses several RBLs, so a majority of the spam is rejected before it's ever received, so it's less than effective. You need to whitelist at least the trap addresses to be effective. I'm also wondering what exactly you're taking from these messages that are received? Are you blocking based on IP? Creating header/body Blocking by IP is the most common - providing the addresses you use as traps have never been used, in your case, maybe not such a good idea because you/someone once used them, and it might be an old friend who went grizzly adams for 10 years and came back trying to genuinely talk to you or the recipient. Or are you only limited to gathering info based on the 'user unknown' messages, Never ever do that! people make typos all the time. Do you have scripts that parse your maillog? twice daily, used to be hourly but thats not nice when they grow to gig a day per server, thinking about changing it to once a day before log rolls. Do you have any type of revocation ability, to keep track of when they were added so they can be removed after some time? its a bash script, that uses awk so can add dates with strftime() so I know when it was added, I use this to go through and clean it up every once in a while (listings on trap hits stay for at least 1 yr unless I get delist request) How about using a domain specifically for creating a honeypot, of you only need an email@address no point in registering a domain soley for this, some might think its better, but I see no real advantage to it over using a well known existing domain, infact if you examine your logs you might see one already there you can use, for example, I use a few email addresses, my private one only friends have, my list address (this one), my opensource contrib address (yeah its public too), work address (nobody has) and another for usenet, the usenet one was obviously botched by a spambot once and it repeated the user@ component, lets say it was xyz@ausics so I always see hits in mail logs for xyzxyz@ausics rather funny, but awesome, because in addition to my never-used long term trap addresses, I added that one too and it catches several hundred a week alone, obviouly spammers trade lists. So, like I said, you might already be seeing one you can use. (footnote: that usenet address has been in use for well over 20 years, so YMMV) sorts? Would you create a basic webpage and populate that with email addresses? Then set up the mail system to accept all mail... That can help, you'd only need a couple, and join usenet thats a good way to catch em. also pop a fake email address in your sigs on some forums.
Re: Honeypot email addresses
Hi, I was hoping it was okay to resurrect a thread from a few months ago and ask a few questions regarding creating some type of honeypot for spammers. Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have an old domain with a number of dormant accounts that I'd like to use. The domain also uses several RBLs, so a majority of the spam is rejected before it's ever received, so it's less than effective. I'm also wondering what exactly you're taking from these messages that are received? Are you blocking based on IP? Creating header/body rules? Those are usually transferable to other systems, but what about bayes? How can you use it for bayes when that doesn't transfer very easily to other systems? Or are you only limited to gathering info based on the 'user unknown' messages, as you said? Do you have scripts that parse your maillog? Do you have any type of revocation ability, to keep track of when they were added so they can be removed after some time? Some tips were mentioned in this thread for seeding a user account to receive spam, but there was a lot of back-and-forth, and it was unclear to me which were really advisable. Is it advisable to use 'unsubscribe' links in spam sent to some address? How about using a domain specifically for creating a honeypot, of sorts? Would you create a basic webpage and populate that with email addresses? Then set up the mail system to accept all mail... I don't think I'm asking for anything that could cause spammers to alter their tactics, but please do tell me if otherwise. Sure appreciate any ideas. Thanks, Alex
Re: Honeypot email addresses
Am 07.01.2015 um 20:23 schrieb Alex: I'm also wondering what exactly you're taking from these messages that are received? Are you blocking based on IP? Creating header/body rules? Those are usually transferable to other systems, but what about bayes? How can you use it for bayes when that doesn't transfer very easily to other systems? depends how you build your bayse mine is a phyiscal ham and a spam-folder with raw-mails and a script calling sa-learn which makes it easy to transfer to other systems as well as maintain the corpus over years * no databases * no magic * no auto learning * just a global bayes with a corpus of 15000 hand-selected mails in the last 5 months with a nearly perfect hit-rate and zero false-positives highly scored signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 11/21/2014 09:49 AM, David F. Skoll wrote: On Fri, 21 Nov 2014 08:43:22 -0800 (PST) John Hardin jhar...@impsec.org wrote: On a public mailng list isn't a great place to discuss such tactics... I suspect spammers are dumb and will just vacuum up any address they can find. Also, the scammers who sell CDs with millions of email addresses on them are unlikely to do anything but the most cursory checking of the addresses. Make a honeypot subdomain, put up any web content with email addresses and I guarantee you'll start receiving email on those addresses within a few days. Regards, David. Having it appear in a resume on any of the job sites (dice, monster, ladders, etc) is a good way to get it harvested. So is posting to mozilla-gene...@mozilla.org or net...@vger.kernel.org ...
Re: Honeypot email addresses
On 04/12/2014 00:54, Christian Grunfeld wrote: It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message - sure this was a lot more common in years gone by, but I've not seen any such evidence of it in almost 10 years, and if you did, well, that's not my problem, its the problem of your provider who obviously doesn't care enough to educate its users of the dangers of spam, period.. lol ! ! ! is it possible to educate users against spam? if that were the case this list would not be needed and we would be free ourselves from reading your posts, period ! you must be doing it wrong, the users of today are far wiser than they were 5 years ago, even my almost 80yo dad knows to handle spam, although its hard to do, get your users to *read* their welcome emails, and dont have a lawyer write the stuff, write it so an 10yo kid can understand it, its also rare spam gets passed SA anyway with our myriad of custom rules, and we block at MTA level from multiple DNSBL's amongst many other milter tricks which I'm not going into in a public forum :) So educate them well, and let SA do its job, and we wouldnt need to read your posts either.
Re: Honeypot email addresses
read my reply to Chris, its rather simple - if you care (and we have some pretty damn illiterate users, if they can get it right, anyone can) Oh additional point, it also helps if your CSR's also have a clue, and sound confident when talking to users, if they sound hesitant u's and ars, then the user will have less confidence, christ, it aint rocket science. On 04/12/2014 01:02, Dave Pooser wrote: It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message Really? I see it all the time, often with a message body of TAKE ME OFF THIS LIST (because four exclamation points will convince a spammer to stop, while three just amuse the spammer). Also, typos happen. In my opinion a honeypot is great for getting data in bulk, but it still has to be manually categorized before it's fed to the RBL generator or used for bayesian learning. The big advantage of a honeypot vs user-marked spam, IMO, is that you can be positive that the honeypot did NOT sign up for an email list and then start marking it as spam in lieu of the unsubscribe button.
Re: Honeypot email addresses
Am 03.12.2014 um 23:56 schrieb Philip Prindeville: On 11/21/2014 09:49 AM, David F. Skoll wrote: On Fri, 21 Nov 2014 08:43:22 -0800 (PST) John Hardin jhar...@impsec.org wrote: On a public mailng list isn't a great place to discuss such tactics... I suspect spammers are dumb and will just vacuum up any address they can find. Also, the scammers who sell CDs with millions of email addresses on them are unlikely to do anything but the most cursory checking of the addresses. Make a honeypot subdomain, put up any web content with email addresses and I guarantee you'll start receiving email on those addresses within a few days. Regards, David. Having it appear in a resume on any of the job sites (dice, monster, ladders, etc) is a good way to get it harvested. So is posting to mozilla-gene...@mozilla.org or net...@vger.kernel.org ... and *that* is exactly hwat you should avoid: post a honeypot address somewhere actively - a honeypot address should never be submitted because you ask for troubles and false positives doing so signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 12/2/2014 5:32 PM, LuKreme wrote: I have *never* considered Barracuda to be reliable. At least they have stopped their practice of listing my server and then sending me spam offering to sell me their crapware to keep it off blacklists for per month. I think there's a direct correlation between how reliable an RBL is and how easy it is to get de-listed! Ted
Re: Honeypot email addresses
Am 03.12.2014 um 02:32 schrieb LuKreme: another recent example: Spamhaus blocked GMX/11/Web.de completly *by a mistake*, no problem in case of scoring, a ruined weekend if we had used it as only source The extremely occasional mistaken black is more than made up for by the vast quantities of spam that are blocked every day. I reject at SMTP based on zen. If zen is mistaken, at least the sender doesn’t think the mail as delivered and f they (and their MUA) are competent, they know WHY their mail didn’t go through. what is based on zen? that is a aggregate list and sensible to use it score-based which the simple settings below you catch *much more* then with zen alone *and* reduce false-positives greatly postscreen_dnsbl_ttl = 5m postscreen_dnsbl_action = enforce postscreen_greet_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.[10;11;12]*4 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 wl.mailspike.net=127.0.0.[18;19;20]*-2 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On Thu, 4 Dec 2014, Noel Butler wrote:
On 04/12/2014 00:54, Christian Grunfeld wrote:
It would be very rare, and if so you would ever more rare CC the
entire list of addresses on your spam message -
sure this was a lot more common in years gone by, but I've not seen any
such evidence of it in almost 10 years, and if
you did, well, that's not my problem, its the problem of your provider
who obviously doesn't care enough to educate its
users of the dangers of spam, period..
lol ! ! ! is it possible to educate users against spam?
if that were the case this list would not be needed and we would be free
ourselves from reading your posts, period !
you must be doing it wrong, the users of today are far wiser than they were 5
years ago, even my almost 80yo dad knows to handle
spam, although its hard to do, get your users to *read* their welcome emails,
and dont have a lawyer write the stuff, write it so an
10yo kid can understand it, its also rare spam gets passed SA anyway with our
myriad of custom rules, and we block at MTA level from
multiple DNSBL's amongst many other milter tricks which I'm not going into in a
public forum :)
So educate them well, and let SA do its job, and we wouldnt need to read your
posts either.
I have to agree with Dave, Christian, et-all. It's not frequent but not
rare to see a reply-all Take me off this list!!!.
Even if you've got the smartest, best educated users who will never make
that mistake and a totally perfect spam filtering system that never has a
FN there are other people/systems in the world which may be on that
shotgun spam recpient list which may be less than perfect.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: Honeypot email addresses
On 12/04/2014 05:32 AM, Reindl Harald wrote: Am 03.12.2014 um 23:56 schrieb Philip Prindeville: On 11/21/2014 09:49 AM, David F. Skoll wrote: On Fri, 21 Nov 2014 08:43:22 -0800 (PST) John Hardin jhar...@impsec.org wrote: On a public mailng list isn't a great place to discuss such tactics... I suspect spammers are dumb and will just vacuum up any address they can find. Also, the scammers who sell CDs with millions of email addresses on them are unlikely to do anything but the most cursory checking of the addresses. Make a honeypot subdomain, put up any web content with email addresses and I guarantee you'll start receiving email on those addresses within a few days. Regards, David. Having it appear in a resume on any of the job sites (dice, monster, ladders, etc) is a good way to get it harvested. So is posting to mozilla-gene...@mozilla.org or net...@vger.kernel.org ... and *that* is exactly hwat you should avoid: post a honeypot address somewhere actively - a honeypot address should never be submitted because you ask for troubles and false positives doing so Not necessarily. If I post to a list with this address, and wait 60 days, I can assume that 99.999% of email that comes back after that date is not related to the original posting. Further, after 15 days, anything which doesn't also copy the list is almost certainly Spam. -Philip
Re: Honeypot email addresses
On 12/4/14, 3:10 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Not necessarily. If I post to a list with this address, and wait 60 days, I can assume that 99.999% of email that comes back after that date is not related to the original posting. Further, after 15 days, anything which doesn't also copy the list is almost certainly Spam. Eh, if I'm researching an odd bug, for instance, and find a 2-year old post from someone who had the same problem but don't see any resolution posted, I'll probably ping the OP offlist with a Hey, did you ever find the fix for that problem $FOO you were having? since I can't assume they're still subscribed to the list. I may or may not copy the list on that email, though I certainly will if I come up with an answer. obligatory http://xkcd.com/979/ reference here -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com ...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!! -- Bill McKenna
Re: Honeypot email addresses
On Dec 4, 2014, at 2:30 PM, Dave Pooser dave...@pooserville.com wrote: On 12/4/14, 3:10 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Not necessarily. If I post to a list with this address, and wait 60 days, I can assume that 99.999% of email that comes back after that date is not related to the original posting. Further, after 15 days, anything which doesn't also copy the list is almost certainly Spam. Eh, if I'm researching an odd bug, for instance, and find a 2-year old post from someone who had the same problem but don't see any resolution posted, I'll probably ping the OP offlist with a Hey, did you ever find the fix for that problem $FOO you were having? since I can't assume they're still subscribed to the list. I may or may not copy the list on that email, though I certainly will if I come up with an answer. obligatory http://xkcd.com/979/ reference here I’ll have to remember to make the posting sufficiently uninteresting to be remembered for any significant length of time. ;-) -Philip
Re: Honeypot email addresses
It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message - sure this was a lot more common in years gone by, but I've not seen any such evidence of it in almost 10 years, and if you did, well, that's not my problem, its the problem of your provider who obviously doesn't care enough to educate its users of the dangers of spam, period.. lol ! ! ! is it possible to educate users against spam? if that were the case this list would not be needed and we would be free ourselves from reading your posts, period !
Re: Honeypot email addresses
It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message Really? I see it all the time, often with a message body of TAKE ME OFF THIS LIST (because four exclamation points will convince a spammer to stop, while three just amuse the spammer). Also, typos happen. In my opinion a honeypot is great for getting data in bulk, but it still has to be manually categorized before it's fed to the RBL generator or used for bayesian learning. The big advantage of a honeypot vs user-marked spam, IMO, is that you can be positive that the honeypot did NOT sign up for an email list and then start marking it as spam in lieu of the unsubscribe button. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com ...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!! -- Bill McKenna
Re: Honeypot email addresses
On 02/12/2014 15:28, Ted Mittelstaedt wrote: On 12/1/2014 8:47 PM, Noel Butler wrote: On 02/12/2014 09:07, Reindl Harald wrote: Am 01.12.2014 um 23:46 schrieb Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's. This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Most honeypots are not used in such a draconian fashion. But go ahead and be Draconian - I guess the only way you both can justify a win on this argument is by assuming people use honeypots in ways that simply are not done in reality. For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bays feeding sources. Don't bother engaging the two Zealots, you will be wasting your time. eyeroll Ted most dont use it this way ? backup your statement with evidence. I await your masses of proof do you even read what you dribble before click send?
Re: Honeypot email addresses
On 12/2/2014 12:28 AM, Ted Mittelstaedt wrote: For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bayes feeding sources. No, it started as a discussion about honeypots to help the SOUGHT 2.0 project which could use more volunteers, BTW! Regards, KAM
Re: Honeypot email addresses
On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. -- You're just impressed by any pretty girl who can walk and talk. She doesn't have to talk.
Re: Honeypot email addresses
On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org, we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. A single spamtrap hit for an IP that has been seen for a few days only says quite a lot. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. Now you've seen one that doesn't :) -- Matthias
Re: Honeypot email addresses
On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? Ted
Re: Honeypot email addresses
On 12/2/2014 12:24 PM, Ted Mittelstaedt wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? For me, spam is always about minimizing collateral damage but it is far from an exact science and subject to friendly debate to improve things for everyone. Let's remember who the bastards are (the spammers) and not attack people's honeypots/DNSWLs, etc. because if you don't like their policies, you don't have to use them. Regards, KAM
Re: Honeypot email addresses
On 12/2/2014 9:31 AM, Kevin A. McGrail wrote: On 12/2/2014 12:24 PM, Ted Mittelstaedt wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? For me, spam is always about minimizing collateral damage but it is far from an exact science and subject to friendly debate to improve things for everyone. Let's remember who the bastards are (the spammers) and not attack people's honeypots/DNSWLs, etc. because if you don't like their policies, you don't have to use them. Agreed, I will also point out I didn't start the attacks. I do not agree with the logic that using email addresses on a domain that have been deactivated for a long period of time - years that is - as honeypots is going to result in blocking a valid sender. My assertion got attacked - I refuted those attacks with logic - my assertion got attacked more with illogical statements like the one I just refuted a few minutes ago. Data from a single honeypot has some value. Data from hundreds of them has far, far more value. If some of those hundreds of honeypots are old email addresses that were bouncing mail for the last 5 years with unknown user then it isn't logical to assert that those will result in blocking a legitimate sender. At least, not in what I consider a reasonable filter. Ted Regards, KAM
Re: Honeypot email addresses
Am 02.12.2014 um 18:24 schrieb Ted Mittelstaedt: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? surely, on *one* RBL Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? no, i am saying nobody right in his mind is rejecting mails because *one* RBL but based on scores and with delisting after a few days - each honeypot one RBL if you put a lot of RBL's as well as a lot of DNSWL in the score mix you unlikely have false positives because *one* honeypot it only becomes a problem when the maintainers of honeypot's are dumb as bread and re-use previous legit addresses as trap or what i heard crazy people suggest register on porn sites with trap addresses the large ISP's like gmail are typically also on whitelists (including one of our internal) and so they need to hit a lot of honeypots within a short timeframe to get blocked, but if they do - so be it signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp3RZaW1KKvL.pgp Description: PGP signature
Re: Honeypot email addresses
Am 02.12.2014 um 19:22 schrieb Niamh Holding: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. you should re-consider that, your users problems as said: the linux.com newsletter get blocked by b.barracudacentral.org which is normally a trustful blacklist (their URIBL's on the devices are crap playing lottery with email) a since we replaced the device i receive it again (b.barracudacentral.org is still used, but as *one* RBL in the postscreen mix) another recent example: Spamhaus blocked GMX/11/Web.de completly *by a mistake*, no problem in case of scoring, a ruined weekend if we had used it as only source signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 12/02/2014 07:22 PM, Niamh Holding wrote: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. Could we stop beating this dead horse? There's way better places to discuss philosophy for example List Guidelines: http://www.new-spam-l.com/admin/faq.html List Information: https://spammers.dontlike.us/mailman/listinfo/list and the good old NANAE news.admin.net-abuse.email
Re: Honeypot email addresses
On 03/12/2014 03:07, Matthias Leisi wrote: On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org [1], we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. I see no difference, if I never have, never will, use say deletet...@ausics.net and its used as a trap address (actually used as examples in some of my pages/blog etc), *anyone* who sends to that address, has got it via means of scraping, it clearly means it was taken from a webpage, or a mailing list archive, if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address, and reputation, trust - my arse, again, no valid or legitimate reason to send to that trap address, its sole purpose in life is to catch those who spam, if one person sees it, they *will* be doing it to many many many others. Noel PS (for the spammers, since we know you scum read this list - that example is only 1 of 7 trap addresses over a couple of domains I use, exempt it, I'll still catch you out) Links: -- [1] http://dnswl.org
Re: Honeypot email addresses
.if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address ït is not really true. If a spammer sends to a list of addresses and among them is a spamtrap address a user might respond to that list and so you'd be blocking a legit ip or domain ! cheers 2014-12-02 20:04 GMT-03:00 Noel Butler noel.but...@ausics.net: On 03/12/2014 03:07, Matthias Leisi wrote: On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org, we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. I see no difference, if I never have, never will, use say deletet...@ausics.net and its used as a trap address (actually used as examples in some of my pages/blog etc), *anyone* who sends to that address, has got it via means of scraping, it clearly means it was taken from a webpage, or a mailing list archive, if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address, and reputation, trust - my arse, again, no valid or legitimate reason to send to that trap address, its sole purpose in life is to catch those who spam, if one person sees it, they *will* be doing it to many many many others. Noel PS (for the spammers, since we know you scum read this list - that example is only 1 of 7 trap addresses over a couple of domains I use, exempt it, I'll still catch you out)
Re: Honeypot email addresses
On 03/12/2014 09:18, Christian Grunfeld wrote: .if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address ït is not really true. If a spammer sends to a list of addresses and among them is a spamtrap address a user might respond to that list and so you'd be blocking a legit ip or domain ! It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message - sure this was a lot more common in years gone by, but I've not seen any such evidence of it in almost 10 years, and if you did, well, that's not my problem, its the problem of your provider who obviously doesn't care enough to educate its users of the dangers of spam, period.
Re: Honeypot email addresses
On Dec 2, 2014, at 10:24 AM, Ted Mittelstaedt t...@ipinc.net wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? If a message claims to come from Yahoo and comes from xyz.tl it is already rejected. Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? I don’t recall ever saying I had my own honeypots. -- Some books are undeservedly forgotten; none are undeservedly remembered
Re: Honeypot email addresses
On Dec 2, 2014, at 11:28 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.12.2014 um 19:22 schrieb Niamh Holding: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. you should re-consider that, your users problems as said: the linux.com newsletter get blocked by b.barracudacentral.org which is normally a trustful blacklist (their URIBL's on the devices are crap playing lottery with email) a since we replaced the device i receive it again (b.barracudacentral.org is still used, but as *one* RBL in the postscreen mix) I have *never* considered Barracuda to be reliable. At least they have stopped their practice of listing my server and then sending me spam offering to sell me their crapware to keep it off blacklists for per month. another recent example: Spamhaus blocked GMX/11/Web.de completly *by a mistake*, no problem in case of scoring, a ruined weekend if we had used it as only source The extremely occasional mistaken black is more than made up for by the vast quantities of spam that are blocked every day. I reject at SMTP based on zen. If zen is mistaken, at least the sender doesn’t think the mail as delivered and f they (and their MUA) are competent, they know WHY their mail didn’t go through. -- Oh, the sweet wine of youth goes sour over time Seems like the more that you lose, the more you ache to find
Re: Honeypot email addresses
On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net mailto:matth...@leisi.net wrote: Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet domain blocking list is already done with SpamAssassins URIBL only URLs found in the email, that’s very limited. blocking sender domains blindly is error prone because you penalty a legit domain because some faced forged senders You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? I think they do know the difference, and even in the case they do collateral damage, they provide public resolution forms, as long as the sender knows how to resolve the block... Have you tried to block based on the domain in the envelope from or From: header? What is your experience? My experience says it is very useful. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Honeypot email addresses
Am 01.12.2014 um 23:46 schrieb Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net mailto:matth...@leisi.net wrote: Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet domain blocking list is already done with SpamAssassins URIBL only URLs found in the email, that’s very limited. stats saying something different blocking sender domains blindly is error prone because you penalty a legit domain because some faced forged senders You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? no, but many i know enough admins are error prone in that case I think they do know the difference, and even in the case they do collateral damage, they provide public resolution forms, as long as the sender knows how to resolve the block... Have you tried to block based on the domain in the envelope from or From: header? What is your experience? that a good forged email is often hard to distinct My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left the point of spam filtering is get out the junk *but* the point of maintain a mailserver is to receive 100% legit mail and if that means 5 junk mails get through - so what - block 5 legit important mails because you want to achieve 100% junk free does much more damage i am coming from a commercial solution where the vendor more and more started to reahc 100% hit rate with growing collateral damage up to just inacceptable a user can easily delete 5 junk mails a user can impossible know and re-receive wrongly blocked mail do what you want - i personally would use valid RCPT addresses only over my dead body as a honeyot some months after the address no longer is used signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
Am 01.12.2014 um 23:46 schrieb Franck Martin: You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? to make it clearer: no, but *i know* for sure that *any* of that blacklists is not trustable enough to block incoming mail based one one list alone hence any sensible spamfilter is using scoring * Spamhaus SBL - blocking repeatly GMX/Web.de completly * Barracuda RBL - blocking for months the Linux foundation newsletter what i see only in the report headers using a single source for blocking mail is wrong until someone only has it's own private server only with his own mailflow to maintain disclaimer: yes, SA is blocking mail in context of a milter signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 02/12/2014 09:07, Reindl Harald wrote: Am 01.12.2014 um 23:46 schrieb Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's.
Re: Honeypot email addresses
On 02/12/2014 08:46, Franck Martin wrote: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net mailto:matth...@leisi.net wrote:Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet domain blocking list is already done with SpamAssassins URIBL only URLs found in the email, that's very limited. blocking sender domains blindly is error prone because you penalty a legit domain because some faced forged senders You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? I think they do know the difference, and even in the case they do collateral damage, they provide public resolution forms, as long as the sender knows how to resolve the block... Have you tried to block based on the domain in the envelope from or From: header? What is your experience? My experience says it is very useful. its useful to a point, but most spammers spoof, and you can spoof envelope headers easily, so unless your blocking a specific yahoo or gmail address, its pretty much a waste of resources blocking by host/domain names now days
Re: Honeypot email addresses
On 12/1/2014 8:47 PM, Noel Butler wrote: On 02/12/2014 09:07, Reindl Harald wrote: Am 01.12.2014 um 23:46 schrieb Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's. This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Most honeypots are not used in such a draconian fashion. But go ahead and be Draconian - I guess the only way you both can justify a win on this argument is by assuming people use honeypots in ways that simply are not done in reality. For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bays feeding sources. Don't bother engaging the two Zealots, you will be wasting your time. eyeroll Ted
Re: Honeypot email addresses
probably the same time it took to ipv4 become exhausted ! 2014-11-27 3:59 GMT-03:00 John Wilcock j...@tradoc.fr: Le 26/11/2014 19:56, Christian Grunfeld a écrit : even /64 DNSxLs will be expensive ! /64 lists will have 2^32 times more entries than IPv4 lists. /64 lists can *theoretically* have that many entries, yes, but it'll be a very long time before there are 2^32 times as many *allocated* IPv6 /64s as there are allocated IPv4 /32s! -- John
Re: Honeypot email addresses
On 11/26/2014 1:53 AM, Matthias Leisi wrote: On Wed, Nov 26, 2014 at 3:45 AM, Franck Martin fmar...@linkedin.com mailto:fmar...@linkedin.com wrote: You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf I'm well aware of the issues of cache efficiency and query volumes due to the vast address space. The solution to just cut off at /64 is nice, but there will be many legitimate cases where this is will not be good enough. That's why I am convinced that in the end we will need something like a tree walk algorithm, where an intelligent algorithm starts at (let's say) a /32 boundary and then gets responses to the best fitting response. Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. Maybe such a tree-walk algorithm is worth an experiment as a SpamAssassin plugin? I could likely ramble about why I don't think the real-world implications will be that large because patterns will emerge. As such, SA Plugins are very safe for experimental work and can be done without any impact on production systems in my experience. I'd support and love to see some experiments in this realm. regards, kAM
Re: Honeypot email addresses
On Wed, 26 Nov 2014 07:53:20 +0100 Matthias Leisi matth...@leisi.net wrote: Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. It's not worth the complexity. I ran an analysis quite a few years ago on the cache efficiency of DNSBLs and they're shockingly low. I collected all the IPs seen on a very busy mail server and calculated how many cache hits we'd get with Spamhaus lookups --- I believe Spamhaus has a TTL of 15 minutes. I'll have to dig up the exact numbers, but I recall something like a 90% cache *miss* rate. Commercial DNSBLs count on a low cache hit rate; otherwise they wouldn't be able to detect heavy users as easily. DNS turns out not to be a very efficient way to distribute reputation data because it changes too often. Having a local authoritative DNS server serving up the reputation zone is fine, but using public caching DNS servers to query it is a waste of resources. I'll try to dig up my results and also the Perl script I used for log analysis. Regards, David.
Re: Honeypot email addresses
Am 26.11.2014 um 14:06 schrieb David F. Skoll: On Wed, 26 Nov 2014 07:53:20 +0100 Matthias Leisi matth...@leisi.net wrote: Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. It's not worth the complexity. I ran an analysis quite a few years ago on the cache efficiency of DNSBLs and they're shockingly low. I collected all the IPs seen on a very busy mail server and calculated how many cache hits we'd get with Spamhaus lookups --- I believe Spamhaus has a TTL of 15 minutes. I'll have to dig up the exact numbers, but I recall something like a 90% cache *miss* rate. Commercial DNSBLs count on a low cache hit rate; otherwise they wouldn't be able to detect heavy users as easily the unbound stats on our inbound MX saying the opposite cache-min-ttl: 300 cache-max-ttl: 3600 2014-11-25 23:05:27 [663:1] info: server stats for thread 1: 200732 queries, 101194 answers from cache, 99538 recursions, 2679 prefetch 2014-11-25 23:05:27 [663:3] info: server stats for thread 3: 115076 queries, 51667 answers from cache, 63409 recursions, 1060 prefetch 2014-11-25 23:05:27 [663:2] info: server stats for thread 2: 125836 queries, 59737 answers from cache, 66099 recursions, 1293 prefetch 2014-11-25 23:05:27 [663:0] info: server stats for thread 0: 112853 queries, 50909 answers from cache, 61944 recursions, 1132 prefetch signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On Wed, 26 Nov 2014 14:10:04 +0100 Reindl Harald h.rei...@thelounge.net wrote: the unbound stats on our inbound MX saying the opposite How much of those are DNSBL lookups against DNSBLs with short TTLs? Regards, David.
Re: Honeypot email addresses
Am 26.11.2014 um 15:07 schrieb David F. Skoll: On Wed, 26 Nov 2014 14:10:04 +0100 Reindl Harald h.rei...@thelounge.net wrote: the unbound stats on our inbound MX saying the opposite How much of those are DNSBL lookups against DNSBLs with short TTLs? below the stats by RBL and keep in mind postscreen always asks *all* of the 18 dnsbl/dnswl and only logs the one with the highest score in case of a reject and *even* cachs results itself (in our config for 5 minutes) and so not asking every time the local resolver spamhaus.org 70980 barracudacentral.org 25851 inps.de23020 sorbs.net 9069 thelounge.net 4676 mailspike.net535 spamcop.net 482 psbl.org 344 uceprotect.net 258 manitu.net79 swinog.ch 27 spameatingmonkey.net 4 = Total DNSBL rejections:135325 signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On Nov 26, 2014, at 2:15 AM, Kevin A. McGrail kmcgr...@pccc.commailto:kmcgr...@pccc.com wrote: On 11/26/2014 1:53 AM, Matthias Leisi wrote: On Wed, Nov 26, 2014 at 3:45 AM, Franck Martin fmar...@linkedin.commailto:fmar...@linkedin.com wrote: You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf I'm well aware of the issues of cache efficiency and query volumes due to the vast address space. The solution to just cut off at /64 is nice, but there will be many legitimate cases where this is will not be good enough. That's why I am convinced that in the end we will need something like a tree walk algorithm, where an intelligent algorithm starts at (let's say) a /32 boundary and then gets responses to the best fitting response. Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. Maybe such a tree-walk algorithm is worth an experiment as a SpamAssassin plugin? I could likely ramble about why I don't think the real-world implications will be that large because patterns will emerge. As such, SA Plugins are very safe for experimental work and can be done without any impact on production systems in my experience. I'd support and love to see some experiments in this realm. I think may be you are missing the other point of this document, if there is no valid SPF or DKIM and the message was received over IPv6, then you reject it (or send it to spam). I think such rule can be easily implemented in SA. Just need to put a score of 10 on it :P As for real case scenario, Google, Microsoft and others are already doing just this. As for /64, yes there are hosting providers that have all their customers in the same /64 and other cases like this where infrastructure is not separated by /64 boundaries. I think IPv6 blocking list will be more last resort, than first line of defense (but that’s just me). Note rbldnsd works at /64 by default, with /128 exceptions.
Re: Honeypot email addresses
On Wed, Nov 26, 2014 at 6:05 PM, Franck Martin fmar...@linkedin.com wrote: As for /64, yes there are hosting providers that have all their customers in the same /64 and other cases like this where infrastructure is not separated by /64 boundaries. I think IPv6 blocking list will be more last resort, than first line of defense (but that’s just me). Note rbldnsd works at /64 by default, with /128 exceptions. DNSxLs are still the cheapest way to determine reputation because it can happen at connection stage (or as a computationally cheap input to a scoring mechanism such as SpamAssassin) - so I believe there is still value in it, and it is important to get it as efficient as possible. For my project, dnswl.org, the situation may be a bit different, because TTLs can be very long (at least in the range of hours) rather than mere minutes for DNSBLs. I'll try to hack together a plugin, I've reserved some time over the next few days. -- Matthias
Re: Honeypot email addresses
Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net mailto:matth...@leisi.net wrote: On Wed, Nov 26, 2014 at 6:05 PM, Franck Martin fmar...@linkedin.com mailto:fmar...@linkedin.com wrote: As for /64, yes there are hosting providers that have all their customers in the same /64 and other cases like this where infrastructure is not separated by /64 boundaries. I think IPv6 blocking list will be more last resort, than first line of defense (but that’s just me). Note rbldnsd works at /64 by default, with /128 exceptions. DNSxLs are still the cheapest way to determine reputation because it can happen at connection stage (or as a computationally cheap input to a scoring mechanism such as SpamAssassin) - so I believe there is still value in it, and it is important to get it as efficient as possible. Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet domain blocking list is already done with SpamAssassins URIBL blocking sender domains blindly is error prone because you penalty a legit domain because some faced forged senders signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
even /64 DNSxLs will be expensive ! /64 lists will have 2^32 times more entries than IPv4 lists. 2014-11-26 15:45 GMT-03:00 Franck Martin fmar...@linkedin.com: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net wrote: On Wed, Nov 26, 2014 at 6:05 PM, Franck Martin fmar...@linkedin.com wrote: As for /64, yes there are hosting providers that have all their customers in the same /64 and other cases like this where infrastructure is not separated by /64 boundaries. I think IPv6 blocking list will be more last resort, than first line of defense (but that’s just me). Note rbldnsd works at /64 by default, with /128 exceptions. DNSxLs are still the cheapest way to determine reputation because it can happen at connection stage (or as a computationally cheap input to a scoring mechanism such as SpamAssassin) - so I believe there is still value in it, and it is important to get it as efficient as possible. Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet.
Re: Honeypot email addresses
Le 26/11/2014 19:56, Christian Grunfeld a écrit : even /64 DNSxLs will be expensive ! /64 lists will have 2^32 times more entries than IPv4 lists. /64 lists can *theoretically* have that many entries, yes, but it'll be a very long time before there are 2^32 times as many *allocated* IPv6 /64s as there are allocated IPv4 /32s! -- John
Re: Honeypot email addresses
On 11/24/2014 12:30 PM, Reindl Harald wrote: the world is not black and white and by *blindly* blacklist you gain nothing than damage This is absolutely correct, Reindl. It is why ALL domain names that MY COMPANY accepts mail from HAVE WEBSITES on them. You send email to exam...@ipinc.net well there's a site on www.ipinc.net You get a bounce from me or your friend on exam...@ipinc.net does not get your message - well you can go to my website and find a phone number there to call a REAL LIVE HUMAN. And if you have some anxiety psychological issue to where talking to another person terrifies you, why there's a webform you can post to that will go straight to a human. That Human will take the time to explain to EDUCATE you either by email or on the phone JUST LIKE I'M DOING HERE about why you don't blindly send mail to lists your friends send you, and that by the way exam...@ipinc.net hasn't had services with us for the last decade and maybe you might pick up the phone and call him and get his email address. AND if your a commercial bulk mailer we will politely tell you that OUR error messages ARE standardized and if you cannot handle bounce management by dealing with standardized errors, well we don't want mail from you AT ALL. THIS is how you PROPERLY handle the greyness in the world - BY ACTUALLY TALKING TO A PERSON. I see people like you every day who are CONVINCED they can deal with greyness in the world by a machine. Poor fools that they are, they are the ones who construct elaborate voice auto responder voice trees (press 1 for this press 2 for that) as if every single problem someone could call in about falls into some neat hole. YO HAVE NO REASONABLE EXCUSE for condemning someone who runs honeypots using addresses that you don't like when they TAKE THE TIME TO PICK UP THE DANM PHONE when you call them. Ted
Re: Honeypot email addresses
Am 25.11.2014 um 18:53 schrieb Ted Mittelstaedt: I see people like you every day who are CONVINCED they can deal with greyness in the world by a machine. Poor fools that they are, they are the ones who construct elaborate voice auto responder voice trees (press 1 for this press 2 for that) as if every single problem someone could call in about falls into some neat hole. YO HAVE NO REASONABLE EXCUSE for condemning someone who runs honeypots using addresses that you don't like when they TAKE THE TIME TO PICK UP THE DANM PHONE when you call them piss in some other direction i am known as a hardliner if it comes to filters but with the intention to accept 100% legit mail and not throw away some percent to gain 100% junk catched i just explained that taking a previous existing valid address as honeypot-source is stuip and why that is the case and frankly don't bother what you do - only if you block or mailserver because some customer did not cleanup / refresh his addressbook you will hear from me with a clear statement as well as your possible customer waiting for mails you block as result of i build spamtraps with previous vaild addresses, that's plain stupid with no but and if if you want to dirve honeypots create own RCPT's, domans/dubdomains and spread that targets hidden into websites - that's the way to go without risk collateral damage - feel free to ignore it but be prepared for complaints signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
Am 25.11.2014 um 18:53 schrieb Ted Mittelstaedt: It is why ALL domain names that MY COMPANY accepts mail from HAVE WEBSITES on them don't get me wrong but that is just stupid a website was enver, is not and will never be a prerequisite for a mail-domain (or mail subdomain) nor is it a MX record and if you *really* enforce that any sending domain needs a website at the same URL please refrain from maintain mailservers for the sake of mail-users signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 11/25/2014 11:24 AM, Reindl Harald wrote: Am 25.11.2014 um 18:53 schrieb Ted Mittelstaedt: It is why ALL domain names that MY COMPANY accepts mail from HAVE WEBSITES on them don't get me wrong but that is just stupid a website was enver, is not and will never be a prerequisite for a mail-domain (or mail subdomain) nor is it a MX record and if you *really* enforce that any sending domain needs a website at the same URL please refrain from maintain mailservers for the sake of mail-users I don't enforce that for customers, but then again, my customers aren't accepting email on their domains for MY company, they are accepting it for THEIR company. I think you badly misunderstand. Badly. I am not saying a website should be a prereq for receiving mail on a domain name nor is it a substitute for an MX - or a proper whois record for that matter. BUT, it is certainly something that is done by ANYONE who is NOT interested in CONCEALING who they are. If a customer were to contact us and say: I want you to setup a domain name that we can quote-unquote receive mail on, but I want our real name concealed in the whois record and I do not want an HTTP referral on the domain name to refer to a website for us - and indeed we don't have a website I would tell them to blow it out their ass. Because, virtually the ONLY REASON that someone wants to do this kind of thing is if they want to do something on the Internet that is illegal or highly immoral. At least, illegal IN THE UNITED STATES and in much of Europe. Fortunately, I do NOT derive money from any customer in Red China or North Korea or someplace like that where their own government is gunning for them. And what I say does not apply in those countries. But in any Free country, the are PLENTY of opportunities for a whistleblower or someone like that with a LEGITIMATE need to conceal themselves, to send email FOR FREE and WITHOUT INVOLVING ME. They can go find some StarFlucks or MackyWhopper place and get themselves onto a free wifi then create a fake name on Hotmail or whatever, and send their stuff out that way. Then when it turns out that what they are sending is stalking emails to some young nubile 17 year old co-ed, and the police start getting involved and sending subponeas, they will be bothering StarFlucks and MackyWhopper who might just decide that it isn't that good of an idea to allow any Tom Dick and Harry to get on their wifi. Getting back to MY operation - and the operations of most of the people here - we are in business to MAKE MONEY. The MORE people who know who we are THE BETTER. We make money by SERVICING CUSTOMERS. And that means HELPING THEM and THEIR FRIENDS who are trying to communicate with them. If one of my customers has a business associate or a friend or whoever who is attempting to SEND THEM MAIL and it's FAILING then FOR DAMN SURE I want a call from that associate asking why. So I can fix the problem, help my customer's friend or associate. So I'm gonna plaster my contact info ANYWHERE that even an ignorant user can find it. You sir, obviously don't view email like this. I frankly don't know WHAT you view email as but FOR SURE it's NOT anything I want to be part of. Ted
Re: Honeypot email addresses
On 11/25/2014 11:21 AM, Reindl Harald wrote: Am 25.11.2014 um 18:53 schrieb Ted Mittelstaedt: I see people like you every day who are CONVINCED they can deal with greyness in the world by a machine. Poor fools that they are, they are the ones who construct elaborate voice auto responder voice trees (press 1 for this press 2 for that) as if every single problem someone could call in about falls into some neat hole. YO HAVE NO REASONABLE EXCUSE for condemning someone who runs honeypots using addresses that you don't like when they TAKE THE TIME TO PICK UP THE DANM PHONE when you call them piss in some other direction i am known as a hardliner if it comes to filters but with the intention to accept 100% legit mail and not throw away some percent to gain 100% junk catched i just explained that taking a previous existing valid address as honeypot-source is stuip and why that is the case and frankly don't bother what you do - only if you block or mailserver because some customer did not cleanup / refresh his addressbook you will hear from me with a clear statement as well as your possible customer waiting for mails you block as result of i build spamtraps with previous vaild addresses, that's plain stupid with no but and if I have no control over what you tell YOUR customer. Undoubtedly once you get ahold of me and I tell you that your customer is being blocked BECAUSE HE IS EMAILING ADDRESSES ON MY SERVER THAT HAVE BEEN BOUNCING MAILS FOR THE LAST DECADE you will realize that it's YOUR customers fault and you will help him to DELETE those stale addresses from his address book - then you will manufacture some pie-in-the-sky reason about how it's my fault that he was dumb enough to IGNORE BOUNCES FOR TEN YEARS. If that helps you sleep at night, so be it. But I think it's ridiculous and I think most people would think that also. You might consider that once an email address is purged from my server that NOBODY in the world, including your customer, has ANY moral right to send more than ONE email to it. They get ONE bounce mail to tell them to purge their address book. But anything more than that, and what is going on is THEIR laziness and ignorance is NOW starting to cost me money, it is costing me server resources and bandwidth for them to open a connection to me. In short, once they got a notification that the address is nonexistent, they are now STEALING from me when they continue to email that address on my server. if you want to dirve honeypots create own RCPT's, domans/dubdomains and spread that targets hidden into websites - that's the way to go without risk collateral damage - feel free to ignore it but be prepared for complaints Do you even understand what a honeypot is? Seriously? A honeypot is USELESS if it appears AT ALL DIFFERENT. MY honeypots are addresses THAT ARE INDISTINGUISHABLE from all other LEGITIMATE addresses on my mailserver. That's why they work. Dumb spammers might be snookered by a bogus subdomain that is only for honeypots. Dumb spammers might be snookered by an email address that only shows up on a webpage. But the smarter spammers are likely going to ignore email addresses obtained from targets hidden in websites, and they are likely to figure out fake domains. The only thing that really can fool the smarter spammer is an email address that is a REAL email address. That is, an email address that WAS IN USE for a period of time. When I review my logs and I see unknown user bounces for email addresses on my server that were cancelled a decade ago, in my view, anything sent to those addresses IS SPAM and it is going into the Bays learner. After all it's not like I NEVER cycle through honeypot addresses. As I said, it's an old domain. My list of cancelled addresses goes back much longer than a decade. I have lots and lots of old email addresses that were cancelled well over a decade ago, and I only use a fraction of those at any time for my current honeypots. I change them out from time to time. Ted
Re: Honeypot email addresses
On Nov 22, 2014, at 4:15 AM, Aban Dokht ml...@abando.de wrote: On 21.11.2014 18:17, Matthias Leisi wrote: We are about to simplify the reporting we previously had, and want to push this especially to detect spam coming in over IPv6. We also have honeypots with enabled IPv6 MX, but SPAM over IPv6 is very, very seldom. But pushing IPv6 anti spam is a good approach. You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf
Re: Honeypot email addresses
On Wed, Nov 26, 2014 at 3:45 AM, Franck Martin fmar...@linkedin.com wrote: You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf I'm well aware of the issues of cache efficiency and query volumes due to the vast address space. The solution to just cut off at /64 is nice, but there will be many legitimate cases where this is will not be good enough. That's why I am convinced that in the end we will need something like a tree walk algorithm, where an intelligent algorithm starts at (let's say) a /32 boundary and then gets responses to the best fitting response. Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. Maybe such a tree-walk algorithm is worth an experiment as a SpamAssassin plugin? -- Matthias
Re: Honeypot email addresses
On Sat, 22 Nov 2014 15:32:26 -0600 (CST) Dave Funk wrote: Another way to seed spamtrap addresses is to make up some and then feed them into unsubscribe links in spam sent to regular users. I've got some of those I started that way 15 years ago and they're still going strong. Isn't there a danger that you get lower-grade spam that way, if spammers avoid unsubscribed addresses in their snowshoe lists.
Re: Honeypot email addresses
Am 24.11.2014 um 13:51 schrieb RW:
On Sat, 22 Nov 2014 15:32:26 -0600 (CST)
Dave Funk wrote:
Another way to seed spamtrap addresses is to make up some and
then feed them into unsubscribe links in spam sent to regular
users. I've got some of those I started that way 15 years ago
and they're still going strong.
Isn't there a danger that you get lower-grade spam that way, if spammers
avoid unsubscribed addresses in their snowshoe lists.
?php
$file = file(__DIR__ . '/unsub.txt');
foreach($file as $line)
{
$line = trim($line);
if(!empty($line))
{
$line = str_replace('[email]', md5(microtime() . $line) .
'@honeypot-domain.tld', $line);
echo $line;
usleep(1000);
$out = @file_get_contents($line);
if(!empty($out))
{
echo ': OK' . \n;
}
else
{
echo ': FAILED' . \n;
}
}
}
?
signature.asc
Description: OpenPGP digital signature
Re: Honeypot email addresses
On Sun, 23 Nov 2014 11:12:58 +0100 Aban Dokht ml...@abando.de wrote: From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Oh, sure! Let's tolerate incompetent mass mailers. While we're at it, let's tolerate sites that can't properly manage their mail servers. And don't forget open relays, too! Just because they can't figure out how to make it work or are too lazy to do it right, we must excuse them. And, Free Speech, right? No, let's not accomodate incompetent bulk mailers. It has never worked before. All it does is allow them to continue to make excuses to fail to do their job properly and it attracts spammers, politicians and other such ilk. Spammers always take advantage of negligent and incompetent mail admins. Blacklist, blocklist badly behaving mailservers, whether known spammers or not. That is the standard policy everywhere. You really should try admin-ing a internet facing mail server for a while. You'll quickly realize that what you are saying here is totally insane. Hopefully before YOU go insane. jd
Re: Honeypot email addresses
Am 24.11.2014 um 18:49 schrieb jdebert: On Sun, 23 Nov 2014 11:12:58 +0100 Aban Dokht ml...@abando.de wrote: From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Oh, sure! Let's tolerate incompetent mass mailers. While we're at it, let's tolerate sites that can't properly manage their mail servers. And don't forget open relays, too! Just because they can't figure out how to make it work or are too lazy to do it right, we must excuse them. And, Free Speech, right? nobod said that but you need to draw a line between catch spam and force to catch any sender you don't know why and how the address went to the RCPT that's far from the reality i see again and again *living humans* continue to send to their outdated best-friends list from the MUA just because they don't understand a bounce, don't care enough or even be afraid remove somebody from his address book based on *not* understood automatic mail (bounce) as tech user i don't understand that users behavior at the same time i, we and our server did *nothing* wrong and if you setup a spam trap to catch that senders you just blacklist for no good reason *frankly* a lot of reject messages are just too stupid for a automated bounce mamagement because some smart ass felt good by use non.default messages where even persons like me sit there wit no clue if this is a temporary local error at the RCPT too stupid reply with a 4xx code and so better *not remove it* automated the world is not black and white and by *blindly* blacklist you gain nothing than damage signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 25/11/2014 03:49, jdebert wrote: No, let's not accomodate incompetent bulk mailers. It has never worked before. All it does is allow them to continue to make excuses to fail to do their job properly and it attracts spammers, politicians and other such ilk. Spammers always take advantage of negligent and incompetent mail admins. Blacklist, blocklist badly behaving mailservers, whether known spammers or not. That is the standard policy everywhere. Exactly, those that care, quickly realise their error and correct their setup, those that don't, clearly don't care, so we don't care about them, why should we. Just like vmware in my case, it's only to me as far as I know, so I ignore it, but one day I might just have a few too many beers and change that ;)
Re: Honeypot email addresses
On Sun, 23 Nov 2014, Reindl Harald wrote:
Am 23.11.2014 um 11:17 schrieb Aban Dokht:
On 22.11.2014 22:32, Dave Funk wrote:
Another way to seed spamtrap addresses is to make up some and
then feed them into unsubscribe links in spam sent to regular
users. I've got some of those I started that way 15 years ago
and they're still going strong.
Also no good idea, as some of them will send an unsubscribe mail to the
trap then. The risk of false positives is very high
using real addresses as a honeypot is wrong, dangerous and reckless
also there is no need for playing with firebecause by use virgin addresses
and not promote them visible or even subcribe them to porn newsletters (don't
laugh i heard proposals register a address to all porn newsletters you can
find and then start blacklisting)
if you want to block all newsletters then just do it, you don't need to play
honeypot-games for that!
I guess I need to elaborate to make it clear exactly what I do and why there
is little to no danger of FPs.
When I said to make up some (spamtrap addresses) I mean make up some -new-
addresses that can -never- be used as legitmate user addresses.
In our organization we have some specific address formats that we use for
various purposes (first-l...@domain.name shortn...@sub.domain.name
service_addr...@domain.name ). However we also have some reserved address
spaces within those formats (which are administrativly enforced) so I can
create some addresses that look like first-l...@domain.name but which I know
will never be used for real purposes (but the spammers won't know which they
are). I use those addresses for spamtrap addresses. (no danger of FPs there).
I then feed those particular spamtrap addresses into the unsubscribe links of
hand-verified spam. So only spammers will ever see those addresses anyplace
outside of our infrastructure. Thus they should almost never FP.
The only way that I can see any possibility of FPs is if a spammer is using
a semi-legit MSP and that MSP sends an unsubscribe-verify message to that
spam-trap address. That should only happen a few times at most and should -not-
have any new spam assocated with it.
So any spam sent to that spamtrap address is fair game.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: Honeypot email addresses
On 22.11.2014 22:05, Ted Mittelstaedt wrote: That's a lot of work, there's a much easier way Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have a pretty old domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! -- Aban Dokht aban.do...@abando.de system administrator of 0 day abusers DNSBL bl.dbrs.de -- pgpVnKwYd7_9s.pgp Description: PGP signature
Re: Honeypot email addresses
On 22.11.2014 22:32, Dave Funk wrote: Another way to seed spamtrap addresses is to make up some and then feed them into unsubscribe links in spam sent to regular users. I've got some of those I started that way 15 years ago and they're still going strong. Also no good idea, as some of them will send an unsubscribe mail to the trap then. The risk of false positives is very high. -- Aban Dokht aban.do...@abando.de system administrator of 0 day abusers DNSBL bl.dbrs.de -- pgpOQC7Hzd4xM.pgp Description: PGP signature
Re: Honeypot email addresses
Am 23.11.2014 um 11:17 schrieb Aban Dokht: On 22.11.2014 22:32, Dave Funk wrote: Another way to seed spamtrap addresses is to make up some and then feed them into unsubscribe links in spam sent to regular users. I've got some of those I started that way 15 years ago and they're still going strong. Also no good idea, as some of them will send an unsubscribe mail to the trap then. The risk of false positives is very high using real addresses as a honeypot is wrong, dangerous and reckless also there is no need for playing with firebecause by use virgin addresses and not promote them visible or even subcribe them to porn newsletters (don't laugh i heard proposals register a address to all porn newsletters you can find and then start blacklisting) if you want to block all newsletters then just do it, you don't need to play honeypot-games for that! signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 23/11/2014 20:12, Aban Dokht wrote: On 22.11.2014 22:05, Ted Mittelstaedt wrote: domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Surely though that is the senders problem. Also any sender - SOHO, medium or large business, government, or mass mailing specialists, who have no, poor, or broken bounce management, do deserve to be listed, to prompt them into getting their act together and fixing their code. Yes it happens, VMware are a perfect example of this incompetence, they still try send to an old list address of mine before I consolidated the 2 into this one, they have been getting user unknowns for about 8 years.
Re: Honeypot email addresses
On 11/23/2014 2:12 AM, Aban Dokht wrote: On 22.11.2014 22:05, Ted Mittelstaedt wrote: That's a lot of work, there's a much easier way Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have a pretty old domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Who are you I've never seen you post on this list before. You sound like a spammer who is scared to death that more people will be putting up honeypots. A bulk sender with no bounce management is a spammer, PERIOD. I'll gladly invite any customer of mine who insists on receiving email from bulk senders who don't do bounce management to go find another email provider. Strange that I have NEVER had a customer complain about this. I am VERY familiar with Gmails rules and Hotmail/Microsoft's rules for bulk senders to send mail into their network. They mandate that anyone sending bulk mail to them IS REQUIRED to do bounce management or they will block them, end of story. I am quite willing to accept mail from bulk mailers who follow CAN-SPAM act in the United States - which by the way REQUIRES bounce management - bulk mailers who do NOT do bounce management are committing a felony in the United States. Ted
Re: Honeypot email addresses
On 11/23/2014 2:17 AM, Aban Dokht wrote: On 22.11.2014 22:32, Dave Funk wrote: Another way to seed spamtrap addresses is to make up some and then feed them into unsubscribe links in spam sent to regular users. I've got some of those I started that way 15 years ago and they're still going strong. Also no good idea, as some of them will send an unsubscribe mail to the trap then. The risk of false positives is very high. If a bulk mailer is legitimate then they will do 2 things, first they will verify that the email listed in the unsubscribe request exists on their mailing list, (and if not, ignore it) and second when they get a de-list request they should IMMEDIATELY honor it. They should NEVER send a confirmation email. Sending an email saying we just de-listed you because of your de-list request is perfectly fine and if it was an accidental de-list the user can merely resubscribe. But a de-list request should be honored immediately. If they can't do that, then they are just setting up barriers to unsubscribe email addresses from their lists, and that is what a spammer does. We have a saying in the United States, Aban. If it looks like a duck, walks like a duck, and quacks like a duck, it's a duck. Ted
Re: Honeypot email addresses
On 21.11.2014 18:17, Matthias Leisi wrote: We are about to simplify the reporting we previously had, and want to push this especially to detect spam coming in over IPv6. We also have honeypots with enabled IPv6 MX, but SPAM over IPv6 is very, very seldom. But pushing IPv6 anti spam is a good approach. -- Aban Dokht aban.do...@abando.de system administrator of 0 day abusers DNSBL bl.dbrs.de -- pgpVDFftbvYaH.pgp Description: PGP signature
IPv6 mail (was Re: Honeypot email addresses)
On Sat, 22 Nov 2014 13:15:29 +0100 Aban Dokht ml...@abando.de wrote: We also have honeypots with enabled IPv6 MX, but SPAM over IPv6 is very, very seldom. We keep reputation reports from a large number of mailboxes and they break down roughly as follows: IPv4 mail: about 475 million reports of which 166 million were reported back as spam. IPv6 mail: about 9 million reports of which 145,000 were reported as spam. Conclusion: Not much mail travels over IPv6 and that which does is more likely to be ham than mail travelling over IPv4. On the other hand, IPv6 is bad news for some anti-spam technologies like RBLs. Even if the smallest RBL entry you make is a /64, there's such a vast pool of addresses available that once IPv6 is ubiquitous, spammers will be able to snowshoe much more effectively than over IPv4. Additionally, if your mail server tries to resolve the hostname of incoming SMTP clients (most do), attackers can blow your DNS server's cache by cycling through billions of IPv6 addresses from one machine; I believe we will need to rethink the strategy of always resolving host names when IPv6 is widespread. Regards, David.
Re: Honeypot email addresses
That's a lot of work, there's a much easier way Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have a pretty old domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. Ted On 11/21/2014 8:10 AM, Joe Quinn wrote: We are setting up some honeypot email addresses, and were wondering if anyone here had tips on how to include those addresses on webpages and other places. We're currently going with a pretty simple !-- honey...@example.com -- HTML comment. Is that too obvious? Should we put it into a CSS invisible div as well? Any other ideas?
Re: Honeypot email addresses
Another way to seed spamtrap addresses is to make up some and
then feed them into unsubscribe links in spam sent to regular
users. I've got some of those I started that way 15 years ago
and they're still going strong.
On Sat, 22 Nov 2014, Ted Mittelstaedt wrote:
That's a lot of work, there's a much easier way
Just search your /var/log/maillog for user unknown messages, and
create email addresses for the unknown users which are showing up
multiple times over multiple days. It's a great trick because it gets
spammers who already have email addresses in their
spamlists and who are too lazy to remove them when they get a
user unknown message from the mailserver.
I have a pretty old domain - I've seen user unknown messages for
users who cancelled mailboxes on the domain over a decade ago. I figure
10 years of getting user unknown messages is long enough for any real
humans and for legitimate mailing lists to remove those entries.
Ted
On 11/21/2014 8:10 AM, Joe Quinn wrote:
We are setting up some honeypot email addresses, and were wondering if
anyone here had tips on how to include those addresses on webpages and
other places.
We're currently going with a pretty simple !-- honey...@example.com --
HTML comment. Is that too obvious? Should we put it into a CSS invisible
div as well? Any other ideas?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Honeypot email addresses
We are setting up some honeypot email addresses, and were wondering if anyone here had tips on how to include those addresses on webpages and other places. We're currently going with a pretty simple !-- honey...@example.com -- HTML comment. Is that too obvious? Should we put it into a CSS invisible div as well? Any other ideas?
Re: Honeypot email addresses
Am 21.11.2014 um 17:10 schrieb Joe Quinn: We are setting up some honeypot email addresses, and were wondering if anyone here had tips on how to include those addresses on webpages and other places. We're currently going with a pretty simple !-- honey...@example.com -- HTML comment. Is that too obvious? Should we put it into a CSS invisible div as well? Any other ideas? use a dedicated domain or subdomain with a own MX record and link a pixel.gif with regular changing addresses - finally avoid the word honeypot to make it not obvious :-) these times the email inide a comment may be ignored by the smarter bots signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On Fri, 21 Nov 2014, Reindl Harald wrote: Am 21.11.2014 um 17:10 schrieb Joe Quinn: We are setting up some honeypot email addresses, and were wondering if anyone here had tips on how to include those addresses on webpages and other places. We're currently going with a pretty simple !-- honey...@example.com -- HTML comment. Is that too obvious? Should we put it into a CSS invisible div as well? Any other ideas? use a dedicated domain or subdomain with a own MX record and link a pixel.gif with regular changing addresses - finally avoid the word honeypot to make it not obvious :-) these times the email inide a comment may be ignored by the smarter bots On a public mailng list isn't a great place to discuss such tactics... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The Tea Party wants to remove the Crony from Crony Capitalism. OWS wants to remove Capitalism from Crony Capitalism. -- Astaghfirullah --- 904 days since the first successful private support mission to ISS (SpaceX)
Re: Honeypot email addresses
On Fri, 21 Nov 2014 08:43:22 -0800 (PST) John Hardin jhar...@impsec.org wrote: On a public mailng list isn't a great place to discuss such tactics... I suspect spammers are dumb and will just vacuum up any address they can find. Also, the scammers who sell CDs with millions of email addresses on them are unlikely to do anything but the most cursory checking of the addresses. Make a honeypot subdomain, put up any web content with email addresses and I guarantee you'll start receiving email on those addresses within a few days. Regards, David.
Re: Honeypot email addresses
Btw., the dnswl.org project is happy to receive whatever spamtrap hits. We are about to simplify the reporting we previously had, and want to push this especially to detect spam coming in over IPv6. Details off list :) -- Matthias
Re: Honeypot Email Addresses
Am 2008-08-18 13:46:56, schrieb [EMAIL PROTECTED]: Hello, Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Install a maildrop or procmail rule for it and do something like :0 * TO_(list_of_burned_email_addresses) |/uar/bin/sa-learn --spam - Maybe use the additional option --no-sync too. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Honeypot Email Addresses
jdow wrote: I believe you could blacklist_from. That would train SpamAssassin's Bayes filter - Or not. Both USER_IN_BLACKLIST and USER_IN_BLACKLIST_TO have tflags set to userconf noautolearn (in current 3.2.5 rules), which means that SpamAssassin will ignore their scores when deciding whether to autolearn. if you use global (shudder) Bayes. Um. There is research ( http://www.ceas.cc/2007/papers/paper-74.pdf ) suggesting that “globally-trained text classification easily outperforms personally-trained classification under realistic settings” (the text-classifier they used was Bayes). James. -- E-mail: james@ | Ah yes. Thingie and thingamagig, and I'll throw in aprilcottage.co.uk | whatchamacallit too. Because in tech support, button is | sometimes a bit too technical for the average caller. | -- mr_scoot
Honeypot Email Addresses
Hello, Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Thanks! Richard Ahlquist Systems Analyst http://www.patentlystupid.com
Re: Honeypot Email Addresses
On Mon, 18 Aug 2008, [EMAIL PROTECTED] wrote: Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Training from those users' mailboxes is pretty straightforward using sa-learn in a script run from cron. I wouldn't worry about trying to get autolearn involved. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The first time I saw a bagpipe, I thought the player was torturing an octopus. I was amazed they could scream so loudly. -- cat_herder_5263 on Y! SCOX --- 6 days until the 1929th anniversary of the destruction of Pompeii
Re: Honeypot Email Addresses
On Mon, Aug 18, 2008 at 1:59 PM, John Hardin [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, [EMAIL PROTECTED] wrote: Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Training from those users' mailboxes is pretty straightforward using sa-learn in a script run from cron. I wouldn't worry about trying to get autolearn involved. -- I guess I should have been more clear. Most of these email addresses have been forwarding into a junkemail gmail account and have no 'local' mailboxes of their own, and I would like to keep it that way. I am also using MailScanner if thats of any use. Basically I want (yes I dont care if a spambot gets this addy) [EMAIL PROTECTED] to always only be recognized as spam content and have it learned. Since there isnt a mailbox how would this best be accomplished? Thanks! Richard Ahlquist
RE: Honeypot Email Addresses
[EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 1:59 PM, John Hardin [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, [EMAIL PROTECTED] wrote: Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Training from those users' mailboxes is pretty straightforward using sa-learn in a script run from cron. I wouldn't worry about trying to get autolearn involved. I guess I should have been more clear. Most of these email addresses have been forwarding into a junkemail gmail account and have no 'local' mailboxes of their own, and I would like to keep it that way. I am also using MailScanner if thats of any use. Basically I want (yes I dont care if a spambot gets this addy) [EMAIL PROTECTED] to always only be recognized as spam content and have it learned. Since there isnt a mailbox how would this best be accomplished? The simplest thing is to create a local mailbox (all of the accounts can use the same one) and deliver the spam there. You can continue forwarding to the gmail account as well, if you like. Then have a cron job that learns the mail and then deletes it. -- Bowie
Re: Honeypot Email Addresses
Maybe this is a completely crazy notion, but if the mail for these accounts is in fact actually flowing into/through your system, and being sent through SA already, you might create a rule so that any item with one of those addresses in it gets a high score so in turn your auto-learn threshold would trigger and process the item. And if that works, then you don't have to do anything else. [EMAIL PROTECTED] 08/18/08 2:08 PM On Mon, Aug 18, 2008 at 1:59 PM, John Hardin [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, [EMAIL PROTECTED] wrote: Long time SA user here. I have googled much for an answer for this. I have a few email addresses that are clearly now spam only. I would like to blacklist them and use them as a honeypot to help train my Bayes through autolearn, does anyone have any suggestions on how to do this? Training from those users' mailboxes is pretty straightforward using sa-learn in a script run from cron. I wouldn't worry about trying to get autolearn involved. -- I guess I should have been more clear. Most of these email addresses have been forwarding into a junkemail gmail account and have no 'local' mailboxes of their own, and I would like to keep it that way. I am also using MailScanner if thats of any use. Basically I want (yes I dont care if a spambot gets this addy) [EMAIL PROTECTED] to always only be recognized as spam content and have it learned. Since there isnt a mailbox how would this best be accomplished? Thanks! Richard Ahlquist
Re: Honeypot Email Addresses
Yes, because rather than use a honeypot, you can forward as an attachment to Spamcop. SA uses Spamcop in its scoring so indirectly you improve your SA scoring accuracy if you do that. I strongly recommend all our users do that also. Ron Smith [EMAIL PROTECTED] Having an email problem is painful, but character-building. On Aug 18, 2008, at 3:27 PM, John Hardin wrote: On Mon, 18 Aug 2008, Ron Smith wrote: You might want to think about using Spamcop to submit those instead as the SA scoring of these spam do increase the accuracy for all of your users. Did you mean to send that to the list?
Re: Honeypot Email Addresses
From: [EMAIL PROTECTED]
Sent: Monday, 2008, August 18 11:08
On Mon, Aug 18, 2008 at 1:59 PM, John Hardin [EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008, [EMAIL PROTECTED] wrote:
Long time SA user here. I have googled much for an answer for this. I
have
a few email addresses that are clearly now spam only. I would like to
blacklist them and use them as a honeypot to help train my Bayes through
autolearn, does anyone have any suggestions on how to do this?
Training from those users' mailboxes is pretty straightforward using
sa-learn in a script run from cron. I wouldn't worry about trying to get
autolearn involved.
--
I guess I should have been more clear. Most of these email addresses have
been forwarding into a junkemail gmail account and have no 'local'
mailboxes
of their own, and I would like to keep it that way. I am also using
MailScanner if thats of any use. Basically I want (yes I dont care if a
spambot gets this addy) [EMAIL PROTECTED] to always only be recognized
as
spam content and have it learned. Since there isnt a mailbox how would
this
best be accomplished?
I believe you could blacklist_from. That would train SpamAssassin's
Bayes filter - if you use global (shudder) Bayes. As for automating
building a block list you'll have to pester someone else into providing
a clue.
If you use per-user Bayes then you have more of a problem because you
need to train it from messages not sent to the user. For that you will
need a local spam repository that operates as a fifo buffer. How you
implement that is an exercise for the student.
{^_^}
