Re: [mailop] Bots, spam-traps and signup pages

[Jay Hennigan via mailop]

On 5/9/19 2:43 PM, Andrew C Aitchison via mailop wrote:


Is this deliberate enemy action or collateral damage ?
I'm finding it difficult to see why a general spam bot
would sign spam traps up to a mailing list,
so guess that I am missing something ?


Some of it may be in response to the growing trend of many websites to 
pop up an annoying overlay asking for an email address either before 
reading the content or after a few-second delay. Site visitors get 
annoyed and put random or not-so-random addresses there just to stop the 
annoyance. We've had customers who have tried these overlays and given 
up because of the high percentage of bogus addresses.


Of course, a lot of these sites don't bother to COI such submissions, 
preferring quantity over quality.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

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

Re: [mailop] Bots, spam-traps and signup pages

[Michael Wise via mailop]

Badness adapts.



COI is critical, as is … bounce detection and detecting if a user never opens 
their mail.

And don’t send signup confirmations out the same IP as regular list traffic.

If the mail bounces, and the List software of Mail Op doesn’t notice, Bad 
Things Will Happen.

If there’s not some form of closed loop confirmation of the email address, More 
and Different Bad Things Will Happen.



The harassment du jour is Subscription Signup Bombing, where various people who 
have pissed off Bad People are signed up to … 2800 different web-based mailing 
lists per hour, Because They Can. Again, these Bad People can and typically do 
deploy CAPTCHA solvers against various Mailing List packages.



Oh, and when sending out a signup confirmation, please specify an 
X-Originating-IP: header with said value. It helps us mitigate.



An SMS validation might slow some of this craziness down.

So would just junking each and every mailing list signup confirmation until the 
one that you did ask for shows up in your junk folder.

The hassles of yester-year have given way to new hassles… lest one bad practice 
should corrupt the world. Or something. ☹

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



-Original Message-
From: mailop  On Behalf Of Rob McEwen via mailop
Sent: Thursday, May 9, 2019 4:29 PM
To: Andrew C Aitchison ; mailop 
Subject: Re: [mailop] Bots, spam-traps and signup pages



On 5/9/2019 5:43 PM, Andrew C Aitchison wrote:

> On Thu, 9 May 2019, Rob McEwen via mailop wrote:

>> The documents that Paul referenced in his last message - probably

>> mentioned this somewhere - but I'll add that (in addition to the link

>> above and doing confirmed-opt-in "COI") you should strongly encourage

>> your customers to captcha-protect their signup forms to prevent bots

>> from signing up spamtrap addresses.

>>

>> That has been happening OFTEN in recent years - and those who don't

>> do COI and don't captcha-protect their forms (or some equivalent

>> only-a-human-could-have-done-this protection) - are OFTEN getting

>> blacklisted due to spamtrap addresses sneaking into their

>> distribution lists.

>

> Is this deliberate enemy action or collateral damage ?

> I'm finding it difficult to see why a general spam bot would sign spam

> traps up to a mailing list, so guess that I am missing something ?





Over the past few years, I've seen a distinct uptick in mailing lists

getting blacklisted due to them sending to spamtrap address - where they

claim that the signup happened on their website. In ALL such cases, the

forms were not CAPTCHA-protected, and they weren't doing COI. I've never

seen a single example of this happening where both CAPTCHA and COI was

used. Most of these came into my system via 3rd party spam feeds. I've

gone back to them and they all claim that they are NOT feeding their

spam feeds with automated "entrapment" signups. So I'm still trying to

figure this out, too. But the results of getting blacklisted when

sending to egregious spamtrap addresses - can bring an otherwise legit

business down to its knees. Why would spammers or hackers do this? I

don't know. It could be an effort to harm blacklists by polluting their

listings with items that are more marginal/legit - in order to try to

cause false positives? Or it could be that they are spamming the form in

an effort to get their spammy content delivered to the owner of the web

site - and they are just throwing random addresses into the signup form

(which then get added to the site owner's lead list if no CAPTCHA and

COI was used?) I know this is happening - I know that those doing both

CAPTCHA and COI are generally unaffected. I don't know all the details

about how/why/who. But this is a real thing - and it happens often.

(thankfully, my own blacklist's false positive-prevention filter -

prevents the vast majority of these from becoming blacklistings - but

the sending to spamtrap addresses means that the sender has lost control

of their processes, fwiw)



--

Rob McEwen

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.invaluement.comdata=02%7C01%7Cmichael.wise%40microsoft.com%7C51605e0ce64d4f7226db08d6d4d7287a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930417897330979sdata=vLqc5qj0NmHzCARnBgctC8WoJ88cVb1D6En8d0wmZQ4%3Dreserved=0







___

mailop mailing list

mailop@mailop.org

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C51605e0ce64d4f7226db08d6d4d7287a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930417897330979sdata=foDULZC2ZuBB3hivf48hTrIJ4yEOV2K10Uwknm4gWuA%3Dreserved=0

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Michael Wise via mailop]

No, you didn’t. Point taken.

But nowadays, CAPTCHAs are pointless.
Find another way.
If only because something ELSE will force them to write custom code.

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

From: mailop  On Behalf Of Rob McEwen via mailop
Sent: Thursday, May 9, 2019 4:20 PM
To: mailop@mailop.org
Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted)

I never claimed that CAPTCHA is FUSSP - it isn't. ("strawman's arg") And I 
realize that CAPTCHA can be defeated. That part wasn't news to me.

HOWEVER:

(1) never let the quest for perfection get in the way of achievable incremental 
improvements (which is EXACTLY what Rich and Michael are doing!)

(2) just because a criminal or spammer *can* do something - doesn't mean that 
it is feasible or easy or economical for them to deploy that strategy 
EVERYWHERE - which is what their arguments against CAPTCHA-protecting forms 
require.

(3) NOT every web form or "lead magnet" page is a big target. For every one 
such form on a large Fortune 100 company's site (like what Michael has to deal 
with) - for every one such high-profile form - there are literally hundreds of 
thousands of web forms on small sole proprietor's web sites and other small and 
medium-sized businesses' web sites. In MOST of the instances where a bot does 
submissions to their forms, the botmaster is simply not going to consider it 
worth the cost/effort to try to defeat CAPTCHA, should that be added.

(4) Many of those SAME organizations are going to find adding CAPTCHA their 
webform - to be relatively easy and within their budget or within their 
internal technical abilities. SMS... not so much. And many automated SMS 
implementation are costly - often costing about 10K/year just to get onboard 
("let them eat cake" - is how this is starting to come across... I'm sure that 
is chump changes to many of you reading this - but for many "mom and pop" 
companies running "lead magnets" web forms for their small-ish ecommerce 
business - that is NOT affordable.)

(5) meanwhile, a massive percentage of sites are doing NONE of this. It would 
be better for them to do CAPTCHA than nothing. Even though CAPTCHA can be 
defeated, most of those sites are visible enough to have their forms attacked 
by bots, but likely too small for a spammer or hacker to find it worth their 
time to use CAPTCHA-defeating techniques on them.

(Plus - when I brought this up - I was originally referring to signup forms - 
not login forms. I think that point got confused, too.)

Rob McEwen

On 5/9/2019 6:10 PM, Michael Wise via mailop wrote:
Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the opposing team:

  
http://scraping.pro/8-best-captcha-solving-services-and-tools/

 You’re going to need to think about an SMS challenge as a basic, entry level 
requirement.

-AND-
On 5/9/2019 5:53 PM, Rich Kulawiec via mailop wrote:

No, you shouldn't.  I'm going to quote something that I just sent

elsewhere, so my apologies to anyone who's seen it.





Captchas are a worst practice.



--

Rob McEwen

https://www.invaluement.com




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

Re: [mailop] Bots, spam-traps and signup pages

[Rob McEwen via mailop]

On 5/9/2019 5:43 PM, Andrew C Aitchison wrote:

On Thu, 9 May 2019, Rob McEwen via mailop wrote:
The documents that Paul referenced in his last message - probably 
mentioned this somewhere - but I'll add that (in addition to the link 
above and doing confirmed-opt-in "COI") you should strongly encourage 
your customers to captcha-protect their signup forms to prevent bots 
from signing up spamtrap addresses.


That has been happening OFTEN in recent years - and those who don't 
do COI and don't captcha-protect their forms (or some equivalent 
only-a-human-could-have-done-this protection) - are OFTEN getting 
blacklisted due to spamtrap addresses sneaking into their 
distribution lists.


Is this deliberate enemy action or collateral damage ?
I'm finding it difficult to see why a general spam bot
would sign spam traps up to a mailing list,
so guess that I am missing something ?



Over the past few years, I've seen a distinct uptick in mailing lists 
getting blacklisted due to them sending to spamtrap address - where they 
claim that the signup happened on their website. In ALL such cases, the 
forms were not CAPTCHA-protected, and they weren't doing COI. I've never 
seen a single example of this happening where both CAPTCHA and COI was 
used. Most of these came into my system via 3rd party spam feeds. I've 
gone back to them and they all claim that they are NOT feeding their 
spam feeds with automated "entrapment" signups. So I'm still trying to 
figure this out, too. But the results of getting blacklisted when 
sending to egregious spamtrap addresses - can bring an otherwise legit 
business down to its knees. Why would spammers or hackers do this? I 
don't know. It could be an effort to harm blacklists by polluting their 
listings with items that are more marginal/legit - in order to try to 
cause false positives? Or it could be that they are spamming the form in 
an effort to get their spammy content delivered to the owner of the web 
site - and they are just throwing random addresses into the signup form 
(which then get added to the site owner's lead list if no CAPTCHA and 
COI was used?) I know this is happening - I know that those doing both 
CAPTCHA and COI are generally unaffected. I don't know all the details 
about how/why/who. But this is a real thing - and it happens often. 
(thankfully, my own blacklist's false positive-prevention filter - 
prevents the vast majority of these from becoming blacklistings - but 
the sending to spamtrap addresses means that the sender has lost control 
of their processes, fwiw)


