Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Michael Wise via mailop 

Until such time as we have the data, we can't know if it would be useful or not.

Such a list would need exclusions (both globally and locally, much like the PBL 
for instance),
and "Well-Known" NAT IPs would be excluded as well.

But I've seen far too much abuse coming from Colocation facilities of dubious 
reputation for far too long.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Dave Warren
Sent: Tuesday, August 30, 2016 5:06 PM
To: mailop@mailop.org
Subject: Re: [mailop] How many more RBL's do we really need?

On Tue, Aug 30, 2016, at 15:22, Michael Peddemors wrote:
> On 16-08-30 12:43 PM, Michael Wise via mailop wrote:
> > We could use one to call out the location of colo servers that should never 
> > be connecting on port 443, for instance.
> 
> Um, I can think of a reason why that might not be perfect.. For 
> instance cloud services which monitor your email box for you..

Or web servers that shouldn't ever be calling out on 443, at least, until we 
install a new gizmo that does and it doesn't work. Or my mail server, which 
should never call out on 443, except that now we use Cyren's spam/AV stuff, 
which does.

Still, it would be nice if there was a way to identify what type of 
traffic/behaviour is expected of an IP, when a commercially run web server 
starts attacking, it would be nice to know I can safely block 443 whereas I 
can't do that if it's a carrier grade NAT outbound IP.

Unfortunately I suspect maintaining such a list would be resource prohibitive, 
and/or the data would be too low quality to be useful.


___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7cmichael.wise%40microsoft.com%7c07c7ecf1281a4f7a8af408d3d133cc46%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081992800710183&sdata=i0gXVO30064%2fxQNRy8pEeFTxErR0%2fBH27u%2fqDI%2feBY4%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Dave Warren 
On Tue, Aug 30, 2016, at 15:22, Michael Peddemors wrote:
> On 16-08-30 12:43 PM, Michael Wise via mailop wrote:
> > We could use one to call out the location of colo servers that should never 
> > be connecting on port 443, for instance.
> 
> Um, I can think of a reason why that might not be perfect.. For instance 
> cloud services which monitor your email box for you..

Or web servers that shouldn't ever be calling out on 443, at least,
until we install a new gizmo that does and it doesn't work. Or my mail
server, which should never call out on 443, except that now we use
Cyren's spam/AV stuff, which does.

Still, it would be nice if there was a way to identify what type of
traffic/behaviour is expected of an IP, when a commercially run web
server starts attacking, it would be nice to know I can safely block 443
whereas I can't do that if it's a carrier grade NAT outbound IP.

Unfortunately I suspect maintaining such a list would be resource
prohibitive, and/or the data would be too low quality to be useful.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Michael Wise via mailop 
We are working on the Azure issue.
Ran into a few hiccups on the way.
But the issue is being worked.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Peddemors
Sent: Tuesday, August 30, 2016 3:23 PM
To: mailop@mailop.org
Subject: Re: [mailop] How many more RBL's do we really need?

On 16-08-30 12:43 PM, Michael Wise via mailop wrote:
> We could use one to call out the location of colo servers that should never 
> be connecting on port 443, for instance.

Um, I can think of a reason why that might not be perfect.. For instance cloud 
services which monitor your email box for you..

But we get what you mean, having just helped a client that was undergoing a 
'dictionary attack' from one.. (Was actually trying
POP/IMAP/POPSSL/IMAPSSL) Shoutout to VolumeDrive. 

And of course, most people already have a 'local' way of blacklisting them, 
methods similar to fail2ban etc..

However, it is funny you mention this.. launching a new DNSBL data collection 
method just for these types of 'hack' sources..

But not sure if DNSBL is the way to use this data.. And the moment we do, of 
course they just move back to BOTs on DYNA.. and of course you can't block 
access to 443 from the dynamic IP Address space, because that is where the 
legitimate users of 443 are..

Which is why we are pushing for changes to the protocols themselves..
Pushing for demanding better public listing of the operators of colo servers 
(rwhois/SWIP) ..

But, sometimes.. (and back to Michelle and the early days of SORBS) sometimes, 
aggressive DNSBL listings do force REAL change among operators, to actually do 
something about their business models of allowing that type of activity on 
their networks..

But given the recent spike's in activity of 'cloud' providers ..

(eg, you might like to block anything from www-data@ that comes from 
cloudapp.net, especially if it was generated from a PHP Script)

Return-Path: 
Received: from weifuh-ff12.cloudapp.net (HELO mail.live.com) (40.74.120.249)
Received: by mail.live.com (Postfix, from userid 33)
Subject: Nota Fiscal Eletrônica Nacional de serie/número [2/709460] - [
935453087  ]
X-PHP-Originating-Script: 0:d3jcfdmypm7hett.php

.. you can expect that another round of controversy surrounding reputation 
providers is coming nigh.. there is more and more talk around making the 
providers responsible for activity on their networks.. in that vein, DNSBL's 
are the least of their worries.

The Digital Ocean's and Amazon's might have started this new opportunity for 
spammers and hackers (eg anonymous clouds) but now everyone is building one.. 
$1 VPS's.. anonymous clouds..

Not surprising everyone is building a DNSBL ;)

PS, while we might thank Microsoft for making the information on AZURE space 
available, maybe Microsoft could do a couple of things..

* Make the information available in a DNSBL format
* SWIP the space as being used for AZURE

NetRange:   40.74.0.0 - 40.125.127.255
CIDR:   40.125.0.0/17, 40.74.0.0/15, 40.76.0.0/14, 
40.124.0.0/16, 40.120.0.0/14, 40.112.0.0/13, 40.80.0.0/12, 40.96.0.0/12

Even better..
* Block traffic to Port 25 et al on Egress from the space (they can use Port 
587 Submissions and relays)

Oh, yeah.. but you mentioned they were attacking Port 443 ;) Umm... we could do 
that from a script on Azure I assume as well.





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.linuxmagic.com&data=02%7c01%7cmichael.wise%40microsoft.com%7cbef42e20e7974cbc804a08d3d1253a47%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081930225717450&sdata=84MyX3OTfaTDX9rO2Kk31eB4bjIsyKUxSBt3NkxU%2fGQ%3d
 @linuxmagic

A Wizard IT Company - For More Info 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.wizard.ca&data=02%7c01%7cmichael.wise%40microsoft.com%7cbef42e20e7974cbc804a08d3d1253a47%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081930225717450&sdata=71mPCFFloX3Mq9eBrj4F%2fe43AqfqhULF%2fw%2fzl5CKDlI%3d
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended 
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely those 
of the author and are not intended to represent those of the company.

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Michael Peddemors 

