Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Michael Rathbun via mailop]

On Fri, 14 Aug 2020 10:40:40 -0500, Mickey Chandler via mailop
 wrote:

>And yet ESPs, like many other businesses, can sometimes look at abuse
>desk operations as a cost center, not as a core functionality. It's
>way easier to justify paying for new salespeople who will bring in
>several times their annual salary in new business per quarter than it
>is a team of dedicated professionals who spend all day terminating
>paying customers.

My favourite Policy Enforcement gig was at ALGX before the money people did a
forced buyout.  Executive management hired me to get the network out of the
blocklist sewer, and eventually when the Mahoganites (EVPs) on the fourth
floor raised some sand about my team terminating $15K/month customers, the 'C'
level directive came down that caused a new clause in the sales commission
policy to go into effect:  If your customer is terminated for AUP violations
within the first six months of their tenure on our network, 100% of your
commission on the sale will be clawed back.

After a while my team spent as much time assisting sales in vetting new
customers as they did whacking bad ones.

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


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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Mickey Chandler via mailop]

I'm going to preface this email by saying that I do, in fact, run an
abuse desk. I'm the director of the policy enforcement team for my
employer, an ESP that everyone knows. I'm not going to mention them by
name because anything that I say here is based upon my own thoughts,
opinions, and experiences and aren't intended to reflect the policies
or positions of my current employer.

On Fri, Aug 14, 2020 at 1:00 AM Hans-Martin Mosner via mailop
 wrote:
>
> Am 13.08.20 um 19:28 schrieb Al Iverson via mailop:
> > On Thu, Aug 13, 2020 at 11:34 AM Hans-Martin Mosner via mailop
> >  wrote:
> >> Mails to abuse@ should be handled quickly without being CC'd to a VP. It's 
> >> the abuse desks job to stop abuse ASAP. If they are understaffed or don't 
> >> have authority to stop spamming senders then there's an organizational 
> >> problem that can not be solved by handling abuse reports from the VP's 
> >> seat.
> > I'm not here to defend any given provider, but I will say, I wish you
> > could see the amount of absolute garbage that an abuse desk address
> > gets.
>
> I don't say it's trivial, abuse desk work for an ESP is certainly highly 
> demanding work. It needs sufficient number and
> quality of staff and sophisticated and highly flexible automation to sift 
> through abuse reports. If sending out bulk
> mail is your business you'd better pay for a high quality abuse desk, it's a 
> core part of your business quality.

And yet ESPs, like many other businesses, can sometimes look at abuse
desk operations as a cost center, not as a core functionality. It's
way easier to justify paying for new salespeople who will bring in
several times their annual salary in new business per quarter than it
is a team of dedicated professionals who spend all day terminating
paying customers.

> If I were to run an abuse desk the first thing I'd do is install a mail-in 
> sorter which separates the immediately
> actionable reports having full headers from random rants that might or might 
> not be cause for action and the inevitable
> garbage (granted, you can't use a traditional spam filter because folks tend 
> to cite spam when they report it.)

And, sometimes you have to work with the tools that company feels like
paying for. Once upon a time, I ran an abuse desk that had operated
for years out of a shared Exchange folder because the company didn't
want to pay for a ticketing/queueing system. I don't know of anyone
who does that now, but I'm sure someone is out there. And talking
about what you'd do "if I were to run an abuse desk" is about as
useful as me suggesting that "if I were running a postmaster team" I
would just open more capacity.

> The immediately actionable reports could be further indexed by customer ID 
> based on mail header information, so when
> multiple reports for one customer are received you can prioritize and react 
> swiftly.

Even that's not always possible in a secure environment. My abuse
queues are held in a completely disconnected portion of our systems
that no one can access without my leave (and usually a signed email
from Legal or my management chain is also required). Why? Because we
take privacy rather seriously and don't think that our salespeople or
Tier 1 Support personnel should have access to your abuse report. I've
got 20 years in anti-abuse operations and I've seen lots of reasons to
do things this way, including having salespeople try to defend their
customer(s) by emailing complainants to ask why they sent a spam
complaint, why they didn't just hit delete, to verify that they
weren't a bot, or about 20 different other things which would mean
that maybe an abuse report wouldn't have come in and this guy could
keep his commission. But the upshot of that is my systems don't have
the ability to index the customer IDs in the CRM -- we have to add it
in by hand (which adds a small headache for us in exchange for
avoiding about 3 other much larger headaches). That's not because the
system isn't smart enough to do it, but because people have proven
themselves untrustworthy enough that I can't let those systems talk to
each other.