--
Rob McEwen
https://www.invaluement.com



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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Rob McEwen via mailop]

I never claimed that CAPTCHA is FUSSP - it isn't. ("strawman's arg") And 
I realize that CAPTCHA can be defeated. That part wasn't news to me.


HOWEVER:

(1) never let the quest for perfection get in the way of achievable 
incremental improvements (which is EXACTLY what Rich and Michael are doing!)


(2) just because a criminal or spammer *can* do something - doesn't mean 
that it is feasible or easy or economical for them to deploy that 
strategy EVERYWHERE - which is what their arguments against 
CAPTCHA-protecting forms require.


(3) NOT every web form or "lead magnet" page is a big target. For every 
one such form on a large Fortune 100 company's site (like what Michael 
has to deal with) - for every one such high-profile form - there are 
literally hundreds of thousands of web forms on small sole proprietor's 
web sites and other small and medium-sized businesses' web sites. In 
MOST of the instances where a bot does submissions to their forms, the 
botmaster is simply not going to consider it worth the cost/effort to 
try to defeat CAPTCHA, should that be added.


(4) Many of those SAME organizations are going to find adding CAPTCHA 
their webform - to be relatively easy and within their budget or within 
their internal technical abilities. SMS... not so much. And many 
automated SMS implementation are costly - often costing about 10K/year 
just to get onboard ("let them eat cake" - is how this is starting to 
come across... I'm sure that is chump changes to many of you reading 
this - but for many "mom and pop" companies running "lead magnets" web 
forms for their small-ish ecommerce business - that is NOT affordable.)


(5) meanwhile, a massive percentage of sites are doing NONE of this. It 
would be better for them to do CAPTCHA than nothing. Even though CAPTCHA 
can be defeated, most of those sites are visible enough to have their 
forms attacked by bots, but likely too small for a spammer or hacker to 
find it worth their time to use CAPTCHA-defeating techniques on them.


(Plus - when I brought this up - I was originally referring to signup 
forms - not login forms. I think that point got confused, too.)


Rob McEwen

On 5/9/2019 6:10 PM, Michael Wise via mailop wrote:
Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the 
opposing team:


http://scraping.pro/8-best-captcha-solving-services-and-tools/ 



You’re going to need to think about an SMS challenge as a basic, entry 
level requirement.



-AND-

On 5/9/2019 5:53 PM, Rich Kulawiec via mailop wrote:

No, you shouldn't.  I'm going to quote something that I just sent
elsewhere, so my apologies to anyone who's seen it.


Captchas are a worst practice.



--
Rob McEwen
https://www.invaluement.com


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

Re: [mailop] Is Digital Ocean a spammer safe haven?

[Ronald F. Guilmette via mailop]

In message , 
Thomas Walter  wrote:

>I have just manually checked the first 5 or so IP addresses and they are
>all listed on at least 10 blacklists. So most of us should be blocking
>them anyway?

I dunno which lists you are checking.  I just checked Spamhaus zen and
they only have 686 out of 862 listed.

Regards,
rfg

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Michael Wise via mailop]

My replies keep going to the original author. Grr.



Anyway, yeah, completely agree.

Y’all who trumpet CAPTCHA as the FUSSP need to know who’s on the opposing team:



  http://scraping.pro/8-best-captcha-solving-services-and-tools/



You’re going to need to think about an SMS challenge as a basic, entry level 
requirement.

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



-Original Message-
From: mailop  On Behalf Of Rich Kulawiec via mailop
Sent: Thursday, May 9, 2019 2:54 PM
To: mailop@mailop.org
Subject: Re: [mailop] Howto be a good mailop (best practice / insights wanted)



On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote:

> you should strongly encourage your customers to captcha-protect their

> signup forms to prevent bots from signing up spamtrap addresses.



No, you shouldn't.  I'm going to quote something that I just sent elsewhere, so 
my apologies to anyone who's seen it.





Captchas are a worst practice.  They can be and are defeated at will by any 
adversary who can trouble themselves to do so. [1] They're security theater: 
think Wile E. Coyote holding an umbrella over his head while a boulder drops 
toward him. [2]  Worth noting as well are (a) the continued and accelerating 
convergence of the trend lines denoting "captcha hard enough to defeat 
automation"

and "captcha easy enough to be solvable by humans" and (b) the onerous 
additional burden that these often place on people who have diminished eyesight 
and hearing, who are part of different cultures, etc.



There are far better ways to defend resources, and -- judiciously deployed -- 
these methods are not nearly as susceptible to adversarial manipulation, nor do 
they make life more difficult for people whose lives are arguably difficult 
enough already.



---rsk



[1] Here's an example of what I mean by "defeated at will":

  Wiseguys Indicted in $25 Million Online Ticket Ring | Threat 