On 16-08-30 12:43 PM, Michael Wise via mailop wrote:

We could use one to call out the location of colo servers that should never be 
connecting on port 443, for instance.


Um, I can think of a reason why that might not be perfect.. For instance 
cloud services which monitor your email box for you..


But we get what you mean, having just helped a client that was 
undergoing a 'dictionary attack' from one.. (Was actually trying 
POP/IMAP/POPSSL/IMAPSSL) Shoutout to VolumeDrive. 


And of course, most people already have a 'local' way of blacklisting 
them, methods similar to fail2ban etc..


However, it is funny you mention this.. launching a new DNSBL data 
collection method just for these types of 'hack' sources..


But not sure if DNSBL is the way to use this data.. And the moment we 
do, of course they just move back to BOTs on DYNA.. and of course you 
can't block access to 443 from the dynamic IP Address space, because 
that is where the legitimate users of 443 are..


Which is why we are pushing for changes to the protocols themselves..
Pushing for demanding better public listing of the operators of colo 
servers (rwhois/SWIP) ..


But, sometimes.. (and back to Michelle and the early days of SORBS) 
sometimes, aggressive DNSBL listings do force REAL change among 
operators, to actually do something about their business models of 
allowing that type of activity on their networks..


But given the recent spike's in activity of 'cloud' providers ..

(eg, you might like to block anything from www-data@ that comes from 
cloudapp.net, especially if it was generated from a PHP Script)


Return-Path: 
Received: from weifuh-ff12.cloudapp.net (HELO mail.live.com) (40.74.120.249)
Received: by mail.live.com (Postfix, from userid 33)
Subject: Nota Fiscal Eletrônica Nacional de serie/número [2/709460] - [ 
935453087  ]

X-PHP-Originating-Script: 0:d3jcfdmypm7hett.php

.. you can expect that another round of controversy surrounding 
reputation providers is coming nigh.. there is more and more talk around 
making the providers responsible for activity on their networks.. in 
that vein, DNSBL's are the least of their worries.


The Digital Ocean's and Amazon's might have started this new opportunity 
for spammers and hackers (eg anonymous clouds) but now everyone is 
building one.. $1 VPS's.. anonymous clouds..


Not surprising everyone is building a DNSBL ;)

PS, while we might thank Microsoft for making the information on AZURE 
space available, maybe Microsoft could do a couple of things..


* Make the information available in a DNSBL format
* SWIP the space as being used for AZURE

NetRange:   40.74.0.0 - 40.125.127.255
CIDR:   40.125.0.0/17, 40.74.0.0/15, 40.76.0.0/14, 
40.124.0.0/16, 40.120.0.0/14, 40.112.0.0/13, 40.80.0.0/12, 40.96.0.0/12


Even better..
* Block traffic to Port 25 et al on Egress from the space (they can use 
Port 587 Submissions and relays)


Oh, yeah.. but you mentioned they were attacking Port 443 ;)
Umm... we could do that from a script on Azure I assume as well.





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and 
intended solely for the use of the individual or entity to which they 
are addressed.
Please note that any views or opinions presented in this email are 
solely those of the author and are not intended to represent those of 
the company.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Michael Wise via mailop 

What if you have a secret, pretty much foolproof test, but you don't want to 
reveal that you know it's spam...?

I think it would be good to put some descriptive (to the Abuse desk, at least) 
code in the reject message, and get the senders to contact the desk and request 
for clarification. Most bad guys won't bother, and will try Black Box Analysis, 
others will just go elsewhere.

And no, we don't have enough DNSBLs (RBL is a trademark, after all).
We could use one to call out the location of colo servers that should never be 
connecting on port 443, for instance.
And many other things.

And we should also not stop evaluating a connection just based on the first hit.
We should distinguish between an IP block and a content block in the message, 
though.
Some people go off on the second thinking it's the first.

Aloha,
Michael.
-- 
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting Tool ?

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of David Hofstee
Sent: Tuesday, August 30, 2016 12:18 AM
To: mailop 
Subject: Re: [mailop] How many more RBL's do we really need?

I for one welcome the explicit blocks of email. They tell me simply what is 
wrong so I can (let people) fix things. What I really hate is the "possible 
spam detected"-like messages. I don't have time to check all 40 domains in the 
email and all IPs involved for those domains (and then usually not finding 
badness). I like to nitpick and find bad stuff, but that stretches it. Explicit 
blocks make my life easier.

So even if you weigh RBLs it would be nice to see the most important reason 
stated in the smtp reply. You could even change that behaviour given the 
reputation of the sender. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Anne P. Mitchell" 
Aan: "Michael Wise via mailop" 
Verzonden: Maandag 29 augustus 2016 19:08:58
Onderwerp: Re: [mailop] How many more RBL's do we really need?

> using Barracuda's RBL for high scoring, and not for outright blocking.

I think that in this day and age, this is true for *any* list - black-, white-, 
reputation- (yes, even ours).  Whitelists can also have false positives - even 
pay for play ones, because while full-on spammers may not pay to be on a 
whitelist, or for reputation certification, etc,  organizations that are 
whitehat can experience personnel changes in their email and marketing 
departments, and an organization can go from blindingly white to a shade of 
grey overnight. 

Plus, even more now than ever, what one receiving system may think of as 'spam' 
another may think of as 'legitimate email our users just didn't know they 
wanted'.  In fact, that's why we take pains to make a point that our lists are 
*not* whitelists - they are lists where receivers can get information about the 
specific practices of the senders - so, like Rob said - use them for scoring, 
not for outright blocking (well, accepting, in our case).

Anne

Anne P. Mitchell,
Attorney at Law
Legislative Consultant
CEO/President,
SuretyMail Email Reputation Certification and Inbox Delivery Assistance 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.SuretyMail.com%2f&data=02%7c01%7cmichael.wise%40microsoft.com%7c0e083a89b84749b7d0bc08d3d0a6fb96%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081388002068480&sdata=72BiVxdFgBniaaiRZBoC15Uwd73HE6kF9URWSr9mW38%3d
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.SuretyMail.eu%2f&data=02%7c01%7cmichael.wise%40microsoft.com%7c0e083a89b84749b7d0bc08d3d0a6fb96%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081388002068480&sdata=kyyKMI6khHq%2fOzMoOzc%2fQMllBgbMUFJrA9LpaR8oaS8%3d

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) 
Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity 
Consortium Member, Asilomar Microcomputer Workshop Committee Ret. Professor of 
Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop 
amitch...@isipp.com | @AnnePMitchell Facebook/AnnePMitchell  | 
LinkedIn/in/annemitchell



