Companies with an MBA director who happened to read the "blacklist" buzzword somewhere and think they will look good by using it themselves.
Sent from ProtonMail Mobile On Tue, Aug 15, 2017 at 7:02 PM, Shivram Krishnan <rorryk...@gmail.com> wrote: > Thanks for the response Bill. I have got a couple of responses from this > group, which agree with what you are saying - they have their own custom > techniques to prevent spam and reduce false positives. If thats the case, > who uses third-party generated blacklists? > > On Mon, Aug 14, 2017 at 11:01 PM, Bill Cole > <sausers-20150...@billmail.scconsult.com> wrote: > >> On 14 Aug 2017, at 18:00, Shivram Krishnan wrote: >> >>> Hi, >>> >>> I am a graduate student at the University of Southern California and am >>> currently researching on the impact of false positives in blacklists. >> >> Apparently they don't bother with a mandatory Research Methodology course >> for grad students any more. That's disappointing. >> >>> I am >>> aware that spamassassin uses blacklists in its rule based system to stop >>> spam messages. But since it is a rule based system, even if there are false >>> positives in blacklists, there may be other rules which can influence >>> spamassassin to mark it correctly. There are several other blacklists which >>> are used to stop different attacks (eg phishing, DDoS, malware hosting >>> etc). I was wondering if operators in general use external >>> blacklists(uribl, spamhaus, spamcop etc) in the form of rule based system >>> (like spamassassin) or use it outrightly to block all IPs listed in them. >> >> Asking that question HERE assures that you will get a badly skewed sample. >> >> The majority of SA users do not read this list. The majority of email admins >> do not use SA. Many who do use DNSBLs don't understand that they do so, >> because the mail filtering is in a box they were told they never need to >> touch or is done externally by a filtering provider who won't tell customers >> what they use. A very large fraction of legitimate mail, possibly a >> majority, flows between and within a few large providers who do not use SA, >> may or may not cooperate with and/or use publicly available DNSBLs, and will >> never admit to using anything other than their own tools for spam filtering. >> >>> It will be great if you can take this four question survey, which can help >>> me understand the usage of blacklists by operators. >> >> Unfortunately my current answers would be very unusual, because I recently >> lost the job where I actively managed mail systems for pay, and the >> micro-systems I manage for myself and friends who ask for help are tiny and >> ridiculously unrepresentative. >> >> But no matter, I'll act like I still have that job or the one before it or >> any of the others I've had managing mail systems in the age of DNSBLs. >> >>> The survey consists of >>> these questions - >>> 1) The size of the network(s) you manage(in terms of customers) >> >> That is confidential and proprietary business information which I am not >> authorized to share. >> >>> 2) List of external blacklists used. >> >> That is confidential and proprietary business information which I am not >> authorized to share. >> >>> 3) How these blacklists are used? whether in a rule based system or >>> outrightly blocked or both >> >> That is confidential and proprietary business information which I am not >> authorized to share. >> >>> 4) If external blacklists are used in a non-rule based system, how do you >>> overcome false positives? >> >> That is confidential and proprietary business information which I am not >> authorized to share. >> >> I expect that a large percentage of professional email admins would answer >> identically. I would not recommend trusting any who answered substantively. >> >> I would also recommend against sharing this message with your faculty >> advisor. Some questions cannot be answered accurately or meaningfully by >> taking surveys of those willing to answer. Spam control is an operational >> security facility. People doing it who understand their jobs will not >> discuss the details.