Level | Wired.com

 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wired.com%2Fthreatlevel%2F2010%2F03%2Fwiseguys-indicted%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=nQA9YpkXlpMYs0d5qI7vvtPMoP%2B%2BUY7xsQuXOiZ7jp8%3Dreserved=0





[2] A partial list of references follows.  Do note that the contemporary state 
of the art in captcha-defeating techniques is much more advanced than any of 
these suggest.  Of course it is: attacks always get better - they never get 
worse. (h/t to Bruce Schneier)



Also, there's plenty of funding -- see footnote [1] above -- available to 
support research and development in this area that will NOT be helpfully 
published in blogs or journals.  So consider what is enumerated below as the 
lower bound of what *was* possible and extrapolate markedly upwards to estimate 
what *is* currently available.



  Stanford researchers outsmart captcha codes

 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.physorg.com%2Fnews%2F2011-11-stanford-outsmart-captcha-codes.htmldata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=AO%2BhAUVSgXsSsnB%2Bg29mpZB5v0V52YaCIUWolM%2B0x%2B8%3Dreserved=0



  CIntruder: pentesting tool to bypass captchas

 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcintruder.sourceforge.net%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=PrdAVLPG3OW7hwZsctUKvPTqHevEbT4SM354e5Iif%2Bw%3Dreserved=0



  How a trio of hackers brought Google's reCAPTCHA to its knees | 
Ars Technica

 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Farstechnica.com%2Fsecurity%2F2012%2F05%2Fgoogle-recaptcha-brought-to-its-knees%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=etl0tN7yv86ABF1kVR2jITgY%2Fh7neRxTptqzKXQ38Ls%3Dreserved=0



  Snapchat Account Registration CAPTCHA Defeated - Slashdot

 
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fit.slashdot.org%2Fstory%2F14%2F01%2F23%2F2037201%2Fsnapchat-account-registration-captcha-defeateddata=02%7C01%7Cmichael.wise%40microsoft.com%7Cf81408659824450b119808d6d4c9c782%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636930360432181620sdata=FtdQqZUTvTohCo5bBdD5n9Wd0BQTtbDCtmK5tOMNp%2Fg%3Dreserved=0



  Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA

 

Re: [mailop] Is Digital Ocean a spammer safe haven?

[Thomas Walter via mailop]

On 09.05.19 23:42, Ronald F. Guilmette via mailop wrote:
> At the following link, I provide a list of 862 currently live IP addresses,
> all located on AS14061 (Digital Ocean) which I have meticulously verified
> as all being in use by a single large-scale snowshoe spamming operation
> which is controlled by the same individuals who also own and control the
> recently-minted RIPE network AS209298 -- Online Marketing Sources Kft --
> ostensibly headquartered in Budapest, Hungary.
> 
> https://pastebin.com/raw/VYx2Yee1

I have just manually checked the first 5 or so IP addresses and they are
all listed on at least 10 blacklists. So most of us should be blocking
them anyway?

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Rich Kulawiec via mailop]

On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote:
> you should strongly encourage your customers to
> captcha-protect their signup forms to prevent bots from signing up spamtrap
> addresses.

No, you shouldn't.  I'm going to quote something that I just sent
elsewhere, so my apologies to anyone who's seen it.


Captchas are a worst practice.  They can be and are defeated
at will by any adversary who can trouble themselves to do so. [1]
They're security theater: think Wile E. Coyote holding an umbrella
over his head while a boulder drops toward him. [2]  Worth noting
as well are (a) the continued and accelerating convergence of the
trend lines denoting "captcha hard enough to defeat automation"
and "captcha easy enough to be solvable by humans" and (b) the onerous
additional burden that these often place on people who have diminished
eyesight and hearing, who are part of different cultures, etc.

There are far better ways to defend resources, and -- judiciously
deployed -- these methods are not nearly as susceptible to adversarial
manipulation, nor do they make life more difficult for people
whose lives are arguably difficult enough already.

---rsk

[1] Here's an example of what I mean by "defeated at will":
 
Wiseguys Indicted in $25 Million Online Ticket Ring | Threat Level | 
Wired.com
http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/


[2] A partial list of references follows.  Do note that the contemporary
state of the art in captcha-defeating techniques is much more advanced than
any of these suggest.  Of course it is: attacks always get better -
they never get worse. (h/t to Bruce Schneier)

Also, there's plenty of funding -- see footnote [1] above -- available to
support research and development in this area that will NOT be helpfully
published in blogs or journals.  So consider what is enumerated below as
the lower bound of what *was* possible and extrapolate markedly upwards
to estimate what *is* currently available.

Stanford researchers outsmart captcha codes
http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html

CIntruder: pentesting tool to bypass captchas
http://cintruder.sourceforge.net/

How a trio of hackers brought Google's reCAPTCHA to its knees | Ars 
Technica

http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/

Snapchat Account Registration CAPTCHA Defeated - Slashdot