___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=02%7c01%7cmichael.wise%40microsoft.com%7c0e083a89b84749b7d0bc08d3d0a6fb96%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636081388002068480&sdata=Pk5lwBprxtESL67zlgS4Z5KpAEWrVGHQ%2b%2b533s1viaU%3d

___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&da

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Brandon Long via mailop 
I did a survey of iconography and words for different mail ui's several
years back, and i think hotmail and yahoo used the same iconography, one
for spam the other for trash.  The desire to use "junk" in place of spam is
probably partially to blame, as well.

ahh, from 2011, here, it was Apple Mail and Outlook that were opposite:
Evolution uses the red circle as trash, and crumbled paper as "junk", which
seems backwards myself.

Thunderbird uses an X for trash, and a trash can with a green "no entry"
circle for junk, which again doesn't seem that clear.

Apple Mail uses the red no entry for trash, and I can't tell if its a
shopping bag or garbage can with a green recycle logo and letters poking
out the top.

Outlook appears to use the opposite from Apple Mail, a recycle garbage can
for trash, and a folder or envelope with a red no entry symbol.

Hotmail is an black X for delete and a red X on envelope for junk (with the
words next to it)

Yahoo mail is a trash can for trash, and a flaming envelope for junk (with
words next to it)

On Tue, Aug 30, 2016 at 5:53 AM, David Hofstee  wrote:

> The Live.com Spam-butten, in Dutch, translates into 'unwanted mail'. Ok...
> Sure. Whatever.
>
>
> Met vriendelijke groet,
>
>
> David Hofstee
>
> Deliverability Management
> MailPlus B.V. Netherlands (ESP)
>
> - Oorspronkelijk bericht -
> Van: "Dominique Rousseau" 
> Aan: mailop@mailop.org
> Verzonden: Dinsdag 30 augustus 2016 14:37:45
> Onderwerp: Re: [mailop] How many more RBL's do we really need?
>
> Le Tue, Aug 30, 2016 at 05:08:21AM -0400, Neil Schwartzman [n...@cauce.org]
> a écrit:
> [...]
> > I saw, and continue to see to this day, error in reporting from *all*
> > such sources (they are myriad, probably numbering in a couple of dozen
> > these days), they are no more endemic to AOL than any other provider.
>
> I never saw what the UI looks like, for AOL users,...
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread David Hofstee 
The Live.com Spam-butten, in Dutch, translates into 'unwanted mail'. Ok... 
Sure. Whatever. 


Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Dominique Rousseau" 
Aan: mailop@mailop.org
Verzonden: Dinsdag 30 augustus 2016 14:37:45
Onderwerp: Re: [mailop] How many more RBL's do we really need?

Le Tue, Aug 30, 2016 at 05:08:21AM -0400, Neil Schwartzman [n...@cauce.org] a 
écrit:
[...]
> I saw, and continue to see to this day, error in reporting from *all*
> such sources (they are myriad, probably numbering in a couple of dozen
> these days), they are no more endemic to AOL than any other provider. 

I never saw what the UI looks like, for AOL users,...

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Dominique Rousseau 
Le Tue, Aug 30, 2016 at 05:08:21AM -0400, Neil Schwartzman [n...@cauce.org] a 
écrit:
[...]
> I saw, and continue to see to this day, error in reporting from *all*
> such sources (they are myriad, probably numbering in a couple of dozen
> these days), they are no more endemic to AOL than any other provider. 

I never saw what the UI looks like, for AOL users, but have longly
suspected they use not-so-clear illustrations and/or terms for
distinguishing "delete this email" and "report this content as spam".

Let's say the second one is called "Junk", what is a user supposed to
understand ?

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Jim Popovitch 
On Aug 30, 2016 05:10, "Neil Schwartzman"  wrote:
>
> Users, like all humans, make errors. Are sys admins the sole tranche
immune to such things? Somehow, I doubt it.
>

But what should be done about those who repeat their errors...within 5
months of their last error...

-Jim P.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Michelle Sullivan 

Rob McEwen wrote:


But, otherwise, I'm having a hard time working up the motivation to 
spend any more time trying change your mind about those things I said 
with which you disagreed--because the world would be a worse place if 
SORBS tried to be an invaluement clone, AND a worse place if 
invaluement tried to be a SORBS clone.


Not suggesting that it should be in anyway what so ever Not quite 
sure where you got the thought that I might have suggested it... I was 
deliberately trying to generalise and keep naming names to a minimum 
(and you'll note that *none* of my comments were actually directed at 
invaluement - they were all comments surrounding those directly 
mentioned but hopefully generalised enough that fingers were not pointed 
where there was something lacking.)


Regards,

--
Michelle Sullivan
http://www.mhix.org/


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Neil Schwartzman 
I used to run a whitelist, and it was predicated upon FBL reports as one metric 
for list purity.

I saw, and continue to see to this day, error in reporting from *all* such 
sources (they are myriad, probably numbering in a couple of dozen these days), 
they are no more endemic to AOL than any other provider. 

I’ve seen credit card statements, password resets, and conversations between 
lovers all reported (the latter, much to my personal embarrassment. It was 
quite explicit, although admittedly I did pick up a few good tips). 

Users, like all humans, make errors. Are sys admins the sole tranche immune to 
such things? Somehow, I doubt it.


> On Aug 30, 2016, at 12:31 AM, Rob McEwen  wrote:
> 
> On 8/29/2016 10:17 AM, Mathias Ullrich wrote:
>> In my opinion and given, that we are talking about UCE, if it's
>> unsolicited mail, the recipient shouldn't get the email in the first
>> place, and if that's the case, the "report junk" button is the correct one.
>> 
>> If you are talking about one to one communication, forget my comment,
> 
> AOL has a fantastic feedback loop... but surprisingly often, an AOL user will 
> mistakenly use the "report spam" button as if it were the "delete button"... 
> and delete hand-typed messages that were clearly part of amicable and ongoing 
> conversations between close friends/relatives... or stuff like receipts for 
> something they just literally bought seconds ago... or newsletters from 
> organizations for which they are active paying members... etc.
> -- 
> Rob McEwen
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread Dave Warren 
Worse still is the silent discards... It makes you beg for a "possible
spam detected". 

The BOFH in me has always wanted to adjust my rejection messages to show
the lowest scored DNSBL in the rejection message, then add a bunch of
useless, high-false-negative DNSBLs with trivially low scores just to
confuse senders, but I've never had the time or energy to implement it.
Plus, I'm not usually that much of a jerk.

