Re: Honeypot email addresses
On Dec 4, 2014, at 2:30 PM, Dave Pooser wrote: > On 12/4/14, 3:10 PM, "Philip Prindeville" > 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. > > 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: ancient perl versions
On 05/12/2014 14:40, Dave Pooser wrote: > On 12/4/14 10:27 PM, "Nick Edwards" wrote: > It's also not wrapping the text at all. it wraps fine here Look at the last roundcube post, the one sent at 01:06 GMT. The line of quoted text runs 273 columns without a linewrap. What client are you using? roundcube - wraps Evolution - wraps the font size btw is identical to yours on both. only two I use for this a/c forwarded that message in question to my private address, and checked it in android tablet and phone, both wrap. since no one has ever brought this up with me before, I'm placing this as not my problem to resolve.
Re: ancient perl versions
On 12/4/14 10:27 PM, "Nick Edwards" wrote: >> It's also not wrapping the text at all. > it wraps fine here Look at the last roundcube post, the one sent at 01:06 GMT. The line of quoted text runs 273 columns without a linewrap. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
Re: ancient perl versions
On 12/5/14, Ted Mittelstaedt wrote: > > > On 12/4/2014 6:24 PM, Noel Butler wrote: >> On Thu, 2014-12-04 at 20:22 -0600, Dave Pooser wrote: >>> > strange, it indicates 12pt, and looks same size when returned on list >>> > as >>> >everyone elses, something must be a miss, hows this one? it's from >>> >evolution >>> >>> That one looked significantly larger in my mail client (Outlook 2011 for >>> Macintosh). Looking at source, your previous had 'font-size: 10pt' and >>> this one omitted font-size entirely. >> >> thanks, seems yet another problem with roundcube *sigh* >> > > It's also not wrapping the text at all. > > Ted > bullshit, it wraps fine here
Re: ancient perl versions
On 12/4/2014 6:24 PM, Noel Butler wrote: On Thu, 2014-12-04 at 20:22 -0600, Dave Pooser wrote: > strange, it indicates 12pt, and looks same size when returned on list as >everyone elses, something must be a miss, hows this one? it's from >evolution That one looked significantly larger in my mail client (Outlook 2011 for Macintosh). Looking at source, your previous had 'font-size: 10pt' and this one omitted font-size entirely. thanks, seems yet another problem with roundcube *sigh* It's also not wrapping the text at all. Ted
Re: ancient perl versions
On Thu, 2014-12-04 at 20:22 -0600, Dave Pooser wrote: > > strange, it indicates 12pt, and looks same size when returned on list as > >everyone elses, something must be a miss, hows this one? it's from > >evolution > > That one looked significantly larger in my mail client (Outlook 2011 for > Macintosh). Looking at source, your previous had 'font-size: 10pt' and > this one omitted font-size entirely. thanks, seems yet another problem with roundcube *sigh* signature.asc Description: This is a digitally signed message part
Re: ancient perl versions
> strange, it indicates 12pt, and looks same size when returned on list as >everyone elses, something must be a miss, hows this one? it's from >evolution That one looked significantly larger in my mail client (Outlook 2011 for Macintosh). Looking at source, your previous had 'font-size: 10pt' and this one omitted font-size entirely. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
Re: ancient perl versions
On Thu, 2014-12-04 at 17:45 -0800, jdow wrote:
> Clipped from the quoted message:
>
> body style=3D'font-size: 10pt'
>
> 12 pt would be better. Everybody else seems to come through with 12pt or
> larger
> font - or else plain text, which sane people prefer. (I may have to read HTML
> format. I try never to send it. {^_-})
>
> {o.o}
strange, it indicates 12pt, and looks same size when returned on list as
everyone elses, something must be a miss, hows this one? it's from
evolution
signature.asc
Description: This is a digitally signed message part
Re: ancient perl versions
On 2014-12-04 17:06, Noel Butler wrote:
On 05/12/2014 06:19, jdow wrote:
Speaking of footnotes, I don't have teeny tiny eyes for reading teeny tiny
print. Could you please use a slightly larger font? The world is not uniformly
made up of hairy chested (lose me right there) 20-40 year old (lose me there,
too) wunderkinds. Thank you in advance.
{o.o}
Ummm, nothing is in tiny print AFAIK, it's the same font size as all my posts
about 12pt according to roundcube... and checking in Evolution my posts made in
roundcube are the same as anyone else's on this list, I dont tend to shrink text
unless its the disclaimer in my sig, which does not go on this account since
this a list account and not personal/private/business, which do have them (and
in smaller print) So I dunno how you saw this any smaller than anything else's
Jo, maybe its your windaz thunderbird /me ducks for cover :)
Clipped from the quoted message:
body style=3D'font-size: 10pt'
12 pt would be better. Everybody else seems to come through with 12pt or larger
font - or else plain text, which sane people prefer. (I may have to read HTML
format. I try never to send it. {^_-})
{o.o}
Re: hacked sites/ costco.com JJ
On Thu, 04 Dec 2014 23:40:39 +0100
Axb wrote:
> uri__URI_COSTCO /costco\.com/i
> uri __URI_PHPASKC /\.php\?c\=/
> meta AXB_URI_COSTCO_JJ (__URI_COSTCO && __URI_PHPASKC)
> score AXB_URI_COSTCO_JJ 10.0
I've seen variants purportedly from Kroger, Target and Best Buy.
We're having good luck with the following:
uri__RP_D_00081_1 /\.php\?(?:dp|k|c|t)=[\/A-Za-z0-9=+]{25}/
header __RP_D_00081_2 Subject =~ /\b(?:order|buying)\b/i
meta RP_D_00081 __RP_D_00081_1 && __RP_D_00081_2
describe RP_D_00081 Link to malware
score RP_D_00081 30
Regards,
David.
Re: SOUGHT 2.0
On 4. dec. 2014 22.42.42 Axb wrote: To be able to create usable rules, several times/day I need feeds to spit *at least* +150k/day. As I don't have the data So not possible to make it run decentraly ? This imho another precompiled problem
Re: ancient perl versions
On 05/12/2014 06:19, jdow wrote:
> Speaking of footnotes, I don't have teeny tiny eyes for reading teeny tiny
> print. Could you please use a slightly larger font? The world is not
> uniformly made up of hairy chested (lose me right there) 20-40 year old (lose
> me there, too) wunderkinds. Thank you in advance.
>
> {o.o}
Ummm, nothing is in tiny print AFAIK, it's the same font size as all my
posts about 12pt according to roundcube... and checking in Evolution my
posts made in roundcube are the same as anyone else's on this list, I
dont tend to shrink text unless its the disclaimer in my sig, which does
not go on this account since this a list account and not
personal/private/business, which do have them (and in smaller print) So
I dunno how you saw this any smaller than anything else's Jo, maybe its
your windaz thunderbird /me ducks for cover :)
Re: SOUGHT 2.0
On Thu, 04 Dec 2014 22:41:13 +0100, Axb wrote: Axb> To be able to create usable rules, several times/day I need feeds Axb> to spit *at least* +150k/day. As I don't have the data 150k of what? Bytes? Emails? Tokens? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court. Local Variables: mode:claws-external End:
Re: ancient perl versions
On 2014-12-04 13:29, Bob Proulx wrote:
jdow wrote:
footnotes:
Speaking of footnotes, I don't have teeny tiny eyes for reading teeny tiny
print. Could you please use a slightly larger font? The world is not
uniformly made up of hairy chested (lose me right there) 20-40 year old
(lose me there, too) wunderkinds. Thank you in advance.
I guess you are reading the text/html alternative? I personally read
the text/plain alternative. Then the text is rendered in my MUA's
choice of fonts which I control. :-)
If you read the text/plain version of the message you would never have
noticed the html alternative and would have read all of the text in
the font of your choice. Plain text is for me the most accessible.
Bob
Unfortunately I have customers
{o.o}
Re: hacked sites/ costco.com JJ
On 12/04/2014 07:08 PM, Axb wrote: On 12/04/2014 07:05 PM, Kevin A. McGrail wrote: On 12/4/2014 1:03 PM, Axb wrote: Costco.com currently offers shipping in the United States only. We are not able to deliver to PO boxes, APO (military) boxes, FPO (foreign) boxes, freight forwarders, hotels, Costco Warehouses, international addresses, or a few limited geographic areas within the U.S. If a product is available for shipment to Alaska and Hawaii there will be additional shipping charges that will be quoted to you at time of checkout. As they don't deliver to my home, I have no need of Costco's Wholesale mail, and theres a ton of hacked site spams which joejob the URI THIS RULE WILL CAUSE FPs - YOU'VE BEEN WARNED! uriCOSTCO_POINTLESS /costco\.com/ For those in the US, we have some rules in KAM.cf so we haven't seen much of these since an onslaught around thanksgiving. atm you can meta with __URI_PHPASKC/\.php\?c\=/ and be on the safe side tomorrow the pattern will change (wanna bet?) As I can't commit atm. *adjust the score* & good luck uri__URI_COSTCO /costco\.com/i uri __URI_PHPASKC /\.php\?c\=/ metaAXB_URI_COSTCO_JJ (__URI_COSTCO && __URI_PHPASKC) score AXB_URI_COSTCO_JJ 10.0
Re: SOUGHT 2.0
On 12/04/2014 10:30 PM, Bob Proulx wrote: Axb wrote: It's been more than a month since my first "SOUGHT 2.0" msg. A few have shown interest but as there hasn't been the flood of enthusiasm and stuff getting done which I hoped for so I've dropped the idea of getting a public autogenerated rule set / sa-update channel going. Good poke! And I will leave this to the list to show further enthusiasm for the project instead of simply promising time off list. Bob, It's not a poke - it's a fact. To be able to create usable rules, several times/day I need feeds to spit *at least* +150k/day. As I don't have the data
Re: SOUGHT 2.0
Axb wrote: > It's been more than a month since my first "SOUGHT 2.0" msg. > > A few have shown interest but as there hasn't been the flood of enthusiasm > and stuff getting done which I hoped for so I've dropped the idea of getting > a public autogenerated rule set / sa-update channel going. Good poke! And I will leave this to the list to show further enthusiasm for the project instead of simply promising time off list. Bob
Re: Honeypot email addresses
On 12/4/14, 3:10 PM, "Philip Prindeville" 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. 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: ancient perl versions
jdow wrote: > >footnotes: > > Speaking of footnotes, I don't have teeny tiny eyes for reading teeny tiny > print. Could you please use a slightly larger font? The world is not > uniformly made up of hairy chested (lose me right there) 20-40 year old > (lose me there, too) wunderkinds. Thank you in advance. I guess you are reading the text/html alternative? I personally read the text/plain alternative. Then the text is rendered in my MUA's choice of fonts which I control. :-) If you read the text/plain version of the message you would never have noticed the html alternative and would have read all of the text in the font of your choice. Plain text is for me the most accessible. Bob
Re: Argument "perl_version" isn't numeric
John Hardin wrote: > Bob Proulx wrote: > >But, but, but... It also failed lint and produced cron noise on my > >perl 5.20.1 system too. Running spamassassin 3.4.0. That is later > >than perl 5.18 and it definitely produced the warning message. > > That's two separate issues. The perl RE lint *error* was due to use of the > \w++ construct from 5.10+ on a 5.8.8 install. That's perl version dependent. Ah... I never saw that error. So I didn't come online until the perl_version noise through cron every hour due to sa-learn runs and once a day due to sa-update runs. > The addition of a perl_version conditional to protect that rule without also > having a check for the SA version to ensure it supported perl_version is > what generated the SA parse *warning*. That's SA version dependent. Since it is recommended to run sa-update by cron (as you now know :-) ) it generates email noise. Additionally many of us set "bayes_auto_expire 0" so that we never pause to expire during an SA run but then run sa-learn --force-expire by cron often. I run it hourly. It is mostly those runs that caused hourly emails. And I have seven systems emailing me those messages. But as an email admin I really don't mind getting a lot of email and can handle that quite easily. :-) > Adding a check for SA version to that conditional suppressed the SA parse > warning, *except* on perl < 5.10, apparently due to a change in perl's > expression shortcut semantics (but this is not proven). That's perl version > dependent. That one I knew about. Thanks for the clarification on the issues. I had missed that first part. Bob
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 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: ancient perl versions
On 2014-12-03 15:55, Noel Butler wrote:
On 04/12/2014 00:28, Greg Troxel wrote:
...
footnotes:
I use slackware, yes its releases come with latest versions of most things, and
updates move with upstreams due to slackwares philosophy and releases are
maintained for usually 5 or more years, but even then, the packages can't cater
for all configurations, since its no hassle using upstream sources, it wont
break anything, and if I only need X and Y built into a binary, I *know* only X
and Y is built in, not massive bloat in having A-W, and Z as well, so updating
perl for instance is a no brainer should I desire, I have requested the -current
repo be updated to 5.20.1 fopr benefit of all slackers, but if I can a rejection
on that request, it'll take all of 20 mins to install the bastard from source
myself :) (well last time I built it it took 20 mins - might be tad longer now
days lol)
Speaking of footnotes, I don't have teeny tiny eyes for reading teeny tiny
print. Could you please use a slightly larger font? The world is not uniformly
made up of hairy chested (lose me right there) 20-40 year old (lose me there,
too) wunderkinds. Thank you in advance.
{o.o}
Re: Argument "perl_version" isn't numeric
On 2014-12-03 15:39, Noel Butler wrote:
On 03/12/2014 21:57, Kevin A. McGrail wrote:
Sure, if that was truly the case nor would I, but if you are running that old
perl, there is plenty of stuff thats outdated, and not all of the goodness
gets backports, not just with perl, but with most other things.
I can't fight every windmill and changing how distros work re: versions of
perl is one I choose not to battle.
Regards,
KAM
Oh absolutely! But why is it SA's problem? Or for that mater, any up-stream's
problem if distro X wants to only maintain version_released_in_BC or some such,
I mean if, and lets take Redhat for example (not singling RH out, because debian
are just as bad, if not worse), they turn around and decide that RHEL since v5
will now be supported for 10 years, not 5, at what point do you draw the line
and say " well RH that's your problem "
N
OK, if RHEL elects to upgrade SA to 3.4.x and leaves perl as it was, they bought
their headaches. If SA provides specific updates to earlier versions so that
perl_version is declared and is numeric and the if clause works for each of the
old versions it makes the distro maintainers' job easy. If after that the distro
does not update AND SA posts word about the fix on the website VERY prominently
then the it becomes the distro maintainers who are the bad guys. Trying to Meet
them half way there seems like the polite thing to do. After all, it is a latent
SA bug that has come out to bite us. So we at least lead the horses to water.
They can choose to drink or not.
The alternate solution is rule updates for 3.4.x that contain the fancy rules
and separate rule updates for lower SA versions. If a sysadmin runs 3.4.2
against perl 5.8.6 he's bought his own problems. LTS distros don't tend to do
such upgrades.
{^_^}
Re: SOUGHT 2.0
On 4. dec. 2014 18.50.41 Axb wrote: It's been more than a month since my first "SOUGHT 2.0" msg. +1 A few have shown interest but as there hasn't been the flood of enthusiasm and stuff getting done which I hoped for so I've dropped the idea of getting a public autogenerated rule set / sa-update channel going. Like sa-learn exists, will there be sa-souch ? I think it still missing on core sa If I can get enough data, privately, I'll give rsync access to ppl who contribute... (you know who you are .-) Yes Thanks to the few who offered to help. Maybe some other time... Oh hopeffully before
Re: message sent to list yesterday
On 12/4/2014 1:40 PM, listsb-spamassas...@bitrate.net wrote: On Dec 04, 2014, at 12.18, Joe Quinn wrote: On 12/4/2014 11:17 AM, listsb-spamassas...@bitrate.net wrote: hi- i sent a message to the list yesterday, but have not yet seen it appear. can someone check? my logs indicate successful delivery to mx1.us.apache.org: Dec 3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: to=, relay=mx1.us.apache.org[140.211.11.136]:25, delay=56, delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! <547f92fe.40...@bitrate.net> (Queue-Id: 70BD3358)) thanks -ben I see a message from you at 5:47 PM yesterday (UTC-05:00) which includes the output of some commands like sa-learn --dump magic. http://spamassassin.1065346.n5.nabble.com/different-results-when-using-debug-td113494.html Is that the email you were looking for? thanks, that's it. sorry, i should have thought to check other places beyond my mail client. i guess i just didn't get the return copy of that particular message. -ben No worries, this past week has had more volume than usual. I lost track of an entire thread in a similar manner just an hour ago.
Re: message sent to list yesterday
> On Dec 04, 2014, at 12.18, Joe Quinn wrote: > > On 12/4/2014 11:17 AM, listsb-spamassas...@bitrate.net wrote: >> hi- >> >> i sent a message to the list yesterday, but have not yet seen it appear. >> can someone check? my logs indicate successful delivery to >> mx1.us.apache.org: >> >> Dec 3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: >> to=, >> relay=mx1.us.apache.org[140.211.11.136]:25, delay=56, >> delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! >> <547f92fe.40...@bitrate.net> (Queue-Id: 70BD3358)) >> >> thanks >> -ben > I see a message from you at 5:47 PM yesterday (UTC-05:00) which includes the > output of some commands like sa-learn --dump magic. > http://spamassassin.1065346.n5.nabble.com/different-results-when-using-debug-td113494.html > > Is that the email you were looking for? thanks, that's it. sorry, i should have thought to check other places beyond my mail client. i guess i just didn't get the return copy of that particular message. -ben
Re: SOUGHT 2.0
On 12/04/14 18:49, Axb wrote: A few have shown interest but as there hasn't been the flood of enthusiasm and stuff getting done which I hoped for so I've dropped the idea of getting a public autogenerated rule set / sa-update channel going. Hello. With the risk of sounding stupid... I would be interested, and I *might* be willing to help, but it is not clear to me what I could do for the task (not even getting to whether I've got what is needed). Maybe your project would be more succesful if you provided a rough guide on what anyone can do? I run a few spamassassing sites, but would that be enough? What should I collect and send? How? ... bye & Thanks av.
Re: Argument "perl_version" isn't numeric
On Thu, 4 Dec 2014, Bob Proulx wrote: John Hardin wrote: Bob Proulx wrote: There have been multiple facets to this problem. The first was a rule update that produced warnings that produced email from every cron run sa-update / sa-learn run if run on recent released spamassassin 3.4.0 but not the development trunk version. That was actually the second facet. The first facet was a new test rule using a perl RE syntax that was introduced in 5.10.0 This rule passed dev validation on perl 5.18-ish, ... But, but, but... It also failed lint and produced cron noise on my perl 5.20.1 system too. Running spamassassin 3.4.0. That is later than perl 5.18 and it definitely produced the warning message. That's two separate issues. The perl RE lint *error* was due to use of the \w++ construct from 5.10+ on a 5.8.8 install. That's perl version dependent. The addition of a perl_version conditional to protect that rule without also having a check for the SA version to ensure it supported perl_version is what generated the SA parse *warning*. That's SA version dependent. Adding a check for SA version to that conditional suppressed the SA parse warning, *except* on perl < 5.10, apparently due to a change in perl's expression shortcut semantics (but this is not proven). That's perl version dependent. -- 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 --- Of the twenty-two civilizations that have appeared in history, nineteen of them collapsed when they reached the moral state the United States is in now. -- Arnold Toynbee --- 11 days until Bill of Rights day
Re: hacked sites/ costco.com JJ
On 12/04/2014 07:05 PM, Kevin A. McGrail wrote: On 12/4/2014 1:03 PM, Axb wrote: Costco.com currently offers shipping in the United States only. We are not able to deliver to PO boxes, APO (military) boxes, FPO (foreign) boxes, freight forwarders, hotels, Costco Warehouses, international addresses, or a few limited geographic areas within the U.S. If a product is available for shipment to Alaska and Hawaii there will be additional shipping charges that will be quoted to you at time of checkout. As they don't deliver to my home, I have no need of Costco's Wholesale mail, and theres a ton of hacked site spams which joejob the URI THIS RULE WILL CAUSE FPs - YOU'VE BEEN WARNED! uriCOSTCO_POINTLESS /costco\.com/ For those in the US, we have some rules in KAM.cf so we haven't seen much of these since an onslaught around thanksgiving. atm you can meta with __URI_PHPASKC /\.php\?c\=/ and be on the safe side tomorrow the pattern will change (wanna bet?)
Re: hacked sites/ costco.com JJ
On 12/4/2014 1:03 PM, Axb wrote: Costco.com currently offers shipping in the United States only. We are not able to deliver to PO boxes, APO (military) boxes, FPO (foreign) boxes, freight forwarders, hotels, Costco Warehouses, international addresses, or a few limited geographic areas within the U.S. If a product is available for shipment to Alaska and Hawaii there will be additional shipping charges that will be quoted to you at time of checkout. As they don't deliver to my home, I have no need of Costco's Wholesale mail, and theres a ton of hacked site spams which joejob the URI THIS RULE WILL CAUSE FPs - YOU'VE BEEN WARNED! uriCOSTCO_POINTLESS /costco\.com/ For those in the US, we have some rules in KAM.cf so we haven't seen much of these since an onslaught around thanksgiving.
hacked sites/ costco.com JJ
Costco.com currently offers shipping in the United States only. We are not able to deliver to PO boxes, APO (military) boxes, FPO (foreign) boxes, freight forwarders, hotels, Costco Warehouses, international addresses, or a few limited geographic areas within the U.S. If a product is available for shipment to Alaska and Hawaii there will be additional shipping charges that will be quoted to you at time of checkout. As they don't deliver to my home, I have no need of Costco's Wholesale mail, and theres a ton of hacked site spams which joejob the URI THIS RULE WILL CAUSE FPs - YOU'VE BEEN WARNED! uri COSTCO_POINTLESS /costco\.com/
SOUGHT 2.0
It's been more than a month since my first "SOUGHT 2.0" msg. A few have shown interest but as there hasn't been the flood of enthusiasm and stuff getting done which I hoped for so I've dropped the idea of getting a public autogenerated rule set / sa-update channel going. If I can get enough data, privately, I'll give rsync access to ppl who contribute... (you know who you are .-) Thanks to the few who offered to help. Maybe some other time... Axb
Re: Argument "perl_version" isn't numeric
John Hardin wrote: > Bob Proulx wrote: > > There have been multiple facets to this problem. The first was a rule > > update that produced warnings that produced email from every cron run > > sa-update / sa-learn run if run on recent released spamassassin 3.4.0 > > but not the development trunk version. > > That was actually the second facet. The first facet was a new test rule > using a perl RE syntax that was introduced in 5.10.0 This rule passed dev > validation on perl 5.18-ish, ... But, but, but... It also failed lint and produced cron noise on my perl 5.20.1 system too. Running spamassassin 3.4.0. That is later than perl 5.18 and it definitely produced the warning message. It couldn't have been solely due to perl version or there wouldn't have been any warnings there. It could only have been due to the spamassassin version 3.4.0, the latest released version, which did not include the development trunk code. > but when it was installed by sa-update on a production 5.8.8-based > install it failed lint and the entire rules update was > rejected. Avoiding that was the impetus for being able to test the > version of perl in a SA conditional. AIUI the combination of versions there is RHEL5/CentOS5 with perl 5.8.8 and spamassassin 3.3.1. Apparently there it is the perl 5.8.8 that tickled a problem because 3.3.2 with perl 5.14 is okay. > The rest has just been trying to figure out how to do that in a > backwards-compatible manner. Yep. The devil is in the details! Bob
Re: message sent to list yesterday
On 12/4/2014 11:17 AM, listsb-spamassas...@bitrate.net wrote: hi- i sent a message to the list yesterday, but have not yet seen it appear. can someone check? my logs indicate successful delivery to mx1.us.apache.org: Dec 3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: to=, relay=mx1.us.apache.org[140.211.11.136]:25, delay=56, delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! <547f92fe.40...@bitrate.net> (Queue-Id: 70BD3358)) thanks -ben I see a message from you at 5:47 PM yesterday (UTC-05:00) which includes the output of some commands like sa-learn --dump magic. http://spamassassin.1065346.n5.nabble.com/different-results-when-using-debug-td113494.html Is that the email you were looking for?
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
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: message sent to list yesterday
The infra team is busy with the emergency issues re: SVN and they would be the only ones who could help. Suggest you just resend and cc me off list. If you are discussing spam and have included real spam samples, you'll likely want to put that info in pastebin and link to it. If you mention bad urls, change them like apache-munge.org so RBLs don't trigger. Try sending without HTML to see if that helps. Regards, KAM
Re: Multiple subject headers - most blank
> I've seen a number of spam messages come through with multiple header > lines ... some of them are blank. > > Subject: > > =?ISO-8859-1?Q?=20The=20Hotte?==?ISO-8859-1?Q?st=20Sm?==?ISO-8859-1?Q?ar?==?ISO-8859-1?Q?tpho?==?ISO-8859-1?Q?nes=20?==?ISO-8859-1?Q?-=20Det?==?ISO-8859-1?Q?ails=20In?==?ISO-8859-1?Q?side=20?= > > Subject: > Subject: > Subject: The Hottest Smartphones - Details Inside > > Any suggestions for a rule to trap this? Hey David, What about the other header, From, Return-Path, Received. Are they the same on multiple mails ? Because you can simply learn to SA this is spam, I think it would be ok Regards -- CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: FF395BD9 GPG FP: DE10 73FD 17EB 5544 A491 B385 1EDA 35DC FF39 5BD9 signature.asc Description: OpenPGP digital signature
Multiple subject headers - most blank
Folks: I've seen a number of spam messages come through with multiple header lines ... some of them are blank. Subject: =?ISO-8859-1?Q?=20The=20Hotte?==?ISO-8859-1?Q?st=20Sm?==?ISO-8859-1?Q?ar?==?ISO-8859-1?Q?tpho?==?ISO-8859-1?Q?nes=20?==?ISO-8859-1?Q?-=20Det?==?ISO-8859-1?Q?ails=20In?==?ISO-8859-1?Q?side=20?= Subject: Subject: Subject: The Hottest Smartphones - Details Inside Any suggestions for a rule to trap this? Thanks! david -- IBM i on Power Systems: For when you can't afford to be out of business! I'm riding a metric century (100 km / 62 miles) in the 2015 American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting http://sa.diabetessucks.net. My goal is $5500 but any amount is appreciated. See where I get my donations from ... visit http://sa.diabetessucks.net/mapdonations.php for an interactive map (it's a geeky thing).
message sent to list yesterday
hi- i sent a message to the list yesterday, but have not yet seen it appear. can someone check? my logs indicate successful delivery to mx1.us.apache.org: Dec 3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: to=, relay=mx1.us.apache.org[140.211.11.136]:25, delay=56, delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! <547f92fe.40...@bitrate.net> (Queue-Id: 70BD3358)) thanks -ben
Re: Argument "perl_version" isn't numeric
On Wed, 3 Dec 2014, Bob Proulx wrote: There have been multiple facets to this problem. The first was a rule update that produced warnings that produced email from every cron run sa-update / sa-learn run if run on recent released spamassassin 3.4.0 but not the development trunk version. That was actually the second facet. The first facet was a new test rule using a perl RE syntax that was introduced in 5.10.0 This rule passed dev validation on perl 5.18-ish, but when it was installed by sa-update on a production 5.8.8-based install it failed lint and the entire rules update was rejected. Avoiding that was the impetus for being able to test the version of perl in a SA conditional. The rest has just been trying to figure out how to do that in a backwards-compatible manner. -- 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 --- You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. -- Lyndon B. Johnson --- 11 days until Bill of Rights day
Re: Argument "perl_version" isn't numeric
Jim Clausing wrote: > What I haven't noticed anyone else mention is that I was getting that error > message even though the perl on my Ubuntu 14.04 system is 5.18.2. You left off your spamassassin version. I assume 3.4.0? On my Debian sid system. (But never use Unstable for a production system. Not unless you enjoy having your house on fire every so often.) $ spamassassin --version SpamAssassin version 3.4.0 running on Perl version 5.20.1 There have been multiple facets to this problem. The first was a rule update that produced warnings that produced email from every cron run sa-update / sa-learn run if run on recent released spamassassin 3.4.0 but not the development trunk version. Therefore it hit almost everyone running any type of production system. It hit your Ubuntu 14.04 system. That was mitigated by disabling the rule for the time being. The capability then being discussed was a suggested version gate using an if expression syntax. This is the spamassassin config parser "if", not the perl "if". That if expression worked for most but it had problems on a quite a bit older perl 5.8.8 still in wide use in RHEL5. It is somewhat surprising that the spamassassin config parser would have a sensitivity there but regardless so it does. Your Ubuntu 14.04 system with perl 5.18.2 probably also is running spamassassin 3.4.0 like my Debian Sid system. It wasn't running the development trunk spamassassin. Therefore the dynamic rule update emitted that warning for you too. But the new suggested rule using the improved if expression gating syntax will work okay for you. Hope that helps, Bob
Re: Argument "perl_version" isn't numeric
On 12/3/2014 6:39 PM, Noel Butler wrote: On 03/12/2014 21:57, Kevin A. McGrail wrote: Sure, if that was truly the case nor would I, but if you are running that old perl, there is plenty of stuff thats outdated, and not all of the goodness gets backports, not just with perl, but with most other things. I can't fight every windmill and changing how distros work re: versions of perl is one I choose not to battle. Regards, KAM Oh absolutely! But why is it SA's problem? Or for that mater, any up-stream's problem if distro X wants to only maintain version_released_in_BC or some such, I mean if, and lets take Redhat for example (not singling RH out, because debian are just as bad, if not worse), they turn around and decide that RHEL since v5 will now be supported for 10 years, not 5, at what point do you draw the line and say " well RH that's your problem " I try to avoid the "that's your problem" discussions as much as possible because, for example, I could make the same argument about supporting 3.3.2 or go further and provide rules at all for the software. So I take the maintain status quo approach as long as the code continues to move forward and we don't spend too many cycles having to work around legacy issues. regards, KAM
Re: different results when using --debug
On 2014.12.03 05.45, Mark Martinec wrote: > listsb-spamassas...@bitrate.net wrote: >> i was testing with a sample message, and noticed that when running >> manually with --debug, there seem to be numerous differences in the >> results, such as scores for the same tests differing, visual ordering >> of results differing [is this significant?], and bayes not being >> listed when using --debug. am i doing something wrong? are my >> expectations misguided? i'm doing these tests as the user named >> amavis, which the amavis software runs as. >> >>> spamassassin --test-mode --debug < message3.txt >> 1.6 RCVD_IN_BRBL_LASTEXT RBL: No description available. > [...] > >>> spamassassin --test-mode < message3.txt >> 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. >> [94.73.46.5 listed in >> bb.barracudacentral.org] >> -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% >> [score: 0.] > > > Apparently in the first case a score set 1 was chosen, and in the second > case a score set 3. Availability of a bayes scanner choses between the two. i'm ignorant here - what is a score set? is there documentation i can read up on? > Could it be that you have a fresh bayes database which had less than 200 > spam and 200 ham entries in the first attempt, but became populated > and functional by the time of the second attempt? i don't believe so - here's another exercise, with bayes info before and after each test. >sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 22642 0 non-token data: nspam 0.000 0 2254 0 non-token data: nham 0.000 0 258660 0 non-token data: ntokens 0.000 0 1416781285 0 non-token data: oldest atime 0.000 0 1417643830 0 non-token data: newest atime 0.000 0 1417643689 0 non-token data: last journal sync atime 0.000 0 1417632951 0 non-token data: last expiry atime 0.000 0 691200 0 non-token data: last expire atime delta 0.000 0 2775 0 non-token data: last expire reduction count >spamassassin --test-mode --debug < message3.txt Content analysis details: (16.0 points, 5.0 required) pts rule name description -- -- 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: ialloansystems.com] 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the DBL blocklist [URIs: ialloansystems.com] 1.6 RCVD_IN_BRBL_LASTEXT RBL: No description available. [94.73.46.5 listed in bb.barracudacentral.org] 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: ialloansystems.com] 0.1 URIBL_SBL_AContains URL's A record listed in the SBL blocklist [URIs: www.ialloansystems.com] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 2.4 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 0.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 2.0 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/) 1.7 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 0.0 DIGEST_MULTIPLEMessage hits more than one network digest check 5.0 KAM_VERY_BLACK_DBL Email that hits both URIBL Black and Spamhaus DBL -3.1 AWLAWL: adjust score towards average for this sender >sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 22642 0 non-token data: nspam 0.000 0 2254 0 non-token data: nham 0.000 0 258660 0 non-token data: ntokens 0.000 0 1416781285 0 non-token data: oldest atime 0.000 0 1417643830 0 non-token data: newest atime 0.000 0 1417643689 0 non-token data: last journal sync atime 0.000 0 1417632951 0 non-token data: last expiry atime 0.000 0 691200 0 non-token data: last expire atime delta 0.000 0 2775 0 non-token data: last expire reduction count >spamassassin --test-mode < message3.txt Content analysis details: (17.0 points, 5.0 required) pts rule name description -- -- 1.7 URIBL_BLACKContains an URL lis
Re: ancient perl versions
On 04/12/2014 00:28, Greg Troxel wrote: > I am really boggled by people wanting to run LTS versions of code with > old versions of tools and expecting to run newer versions of other > things. > > More constructively, it's perfectly possible to build newer perl in a > different prefix. Just because there's an old perl in the base system > doesn't mean someone can't do that; that's what you'd have to do if the > base system didn' have perl. Exactly! The problem is, those who use distro_X only want to use packages released by distro_X's repo, in some cases its pure laziness, in others, not so, some of those package managers have I'm sure been designed by ex Microsoft employees, because try remove one thing, and the package manager will try remove 3/4 of the system. IIRC with Redhat you can tell it to singular remove that program and ignore the deps, so it is, or wasn't, that bad compared the debian's apt. The remainder are just lazy, or don't live on the edge :) footnotes: I use slackware, yes its releases come with latest versions of most things, and updates move with upstreams due to slackwares philosophy and releases are maintained for usually 5 or more years, but even then, the packages can't cater for all configurations, since its no hassle using upstream sources, it wont break anything, and if I only need X and Y built into a binary, I *know* only X and Y is built in, not massive bloat in having A-W, and Z as well, so updating perl for instance is a no brainer should I desire, I have requested the -current repo be updated to 5.20.1 fopr benefit of all slackers, but if I can a rejection on that request, it'll take all of 20 mins to install the bastard from source myself :) (well last time I built it it took 20 mins - might be tad longer now days lol)
Re: Argument "perl_version" isn't numeric
On 03/12/2014 21:57, Kevin A. McGrail wrote: >> Sure, if that was truly the case nor would I, but if you are running that >> old perl, there is plenty of stuff thats outdated, and not all of the >> goodness gets backports, not just with perl, but with most other things. > I can't fight every windmill and changing how distros work re: versions of > perl is one I choose not to battle. > > Regards, > KAM Oh absolutely! But why is it SA's problem? Or for that mater, any up-stream's problem if distro X wants to only maintain version_released_in_BC or some such, I mean if, and lets take Redhat for example (not singling RH out, because debian are just as bad, if not worse), they turn around and decide that RHEL since v5 will now be supported for 10 years, not 5, at what point do you draw the line and say " well RH that's your problem " N
Re: ancient perl versions
On 12/3/2014 6:28 AM, Greg Troxel wrote: I am really boggled by people wanting to run LTS versions of code with old versions of tools and expecting to run newer versions of other things. Microsoft thinks like you do, that's why Internet Explorer 8 was the last version of IE to run on Windows XP. Google does not, that's why Chrome today still runs on Windows XP. Chrome is kicking IE's ass out of major swaths of market share because of this decision. I still see IE required by large IT departments running big commercial apps which require IE - but every end user nowadays I setup with a new PC tells me to install Chrome because they prefer it. What does the SA project want to be? More constructively, it's perfectly possible to build newer perl in a different prefix. Just because there's an old perl in the base system doesn't mean someone can't do that; that's what you'd have to do if the base system didn' have perl. Perl stopped being a good idea to include in the base distos when it decided it was an OK thing to break backwards compatibility with Perl scripts around Perl version 5.0. The clueful distro maintainers started dropping it then. Ted
Re: Honeypot email addresses
Am 03.12.2014 um 02:32 schrieb LuKreme: another recent example: Spamhaus blocked GMX/1&1/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: Argument "perl_version" isn't numeric
On 12/3/2014 7:38 AM, Jim Clausing wrote: What I haven't noticed anyone else mention is that I was getting that error message even though the perl on my Ubuntu 14.04 system is 5.18.2. No, they mentioned it - the problem is that the proposed "fix" to allow inclusion of the new fancy rules only works with newer Perl versions. The argument now is since the proposed fix breaks antique versions of Perl, are we going to tell those people to pound sand or not? Ted -- Jim Clausing GIAC GSE #26, GREM-Gold, CISSP GPG fingerprint = 4780 13A4 F33E BF4E AE86 0D64 0EFD B3E3 03BF 407A On or about Tue, 2 Dec 2014, Noel Butler pontificated thusly: On 02/12/2014 23:10, Kevin A. McGrail wrote: 5.10 is only what, six years old? Surely anyone running anything older have far greater issues :) (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe but theyll join the 14 series this Christmas when I can take them offline to upgrade em, even -current is useing a 12 month old 5.18.1) There is a fairly consistent streak in some distros to backport patches to older versions rather than move the version forward. 5.8.8 is in pretty far spread use from my knowledge. Likely in antique versions of debian and Redhat (which again will have bigger issues), there surely must come a time when the line is drawn and say - you're unsupported from this_date, give them plenty of notice, I think 12 months notice is plenty of time for planned upgrades or devise workarounds, SA is not updated all that often, so a next major release would be about 12 months away, short of a serious exploit found anyway, so there's plenty of time for lazy admins to do what they actually get paid to do :)
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: ancient perl versions
I'm only expecting new rules sets to work, sir. I still run a lamentably antique
version of SA with my middle aged version of perl.
{o.o}
On 2014-12-03 06:28, Greg Troxel wrote:
I am really boggled by people wanting to run LTS versions of code with
old versions of tools and expecting to run newer versions of other
things.
More constructively, it's perfectly possible to build newer perl in a
different prefix. Just because there's an old perl in the base system
doesn't mean someone can't do that; that's what you'd have to do if the
base system didn' have perl.
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 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
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
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
On 11/21/2014 09:49 AM, David F. Skoll wrote: On Fri, 21 Nov 2014 08:43:22 -0800 (PST) John Hardin 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 ...