http://it.slashdot.org/story/14/01/23/2037201/snapchat-account-registration-captcha-defeated

Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA

http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html

Troy Hunt: Breaking CAPTCHA with automated humans

http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html

Slashdot | Now Even Photo CAPTCHAs Have Been Cracked
http://it.slashdot.org/article.pl?sid=08/10/14/1442213

Cheap CAPTCHA Solving Changes the Security Game

https://freedom-to-tinker.com/blog/felten/cheap-captcha-solving-changes-security-game/

unCAPTCHA Breaks 450 ReCAPTCHAs in Under 6 Seconds

https://www.bleepingcomputer.com/news/technology/uncaptcha-breaks-450-recaptchas-in-under-6-seconds/




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

[mailop] Bots, spam-traps and signup pages

[Andrew C Aitchison via mailop]

On Thu, 9 May 2019, Rob McEwen via mailop wrote:

The documents that Paul referenced in his last message - 
probably mentioned this somewhere - but I'll add that (in 
addition to the link above and doing confirmed-opt-in "COI") 
you should strongly encourage your customers to 
captcha-protect their signup forms to prevent bots from 
signing up spamtrap addresses.


That has been happening OFTEN in recent years - and those who 
don't do COI and don't captcha-protect their forms (or some 
equivalent only-a-human-could-have-done-this protection) - are 
OFTEN getting blacklisted due to spamtrap addresses sneaking 
into their distribution lists.


Is this deliberate enemy action or collateral damage ?
I'm finding it difficult to see why a general spam bot
would sign spam traps up to a mailing list,
so guess that I am missing something ?

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

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

[mailop] Is Digital Ocean a spammer safe haven?

[Ronald F. Guilmette via mailop]

To be honest, I've been subscribed to this list for some time, but haven't
actually been reading the list traffic for quite awhile.

Recently however, it was brought to my attention that there has, of late,
been some discussion about Digital Ocean and its abundant spammer problems.
Given that I just found another such problem on Digital Ocean (and
a sizable one at that) I thought that I should just share what I know
about that with you all.

Before we get to the new stuff however, let's briefly review some of
the historical evidence that may give us some idea of the level of
concern Digital Ocean has for keeping their network free of spammers.

Back on March 19, 2019, I posted to the NANOG mailing list regarding a
spam operation that I personally found particularly disturbing.  I don't
normally make a public fuss about "ordinary" snowshoe spammers, but this
one was special.  It was one of three separate operations that I have
worked to try to destroy that were all involved in sending so-called
bitcoin extortion spams:

https://mailman.nanog.org/pipermail/nanog/2019-March/100135.html

As you can see, at that time (Mar 19) I had managed to construct a
fairly comprehensive listing of the IP addresses that were in use by
this specific "extortion" spammer, and I provided a link to that in my
March 19th NANOG posting:

https://pastebin.com/raw/WtM0Y5yC

As you can see in the above listing, the IP addresses in question were all
located on either AS16276 (OVH) or AS14061 (Digital Ocean).

I assumed at the time that my bitching an moaning about this "extortion"
spamming operation, via the NANOG list, would get some attention focused
on the problem by both OVH and Digital Ocean.  I posted very complete
information about this spammer, and the specific IP addresses he was using,
and I was sure that that infomation would allow both companies to fully
expunge this spammer from their networks.  As I subsequently learned, both
companies -were- made aware of my NANOG posting.

Shortly thereafter, and to their credit, OVH took steps to completely remove
the perpetrator from their network.

I thought no more about the matter after that, assuming the problem either
had been or was being solved on both networks.  (Silly me!)

I was thus understandably dismayed to learn, just recently, about a thread
here on the mailop mailing list which was apparently begun on April 8, 2019,
nearly three weeks after my posting about all this to the NANOG list:


https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-April/013754.html

I personally have no knowledge of, or information about the listing of
spammer IPs that Michael Peddemors posted here on that date in the above
message. I had no hand in creating that listing, and indeed, I only even
just found out about its existance this week.  I must say however that
simply comparing and contrasting the list that I posted to NANOG on March
19th with the listing that Michael Peddemors posted here, nearly three weeks
later on April 8th strongly suggests that (a) it is the same spammer
in both cases, and also (b) that either the spammer or Digital Ocean simply
swapped out the IP addresses that the spammer had been using for some new
ones.   (And the new ones were also located on the Digital Ocean network.)

No matter how this is viewed, it isn't good.  There are really only two
plausible explanations.  Either (a) Digital Ocean is in cahoots with the
spammer in this case or else (b) Digital Ocean staff is simply too dumb to
be able to tell when this spammer is signing up for fresh new accounts...
and lots of them.  There is no third possibility.

Generosity demands that we rely on Hanlon's Razor in such circumstances:

https://en.wikipedia.org/wiki/Hanlon%27s_razor

If we do so, then we are forced to conclude that possibility (b) applies
and that Digital Ocean staff are simply too stupid to be able to effectively
prevent spammers who they have already turfed from getting a fresh new set
of Digital Ocean IP addresses, perhaps even as soon as the following day.