On Tue, Aug 30, 2016, at 00:18, David Hofstee wrote:
> I for one welcome the explicit blocks of email. They tell me simply what
> is wrong so I can (let people) fix things. What I really hate is the
> "possible spam detected"-like messages. I don't have time to check all 40
> domains in the email and all IPs involved for those domains (and then
> usually not finding badness). I like to nitpick and find bad stuff, but
> that stretches it. Explicit blocks make my life easier.
> 
> So even if you weigh RBLs it would be nice to see the most important
> reason stated in the smtp reply. You could even change that behaviour
> given the reputation of the sender. 
> 
> Met vriendelijke groet,
> 
> 
> David Hofstee
> 
> Deliverability Management
> MailPlus B.V. Netherlands (ESP)
> 
> - Oorspronkelijk bericht -
> Van: "Anne P. Mitchell" 
> Aan: "Michael Wise via mailop" 
> Verzonden: Maandag 29 augustus 2016 19:08:58
> Onderwerp: Re: [mailop] How many more RBL's do we really need?
> 
> > using Barracuda's RBL for high scoring, and not for outright blocking.
> 
> I think that in this day and age, this is true for *any* list - black-,
> white-, reputation- (yes, even ours).  Whitelists can also have false
> positives - even pay for play ones, because while full-on spammers may
> not pay to be on a whitelist, or for reputation certification, etc, 
> organizations that are whitehat can experience personnel changes in their
> email and marketing departments, and an organization can go from
> blindingly white to a shade of grey overnight. 
> 
> Plus, even more now than ever, what one receiving system may think of as
> 'spam' another may think of as 'legitimate email our users just didn't
> know they wanted'.  In fact, that's why we take pains to make a point
> that our lists are *not* whitelists - they are lists where receivers can
> get information about the specific practices of the senders - so, like
> Rob said - use them for scoring, not for outright blocking (well,
> accepting, in our case).
> 
> Anne
> 
> Anne P. Mitchell, 
> Attorney at Law
> Legislative Consultant
> CEO/President, 
> SuretyMail Email Reputation Certification and Inbox Delivery Assistance
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
> 
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Member, Asilomar Microcomputer Workshop Committee
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop
> amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-30 Thread David Hofstee 
I for one welcome the explicit blocks of email. They tell me simply what is 
wrong so I can (let people) fix things. What I really hate is the "possible 
spam detected"-like messages. I don't have time to check all 40 domains in the 
email and all IPs involved for those domains (and then usually not finding 
badness). I like to nitpick and find bad stuff, but that stretches it. Explicit 
blocks make my life easier.

So even if you weigh RBLs it would be nice to see the most important reason 
stated in the smtp reply. You could even change that behaviour given the 
reputation of the sender. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Anne P. Mitchell" 
Aan: "Michael Wise via mailop" 
Verzonden: Maandag 29 augustus 2016 19:08:58
Onderwerp: Re: [mailop] How many more RBL's do we really need?

> using Barracuda's RBL for high scoring, and not for outright blocking.

I think that in this day and age, this is true for *any* list - black-, white-, 
reputation- (yes, even ours).  Whitelists can also have false positives - even 
pay for play ones, because while full-on spammers may not pay to be on a 
whitelist, or for reputation certification, etc,  organizations that are 
whitehat can experience personnel changes in their email and marketing 
departments, and an organization can go from blindingly white to a shade of 
grey overnight. 

Plus, even more now than ever, what one receiving system may think of as 'spam' 
another may think of as 'legitimate email our users just didn't know they 
wanted'.  In fact, that's why we take pains to make a point that our lists are 
*not* whitelists - they are lists where receivers can get information about the 
specific practices of the senders - so, like Rob said - use them for scoring, 
not for outright blocking (well, accepting, in our case).

Anne

Anne P. Mitchell, 
Attorney at Law
Legislative Consultant
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Asilomar Microcomputer Workshop Committee
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Rob McEwen 

On 8/29/2016 8:40 PM, Michelle Sullivan wrote:

The point being what is an FP?  Something blocked that was blocked by
the RBL for a completely valid reason, that I wouldn't want to block, or
something that the RBL blocked that did not match the policy they
publish that they operate by?


Michelle,

Yes, technically, "blocked that did not match the policy they publish" 
is a more accurate, scientific, dictionary-ish definition of a FP. But I 
think the real world is both more complicated and more nuanced.. and 
"what the people want" should ALSO be factored in, too--or, at least... 
AFTER statistical human errors... and occasional rare human crazies... 
and "artificial turf" manipulation by spammers or marketers... are 
(hopefully!) factored out.


AND I understand your point about some blacklists being more helpful or 
more harmful to DIFFERENT consumers of that blacklist. (especially, 
geography can be a huge factor)


But, otherwise, I'm having a hard time working up the motivation to 
spend any more time trying change your mind about those things I said 
with which you disagreed--because the world would be a worse place if 
SORBS tried to be an invaluement clone, AND a worse place if invaluement 
tried to be a SORBS clone.


--
Rob McEwen


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Rob McEwen 

On 8/29/2016 10:17 AM, Mathias Ullrich wrote:

In my opinion and given, that we are talking about UCE, if it's
unsolicited mail, the recipient shouldn't get the email in the first
place, and if that's the case, the "report junk" button is the correct one.

If you are talking about one to one communication, forget my comment,


AOL has a fantastic feedback loop... but surprisingly often, an AOL user 
will mistakenly use the "report spam" button as if it were the "delete 
button"... and delete hand-typed messages that were clearly part of 
amicable and ongoing conversations between close friends/relatives... or 
stuff like receipts for something they just literally bought seconds 
ago... or newsletters from organizations for which they are active 
paying members... etc.

--
Rob McEwen



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Michael Peddemors 

On 16-08-29 05:40 PM, Michelle Sullivan wrote:


Don't you just hate these threads that can start arguments on what is an
FP and what is not? :P


You know what we could use more of?

https://www.intra2net.com/en/support/antispam/
https://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html

There isn't much like this any more..

Might be something that we can encourage universities, and/or large 
organizations with large email volumes who have the capability to check..


Not saying Google should do this ;)

But for example, tag incoming emails somehow with a hash of which RBL's 
would be triggered, and compare it to their internal spam/ham systems.


Any one else know some hidden gems on the 'net that might not be on the 
search results of real world results that can be shared around?


Of course, the problem really stems from what Michelle alluded to..
While we can probably all agree on 99% of the content, it is that last 
1% that different operators have different opinions on..


