On 12/01/2015 10:09 PM, Ted Lemon wrote:
I am very curious to hear your numbers, as long as you explain how you got
them. I don't mean explain your spam algorithm--I mean characterize your
sample, and explain why you think it's a good sample, and explain your
methodology: what you did to the sample for test A versus what you did for test
B. Interesting things to do for the test sample to differentiate it from the
control sample would be removing the last Received header field entirely (last
in sequence, meaning first added), modifying the From clause for example as
Stephen Farrell suggested, or simply deleting the From clause but keeping the
rest of the last Received header field.
The issue here is even describing the methodology of comparing the test
sets and the discussion about how it's very difficult to catch the same
spam in other ways, reveals altogether too much information for spammers
to use.
The numbers I've been able to give in these threads should be
informative and are about as far as I can go.
BTW, turning off the Received header field testing for a week isn't a valid
methodology, since there's no way to control for the rather substantial
variation in amounts and types of spam from week to week.
Actually, even though I'm not specifically measuring this over long
periods of time (because the efficacious is already proven well enough
to me and the systems who use the results which is what matters), I
could readily provide time-series numbers that take into account that
variation and demonstrate the usefulness of the technique. But I don't
think it worth the days worth of digging through old log files, and the
exposure risk to the measurement infrastructure itself it would take to
prove to you that I actually do know what I'm talking about.
In an ideal world, when everybody here was under NDA, I could give you some of
the obvious, compelling and overwhelming evidence.
I don't think you could. You've said enough things that don't actually make
sense at this point that I would really need you to show your work, not just
give me assurances like the following:
Your inability to make sense of what I've said is demonstrative of a
lack of operational experience. I don't like "I know, and can't tell
you how, trust me" arguments from authority any more than you do.
Ironically, most people say I talk far too much. I like explaining
things and do a lot of free training in the appropriately secured
venues. But sometimes I have no choice.
Sorry.
If you can tell me what I said doesn't make sense, maybe I could fix
those bits.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp