Am 07.08.21 um 11:15 schrieb Noel Butler via mailop: > > > So you think it's better to have the potential to inconvenience > > MariaDB [vmail]> select count(*) from virtual_users where active='1'; > +----------+ > | count(*) | > +----------+ > | 836019 | > +----------+ > > over the likelihood of a dozen or so people who may have loss of a legit mail? > > I'm not one to bow to the tiny minorities, also, T&C's are most clear. > Of course, your server, your rules (especially if your users understand and agree with them).
In my case, the spam inconvenience per affected user was vastly smaller than the possible inconvenience and financial loss of the handful users who would have missed mail that they explicitly requested. I'm taking pretty extensive measures to keep the spam amount coming from SendGrid and other similar service to a minimum, so the spam inconvenience should already be very low. One effective measure is to put every SendGrid mail with an as yet unknown sender id on hold, check whether it looks like a spam run (multiple users addressed from someone they never before had a contact with) and either releasing mail from hold (and adding the id into the list of acceptable senders) or reporting to SendGrid and blocking the sender id for good. Of course I would love to see more proactive spam prevention and more swift action on the part of SendGrid to curb the number of spam mails sent, there's plenty room for improvement. On the servers that I control, an account caught sending unrequested mail (whether intentionally or through an exploit) will be suspended until the problem is resolved with the account owner. I'd expect similar policies to be established wherever the owner of the mail infrastructure isn't the one deciding what gets sent, be it ESPs or freemail providers. Some reasonable amount of fraudulent registration detection would be nice (and being a software developer, I would certainly see to implement something that has a noticeable effect) but I understand that there are no off-the-shelf solutions for that and it might be difficult to create one, especially as the freemail business doesn't yield revenue. Cheers, Hans-Martin _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