The small little WISP in rural Texas might have different opinions on 
what type of email they think their users want, than the large email 
provider in Turkey.. different RBL's can serve different purposes..


(oh, and you should see the Clinton/Trump divide on what is spam and 
what isn't)


We used to do this with some friendly ISP's (course we didn't use direct 
RBL lookups, we created a caching system) in logging mode to identify 
UNIQUE and MULTIPLE RBL hits in the early days, but it really should be 
tied into some form of customer definition as well. (This is junk/not 
junk) but even then, take the case of the large provider who has a 
temporary really bad spam outbreak.. was the RBL who listed them wrong 
when a couple of good messages from the same source where also tagged?


However, I think that data would be useful to help others make informed 
choices on which RBL's they might like to implement.


RBL's are still one of the most efficient and effective way to reject 
the worst/most of the current spam outbreaks. (Followed by other simple 
DNS checks..talking to you 'static.vnpt.vn' and 'broadband.actcorp.in')


But open comparison sources of the accuracy/validity of the data is 
something that would help everyone.  I do suggest it needs to be based 
on demographics though.  Which RBL's are most effective for email 
servers based on continent they operate might be a great start.


(For instance, lists that identified sources of the CUT-WAIL outbreak 
for a while could claim to block 80-90-99% + of all attacks, if you 
happened to be one of those targeted by those attacks, doesn't mean in 
the long term it is the most accurate RBL for others)


And I am sure that Gmail, or Yahoo, or AOL each would have a different 
opinion, based on the attackers who prefer targeting them, on which RBL 
is best (which is probably why they also run their own to some extent or 
another).







--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Michelle Sullivan 

Rob McEwen wrote:


For this reason, I regularly encounter hand-typed legit messages 
blocked by even SpamHaus's Zen list--yet Zen continues to be the best 
blacklist. In pretty much all such cases, those Zen "false positives" 
(if you can even call them that?) were situations where a small-ish 
legit sender had a compromised account that was spewing out much spam, 
and the ratio of spam/ham made the collateral damage very 
justifiable--and usually the blacklisting is short lived, keeping 
collateral damage to a minimum.


What separates the men from the boys here is NOT which list has zero 
FPs... but instead... which keeps such collateral damage to a minimum, 
via making good judgements about the ratio of spam blocked vs. 
resulting collateral damage--and keeping such listings short-lived, 
yet WITHOUT giving deliberate snowshoe spammers easy-off mechanisms, 
or too-short expire times.


By this very measure, Barracuda's RBL is a great list, but still not 
nearly as good as Zen, and probably too risky for outright blocking by 
larger senders.


From my perspective, you're wrong.. but you're also right...  Here's my 
observations:


My Own blocklist has very few false positives (if any) for some people, 
but has a good many for others (and for a few more than 50%)

Spamhaus is the same, it has few FPs for some people and has FPs for others.
Barracuda is the same.. it has few FPs for some and lots for others...

What I have observed is it depends on the domain you are using to 
receive email, it depends also on the location (globally) where your 
MX's are, it also depends on what you do (the company/you personally etc..)


