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
