jdow wrote:
>
> This is a potential if a list will add a site on the basis of ONE
> spam report. When it takes ten or twenty or more spam reports then
> sites will get listed. Your Scotts example is an example of how a
> large number of people would be likely to consider it to be spam
> and complain. Upon receiving the complaints even a whois lookup to
> confirm it was Scotts would not absolve the company for their spam
> run. Their contest site did not ANYWHERE obvious say that you'd be
> receiving promotional emailings from Scotts as well as contest data.

So question. Can anyone actually produce a promotional mailing
containing a winterizewithscotts.com URL in it?

Paul has theorized it may have happened. Did it? I've not seen a
sample-spam yet.

I personally never entered this contest. I got a link to it through
their lawn-care-update email service. Something I very much did opt-in
for. I've never gotten any other promotional materials from them, other
than the newsletter I subscribe to.

> Thus Scotts DID spam. They got listed. Find a better example.
Did they? Are you sure?

Jumping from "Reading with a skeptics mind I can see how their privacy
policy could be construed to allow marketing material" is quite a bit
different from "Scotts actually did send promotional email to unwitting
customers".

Quite frankly, the way *I* read the scotts privacy policy, they CANNOT
send you promotional materials merely for entering the contest.

I'd very much like to see a sample of one, if it really did happen.

Anyone?

>
>> Take Joe user, who gets a message he considers spam. He runs
>> spamassassin -r on it, reporting the message to spamcop, and Razor (e8
>> is uri based, so relevant here. Pyzor, and DCC will also be reported,
>> but less relevant). The Spamcop report would require multiple reports,
>> but if it happens that feeds into SC and AB, which then re-check
>> theURIs. He then pulls out a few URIs, and manualy reports them to
>> URIBL. He then goes to rulesemporium.com and reports it to WS. If he's
>> got an outblaze account, he could also report to OB.
>
> Average user is one of your customers. Do THEY run spamassassin -r?
>
I did say it was an extreme example. I'm not talking about the common,
I'm talking about what's possible in the worst-case.

> ...
>
>> That's why I'm suggesting we consider a base+offset approach to surbl.
>> It allows each list to be scored independently, but also allows the
>> perceptron to allocate scores that reflect the overlap.
>
> You are suggesting something that may well be valid. What are your
> testing results from the suggestion? YOU control the scores on your
> site, in the final analysis. An /etc/mail/spamassassin/ZZZ_local.cf
> will get parsed last and can override the BL scores. Feed it your
> score suggestions and report the results.
>
I fully intend to do so when I'm next at my site.
>
> Vast increase.... From one in 100,000 to one in 1,000? That would be
> dramatic and it would lead to a multiple list hit overlap issue, as well.
> The overlap might be down in the one in 10,000 level. But with a million
> mails a day to handle that's 100 complaints, more than any sane ISP would
> enjoy handling.
I'm processing about 4k messages per day, with about half of that being
spam (I'm partially greylisting to reduce my spam totals before SA).

I'm seeing enough to find a double-list between uribl and surbl once a week.

>
> At the moment you are focused on something you see as a sure cure. 
No, I see it as worthy of consideration. And testing, which I'm already
planing on.

Right now I'm already testing all those MULTI meta rules with negative
scores in-hand (-1.5 for URIBL_OVERLAP, -0.5 for SURBL_MULTI1 and 2,
-0.2 for the rest.)

I can only test one approach at a time.
> You might
> be right. Only you are in the position to TEST your proposal. I don't see
> anyone here rushing in to take the risk of it being wrong so that you can
> point a finger when the idea backfires. (Hey, after 40 years in industry
> a person learns about this trick and gets, perhaps, a little overly
> cynical from repeated experience. {^_-})
>
> You MIGHT also think out of the box. Are there other things that can be
> done to mitigate the problem? I suspect there are. They'd require some
> tool
> construction. If there is somebody on the list wanting some
> suggestions for
> some perl hacking I can dredge my emails to Matt for some interesting
> tool
> ideas. Some might directly help Jeff more than Matt while others would
> benefit someone in Matt's shoes more than most other folks.
That would be interesting too.

Reply via email to