I can also say definitively (again by observation - and by my definition 
of a FP - which is something that is listed that does not match the 
definition of the stated reason for the listing) that Spamhaus has far 
more FPs than Barracuda and SORBS put together... However, two point in 
their defense... first, I haven't seen much in the way of evidence to 
say that those FPs are undesirable (unlike what may consider to be FPs 
in SORBS for example, where their definition is "listings of IPs I 
wouldn't want to block"), and second the likes of Barracuda skew the 
'FP' test by being quite deliberately vague about a listing reason as 
does the definition of an FP.  The point being what is an FP?  Something 
blocked that was blocked by the RBL for a completely valid reason, that 
I wouldn't want to block, or something that the RBL blocked that did not 
match the policy they publish that they operate by?


As for the OPs comments.. "RBL's that rely on 15 year old data sets 
should be forgotten" is very misleading, and I would state is wrong... I 
have listings in SORBS from 2003 which are still perfectly valid and 
correct..  The data may be 13 years old, but if I were to go and recheck 
it today it would be the same *correct* result... so the date on the 
dataset has little to do with validity.  Similarly I have historical 
data going back to the very beginning including Audit logs of the same.. 
it's not exported for use by anyone, but the listings are there for 
historical record and research... would this invalidate the SORBS RBL 
for 'old data'... I think not, you're welcome to think otherwise.


Don't you just hate these threads that can start arguments on what is an 
FP and what is not? :P


--
Michelle Sullivan
http://www.mhix.org/


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Tim Starr 
My impression of it has always been that it is a "pay to get whitelisted"
system, but not a "pay to stay whitelisted" one. IOW, you can be booted off
at any time, and can't buy your way back on - at least, not w/ the same
domain. But that is only my external impression, I have no direct
first-hand experience w/ it, just friends who used to work for Barracuda.

-Tim

On Mon, Aug 29, 2016 at 8:55 AM, Rob McEwen  wrote:

> On 8/29/2016 10:26 AM, Eric Henson wrote:
>
>> Rob posted in the thread above that emailreg.org is legit.
>>
>
> fwiw, here is what I said about emailreg.org, back in 2009:
>
> -
> Someone I have great respect for has vouched to me (off-list) that he has
> inside personal knowledge of emailreg.org and that he knows for 100%
> positive that this is well run, very ethically run, and NOT pay-for-play
> (or something like that--still trying to figure that last one out a bit).
> Nevertheless, given this person's confidential assessment, I am now
> convinced that there are honest and altruistic intentions behind
> emailreg.org and I'm convinced that those running it must be highly
> ethical and competent. (I'm still distrustful of the quality of ANY
> whitelist which involves payment even if the intentions are honorable, but
> that is just my personal taste.)
> -
>
> That is what I said in 2009. But I continue to have doubts about how the
> stated altruistic goals can even be achieved without this downward
> spiraling into pay-for-play... or, at the least, how pay for whitelisting
> can't lead to a negative impact on the quality of the whitelist, especially
> when compared to whitelists that are instead built by recipients' feedback,
> etc? Still, considering the good things that I was told in confidence by an
> unbiased industry expert, I'm very much inclined to give emailreg.org
> MUCH "benefit of the doubt"
>
> --
> Rob McEwen
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Anne Mitchell 

> using Barracuda's RBL for high scoring, and not for outright blocking.

I think that in this day and age, this is true for *any* list - black-, white-, 
reputation- (yes, even ours).  Whitelists can also have false positives - even 
pay for play ones, because while full-on spammers may not pay to be on a 
whitelist, or for reputation certification, etc,  organizations that are 
whitehat can experience personnel changes in their email and marketing 
departments, and an organization can go from blindingly white to a shade of 
grey overnight. 

Plus, even more now than ever, what one receiving system may think of as 'spam' 
another may think of as 'legitimate email our users just didn't know they 
wanted'.  In fact, that's why we take pains to make a point that our lists are 
*not* whitelists - they are lists where receivers can get information about the 
specific practices of the senders - so, like Rob said - use them for scoring, 
not for outright blocking (well, accepting, in our case).

Anne

Anne P. Mitchell, 
Attorney at Law
Legislative Consultant
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Asilomar Microcomputer Workshop Committee
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Simon Forster 

> On 29 Aug 2016, at 14:45, Bryan Vest  wrote:
> 
> This may have been brought up before and if there is already a group please 
> point me to it, but we need a study group/governing body/RFC to at least put 
> out suggestions on RBL structure.

RFC 6471 - Overview of Best Email DNS-Based List (DNSBL) Operational Practices 
>.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Rob McEwen 

On 8/29/2016 10:26 AM, Eric Henson wrote:

Rob posted in the thread above that emailreg.org is legit.


fwiw, here is what I said about emailreg.org, back in 2009:

-
Someone I have great respect for has vouched to me (off-list) that he 
has inside personal knowledge of emailreg.org and that he knows for 100% 
positive that this is well run, very ethically run, and NOT pay-for-play 
(or something like that--still trying to figure that last one out a 
bit). Nevertheless, given this person's confidential assessment, I am 
now convinced that there are honest and altruistic intentions behind 
emailreg.org and I'm convinced that those running it must be highly 
ethical and competent. (I'm still distrustful of the quality of ANY 
whitelist which involves payment even if the intentions are honorable, 
but that is just my personal taste.)

-

That is what I said in 2009. But I continue to have doubts about how the 
stated altruistic goals can even be achieved without this downward 
spiraling into pay-for-play... or, at the least, how pay for 
whitelisting can't lead to a negative impact on the quality of the 
whitelist, especially when compared to whitelists that are instead built 
by recipients' feedback, etc? Still, considering the good things that I 
was told in confidence by an unbiased industry expert, I'm very much 
inclined to give emailreg.org MUCH "benefit of the doubt"


--
Rob McEwen



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Dominique Rousseau 
Le Mon, Aug 29, 2016 at 04:17:05PM +0200, Mathias Ullrich 
[mathias.ullr...@optivo.de] a écrit:
> In my opionion and given, that we are talking about UCE, if it's
> unsolicited mail, the recipient shouldn't get the email in the first
> place, and if that's the case, the "report junk" button is the
> correct one.
> 
> If you are talking about one to one communication, forget my comment,

Receiving feedback loop email from AOL for the mail servers I manage,
there are more than a few of them that report once-sollicited emails,
such as newsletters (from commercial website or not), as "junk".
And for some I looked at precisely, they do include working unsubcribe
links.

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread David Hofstee 
It see it as typical that one receives a baseline of 0.02% or 0.01% complaints 
for legitimate senders where the opt-in process is fine and dandy. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 


Van: "Eric Henson"  
Aan: "Suresh Ramasubramanian"  
Cc: mailop@mailop.org 
Verzonden: Maandag 29 augustus 2016 16:26:09 
Onderwerp: Re: [mailop] How many more RBL's do we really need? 



The relationship between Barracuda and EmailReg.org isn’t very clear. At the 
very least, Barracuda is sponsoring EmailReg.org, providing them with 
equipment, IP space, and referrals. Emailreg.org claims the $20/year is to keep 
spammers from abusing the service. 



http://spamassassin.1065346.n5.nabble.com/emailreg-org-pretty-good-white-list-td67383.html
 




I should mention that Rob McElwen—who I see just posted—runs a good RBL, I 
stopped using it earlier this year because we started using the Barracuda RBL 
when we bought our Barracuda appliances. Rob posted in the thread above that 
emailreg.org is legit. 



Mathias—I’m referring to transactional emails (“We have received your order”, 
“we have shipped your order”) as well as replies to emails from the customer 
(1.Customer emails, “where is my order?”, 2. Email agent replies, “we shipped 
it yesterday”, 3. customer marks reply as spam). Take a look at 
http://www.pfsweb.com/what-we-do/omni-channel-operations.php and 
http://www.pfsweb.com/clients/ and you should get a pretty good idea of what 
these emails look like. 








From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com] 
Sent: Monday, August 29, 2016 9:04 AM 
To: Eric Henson 
Cc: mailop@mailop.org 
Subject: Re: [mailop] How many more RBL's do we really need? 





Does Barracuda still operate that paid whitelist? 



--srs 



On 29-Aug-2016, at 7:28 PM, Eric Henson < ehen...@pfsweb.com > wrote: 





I’ve done lots of RBL testing, for years, and the only RBLs that I’m using are 
the ones that are effective and don’t have false positives: Barracuda RBL and 
Spamhaus Zen (paid). But I still do my best to keep my mail servers off the 
other lists; usually this just means I stop sending email from one of my 
gateways for a week. I also had to sign up for the AOL junk reporting service 
because their users are too stupid to know the difference between the “delete” 
button and the “report junk” button. 




___ 
mailop mailing list 
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Rob McEwen 

On 8/29/2016 9:58 AM, Eric Henson wrote:

don’t have false positives: Barracuda RBL


Barracuda's RBL is a very good list... for high scoring... or for 
outright blocking for somewhat small hosters. But if an ISP or hoster 
has more than several thousand mailboxes AND is even moderately 
concerned about FPs, they would probably be happier using Barracuda's 
RBL for high scoring, and not for outright blocking.


Having said that... the age of high quality, virtually-zero FPs... is OVER!

Why? Because compromised mail accounts and hijacked web servers have 
both become a MASSIVE EPIDEMIC in the past few years.


For this reason, I regularly encounter hand-typed legit messages blocked 
by even SpamHaus's Zen list--yet Zen continues to be the best blacklist. 
In pretty much all such cases, those Zen "false positives" (if you can 
even call them that?) were situations where a small-ish legit sender had 
a compromised account that was spewing out much spam, and the ratio of 
spam/ham made the collateral damage very justifiable--and usually the 
blacklisting is short lived, keeping collateral damage to a minimum.


What separates the men from the boys here is NOT which list has zero 
FPs... but instead... which keeps such collateral damage to a minimum, 
via making good judgements about the ratio of spam blocked vs. resulting 
collateral damage--and keeping such listings short-lived, yet WITHOUT 
giving deliberate snowshoe spammers easy-off mechanisms, or too-short 
expire times.


