Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

2020-02-10 Thread Michael Rathbun via mailop 
On Mon, 10 Feb 2020 09:17:55 -0800, Michael Peddemors via mailop
 wrote:

>While kind of off the record, for those tracking this..
>
>We did get some back channel feedback indicating that they now know what 
>the sources of these are, but as of this morning it is still occurring.

The note below comprises the details of the IPs that have been banned since
midnight USCST today due to attempted delivery to a manifest spamtrap (e.g.
nadine-p...@honet.com).

>Of course, the AWS claims that these IP(s) are (call it dynamic) and 
>that blocking the IP should not be done, as they suggest it can affect 
>other customers who also use the same IP in rotation etc..

Let us await the economic outcome of this Free-Market-Based corporate
strategy.

- - -

The data:

>3.134.102.160
>ec2-3-134-102-160.us-east-2.compute.amazonaws.com
>160.102.134.3.zen.spamhaus.org = 127.0.0.3
>160.102.134.3.dnsbl-1.uceprotect.net = 127.0.0.2
>160.102.134.3.dnsbl-3.uceprotect.net = 127.0.0.2
>160.102.134.3.b.barracudacentral.org = 127.0.0.2
>160.102.134.3.ubl.unsubscore.com = 127.0.0.2
>160.102.134.3.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:34 ---
> 54.186.253.233
>ec2-54-186-253-233.us-west-2.compute.amazonaws.com
>233.253.186.54.zen.spamhaus.org = 127.0.0.3
>233.253.186.54.dnsbl.sorbs.net = 127.0.0.6
>233.253.186.54.spam.dnsbl.sorbs.net = 127.0.0.6
>233.253.186.54.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>233.253.186.54.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>233.253.186.54.dnsbl-1.uceprotect.net = 127.0.0.2
>233.253.186.54.dnsbl-3.uceprotect.net = 127.0.0.2
>233.253.186.54.ubl.unsubscore.com = 127.0.0.2
>233.253.186.54.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:38 ---
> 54.212.82.49
>ec2-54-212-82-49.us-west-2.compute.amazonaws.com
>49.82.212.54.zen.spamhaus.org = 127.0.0.3
>49.82.212.54.dnsbl-1.uceprotect.net = 127.0.0.2
>49.82.212.54.dnsbl-3.uceprotect.net = 127.0.0.2
>49.82.212.54.ubl.unsubscore.com = 127.0.0.2
>49.82.212.54.psbl.surriel.com = 127.0.0.2
>49.82.212.54.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:43 ---
> 35.175.146.160
>ec2-35-175-146-160.compute-1.amazonaws.com
>160.146.175.35.zen.spamhaus.org = 127.0.0.3
>160.146.175.35.dnsbl.sorbs.net = 127.0.0.6
>160.146.175.35.spam.dnsbl.sorbs.net = 127.0.0.6
>160.146.175.35.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>160.146.175.35.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>160.146.175.35.dnsbl-1.uceprotect.net = 127.0.0.2
>160.146.175.35.ubl.unsubscore.com = 127.0.0.2
>160.146.175.35.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:45 ---
> 52.24.161.90
>ec2-52-24-161-90.us-west-2.compute.amazonaws.com
>90.161.24.52.zen.spamhaus.org = 127.0.0.3
>90.161.24.52.dnsbl.sorbs.net = 127.0.0.6
>90.161.24.52.spam.dnsbl.sorbs.net = 127.0.0.6
>90.161.24.52.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>90.161.24.52.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>90.161.24.52.dnsbl-1.uceprotect.net = 127.0.0.2
>90.161.24.52.dnsbl-3.uceprotect.net = 127.0.0.2
>90.161.24.52.ubl.unsubscore.com = 127.0.0.2
>90.161.24.52.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:46 ---
> 52.27.72.14
>ec2-52-27-72-14.us-west-2.compute.amazonaws.com
>14.72.27.52.zen.spamhaus.org = 127.0.0.3
>14.72.27.52.dnsbl-3.uceprotect.net = 127.0.0.2
>--- 02/10/20 22:17:47 ---
> 52.14.153.249
>ec2-52-14-153-249.us-east-2.compute.amazonaws.com
>249.153.14.52.zen.spamhaus.org = 127.0.0.3
>249.153.14.52.dnsbl.sorbs.net = 127.0.0.6
>249.153.14.52.spam.dnsbl.sorbs.net = 127.0.0.6
>249.153.14.52.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>249.153.14.52.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>249.153.14.52.dnsbl-1.uceprotect.net = 127.0.0.2
>249.153.14.52.dnsbl-3.uceprotect.net = 127.0.0.2
>249.153.14.52.ubl.unsubscore.com = 127.0.0.2
>249.153.14.52.psbl.surriel.com = 127.0.0.2
>249.153.14.52.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:48 ---
> 3.18.213.86
>ec2-3-18-213-86.us-east-2.compute.amazonaws.com
>86.213.18.3.zen.spamhaus.org = 127.0.0.3
>86.213.18.3.dnsbl-1.uceprotect.net = 127.0.0.2
>86.213.18.3.dnsbl-3.uceprotect.net = 127.0.0.2
>86.213.18.3.ubl.unsubscore.com = 127.0.0.2
>86.213.18.3.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:50 ---
> 54.201.227.223
>ec2-54-201-227-223.us-west-2.compute.amazonaws.com
>223.227.201.54.zen.spamhaus.org = 127.0.0.3
>223.227.201.54.dnsbl.sorbs.net = 127.0.0.6
>223.227.201.54.spam.dnsbl.sorbs.net = 127.0.0.6
>223.227.201.54.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>223.227.201.54.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>223.227.201.54.dnsbl-3.uceprotect.net = 127.0.0.2
>223.227.201.54.score.senderscore.com = 127.0.4.17
>223.227.201.54.ubl.unsubscore.com = 127.0.0.2
>223.227.201.54.truncate.gbudb.net = 127.0.0.2
>--- 02/10/20 22:17:51 ---
> 100.26.185.25
>ec2-100-26-185-25.compute-1.amazonaws.com
>25.185.26.100.zen.spamhaus.org = 127.0.0.3
>25.185.26.100.dnsbl.sorbs.ne