> But without knowing any details about how the current abuse desk work is 
> organized it's impossible to make specific
> improvement suggestions. We already listed some technical and organizational 
> changes that would likely reduce abuse in
> the first place, which would presumably cause a significant reduction in 
> abuse reports and pressure on the abuse desk.

Running email as an infrastructure-only provider is hard -- especially
when someone can sign up for an account without sitting down with a
salesperson and a lawyer. I've got lots of respect for the job that
Will, Len, and their team are doing on this particular issue. It's a
hard one. And sometimes, believe it or not, even when you have a
salesperson and a lawyer, whack-a-mole is the only game in town. I had
one incident a ways back now where the spammer actually put himself
out there as a consultant 

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Steve Freegard via mailop]

On 14/08/2020 02:14, Ángel via mailop wrote:


I don't think it's rocket science.
As an ESP, you have a series of customers.
For each customer, you should have a table of their validated domains
(you do have a process for validating domains, right?).

Each customer must place and shall only place in their From: header
emails in one of their validated domains.

Prior to sending a campaign, the SPF and DKIM records must be checked.

- The domain spf when sent by the ESP MUST pass  to send it (that could
be via a generic include, by specifically including an ip address that
was pre-assigned for this campaign...)
- The ESP SHOULD be able to place a DKIM signature for the given domain.

It's included in the prior steps, but worth mentioning explictely
anyway. If the domain does not exist, or the SPF would now fail, it MUST
NOT be sent. Even if the domain was previously authorized (e.g. the
company could have validated that domain years before, but now they
might have changed their mind - the domain may even be owned by a
completely different entity, now!), the failing spf record is an
explicit signal not allowing them to perform such sending.

This is not only in the benefit of the ESP and to avoid phishings, but
to the customer as well. A campaign failing such validations is very
likely to have a poor inbox rate. The ESP must block that, and get that
customer (a marketing guy with zero idea about mail delivery, probably)
to get their IT people to add the needed records. Through whatever
internal procedures are needed.


Just this would already prevent the most egregious cases suffered last
months. And as you see, it's really simple.

As Hans mentions, you may want to add the same limitation that href in
the email body must be linked to the accounts, although you may want
some more leeway there, such as allowing anyone certain neutral sites,
like common newspapers (did you see the last piece of news about our
company?).


Compromised accounts are a problem, sure. However, I wonder *how* are
they such a big problem.
Did Sendgrid somehow lose a full list of customer users & passwords? Do
their api allow easily bruteforcing them?

If a customer loses his user and password, yes, they could send a
mailing. As their own company. (Hopefully) damaging their own image. Not
hurting other customers, or third parties that never allowed you to send
emails impersonating them.


You will obviously want to do much more on the validation step. Like, if
someone registered paypal-mails.com, different than PayPal Holdings,
Inc., and tried to set up a campaign, imho it should be rejected.



All these points are spot-on.  Quite how Sendgrid hasn't managed to get 
on top of this after so long, is frankly baffling to me.


The only thing I would add to this would be that Sendgrid should 
immediately separate their outbound IP pools into groups.
There's probably lots of ways to do this but, I'd probably go with 
something like:


- Long-term customers with no abuse history
- New customers
- Customers with abuse reports or suspicious activity (e.g. morphing 
From: domains or Display Names).

- Everyone else

These pools should be published to the community so they can be handled 
accordingly.




Also, an ESP must be able to properly handle abuse. When abuse is
reported, it shall be properly handled and acknowledged. If there is
information missing, ask about it. If the customer has been found to be
in violations of the Terms (such as sending the obvious phishings), they
should be able to one-click block the customer.
If the account was compromised, that can be handled later. It's best to
let before it makes more harm.
Then, after taking proper action, reply to the report. It can be a
simple one-liner: "Customer blocked", "We already disabled that account
a few hours ago", "We could not verify this to be abusive"...