By this very measure, Barracuda's RBL is a great list, but still not 
nearly as good as Zen, and probably too risky for outright blocking by 
larger senders.


And the absolutely zero FP blacklist is now a mythical creature... more 
sys admins in the e-mail industry need to recognize that and recognize 
that an RBL occasionally blocking a relatively few legit messages of a 
compromised sender (as Zen does!) can be a very GOOD thing (as long as 
there is a good balance--unfortunately, unlike Zen, some don't quite 
achieve the best balance!).


Such minimal and well-justified "collateral damage" does much to 
motivate system administrators to clean up their mess and implement 
better procedures to prevent (or more quickly mitigate) compromised 
accounts and other exploits.


--
Rob McEwen


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Eric Henson 
The relationship between Barracuda and EmailReg.org isn’t very clear. At the 
very least, Barracuda is sponsoring EmailReg.org, providing them with 
equipment, IP space, and referrals. Emailreg.org claims the $20/year is to keep 
spammers from abusing the service.

http://spamassassin.1065346.n5.nabble.com/emailreg-org-pretty-good-white-list-td67383.html

I should mention that Rob McElwen—who I see just posted—runs a good RBL, I 
stopped using it earlier this year because we started using the Barracuda RBL 
when we bought our Barracuda appliances. Rob posted in the thread above that 
emailreg.org is legit.

Mathias—I’m referring to transactional emails (“We have received your order”, 
“we have shipped your order”) as well as replies to emails from the customer 
(1.Customer emails, “where is my order?”, 2. Email agent replies, “we shipped 
it yesterday”, 3. customer marks reply as spam). Take a look at 
http://www.pfsweb.com/what-we-do/omni-channel-operations.php and 
http://www.pfsweb.com/clients/  and you should get a pretty good idea of what 
these emails look like.



From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com]
Sent: Monday, August 29, 2016 9:04 AM
To: Eric Henson
Cc: mailop@mailop.org
Subject: Re: [mailop] How many more RBL's do we really need?

Does Barracuda still operate that paid whitelist?

--srs

On 29-Aug-2016, at 7:28 PM, Eric Henson 
mailto:ehen...@pfsweb.com>> wrote:
I’ve done lots of RBL testing, for years, and the only RBLs that I’m using are 
the ones that are effective and don’t have false positives: Barracuda RBL and 
Spamhaus Zen (paid). But I still do my best to keep my mail servers off the 
other lists; usually this just means I stop sending email from one of my 
gateways for a week. I also had to sign up for the AOL junk reporting service 
because their users are too stupid to know the difference between the “delete” 
button and the “report junk” button.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Mathias Ullrich 
In my opionion and given, that we are talking about UCE, if it's 
unsolicited mail, the recipient shouldn't get the email in the first 
place, and if that's the case, the "report junk" button is the correct one.


If you are talking about one to one communication, forget my comment,

Cheers,
Mathias

Am 29.08.2016 um 15:58 schrieb Eric Henson:

I also had to sign up for the AOL junk reporting service because their
users are too stupid to know the difference between the “delete” button
and the “report junk” button.


--
optivo GmbH
Deliverability & Abuse Management
Wallstraße 16
10179 Berlin

Telefon: 030 / 76 80 78 269
Fax: 030 / 76 80 78 499

Email:mailto:mathias.ullr...@optivo.de
Website:  http://www.optivo.de

Handelsregister: HRB Berlin 88738
Geschäftsführer: Dr. Rainer Brosch, Thomas Diezmann

optivo ist ein Unternehmen von Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Suresh Ramasubramanian 
Does Barracuda still operate that paid whitelist? 

--srs

> On 29-Aug-2016, at 7:28 PM, Eric Henson  wrote:
> 
> I’ve done lots of RBL testing, for years, and the only RBLs that I’m using 
> are the ones that are effective and don’t have false positives: Barracuda RBL 
> and Spamhaus Zen (paid). But I still do my best to keep my mail servers off 
> the other lists; usually this just means I stop sending email from one of my 
> gateways for a week. I also had to sign up for the AOL junk reporting service 
> because their users are too stupid to know the difference between the 
> “delete” button and the “report junk” button.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Eric Henson 
I’ve done lots of RBL testing, for years, and the only RBLs that I’m using are 
the ones that are effective and don’t have false positives: Barracuda RBL and 
Spamhaus Zen (paid). But I still do my best to keep my mail servers off the 
other lists; usually this just means I stop sending email from one of my 
gateways for a week. I also had to sign up for the AOL junk reporting service 
because their users are too stupid to know the difference between the “delete” 
button and the “report junk” button.


From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Suresh 
Ramasubramanian
Sent: Monday, August 29, 2016 8:46 AM
To: Bryan Vest
Cc: mailop@mailop.org
Subject: Re: [mailop] How many more RBL's do we really need?

Most of them have about the same reach as some random guy tweeting just how bad 
a movie sucks.  Nobody other than his girlfriend, and maybe his family dog, are 
likely to read it.

Now if nytimes, Rogerebert.com<http://Rogerebert.com> etc write reviews panning 
it, the movie will flop

So - those are like Spamhaus and two or three other block lists that are widely 
used while the rest are more often than not  some random guy with a bofh 
complex and maybe ten users on one vps.

--srs

On 29-Aug-2016, at 6:15 PM, Bryan Vest 
mailto:murli...@gmail.com>> wrote:
I have been lurking here for a couple years but have really not had any 
information worth jumping into a conversation. But the question in my subject 
is really burning me up these days.
As far as my last general check there are at least 200 RBL's that could 
potentially be used by any mail admin anywhere in the world. They rarely have 
matching data sets and just becomes a real pain for a 2 person operation 
managing a system with 80k+ email accounts. We have built a very complex 
outbound mail verification system but we cant stop 100% of the spam 100% of the 
time so some does slip out.
I have ran into some RBL's where you ask for removal and they either want 
payment (fairly rare at this point) or do not answer or give a really long 
explanation of why they are right and you are wrong.