Regardless of whether Digital Ocean is in any sense "in on" this game or
not, the outward effects, including on Digital Ocean's reputation, among
both anti-spam activists *and* spammers, is and should be quite immediately
apparent.  Over time, Digital Ocean, has, I believe, garnered a reputation
as a relatively "safe" place for spammers to set up shop, at least in and
among the professional spammer community.

It should thus come as little surprise to anyone when I disclose, as I now
do, that other and additional snoewshoe spaming enterprises are, as we
speak, operating from Digital Ocean's network.  I provide here but one
example of one such operation that my attention was called to recently.

At the following link, I provide a list of 862 currently live IP addresses,
all located on AS14061 (Digital Ocean) which I have meticulously verified
as all being in use by a single large-scale snowshoe spamming operation

Re: [mailop] AT - Need assistance with /24 listing

[Tim Starr via mailop]

Seems to be our turn to get a class C blocked by ATT for the first time in
years. Haven't made any progress via official channels yet. Anyone else
have a recommendation?

Tim Starr
Senior Director, Deliverability
Maropost Postmaster
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DigitalOcean calling for social media s* storm? (Re: Why is it so hard to have takedown's performed..)

[Chris Woods via mailop]

Like others I've reached the end of my tether with DO. In my case, I've
seen increasing volumes of malicious / junk traffic via their IPv6
prefixes, with reports to abuse doing virtually nothing, so now I just
define ip/ip6tables drop rules.

30 seconds' browsing will return the ranges you need,
https://www.peeringdb.com/net/6494
https://bgp.he.net/AS14061#_prefixes & https://bgp.he.net/AS14061#_prefixes6
https://bgp.he.net/AS46652#_prefixes

I don't miss their traffic...

On Thu, 9 May 2019 at 17:57, John Levine via mailop 
wrote:

> In article <20190509145346.gd8...@gsp.org> you write:
> >It would be far easier and much more effective if everyone on this
> >mailing list caused every mail server that they run to refuse all
> >mail from all Digital Ocean network space without warning, effective
> >immediately
>
> Don't waste your time, they don't care.  I've blocked all of the
> blocks I was aware of for a long time and haven't seen it affect any
> real mail at all.
>
> I would encourage people to block their corporate mail servers except
> that they don't have any.  Mail for digitalocean.com is outsourced to
> Google.
>
> They could save themselves a lot of pain by just blocking port 25
> across their entire network, and saying if you want to send mail, send
> it through a submission server somewhere else, and you can get your
> VPS port 25 unblocked after you've been a paying customer for three
> months.
>
> Other cloud providers do roughly that and it works pretty well.  Some
> of them even monetize it by referring users to freemium service at
> Sendgrid.
>
>
>
>
>
>
> ___
> 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] DigitalOcean calling for social media s* storm? (Re: Why is it so hard to have takedown's performed..)

[John Levine via mailop]

In article <20190509145346.gd8...@gsp.org> you write:
>It would be far easier and much more effective if everyone on this
>mailing list caused every mail server that they run to refuse all
>mail from all Digital Ocean network space without warning, effective
>immediately

Don't waste your time, they don't care.  I've blocked all of the
blocks I was aware of for a long time and haven't seen it affect any
real mail at all.

I would encourage people to block their corporate mail servers except
that they don't have any.  Mail for digitalocean.com is outsourced to
Google.

They could save themselves a lot of pain by just blocking port 25
across their entire network, and saying if you want to send mail, send
it through a submission server somewhere else, and you can get your
VPS port 25 unblocked after you've been a paying customer for three
months.

Other cloud providers do roughly that and it works pretty well.  Some
of them even monetize it by referring users to freemium service at
Sendgrid.






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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Rich Kulawiec via mailop]

I'll have more to say on this (of course I will ;) ) but I'll mention
that I'm attempting to assemble what I'll call, for lack of a better
term, a roadmap of RFCs that mail system operators should be familiar
with.  I'm doing this because I'm trying to (a) train some junior
people and (b) fill in gaps in my own knowledge.  I'll likely ask
ietf-smtp and mailop to both review it because I have no doubt that
I'll overlook some that should arguably be included.

Once it's put together, perhaps it would be useful to all of us.
(Modulo those people who've already read them all and can quote
them at length from memory. ;) )

---rsk


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

Re: [mailop] DigitalOcean calling for social media s* storm? (Re: Why is it so hard to have takedown's performed..)

[Rich Kulawiec via mailop]

On Mon, Apr 29, 2019 at 03:54:41PM +0200, Benoit Panizzon via mailop wrote:
> I wonder if DigitalOcean is running for some social media related
> wake-up call.

It would be far easier and much more effective if everyone on this
mailing list caused every mail server that they run to refuse all
mail from all Digital Ocean network space without warning, effective
immediately, remaining in effect until such time as all open issues
have been addressed, apologies have been made, and a convincing plan
for prompt future action put forth.

After all, there seems little reason to continue extending them the
privilege of access to mail (and other) services when they repay that
largesse by abusing it on a mass scale.  And my guess is that a concerted
move of this nature would get their attention in a matter of hours
and that long-overdue remediation would quickly follow.  (And if not?
I don't see a problem with letting them enjoy their intranet.  That
might be the best outcome for all concerned.)

Alternatively, we can continue to note the chronically, systematically,
deliberately abusive conduct of Digital Ocean for another decade or two.

---rsk

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Rob McEwen via mailop]

On 5/9/2019 9:15 AM, Paul Kincaid-Smith via mailop wrote:


If your service will enable customers to collect email addresses via a 
web form, you can reduce the risk of list bombing:

https://www.m3aawg.org/rel-WebFormHeader



The documents that Paul referenced in his last message - probably 
mentioned this somewhere - but I'll add that (in addition to the link 
above and doing confirmed-opt-in "COI") you should strongly encourage 
your customers to captcha-protect their signup forms to prevent bots 
from signing up spamtrap addresses.


That has been happening OFTEN in recent years - and those who don't do 
COI and don't captcha-protect their forms (or some equivalent 
only-a-human-could-have-done-this protection) - are OFTEN getting 
blacklisted due to spamtrap addresses sneaking into their distribution 
lists.


--
Rob McEwen
https://www.invaluement.com



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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Paul Kincaid-Smith via mailop]

Hi Stefan,

I am encouraged that you're choosing to be proactive and want to configure
your platform and processes to reduce the risk of email abuse.

M3AAWG, the Messaging, Mobile and Malware Anti-Abuse Working Group has
published numerous best practices documents to help senders and ESPs reduce
abusive email:
https://www.m3aawg.org/published-documents

A few that will interest you:
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf
https://www.m3aawg.org/sites/default/files/m3aawg-senders-complaint-handling-2017-12.pdf
https://www.m3aawg.org/sites/default/files/document/MAAWG_Vetting_BCP_2011-11.pdf
https://www.m3aawg.org/sites/default/files/document/CodeofConduct.pdf
https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf

If your service will enable customers to collect email addresses via a web
form, you can reduce the risk of list bombing:
https://www.m3aawg.org/rel-WebFormHeader

As your email volume grows, you may qualify for a Gmail Postmaster Tools
account, which can provide helpful insight:
https://www.gmail.com/postmaster/

Regards,

Paul Kincaid-Smith
EmailGrades

On Wed, May 8, 2019 at 10:48 AM Stefan Bauer via mailop 
wrote:

> Hi,
>
>
> we're providing a small smtp sent-service for our customers (via
> submission port / auth only - postfix). ~ 7.000 outgoing mails / day (via 2
> hosts in different data centers/ip networks).
>
>
> As the amount of mails increase, we would like to be ready for
>
>
> - stolen auth-data to our service is used for sending spam
>
>
> - broken clients send thousand of mails/minute
>
>
> - one of our pub-ips get blacklisted / rerouting traffic?
>
>
> - ISPs block our complete provider networks (and we are included)
>
>
> - Perm-blocks with 5xx, always return all 5xx to senders?
>
>
>
> How do you guys prepare yourself for this?
>
>
> we have in place:
>
>
> only allow pre-defined sender-addresses after auth
>
> monitor mail-queues for high connection count
>
> monitor RBLs if we're listed
>
> only allow single mail / 5s to be sent outgoing
>
> anti-virus checking of attachments
>
>
> Would be awesome to get some insight how "big sites" handle this and maybe
> other cases.
>
>
> Thank you!
>
>
> Stefan
> ___
> 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] Howto be a good mailop (best practice / insights wanted)

[Michael Orlitzky via mailop]

On 5/8/19 1:48 PM, Ken O'Driscoll via mailop wrote:
> There is likely more, above is, as I said, off the top of my head. Good
> luck.
>

One to add:

  * Sign up for feedback loops with the major providers.

I see a remarkable number of phished-credential bots that are smart
enough to send one message every ~five minutes. Our automated defenses
miss those, until Comcast or AOL starts sending me complaints.

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Mark Foster via mailop]

> Hi Ken,
>
>
>
> awesome. Thats a bunch of helpful steps! Thanks a lot!
>

I'm a few years removed from directly administering a 'real' mail server
(directly, at least) but I have some observations about Ken's list:


>
>  * Monitor abuse@ and make sure that this address a) exists for your
> client
>domains and b) you receive a copy of messages sent to them.

Tough call mandating the existance and handling of abuse@ for client
domains, nevermind actually receiving email that belongs to clients!
Clients should be advised to run the RFC-specified email addresses, but
they're responsible for their conduct.

If someone reports to me that one of my customers is engaged in abusive
practices (or compromised, perhaps) then i'll take action directly, but
they should have the chance to solve their own issue (or identify
malicious false-positives, perhaps) before their service provider has to
get involved.


>  * Restrict access to the submission port to either the client IP range.

When authenticated SMTP is offered as a service (essentially a must for
mobile support), IP address restrictions are counter-productive.

The usual 'don't be an open mail relay' rules apply of course.


>
>  * Lock accounts after X failed logins and get an alert about that.

I do support this to an extent, but this is also a DoS vector. Alert, yes.
Lock? Not necessarily.

>  * Have a third (failover/fallback) sending capability with a different
>data centre. Periodically route enough email though that to ensure that
>it will not be throttled in case you need it. But, don't use it as a
>primary.

I agree with this in principle. Not sure how straightforward it is to do
it in practice, but an alternative SMTP option is useful.


>  * Understand what your normal usage profile looks like - graph the mail
>
>queues. This will help you build policies / tech. around detecting
>unusual behaviour. E.g. tougher throttling outside of business hours
>etc.

This could have merit, depends on the nature of those using your service.

>  * Add a custom header (X-abuse) to make it clear where the email came
> from
>and how to report abuse of your service.

Yes, supported.

>  * Make it clear on your website how a non-customer can contact you to
>report abuse.

Also supported... consider https://github.com/securitytxt/security-txt as
well.

>  * Run a cut-down spam filter on the outbound mails (look for stuff like
>
>freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of
>
>that will be false positives so just put it into a holding queue and
>create a service desk ticket for it to be reviewed.

Spamfiltering outbound mail is a great idea, as it'll help preserve your
reputation, and that of a customer, if they get compromised and someone
starts taking advantage.e  But putting suspect email in a queue for your
own service desk is questionable IMO. Notify, Alert, absolutely, but
again, unsure if you should bog your own service desk and essentially
tarpit outgoing email,... I'd say refuse outright (5xx error) and let the
sender unpick it. No black hole ambiguity.


>  * Have a clear upgrade path if case they wish to send marketing emails.
> If
>you don't, they will just try to send them through your platform.
>  * Publish an Acceptable Use Policy (AUP) and make them agree to it as a
>
>pre-condition to using your service. Spamhaus have a good template to
>
>start from on their website.

The above kinda relate, the AUP is a given (anyone offering a service
should have one, regardless of the service, pretty much!) and that should
include the nature of what the threshold for marketing emails might be
before an alternative product needs to be considered.

>  * Monitor bounces and tie that it with your monitor solution.

Yes, if you can.


>  * Monitor the health of your clients connecting IPs (and possibly
>website). Any indication of a compromised site is grounds for locking
>
>the account until a human can review.

For suspected compromises, yes this is great... your T needs to permit
you to immediately suspend service if you think an account has been
compromised, as a risk and damage mitigation factor (your IP's rep on the
line, thus, the deliverability of all your other customer's emails).
Customers don't tend to think about this until they're blocked, then they
get grumpy.. so if they know about it ahead of time, you're covered.

GLHF
Mark.







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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Stefan Bauer via mailop]

Hi Ken,



awesome. Thats a bunch of helpful steps! Thanks a lot!

Cheers

Stefan




-Ursprüngliche Nachricht-
Von: Ken O'Driscoll via mailop 
Gesendet: Mittwoch 8 Mai 2019 20:01
An: mailop@mailop.org
Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted)



On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote:
> we have in place:
> 
> only allow pre-defined sender-addresses after auth
> monitor mail-queues for high connection count
> monitor RBLs if we're listed
> only allow single mail / 5s to be sent outgoing
> anti-virus checking of attachments

Hi Stefan,

off the top of my head I would add:

 * Monitor abuse@ and make sure that this address a) exists for your client
   domains and b) you receive a copy of messages sent to them.
 * Restrict access to the submission port to either the client IP range.

 * Lock accounts after X failed logins and get an alert about that.
 * Have a third (failover/fallback) sending capability with a different
   data centre. Periodically route enough email though that to ensure that
   it will not be throttled in case you need it. But, don't use it as a
   primary.
 * Understand what your normal usage profile looks like - graph the mail

   queues. This will help you build policies / tech. around detecting
   unusual behaviour. E.g. tougher throttling outside of business hours
   etc.
 * Add a custom header (X-abuse) to make it clear where the email came from
   and how to report abuse of your service.
 * Make it clear on your website how a non-customer can contact you to
   report abuse.
 * Run a cut-down spam filter on the outbound mails (look for stuff like

   freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of

   that will be false positives so just put it into a holding queue and
   create a service desk ticket for it to be reviewed.
 * Have a clear upgrade path if case they wish to send marketing emails. If
   you don't, they will just try to send them through your platform.
 * Publish an Acceptable Use Policy (AUP) and make them agree to it as a

   pre-condition to using your service. Spamhaus have a good template to

   start from on their website.
 * Monitor bounces and tie that it with your monitor solution.
 * Monitor the health of your clients connecting IPs (and possibly
   website). Any indication of a compromised site is grounds for locking

   the account until a human can review. 
There is likely more, above is, as I said, off the top of my head. Good
luck.

Ken.


___
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