Not being on top of the Abuse reports and having strong automation 
around them is inexcusable.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Hans-Martin Mosner via mailop]

Am 13.08.20 um 19:28 schrieb Al Iverson via mailop:
> On Thu, Aug 13, 2020 at 11:34 AM Hans-Martin Mosner via mailop
>  wrote:
>> Mails to abuse@ should be handled quickly without being CC'd to a VP. It's 
>> the abuse desks job to stop abuse ASAP. If they are understaffed or don't 
>> have authority to stop spamming senders then there's an organizational 
>> problem that can not be solved by handling abuse reports from the VP's seat.
> I'm not here to defend any given provider, but I will say, I wish you
> could see the amount of absolute garbage that an abuse desk address
> gets.

I don't say it's trivial, abuse desk work for an ESP is certainly highly 
demanding work. It needs sufficient number and
quality of staff and sophisticated and highly flexible automation to sift 
through abuse reports. If sending out bulk
mail is your business you'd better pay for a high quality abuse desk, it's a 
core part of your business quality.

If I were to run an abuse desk the first thing I'd do is install a mail-in 
sorter which separates the immediately
actionable reports having full headers from random rants that might or might 
not be cause for action and the inevitable
garbage (granted, you can't use a traditional spam filter because folks tend to 
cite spam when they report it.)

The immediately actionable reports could be further indexed by customer ID 
based on mail header information, so when
multiple reports for one customer are received you can prioritize and react 
swiftly.

It's possible that such a system isn't available off-the-shelf, but then I'm 
primarily a software developer, and writing
code to interpret data and do something based on the results is pretty natural 
for me, so I would not consider it out of
reach.

But without knowing any details about how the current abuse desk work is 
organized it's impossible to make specific
improvement suggestions. We already listed some technical and organizational 
changes that would likely reduce abuse in
the first place, which would presumably cause a significant reduction in abuse 
reports and pressure on the abuse desk.

Cheers,
Hans-Martin


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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Ángel via mailop]

On 2020-08-13 at 18:27 +0200, Hans-Martin Mosner via mailop wrote:
> The first thing you need to do is to know your customers. Don't send
> out mails on behalf of someone you don't really know, period.
> 
> 
> Apparently some customers themselves are victims of hacks now, so that
> alone would not help. Additional technical steps to be taken are
> limiting the names and domains that may appear in the From: header
> lines to fixed lists (maybe restrictive regular expression patterns)
> per customer, and limit the IP ranges from where each customer may
> inject mails. Some customers seem to employ auto-mailing from web
> forms. Sorry, that was a nice idea a decade ago, it's not anymore. Web
> subscriptions and inquiries should be checked and followed up by a
> human or at least some pretty well trained AI engine.
> 

I don't think it's rocket science.
As an ESP, you have a series of customers.
For each customer, you should have a table of their validated domains
(you do have a process for validating domains, right?).

Each customer must place and shall only place in their From: header
emails in one of their validated domains.

Prior to sending a campaign, the SPF and DKIM records must be checked.

- The domain spf when sent by the ESP MUST pass  to send it (that could
be via a generic include, by specifically including an ip address that
was pre-assigned for this campaign...)
- The ESP SHOULD be able to place a DKIM signature for the given domain.

It's included in the prior steps, but worth mentioning explictely
anyway. If the domain does not exist, or the SPF would now fail, it MUST
NOT be sent. Even if the domain was previously authorized (e.g. the
company could have validated that domain years before, but now they
might have changed their mind - the domain may even be owned by a
completely different entity, now!), the failing spf record is an
explicit signal not allowing them to perform such sending.

This is not only in the benefit of the ESP and to avoid phishings, but
to the customer as well. A campaign failing such validations is very
likely to have a poor inbox rate. The ESP must block that, and get that
customer (a marketing guy with zero idea about mail delivery, probably)
to get their IT people to add the needed records. Through whatever
internal procedures are needed.


Just this would already prevent the most egregious cases suffered last
months. And as you see, it's really simple.

As Hans mentions, you may want to add the same limitation that href in
the email body must be linked to the accounts, although you may want
some more leeway there, such as allowing anyone certain neutral sites,
like common newspapers (did you see the last piece of news about our
company?).


Compromised accounts are a problem, sure. However, I wonder *how* are
they such a big problem.
Did Sendgrid somehow lose a full list of customer users & passwords? Do
their api allow easily bruteforcing them?

If a customer loses his user and password, yes, they could send a
mailing. As their own company. (Hopefully) damaging their own image. Not
hurting other customers, or third parties that never allowed you to send
emails impersonating them.


You will obviously want to do much more on the validation step. Like, if
someone registered paypal-mails.com, different than PayPal Holdings,
Inc., and tried to set up a campaign, imho it should be rejected.


Also, an ESP must be able to properly handle abuse. When abuse is
reported, it shall be properly handled and acknowledged. If there is
information missing, ask about it. If the customer has been found to be
in violations of the Terms (such as sending the obvious phishings), they
should be able to one-click block the customer.
If the account was compromised, that can be handled later. It's best to
let before it makes more harm.
Then, after taking proper action, reply to the report. It can be a
simple one-liner: "Customer blocked", "We already disabled that account
a few hours ago", "We could not verify this to be abusive"...


These things should be a good starting point to get started and gain
back some of the community trust.


Best regards


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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Al Iverson via mailop]

On Thu, Aug 13, 2020 at 11:34 AM Hans-Martin Mosner via mailop
 wrote:
>
> Mails to abuse@ should be handled quickly without being CC'd to a VP. It's 
> the abuse desks job to stop abuse ASAP. If they are understaffed or don't 
> have authority to stop spamming senders then there's an organizational 
> problem that can not be solved by handling abuse reports from the VP's seat.

I'm not here to defend any given provider, but I will say, I wish you
could see the amount of absolute garbage that an abuse desk address
gets.

They get tons of GWF Goober With Firewall reports -- the "stop hacking
my port 80" kind of thing. They get weirdo tinfoil hat reports from
actually, really crazy people who CC half the earth and want an ESP to
do something about a bad Amazon order they placed two years ago or
they need you to send the troops into India ASAP. They get tons of
actual spam directed at abuse@ domain, because some A-holes mad about
the provider thought it would be funny to submit that address to
signup forms as a form of payback. And the abuse desk typically cannot
run a spam filter because the chances of it eating legit spam reports
is high. They get tons of misdirected customer service emails-- online
store X may be a client and the user opted-in but is mad about their
last order so they think complaining to the ESP is going to get them a
refund on their order. Then you get complaints from people who are
lawyers or think they are lawyers and they demand payment because some
client pissed them off, or they cite some non-existent law or legal
theory and get mad if you don't follow their explicit instructions.
Then you get lots of what might be legit complaints but there are no
headers or other markers to identify a particular client, send or IP.
Then you get phishing warnings from security services who get confused
everything they see a redirect in a URL, and even if it legitimately
starts on bank.com and ends on bank.com, some of them still get
confused and send helpful third party takedown recommendations. Then
you get some legitimate complaints but they've mangled the forwarding
enough that the automation can't parse it. Is it QP, Base64, 7-bit,
UTF-8, headers pasted in body, MIME attachment in some format other
than ARF, etc. etc. etc. Most of that automation is either home grown
or a ticketing system not meant for abuse work so each one of them
probably fails to properly read at least one of those types of
messages. And thus, even with automation, it can be hard to quickly
figure out which complaints matter most, and those perfect complaints
with full headers pasted into a new email report to abuse don't always
get handled as quickly as you might like.

Does ESP X have a systemic problem? That I can't speak to. But man, I
can only imagine the volume of useless emails to abuse they are having
to wade through.

Cheers,
Al Iverson

-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Hans-Martin Mosner via mailop]

Am 11.08.20 um 18:22 schrieb Len Shneyder via mailop:
> Hello Benoit and Hokan,
>
> Thanks for pointing this out and I'm sorry you're still seeing what sounds 
> like a high volume of phish. I've asked our
> fraud ops team to investigate this. In the future if you could send 
> suspicious emails to ab...@sendgrid.com
>  we will get this handled. Feel free to CC me when 
> you do this to make sure these are
> handled quickly. 
>
Mails to abuse@ should be handled quickly without being CC'd to a VP. It's the 
abuse desks job to stop abuse ASAP. If
they are understaffed or don't have authority to stop spamming senders then 
there's an organizational problem that can
not be solved by handling abuse reports from the VP's seat.
> We've instituted some self-limiting features on our front door that should've 
> decreased the overall volume of abuse.
> This is a stop gap measure as we roll out some other countermeasures in the 
> next few weeks. Could you let me know if
> you have seen a perceptible drop in volume and velocity between June and July 
> when this was rolled out?

I don't do statistics, but it does not feel like the problem is under control 
yet.

I've already communicated some ideas to Will Boyd over on the SDLU list.

The first thing you need to do is to know your customers. Don't send out mails 
on behalf of someone you don't really
know, period.

Apparently some customers themselves are victims of hacks now, so that alone 
would not help. Additional technical steps
to be taken are limiting the names and domains that may appear in the From: 
header lines to fixed lists (maybe
restrictive regular expression patterns) per customer, and limit the IP ranges 
from where each customer may inject
mails. Some customers seem to employ auto-mailing from web forms. Sorry, that 
was a nice idea a decade ago, it's not
anymore. Web subscriptions and inquiries should be checked and followed up by a 
human or at least some pretty well
trained AI engine.

From the mail body samples I've seen, it looks like target links go through 
Sendgrid's own redirection services. This
makes filtering on suspicious link domains harder for us, but should make it 
easier for Sendgrid. Only accept link
destinations that are clearly controlled by the customer or very public 
information such as Wikipedia links etc. Google
searches? Links to link shorteners? Nope.

And last but not least, let customers post a bond which is forfeited when spam 
is sent via their account. It might
educate them on the value of IT security.

>
> Again, I want to assure you that there is a massive effort happening here to 
> address the problems you are seeing. I'm
> happy to meet off list and discuss this further and help you understand what 
> we're working on if that would be
> helpful. Again, thank you for your patience and please don't hesitate to 
> contact me when you see any of these issues
> arise. 
>
> Best,
> -L

Please don't take my repeated and sometimes sarcastic criticism as destructive. 
I am aware of the value that ESPs can
have for small organisations which need to send out mails to large numbers of 
interested recipients, even though I'd
personally always run a mailing list manager on machines under my own control. 
But the spam and phishing emitted by
Sendgrid is already hurting the value of your company significantly, it's high 
time that effective measures are taken.

And taking this off-list is not a viable option. If you want to regain trust 
you need to do it in the open.

Cheers,
Hans-Martin

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Tim Bray via mailop]

On 11/08/2020 20:41, Matt Harris via mailop wrote:






We'd been using sendgrid in production for some stuff, but we're 
looking at changing that now because it seems like their lack of 
concern regarding abuse on their platform will lead to more and more 
deliverability issues as time goes on. It just seems like sendgrid 
doesn't care about abuse on their platform.




I think sendgrid do care.   At least some people do.   I suspect they 
are just getting accounts compromised faster than they know what to do 
with.    They read this list.


There could even be a compromise in some other software which allows 
people to easily steal sendgrid credentials.


(of course, none of this helps if you are looking at your inbox and 
seeing more phishing)



--
Tim Bray
Huddersfield, GB
t...@kooky.org
+44 7966479015

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Matt Harris via mailop]

On Tue, Aug 11, 2020 at 2:21 PM Michael Orlitzky via mailop <
mailop@mailop.org> wrote:

> In the past few months there have been several threads on mailop and
> similar lists (sdlu, spamassassin-users, nanog, ...) complaining about
> how SendGrid doesn't seem to do anything at all to stop the ongoing
> blatant phishing campaigns from their servers.
>

I've received some spam from sendgrid, including another "we caught you
looking at pr0n, send us btc" just today from sendgrid at my personal email
address, and dutifully forwarded them with headers along to abuse@. What
I've never received is any sort of follow up on those reports indicating
that they were received, much less any action would be taken. Some of these
messages are spam in ways that are exceptionally obvious - things like
having the From: header set to the same address as the recipient, for
example, or matching patterns that even a junior sysadmin's spamassassin
deployment would be able to catch.

We'd been using sendgrid in production for some stuff, but we're looking at
changing that now because it seems like their lack of concern regarding
abuse on their platform will lead to more and more deliverability issues as
time goes on. It just seems like sendgrid doesn't care about abuse on their
platform.

As far as determining the difference between a compromised account that
isn't a spammer and a spammer who simply signed up for an account, this
should be relatively simple by looking at their history. Even without doing
so, the action should clearly be the same: shut down the account
immediately. There's no reason to let a legitimate user's compromised
account continue being used illicitly, and the legitimate user can be
contacted to address the issue after which time the account can be
re-enabled.

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Michael Orlitzky via mailop]

On 2020-08-11 16:53:46, Benoit Panizzon via mailop wrote:
> 
> Now a sendgrid customers complains to us, that his emails are being
> rejected because of this listing.
> 
> But that makes me wonder: Doesn't sendgrid deal with such issues like
> asking for delisting after blocking the sender itself and re-uses
> recently (last phish received on 14. July) 'abused' ip addresses for
> other customers?
> 

In the past few months there have been several threads on mailop and
similar lists (sdlu, spamassassin-users, nanog, ...) complaining about
how SendGrid doesn't seem to do anything at all to stop the ongoing
blatant phishing campaigns from their servers.

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Adam D. Barratt via mailop]

On Tue, 2020-08-11 at 09:22 -0700, Len Shneyder via mailop wrote:
> Thanks for pointing this out and I'm sorry you're still seeing what
> sounds like a high volume of phish. I've asked our fraud ops team to
> investigate this. In the future if you could send suspicious emails
> to ab...@sendgrid.com we will get this handled.

fwiw I forwarded an obvious phish to that address last Friday (claiming
to be from ebay and using a sender address @ebay-ws.com, which isn't
even registered) and received no response other than a second
practically identical mail today.

Adam


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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Len Shneyder via mailop]

Hello Benoit and Hokan,

Thanks for pointing this out and I'm sorry you're still seeing what sounds
like a high volume of phish. I've asked our fraud ops team to investigate
this. In the future if you could send suspicious emails to
ab...@sendgrid.com we will get this handled. Feel free to CC me when you do
this to make sure these are handled quickly.

We've instituted some self-limiting features on our front door that
should've decreased the overall volume of abuse. This is a stop gap measure
as we roll out some other countermeasures in the next few weeks. Could you
let me know if you have seen a perceptible drop in volume and velocity
between June and July when this was rolled out?

Again, I want to assure you that there is a massive effort happening here
to address the problems you are seeing. I'm happy to meet off list and
discuss this further and help you understand what we're working on if that
would be helpful. Again, thank you for your patience and please don't
hesitate to contact me when you see any of these issues arise.

Best,
-L

Len Shneyder
VP Industry Relations
[image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
EMAIL l...@twilio.com
TWITTER @LenShneyder <https://twitter.com/LenShneyder>Message: 6
Date: Tue, 11 Aug 2020 16:53:46 +0200
From: Benoit Panizzon 
To: mailop@mailop.org
Subject: [mailop] Delisting request from sendgrid customer about ip
used in recent phishing campaign.
Message-ID: <20200811165346.4e775...@go.imp.ch>
Content-Type: text/plain; charset=UTF-8

Hi List

o1678912x138.outbound-mail.sendgrid.net [167.89.12.138] and IP under
control of sendgrid was repeatedly involved in phishing and other spam
since June.

It ended up being blacklisted @ SWINOG.

Now a sendgrid customers complains to us, that his emails are being
rejected because of this listing.

But that makes me wonder: Doesn't sendgrid deal with such issues like
asking for delisting after blocking the sender itself and re-uses
recently (last phish received on 14. July) 'abused' ip addresses for
other customers?

Mit freundlichen Grüssen

-Benoît Panizzon-
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web
https://urldefense.com/v3/__http://www.imp.ch__;!!NCc8flgU!Jyb1oWP7APkgX0rrc5NFacUfW0Yu4XeA1B6Dcl0IJWNPlcXIUaIq9196yCI$
__



--

Message: 7
Date: Tue, 11 Aug 2020 10:20:47 -0500
From: Hokan 
To: mailop@mailop.org
Subject: Re: [mailop] Delisting request from sendgrid customer about
    ip used in recent phishing campaign.
Message-ID: <20200811152047.ga7...@me.umn.edu>
Content-Type: text/plain; charset=iso-8859-1

I've instituted short-term blocks of Sendgrid mail several times this year
and started another today because it looks like as much as a third of the
mail they've sent us in the past week has been evil -- mostly phishing.

This is a problem for me because some of the mail Sendgrid sends is
wanted by my users.  I'm thinking about just accepting it all and filing
it into user spam folders.

I see that the IP you mention, Benoit, is currently listed on the SBL and
Spamcop.


On Tue, Aug 11, 2020 at 04:53:46PM +0200, Benoit Panizzon via mailop wrote:
> Hi List
>
> o1678912x138.outbound-mail.sendgrid.net [167.89.12.138] and IP under
> control of sendgrid was repeatedly involved in phishing and other spam
> since June.
>
> It ended up being blacklisted @ SWINOG.
>
> Now a sendgrid customers complains to us, that his emails are being
> rejected because of this listing.
>
> But that makes me wonder: Doesn't sendgrid deal with such issues like
> asking for delisting after blocking the sender itself and re-uses
> recently (last phish received on 14. July) 'abused' ip addresses for
> other customers?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-

--
Hokan MEnet, a wholly owned subsidiary of
Enet
System Administrator Department of Aerospace Engineering and
Mechanics
ho...@me.umn.edu  Department of Mechanical
Engineering
612.208.3105 (cell)   Department of Industrial and Systems
Engineering



--

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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Hans-Martin Mosner via mailop]

Am 11.08.20 um 16:53 schrieb Benoit Panizzon via mailop:
> Hi List
>
> o1678912x138.outbound-mail.sendgrid.net [167.89.12.138] and IP under
> control of sendgrid was repeatedly involved in phishing and other spam
> since June.
>
> It ended up being blacklisted @ SWINOG.
>
> Now a sendgrid customers complains to us, that his emails are being
> rejected because of this listing.
>
> But that makes me wonder: Doesn't sendgrid deal with such issues like
> asking for delisting after blocking the sender itself and re-uses
> recently (last phish received on 14. July) 'abused' ip addresses for
> other customers?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-

As far as I understood, the IP addresses are not allocated to customers (except 
in some cases where the customer domain
is being used for hostnames of big customers) but are part of a shared mail 
distribution network.

This means that blocking sendgrid IPs does on one hand affect other customers, 
and on the other hand it does not
reliably block the spammer.

Much more effective is to block based on the string of digits in the envelope 
sender address (bounces+1234567-...) which
apparently identifies the sender.

Whether the sender has been hacked or is a genuine spammer is sometimes not 
easy to see, because sendgrid does some
header obfuscation of their own, so some marks normally associated with 
spammers may also be seen in mails from
non-spammers or compromised accounts.

Cheers,
Hans-Martin



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

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Hokan via mailop]

I've instituted short-term blocks of Sendgrid mail several times this year
and started another today because it looks like as much as a third of the
mail they've sent us in the past week has been evil -- mostly phishing.

This is a problem for me because some of the mail Sendgrid sends is
wanted by my users.  I'm thinking about just accepting it all and filing
it into user spam folders.

I see that the IP you mention, Benoit, is currently listed on the SBL and
Spamcop.


On Tue, Aug 11, 2020 at 04:53:46PM +0200, Benoit Panizzon via mailop wrote:
> Hi List
> 
> o1678912x138.outbound-mail.sendgrid.net [167.89.12.138] and IP under
> control of sendgrid was repeatedly involved in phishing and other spam
> since June.
> 
> It ended up being blacklisted @ SWINOG.
> 
> Now a sendgrid customers complains to us, that his emails are being
> rejected because of this listing.
> 
> But that makes me wonder: Doesn't sendgrid deal with such issues like
> asking for delisting after blocking the sender itself and re-uses
> recently (last phish received on 14. July) 'abused' ip addresses for
> other customers?
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
 
-- 
Hokan MEnet, a wholly owned subsidiary of Enet
System Administrator Department of Aerospace Engineering and Mechanics
ho...@me.umn.edu  Department of Mechanical Engineering
612.208.3105 (cell)   Department of Industrial and Systems Engineering

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