Re: [mailop] mailbox auth for system integration

2020-02-10 Thread Michael Peddemors via mailop 

On 2020-02-10 11:47 a.m., Jesse Thompson via mailop wrote:

On 2/7/20 6:31 PM, Brandon Long via mailop wrote:



On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop 
mailto:mailop@mailop.org>> wrote:


    __

    On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:

    On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:

    On 2020/02/07 13:41, Philip Paeps via mailop wrote:

    I think the only viable solution will be to set up
    forwarders

    Or pass it through a proxy which knows how to authenticate.
    I'm not
    aware of any that have been written yet but it shouldn't be
    too complex.

    I just spent an instructive half hour in a web browser trying to
    jump through the hoops to set this up. Before you can create a
    "token", you need to create a "credential". In order to create
    that you need a "project". And then you need a "application
    consent screen".

    All of this to fetch email unattended.

    This is the very definition of "user hostile".

    And reportedly, the "tokens" can expire. So supposedly, this
    needs to be done regularly?

    Furthermore: this only fixes /retrieving/ email (and then only IMAP,
    because it doesn't seem to work for POP3). Presumably similar hoops
    need to be jumped to send email through smtp.gmail.com
    . What fun!

Note you should be able to use the same project and client id/secret 
for smtp and pop/imap.  You might be able to use the same token if you 
ask for the scopes for both.


I know it's annoying.  See the previous long thread on why passwords 
are bad, as for restricting access to your mailbox, there was the 
excitement from 2018: 
https://www.androidauthority.com/gmail-snooping-882270/ which lead to 
Google being a lot more paranoid about third party access 
https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems . 



The hoops you're jumping through aren't for users, they're for 
developers... and they're only the first steps, you then need to get 
approval 
 
from Google to expand beyond 100 users.  Many open source projects 
have decided to punt on that, and so they require their users to get 
their own client tokens.  I understand, I made the same choice when I 
added oauth support to mutt last year.


For users just using the most popular mail apps, using oauth instead 
of password auth is at least as easy.


We worked hard to make sure Gmail supported open standards for access 
by third parties, and not locking our services down or locking people 
in... and then others took advantage of our users, and that's why we 
can't have nice things.  Access is still possible, the process is 
still mostly standards based (automated discovery of oauth endpoints 
and client registration is the missing part)... but there are a lot 
more hoops.


Thank you for sharing this perspective, Brandon.  It helps us understand 
the "why".  It sounds like Microsoft and Google are acting hand-in-hand 
to force industry-wide changes since they've gobbled up the market 
they've also aggregated most of the credential abuse.


I'm skeptical that app-specific passwords were a major part of the 
credential abuse problem, but I don't have data to challenge it.


I may be able to force some of our system integrators through "a lot 
more hoops", but I think that for the remaining system integration use 
cases I'll need to shop around for a smaller mailbox provider that is 
willing to commit to supporting basic auth (along with necessary 
security controls to mitigate against credential abuse) for the medium 
term future.


Thanks!
Jesse Thompson
UW-Madison


Yes, there is still a concern (and maybe justified) that business 
considerations at the BIG guys, do 'force' user behaviour in a method 
that is geared towards business concerns and not technical or altruistic 
in nature.


Eg, AutoDiscovery in Office 2016, where did it go?

Which is why I hope that everyone sees our alternative to transparent 
two factor to be more altruistic, no matter which email provider you 
use, (providing they have implemented it) without dependency on a 3rd 
party systems.


And it would be nice if at least the email clients offered by the big 
providers support that, for connectivity to resources other than their own.


I do worry is that the trend is moving towards 'closed eco-systems' for 
email, eg you need to use their email clients, to access their email, 
and the email clients are only designed to use their email platforms.


But, it has spawned a huge new round of entrants to the email space, 
some with just email clients, some with a combination of 
client/cloud/hosting provider, and some with just client/cloud closed 
eco-systems.


Companies like SaneBox, BlueMail, SuperHuman, and others..

Nice to see many are starti

Re: [mailop] mailbox auth for system integration

2020-02-10 Thread Jesse Thompson via mailop 

On 2/10/20 2:24 PM, Brandon Long wrote:



On Mon, Feb 10, 2020 at 11:56 AM Jesse Thompson via mailop 
mailto:mailop@mailop.org>> wrote:


On 2/7/20 6:31 PM, Brandon Long via mailop wrote:
 >
 >
 > On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop
 > mailto:mailop@mailop.org>
>> wrote:
 >
 >     __
 >
 >     On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:
 >
 >         On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:
 >
 >             On 2020/02/07 13:41, Philip Paeps via mailop wrote:
 >
 >                 I think the only viable solution will be to set up
 >                 forwarders
 >
 >             Or pass it through a proxy which knows how to
authenticate.
 >             I'm not
 >             aware of any that have been written yet but it
shouldn't be
 >             too complex.
 >
 >         I just spent an instructive half hour in a web browser
trying to
 >         jump through the hoops to set this up. Before you can
create a
 >         "token", you need to create a "credential". In order to
create
 >         that you need a "project". And then you need a "application
 >         consent screen".
 >
 >         All of this to fetch email unattended.
 >
 >         This is the very definition of "user hostile".
 >
 >         And reportedly, the "tokens" can expire. So supposedly, this
 >         needs to be done regularly?
 >
 >     Furthermore: this only fixes /retrieving/ email (and then
only IMAP,
 >     because it doesn't seem to work for POP3). Presumably similar
hoops
 >     need to be jumped to send email through smtp.gmail.com

 >     . What fun!
 >
 > Note you should be able to use the same project and client
id/secret for
 > smtp and pop/imap.  You might be able to use the same token if
you ask
 > for the scopes for both.
 >
 > I know it's annoying.  See the previous long thread on why
passwords are
 > bad, as for restricting access to your mailbox, there was the
excitement
 > from 2018:
https://www.androidauthority.com/gmail-snooping-882270/ which
 > lead to Google being a lot more paranoid about third party access
 >

https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems
 .
 >
 > The hoops you're jumping through aren't for users, they're for
 > developers... and they're only the first steps, you then need to get
 > approval
 >

from
 > Google to expand beyond 100 users.  Many open source projects have
 > decided to punt on that, and so they require their users to get
their
 > own client tokens.  I understand, I made the same choice when I
added
 > oauth support to mutt last year.
 >
 > For users just using the most popular mail apps, using oauth
instead of
 > password auth is at least as easy.
 >
 > We worked hard to make sure Gmail supported open standards for
access by
 > third parties, and not locking our services down or locking
people in...
 > and then others took advantage of our users, and that's why we can't
 > have nice things.  Access is still possible, the process is still
mostly
 > standards based (automated discovery of oauth endpoints and client
 > registration is the missing part)... but there are a lot more hoops.

Thank you for sharing this perspective, Brandon.  It helps us
understand
the "why".  It sounds like Microsoft and Google are acting hand-in-hand
to force industry-wide changes since they've gobbled up the market
they've also aggregated most of the credential abuse.

I'm skeptical that app-specific passwords were a major part of the
credential abuse problem, but I don't have data to challenge it.

I may be able to force some of our system integrators through "a lot
more hoops", but I think that for the remaining system integration use
cases I'll need to shop around for a smaller mailbox provider that is
willing to commit to supporting basic auth (along with necessary
security controls to mitigate against credential abuse) for the medium
term future.


Ah, one more thing to point out for your case, gsuite admins can 
whitelist specific oauth clients

even if they're not on the google approved list.

 From the page i posted above:
Domain-wide Installation:
     The app is used only by G Suite enterprise users. Access will 
depend on permission being granted by the domain administrator. G Suite  
     domain administrators are the only ones that can whitelist the app 
for use within their domains.


  * To learn how to make your app Doma

Re: [mailop] mailbox auth for system integration

2020-02-10 Thread Brandon Long via mailop 
On Mon, Feb 10, 2020 at 11:56 AM Jesse Thompson via mailop <
mailop@mailop.org> wrote:

> On 2/7/20 6:31 PM, Brandon Long via mailop wrote:
> >
> >
> > On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop
> > mailto:mailop@mailop.org>> wrote:
> >
> > __
> >
> > On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:
> >
> > On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:
> >
> > On 2020/02/07 13:41, Philip Paeps via mailop wrote:
> >
> > I think the only viable solution will be to set up
> > forwarders
> >
> > Or pass it through a proxy which knows how to authenticate.
> > I'm not
> > aware of any that have been written yet but it shouldn't be
> > too complex.
> >
> > I just spent an instructive half hour in a web browser trying to
> > jump through the hoops to set this up. Before you can create a
> > "token", you need to create a "credential". In order to create
> > that you need a "project". And then you need a "application
> > consent screen".
> >
> > All of this to fetch email unattended.
> >
> > This is the very definition of "user hostile".
> >
> > And reportedly, the "tokens" can expire. So supposedly, this
> > needs to be done regularly?
> >
> > Furthermore: this only fixes /retrieving/ email (and then only IMAP,
> > because it doesn't seem to work for POP3). Presumably similar hoops
> > need to be jumped to send email through smtp.gmail.com
> > . What fun!
> >
> > Note you should be able to use the same project and client id/secret for
> > smtp and pop/imap.  You might be able to use the same token if you ask
> > for the scopes for both.
> >
> > I know it's annoying.  See the previous long thread on why passwords are
> > bad, as for restricting access to your mailbox, there was the excitement
> > from 2018: https://www.androidauthority.com/gmail-snooping-882270/ which
>
> > lead to Google being a lot more paranoid about third party access
> >
> https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems
>  .
> >
> > The hoops you're jumping through aren't for users, they're for
> > developers... and they're only the first steps, you then need to get
> > approval
> > 
> from
> > Google to expand beyond 100 users.  Many open source projects have
> > decided to punt on that, and so they require their users to get their
> > own client tokens.  I understand, I made the same choice when I added
> > oauth support to mutt last year.
> >
> > For users just using the most popular mail apps, using oauth instead of
> > password auth is at least as easy.
> >
> > We worked hard to make sure Gmail supported open standards for access by
> > third parties, and not locking our services down or locking people in...
> > and then others took advantage of our users, and that's why we can't
> > have nice things.  Access is still possible, the process is still mostly
> > standards based (automated discovery of oauth endpoints and client
> > registration is the missing part)... but there are a lot more hoops.
>
> Thank you for sharing this perspective, Brandon.  It helps us understand
> the "why".  It sounds like Microsoft and Google are acting hand-in-hand
> to force industry-wide changes since they've gobbled up the market
> they've also aggregated most of the credential abuse.
>
> I'm skeptical that app-specific passwords were a major part of the
> credential abuse problem, but I don't have data to challenge it.
>
> I may be able to force some of our system integrators through "a lot
> more hoops", but I think that for the remaining system integration use
> cases I'll need to shop around for a smaller mailbox provider that is
> willing to commit to supporting basic auth (along with necessary
> security controls to mitigate against credential abuse) for the medium
> term future.
>

Ah, one more thing to point out for your case, gsuite admins can whitelist
specific oauth clients
even if they're not on the google approved list.

>From the page i posted above:
Domain-wide Installation:
The app is used only by G Suite enterprise users. Access will depend on
permission being granted by the domain administrator. G Suite  domain
administrators are the only ones that can whitelist the app for use within
their domains.

   - To learn how to make your app Domain-Wide Install, see My application
   has users with enterprise accounts from another G Suite Domain.
   


I think that'll work for your case, not sure.

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

Re: [mailop] mailbox auth for system integration

2020-02-10 Thread Jesse Thompson via mailop 

On 2/7/20 6:31 PM, Brandon Long via mailop wrote:



On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop 
mailto:mailop@mailop.org>> wrote:


__

On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:

On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:

On 2020/02/07 13:41, Philip Paeps via mailop wrote:

I think the only viable solution will be to set up
forwarders

Or pass it through a proxy which knows how to authenticate.
I'm not
aware of any that have been written yet but it shouldn't be
too complex.

I just spent an instructive half hour in a web browser trying to
jump through the hoops to set this up. Before you can create a
"token", you need to create a "credential". In order to create
that you need a "project". And then you need a "application
consent screen".

All of this to fetch email unattended.

This is the very definition of "user hostile".

And reportedly, the "tokens" can expire. So supposedly, this
needs to be done regularly?

Furthermore: this only fixes /retrieving/ email (and then only IMAP,
because it doesn't seem to work for POP3). Presumably similar hoops
need to be jumped to send email through smtp.gmail.com
. What fun!

Note you should be able to use the same project and client id/secret for 
smtp and pop/imap.  You might be able to use the same token if you ask 
for the scopes for both.


I know it's annoying.  See the previous long thread on why passwords are 
bad, as for restricting access to your mailbox, there was the excitement 
from 2018: https://www.androidauthority.com/gmail-snooping-882270/ which 
lead to Google being a lot more paranoid about third party access 
https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems .


The hoops you're jumping through aren't for users, they're for 
developers... and they're only the first steps, you then need to get 
approval 
 from 
Google to expand beyond 100 users.  Many open source projects have 
decided to punt on that, and so they require their users to get their 
own client tokens.  I understand, I made the same choice when I added 
oauth support to mutt last year.


For users just using the most popular mail apps, using oauth instead of 
password auth is at least as easy.


We worked hard to make sure Gmail supported open standards for access by 
third parties, and not locking our services down or locking people in... 
and then others took advantage of our users, and that's why we can't 
have nice things.  Access is still possible, the process is still mostly 
standards based (automated discovery of oauth endpoints and client 
registration is the missing part)... but there are a lot more hoops.


Thank you for sharing this perspective, Brandon.  It helps us understand 
the "why".  It sounds like Microsoft and Google are acting hand-in-hand 
to force industry-wide changes since they've gobbled up the market 
they've also aggregated most of the credential abuse.


I'm skeptical that app-specific passwords were a major part of the 
credential abuse problem, but I don't have data to challenge it.


I may be able to force some of our system integrators through "a lot 
more hoops", but I think that for the remaining system integration use 
cases I'll need to shop around for a smaller mailbox provider that is 
willing to commit to supporting basic auth (along with necessary 
security controls to mitigate against credential abuse) for the medium 
term future.


Thanks!
Jesse Thompson
UW-Madison

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

Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

2020-02-10 Thread Michael Rathbun via mailop 
On Mon, 10 Feb 2020 09:17:55 -0800, Michael Peddemors via mailop
 wrote:

>I know of some operators that already are being more aggressive, eg 
>denying SMTP traffic..

I have almost dropped all the AWS CIDRs I can find into the persistent IP
REFUSE, except for the fact that I sometimes need to use the local server to
analyze client sends.


>If it walks like duck, and talks like a duck..

I probably sounds like Groucho.

mdr
-- 
The Duckage Is Feep.
   -- Vaul Pixie


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

Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

2020-02-10 Thread Michael Peddemors via mailop 

While kind of off the record, for those tracking this..

We did get some back channel feedback indicating that they now know what 
the sources of these are, but as of this morning it is still occurring.


Of course, the AWS claims that these IP(s) are (call it dynamic) and 
that blocking the IP should not be done, as they suggest it can affect 
other customers who also use the same IP in rotation etc..


Take it as you see fit, but IMHO if the IP(s) are that dynamic, then 
maybe they need to be treated as 'dynamic', eg think of a home users' 
dynamic IP Address, we block those now as a course of action from 
sending email..


Typically the industry as a whole denies email from dynamic IP space, if 
they don't have a static IP, they should relay out a real email server. 
They should have a static IP address, and a valid PTR that reflects the 
operators domain.


Due to the sheer amount (and as you mentioned, they already are 
appearing on many RBL's) we can see why this (blocking on detection) is 
an attractive option.


Unfortunately, it will affect legitimate mail operations on AWS (think 
billing systems, and transaction systems) but they do have the option to 
get a dedicated IP/PTR.


I know of some operators that already are being more aggressive, eg 
denying SMTP traffic..


If it walks like duck, and talks like a duck..



On 2020-02-10 8:57 a.m., Michael Rathbun via mailop wrote:

On Sat, 8 Feb 2020 09:15:49 -0800, Michael Peddemors via mailop
 wrote:


It's only one of several pandemic issues raised with Amazon.. hopefully
we have some feedback soon ;)


As of the timestamp of this message, looking at the six unarchived daily logs,
I see that since Wed 2020-02-05, this AWS client has used 62 IPs to deliver
obvious spam.  Of those IPs, 45 were added to IP REFUSE locally; all of them I
have bothered to check are now on Spamhaus CSS, Barracuda, and any number of
other lists.

It would appear that this entity has more than enough cash to keep AWS
interested in their trade, with AWS valuing the revenue more than the possible
negative impact on the business of their legitimate customers.

I am almost to the point of saying "Aw, that's really too bad" to new clients
who intend to warm up their new arrays of AWS IPs.

I've already explained to (uninterested) people at Liberty Mutual that our
25-year business relationship will be coming to an end soon, owing to their
refusal to stop sending money to criminal net abusers.

mdr





--
"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

[mailop] Contact at Interia.pl?

2020-02-10 Thread Tracey Crawford via mailop 
Does anyone have a contact at Interia.pl?  If so, please email me directly.

Thank you,
Tracey Crawford
Manager Deliverability Ops, SparkPost


On Mon, Feb 10, 2020 at 7:02 AM  wrote:

> Send mailop mailing list submissions to
> mailop@mailop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> or, via email, send a message with subject or body 'help' to
> mailop-requ...@mailop.org
>
> You can reach the person managing the list at
> mailop-ow...@mailop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mailop digest..."
>
>
> Today's Topics:
>
>1. Re: Is Spectrum trying to sunset rr.com and twc.com emails?
>   (Russell Clemings)
>2. Re: Is Spectrum trying to sunset rr.com and twc.com emails?
>   (John Levine)
>
>
> --
>
> Message: 1
> Date: Sun, 9 Feb 2020 18:02:13 -0800
> From: Russell Clemings 
> To: mailop 
> Subject: Re: [mailop] Is Spectrum trying to sunset rr.com and twc.com
> emails?
> Message-ID:
> <
> can7rx0yytcaaygl5s76qn9sryg45voff6cqf92lt0ssoy1q...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sat, Feb 8, 2020 at 6:59 PM Jay R. Ashworth via mailop <
> mailop@mailop.org>
> wrote (in part):
>
> >
> > but my experience of email carrier buyouts is that no-one *ever* sunsets
> > the
> > domain names, cause there's no real reason to do so, and it pisses off
> > end-users.
> >
> >
> Tell that to Comcast, which bought attbi.com and made all of their users
> change their email addresses to comcast.net, just as attbi.com had done a
> few years earlier when it bought mediaone.net. Quite a few years ago, but
> it was a colossal pain.
>
>
> https://www.marketingsherpa.com/article/blog/19-million-attbi-email-addresses
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/attachments/20200209/5cfb56dd/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: 10 Feb 2020 03:02:23 -
> From: "John Levine" 
> To: mailop@mailop.org
> Subject: Re: [mailop] Is Spectrum trying to sunset rr.com and twc.com
> emails?
> Message-ID: 
>
> In article <
> can7rx0yytcaaygl5s76qn9sryg45voff6cqf92lt0ssoy1q...@mail.gmail.com>,
> Russell Clemings via mailop  wrote:
> >Tell that to Comcast, which bought attbi.com and made all of their users
> >change their email addresses to comcast.net, just as attbi.com had done a
> >few years earlier when it bought mediaone.net. Quite a few years ago, but
> >it was a colossal pain.
>
> They learned their lesson.  Now even if you cancel your Comcast service you
> can keep your comcast.net address.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
>
> End of mailop Digest, Vol 148, Issue 25
> ***
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

2020-02-10 Thread Michael Rathbun via mailop 
On Sat, 8 Feb 2020 09:15:49 -0800, Michael Peddemors via mailop
 wrote:

>It's only one of several pandemic issues raised with Amazon.. hopefully 
>we have some feedback soon ;)

As of the timestamp of this message, looking at the six unarchived daily logs,
I see that since Wed 2020-02-05, this AWS client has used 62 IPs to deliver
obvious spam.  Of those IPs, 45 were added to IP REFUSE locally; all of them I
have bothered to check are now on Spamhaus CSS, Barracuda, and any number of
other lists.

It would appear that this entity has more than enough cash to keep AWS
interested in their trade, with AWS valuing the revenue more than the possible
negative impact on the business of their legitimate customers.

I am almost to the point of saying "Aw, that's really too bad" to new clients
who intend to warm up their new arrays of AWS IPs.

I've already explained to (uninterested) people at Liberty Mutual that our
25-year business relationship will be coming to an end soon, owing to their
refusal to stop sending money to criminal net abusers.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie


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