This may have been brought up before and if there is already a group please 
point me to it, but we need a study group/governing body/RFC to at least put 
out suggestions on RBL structure. Granted the RBL owners do not have to listen 
to anything that is said but maybe if it gained some traction admin's, at least 
the true admin's that know the internals of their mail system would start to 
listen.
Hard set RBL's with no timeout's should be frowned upon.
RBL's that give you the run around when you ask for a removal should be 
forgotten.
RBL's that have no option for removal should be forgotten.
RBL's that rely on 15 year old data sets should be forgotten. (I have ran into 
a few)
We run our own internal RBL that slurp's IP's from a couple different reputable 
RBL's and through scripting/algorithm's that we have been perfecting for 10 
years no IP stays in our RBL more than 12 hours, some are even less it all 
depends on hits over time. If they start spamming again they are added back to 
the RBL if spamming patterns are detected. We take care of most of this using 
rbldns and triggers from our Logstash system. Our internal RBL rarely contains 
more than 150k entries at one time since it is auto cleaning. It does swap in 
and out thousands of ip's per day but generally averages about 150k.
We can always route around these what I will call at this point bogus RBL's but 
that should not be something we have to do. The RBL owners should properly 
maintain their lists. For instance it was not long ago that I had to jump 
though hoops to get one RBL to reassign a block of our ipaddresses as static in 
their system when we had reassigned them as static 5 years earlier.
These RBL's are not doing anyone any favors, maybe to the admin's that can say 
"YAY we block all spam with this RBL." Acceptable, but how much legitimate mail 
are you blocking?
I know there are some system vendors that have a set of RBL's built into their 
system's but what are the default RBL's, how many admin's would even know how 
to figure out?
--Bryan Vest
___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Rob McEwen 

On 8/29/2016 8:45 AM, Bryan Vest wrote:

We have built a very complex outbound mail verification system but we
cant stop 100% of the spam 100% of the time so some does slip out.


Good for you that you are working hard to prevent outbound spam. In 
addition to using RBLs, here are a couple of other suggestions (that you 
may already be doing):


(1) consider also doing checks on the domains found in the clickable 
links of outbound messages, checking them against various URI/domain 
blacklists (SURBL, etc). (the "etc" is key here as certain URI lists are 
often much faster-reacting than SURBL, for some spams campaigns) If such 
content filtering is too resource-intensive, then consider doing random 
sampling checks.


(2) rate limit (or otherwise limit) outbound messages per each 
SMTP-authenticated account--so one account can't suddenly go from 
averaging 12 outbound message per day, to >500... stuff like that is 
OFTEN a sign of a compromised mail account


(3) CAREFUL--remember that some shared IPs are going to see a 
combination of (a) non-authenticated botnet-sent spams sent (from a 
viruses on some infected workstation) -AND- (b) smtp-authenticated legit 
mail sent from some person's Outlook or Thunderbird mail client. In that 
situation, going too hard on a sender due to an RBL could cause too much 
collateral damage--therefore, for THAT scenario, the smtp-authenticated 
outbound mail should be allowed, while the non-authenticated inbound 
messages should be blocked. Then again... this might conflict with 
strategies that use RBLs to limit smtp-authenticated outbound spam sent 
from compromised accounts?



I know there are some system vendors that have a set of RBL's built into
their system's but what are the default RBL's, how many admin's would
even know how to figure out?


"default RBL's" is subjective. But one place you might want to look 
at... is to see what RBLs are currently the default RBLs in 
SpamAssassin. But keep in mind that those won't include any commercial 
RBLs... do it isn't a comprehensive list... and even some of those are 
most appropriate for a scoring system, and shouldn't be used for 
outright blocking (or there would be too many FPs). You can get an idea 
from how high SA scores each particular RBL.


There have been some good articles written recently about the better 
RBLs. Do a search engine lookup on "best spam blacklists" (or similar 
searches) to find them. (look for articles written within the past 
couple of years--older reviews often have horrible outdated information)


I hope this helps!
--
Rob McEwen


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How many more RBL's do we really need?

2016-08-29 Thread Suresh Ramasubramanian 
Most of them have about the same reach as some random guy tweeting just how bad 
a movie sucks.  Nobody other than his girlfriend, and maybe his family dog, are 
likely to read it.

Now if nytimes, Rogerebert.com etc write reviews panning it, the movie will flop

So - those are like Spamhaus and two or three other block lists that are widely 
used while the rest are more often than not  some random guy with a bofh 
complex and maybe ten users on one vps.

--srs

> On 29-Aug-2016, at 6:15 PM, Bryan Vest  wrote:
> 
> I have been lurking here for a couple years but have really not had any 
> information worth jumping into a conversation. But the question in my subject 
> is really burning me up these days.
> 
> As far as my last general check there are at least 200 RBL's that could 
> potentially be used by any mail admin anywhere in the world. They rarely have 
> matching data sets and just becomes a real pain for a 2 person operation 
> managing a system with 80k+ email accounts. We have built a very complex 
> outbound mail verification system but we cant stop 100% of the spam 100% of 
> the time so some does slip out.
> 
> I have ran into some RBL's where you ask for removal and they either want 
> payment (fairly rare at this point) or do not answer or give a really long 
> explanation of why they are right and you are wrong.
> 
> This may have been brought up before and if there is already a group please 
> point me to it, but we need a study group/governing body/RFC to at least put 
> out suggestions on RBL structure. Granted the RBL owners do not have to 
> listen to anything that is said but maybe if it gained some traction admin's, 
> at least the true admin's that know the internals of their mail system would 
> start to listen.
> 
> Hard set RBL's with no timeout's should be frowned upon.
> RBL's that give you the run around when you ask for a removal should be 
> forgotten.
> RBL's that have no option for removal should be forgotten.
> RBL's that rely on 15 year old data sets should be forgotten. (I have ran 
> into a few)
> 
> We run our own internal RBL that slurp's IP's from a couple different 
> reputable RBL's and through scripting/algorithm's that we have been 
> perfecting for 10 years no IP stays in our RBL more than 12 hours, some are 
> even less it all depends on hits over time. If they start spamming again they 
> are added back to the RBL if spamming patterns are detected. We take care of 
> most of this using rbldns and triggers from our Logstash system. Our internal 
> RBL rarely contains more than 150k entries at one time since it is auto 
> cleaning. It does swap in and out thousands of ip's per day but generally 
> averages about 150k.
> 
> We can always route around these what I will call at this point bogus RBL's 
> but that should not be something we have to do. The RBL owners should 
> properly maintain their lists. For instance it was not long ago that I had to 
> jump though hoops to get one RBL to reassign a block of our ipaddresses as 
> static in their system when we had reassigned them as static 5 years earlier.
> 
> These RBL's are not doing anyone any favors, maybe to the admin's that can 
> say "YAY we block all spam with this RBL." Acceptable, but how much 
> legitimate mail are you blocking?
> 
> I know there are some system vendors that have a set of RBL's built into 
> their system's but what are the default RBL's, how many admin's would even 
> know how to figure out?
> 
> --Bryan Vest
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop