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
