Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
23. Juli 2022 00:54, "Atro Tossavainen via mailop" schrieb: > Er, I think you mean > > https://msbl.org/ebl.html Yeah, basically that, except that i'm thinking of a somewhat wider scope by also covering compromised mailboxes, which gets closer to the PII danger zone as those woould belong to individuals more likely than the typical spammer addresses which are probably controlled by spammer teams or at least have not the slightest relation to the particular spammer using them. But the presence of the EBL shows that other people think that hashed e-mail addresses are reasonably safe to handle, even though they (like most BL operators) prefer to stay somewhat anonymous. That's at least a partial answer to my concerns. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400) Luis E. Muñoz via mailop is rumored to have said: On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote: This would allow the ESP to quickly "fail" the API request to send to that email address. There are other metrics that could be tied into those addresses and used to provide a more expedite response to the caller, which incidentally would also help deter abuse. In many, many cases the issue is that other customers are mailing to the same address - and just because an address bounces for X sender doesn’t mean that it shouldn’t be mailed for Y sender. One clear example is when senders push individual user blocks out to the SMTP transaction. I question your assertion that "bounces for X sender doesn’t mean that it shouldn’t be mailed for Y sender". If recipient R has a history of blocking many senders, continuing to send from other senders is not worth it in the long run for the ESP. Just as receivers reject with errors such as "this account is receiving email at a rate that...", the ESP could respond to its client with "this receiver has a history of bounces / rejections / complaints that is incompatible with our policies...". If only we had a framework for error codes in SMTP that carry useful semantics... Forcing a COI at that stage would revert this status and return to the status quo. Implementation in small steps. But this require the ESPs to willingly step out of the box to want to make things better. The economic incentives are likely not there, unfortunately. There it is. ESPs don't make money by not sending spam. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2022-07-20 at 12:41 -0600, Brie via mailop wrote: > It's still going on even though it was 'being looked into'. Fixed here by blacklisting the DKIM signature from zoom.us -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYttJkRUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsGGygCeJBuMa1jhYyuR9AAnTbcJimqqpEcA niiNBogb6ZVt3ukVVjkglWeC7s5h =nLAT -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Hans-Martin Mosner wrote: > Especially in the area of freemailer spam (and somewhat ESP spam, of course), > hashes of spammy mail senders could be used to share reputation among mailops > without handling actual e-mail addresses. Er, I think you mean https://msbl.org/ebl.html which was presented to the public in M3AAWG 41, Toronto, October 2017. Ever since, Spamhaus have also made their own take of the same idea. It is the HBL. The HBL has a wider scope (in addition to email addresses, it also considers file attachments and cryptocurrency wallets), but availability is somewhat restricted whereas the use of the MSBL EBL is free as in free beer. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, http://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
22. Juli 2022 22:20, "Luis E. Muñoz via mailop" schrieb: > Going back to the example of an ESP, does the hash of the email address > equate the email address as > per GDPR? This probably reaches well into the area of legal expertise and may therefore be off-topic here, but it would be very interesting to know what people think about this anyway. Especially in the area of freemailer spam (and somewhat ESP spam, of course), hashes of spammy mail senders could be used to share reputation among mailops without handling actual e-mail addresses. I could contribute dozens of fresh advance fee fraud gmail address hashes every day, which could potentially be used by others to refuse unsolicited mail. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 22 Jul 2022, at 13:10, Atro Tossavainen via mailop wrote: [✄ but thoroughly read] > Becoming a data controller entails needing a legitimate basis for > processing the personal data of the customer's customers, with whom > the ESP does not have any kind of a direct business relationship so > it's really very hard to justify. You can probably pull the notes on > "so, you want to be a data controller" from the past conference > proceedings from the members area. I love this angle! If we agree that IP addresses, email addresses and real names are all PII as per GDPR, your example is comparable to Cloudflare. The end-user browsing a website is sending PII (its IP address, along with cookies and whatnot) to CF, which it then forwards to the proxied website. The visitor that does not know how to block cookies on their browser, also cannot know it is sending its PII to CF. Does this turn CF into a data controller? If CF decides that the end user is indeed a bot because of data gathered among various CF clients, does it become a data controller? Going back to the example of an ESP, does the hash of the email address equate the email address as per GDPR? Happy weekend! -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 7/22/22 10:57 AM, Robert L Mathews via mailop wrote: I have an bad example of this. My company opened a thousands-of-dollars-a-year account with a large company, and apparently this company does all their transactional mailing through a certain well-known ESP. I got none of it, and nobody could figure out why for a while. It finally turned out that the ESP had added our entire domain name to some sort of global blocklist they have, solely based on my complaints that the ESP was letting their customers repeatedly send spam to our role addresses like support@, billing@, and info@. (The address the large company was trying to send to was not one of those addresses.) Worse, their global blocklist acted as a black hole for mail, where nobody was notified of the problem. This is a good example of how many ESPs are just really not trying even the most basic stuff. Rather than add a check to say "hey, our customer's importing a list that has lots of role addresses, that's unusual, let's check it out", they instead just maximally listwashed me so I would stop complaining about it. I think I know which ESP you are talking about. I had a very similar issue. For $dayjob I send mails for in-person and online auctions. I like to use my personal address as a test destination to see how it looks to various filters. Because certain ESPs, rather than deal with their spamming customers, have decided it's easier to blacklist/blackhole my address/domain, I can't do that. Anything to avoid holding people responsible for their actions. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> I got none of it, and nobody could figure out why for a while. It > finally turned out that the ESP had added our entire domain name to > some sort of global blocklist they have, solely based on my > complaints that the ESP was letting their customers repeatedly send > spam to our role addresses like support@, billing@, and info@. (The > address the large company was trying to send to was not one of those > addresses.) BTDTGTTS. The people who were then on the other side of this incident are probably among mailop readers. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Lem said: > I question your assertion that "bounces for X sender doesn’t mean that it > shouldn’t be mailed for Y sender". Indeed if, say, an address doesn't exist, it doesn't exist whether the sender is X or Y. Also, if the mail platform rejects mail from the sender's IPs or domains, it will probably do that for X and Y alike. According to people who know better than I do, and any M3 member (which would mean at least Laura and Lem) has had the chance to hear them out in person, maintaining a suppression list that is above the level of a single customer makes the ESP a _data controller_ in terms of the GDPR. When they're doing stuff for their customers only, individually (as in, data from customer X does not affect the proceedings for customer Y), they are a _data processor_ and that's where they want to be. Becoming a data controller entails needing a legitimate basis for processing the personal data of the customer's customers, with whom the ESP does not have any kind of a direct business relationship so it's really very hard to justify. You can probably pull the notes on "so, you want to be a data controller" from the past conference proceedings from the members area. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 7/22/22 4:31 AM, Laura Atkins via mailop wrote: I’ll point out, this isn’t an ESP only problem. Two of the biggest sources of spam right now are O365 and Google IP addresses. They are actually a bigger problem in my (mostly unfiltered for reasons) inbox than any ESP. That is an understatement. Worst part is, I can't get more aggressive on the filtering for gmail/gapps and o365 sources without running the risk of catching legit mail from my customers or their customers. I’m agreeing there is a problem with ESPs and have said so to ESPs individually and as a group over the last few weeks. The ESPs are interested in sender reputation. But, in this context, reputation means “Our mail gets accepted at the ISPs”. In that context their reputation is fine. They’re not being blocked. Specific customers may have delivery problems, but a lot of the modern machine learning filters are very good at blocking the problem customers without blocking the good ones. My biggest (well, one of two big) gripe right now with SendGrid is their apparent lack of bounce handling. I can throw their mail back at their tagged from addresses with a rejection notice or reject at connection time and their systems just won't take NO for an answer. Zoom on the other hand, it seems like they're just letting (at least this particular spammer that has been spewing for over a year now) people use their mail systems with a from of no-re...@zoom.us and no list tagging or any way to unsubscribe or block messages from them. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 7/22/22 8:49 AM, Laura Atkins via mailop wrote: That’s normal practice as far as I’m aware. If an address bounces the ESP prevents the sender from mailing to it in the future. There are some ESPs that don’t (and they know how I feel about their practices). I’ve also heard complaints from ISP representatives about ESPs that do this and make it impossible to troubleshoot why their customer isn’t getting the mail they asked for. I have an bad example of this. My company opened a thousands-of-dollars-a-year account with a large company, and apparently this company does all their transactional mailing through a certain well-known ESP. I got none of it, and nobody could figure out why for a while. It finally turned out that the ESP had added our entire domain name to some sort of global blocklist they have, solely based on my complaints that the ESP was letting their customers repeatedly send spam to our role addresses like support@, billing@, and info@. (The address the large company was trying to send to was not one of those addresses.) Worse, their global blocklist acted as a black hole for mail, where nobody was notified of the problem. This is a good example of how many ESPs are just really not trying even the most basic stuff. Rather than add a check to say "hey, our customer's importing a list that has lots of role addresses, that's unusual, let's check it out", they instead just maximally listwashed me so I would stop complaining about it. -- Robert L Mathews ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote: >> This would allow the ESP to quickly "fail" the API request to send to that >> email address. There are other metrics that could be tied into those >> addresses and used to provide a more expedite response to the caller, which >> incidentally would also help deter abuse. > > In many, many cases the issue is that other customers are mailing to the same > address - and just because an address bounces for X sender doesn’t mean that > it shouldn’t be mailed for Y sender. One clear example is when senders push > individual user blocks out to the SMTP transaction. I question your assertion that "bounces for X sender doesn’t mean that it shouldn’t be mailed for Y sender". If recipient R has a history of blocking many senders, continuing to send from other senders is not worth it in the long run for the ESP. Just as receivers reject with errors such as "this account is receiving email at a rate that...", the ESP could respond to its client with "this receiver has a history of bounces / rejections / complaints that is incompatible with our policies...". Forcing a COI at that stage would revert this status and return to the status quo. Implementation in small steps. But this require the ESPs to willingly step out of the box to want to make things better. The economic incentives are likely not there, unfortunately. > This is another “simple” solution that demonstrates a significant lack of > understanding of how bulk email is sent. It could be argued that your response demonstrates a significant resistance to change. The status quo is not cutting it for a growing number of participants while the only ones making money, are the ones selling filters and consulting. Best regards -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Dňa 22. júla 2022 15:49:08 UTC používateľ Laura Atkins via mailop napísal: >In many, many cases the issue is that other customers are mailing to the same >address - and just because an address bounces for X sender doesn’t mean that >it shouldn’t be mailed for Y sender. One clear example is when senders push >individual user blocks out to the SMTP transaction. Nobody other is intersted in ESP's customers, only the ESP itself, thus that is ESP's problem how to deal with this. regards Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 16:02, Luis E. Muñoz via mailop wrote: > > On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote: > >> I’m agreeing there is a problem with ESPs and have said so to ESPs >> individually and as a group over the last few weeks. > > Something that I don't see mentioned often enough and that would help, is to > retain records of bounces—even of hashed email addresses vs the bounce. That’s normal practice as far as I’m aware. If an address bounces the ESP prevents the sender from mailing to it in the future. There are some ESPs that don’t (and they know how I feel about their practices). I’ve also heard complaints from ISP representatives about ESPs that do this and make it impossible to troubleshoot why their customer isn’t getting the mail they asked for. > This would allow the ESP to quickly "fail" the API request to send to that > email address. There are other metrics that could be tied into those > addresses and used to provide a more expedite response to the caller, which > incidentally would also help deter abuse. In many, many cases the issue is that other customers are mailing to the same address - and just because an address bounces for X sender doesn’t mean that it shouldn’t be mailed for Y sender. One clear example is when senders push individual user blocks out to the SMTP transaction. This is another “simple” solution that demonstrates a significant lack of understanding of how bulk email is sent. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote: > I’m agreeing there is a problem with ESPs and have said so to ESPs > individually and as a group over the last few weeks. Something that I don't see mentioned often enough and that would help, is to retain records of bounces—even of hashed email addresses vs the bounce. This would allow the ESP to quickly "fail" the API request to send to that email address. There are other metrics that could be tied into those addresses and used to provide a more expedite response to the caller, which incidentally would also help deter abuse. Best regards -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Hi Laura, *! / The ESPs are interested in sender reputation. But, in this context, reputation means “Our mail gets accepted at the ISPs”. In that context their reputation is fine. They’re not being blocked. Specific customers may have delivery problems, but a lot of the modern machine learning filters are very good at blocking the problem customers without blocking the good ones. \ ESPs specialized in their business. If they expect the MBPs to solve their problems with modern machine learning filters, I'd expect the MBPs earn their fair part of the job. I suggest ESPs book filter capacity in advance with the MBPs they intend to feed. And maybe we should treat "we're too big to fail candidates" the same way. We teach our children that the bigger you get, the more responsibility you have to take on. Florian ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 12:22, Simon Arlott via mailop wrote: > > On 22/07/2022 10:21, Laura Atkins via mailop wrote: >>> After that there should be an integrated opt-in process to verify any >>> new email address for that ESP customer's list. >> >> While this sounds simple and like a no-brainer, it doesn’t account for how >> complex many companies email programs are. In many, many cases full customer >> data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know >> (and in fact absolutely shouldn’t know) things like credit card numbers or >> login passwords. There are also a number of systems that don’t keep email >> addresses at all. Mail is triggered through an API call and all of the email >> addresses are stored on the sender’s system, “lists” never go near the ESP. >> All the ESP sees are send requests. > > At no point did I suggest the ESP needs to receive more than the email > address? You didn’t say it, no. But that’s what your comment "It should only be possible to import addresses from a list once or twice, not on a regular basis” leads to. That’s what I meant by “it sounds simple but it’s not.” The “simple" solution you're suggesting cannot work because it doesn’t address the reality of how bulk email is handled. The only practical way to not upload addresses on a regular basis is to keep all customer data at the ESP and build your entire customer database around the ESP. Otherwise, you’re going to need to import addresses on a regular basis. On a practical level, say you want to send email to users that have purchased a particular product because that’s been recalled. Either, the purchase data needs to be inside the ESP or the list of users who have purchased that product needs to be updated. Or, you want to send email to users that have opened your application in the last month. Either you need to have that data inside the ESP or you need to upload the list of users to the ESP on a regular basis. > Only the email verification message needs to go through the ESP. It > could insert a confirmation token in a URL that the ESP customer then > presents to confirm opt-in for that ESP account. The user experience is an issue here. I have multiple big senders who use 2 or even 3 different ESPs - typically for different types of messages. Are they supposed to confirm the email address through each ESP individually? Is that a reasonable process to expect to happen? > None of this prevents PayPal, banks, etc. from operating. It also > doesn't prevent online shops from operating but it does complicate the > process of receiving a receipt if that normally comes direct from the > payment processor because all messages would need to use the same ESP. My point exactly. And expecting people to confirm every source of email independently is not a solution. > There's just a conflict of interest between "people pay us to send > email" and "people who pay us nothing don't want to receive that email”. You’re forgetting another group: People who pay us nothing want to and expect to receive this email. One of the most challenging bits of email filtering is dealing with emails that are wanted by some recipients and are unwanted by other recipients. This isn’t a new concept at all, it’s a problem that I remember having discussions with JD about back when he was at Y! (and he’s been gone for more than a decade at this point). laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
On 22/07/2022 10:21, Laura Atkins via mailop wrote: >> After that there should be an integrated opt-in process to verify any >> new email address for that ESP customer's list. > > While this sounds simple and like a no-brainer, it doesn’t account for how > complex many companies email programs are. In many, many cases full customer > data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know > (and in fact absolutely shouldn’t know) things like credit card numbers or > login passwords. There are also a number of systems that don’t keep email > addresses at all. Mail is triggered through an API call and all of the email > addresses are stored on the sender’s system, “lists” never go near the ESP. > All the ESP sees are send requests. At no point did I suggest the ESP needs to receive more than the email address? Only the email verification message needs to go through the ESP. It could insert a confirmation token in a URL that the ESP customer then presents to confirm opt-in for that ESP account. None of this prevents PayPal, banks, etc. from operating. It also doesn't prevent online shops from operating but it does complicate the process of receiving a receipt if that normally comes direct from the payment processor because all messages would need to use the same ESP. There's just a conflict of interest between "people pay us to send email" and "people who pay us nothing don't want to receive that email". -- Simon Arlott ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
> On 22 Jul 2022, at 11:13, Slavko via mailop wrote: > > Ahoj, > > Dňa Fri, 22 Jul 2022 10:21:44 +0100 Laura Atkins via mailop > napísal: > >> ESPs have many, many problems, but the fixes being suggested here on >> mailop are overly simplistic and evidence a lack of conceptual >> understanding of how bulk email is sent in 2022. > > Sure, complex things has complex problems, no doubts. > > But IMO the right question is: > > "Are (big) ESPs interested in its (as sender) reputation at all?" I’ll point out, this isn’t an ESP only problem. Two of the biggest sources of spam right now are O365 and Google IP addresses. They are actually a bigger problem in my (mostly unfiltered for reasons) inbox than any ESP. I’m agreeing there is a problem with ESPs and have said so to ESPs individually and as a group over the last few weeks. The ESPs are interested in sender reputation. But, in this context, reputation means “Our mail gets accepted at the ISPs”. In that context their reputation is fine. They’re not being blocked. Specific customers may have delivery problems, but a lot of the modern machine learning filters are very good at blocking the problem customers without blocking the good ones. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Ahoj, Dňa Fri, 22 Jul 2022 10:21:44 +0100 Laura Atkins via mailop napísal: > ESPs have many, many problems, but the fixes being suggested here on > mailop are overly simplistic and evidence a lack of conceptual > understanding of how bulk email is sent in 2022. Sure, complex things has complex problems, no doubts. But IMO the right question is: "Are (big) ESPs interested in its (as sender) reputation at all?" IMO not, or at least not completely. While i do not know how they get moneys from customers, i will guess, that bigger list = more money, thus cleaning the lists = smaller lists = less money. And which company wants to get less money? I can understand (and agree), that those ESPs do not need to know about particular address list. I agree, that list cleaning is not simple task. I understand, that unsubscribing from lists (especially via link in email) is prone to confirming address/reading, and often misused by SPAMmers, thus it is often doesn't not used. Etc, etc... But they simple have to act into process, when there are permanent/repeating rejects and list's owner do not care, otherwise they will become SPAM actors/supporters. But once again, are they interested in that? The thread some time ago about googlegroups and adding address into it shows base of the problem: + from google's point of view, the manual adding method is noneffective, as only small amount of outgoing mail goes by that way + from target user's view, it is 100 % effective, as every time the address is added, it is SPAMmed And that goes to ESP (bulk mails) too. Big ESPs doesn't care about single (particular) user, they have its own percentages to decide what is acceptable. And one user have no place in its calculations. Until these (big) ESPs will not change their point of view from own percentage calculation, to target (offended) user's percentage, nothing will change. But i afraid, that this change will never happen, as many companies consider, that others have created mailbox only to they can get these crap emails... regards -- Slavko https://www.slavino.sk pgp5UWX1kJZVr.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
Am 22. Juli 2022 11:34:16 schrieb Laura Atkins via mailop : ESPs have many, many problems, but the fixes being suggested here on mailop are overly simplistic and evidence a lack of conceptual understanding of how bulk email is sent in 2022. Suggested technical fixes are certainly too simplistic when they are based on insufficient understanding of how bulk email is being handled. However, there are some basic requirements which should enable ESPs to keep their shop relatively free from spam: * Have clear contractual rules against unsolicited email, together with clear consequences when those rules are violated. * Have a working and knowledgeable abuse desk that is able to discern whether complaints are spurious or a sign of systematic unsolicited email sending. * Authorize this abuse desk to restrict service to a customer until issues are resolved. * Know your customer in the first place, to avoid onboarding repeat offenders. * And of course, have management buy-in about spam prevention. An abuse desk working against sales and management interest will inevitably fail. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?
>>> The basic problem is allowing an ESP customer to import a list that >>> existed before the customer became a customer of this ESP. I can't >>> think of an ESP that would not allow that. >> >> I saw this again as someone replied to it. >> >> Sadly, there is at least one legitimate reasons to allow this: >> how else could a customer change ESP ? > > It should only be possible to import addresses from a list once or > twice, not on a regular basis. > > After that there should be an integrated opt-in process to verify any > new email address for that ESP customer's list. While this sounds simple and like a no-brainer, it doesn’t account for how complex many companies email programs are. In many, many cases full customer data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know (and in fact absolutely shouldn’t know) things like credit card numbers or login passwords. There are also a number of systems that don’t keep email addresses at all. Mail is triggered through an API call and all of the email addresses are stored on the sender’s system, “lists” never go near the ESP. All the ESP sees are send requests. There are opt-in processes that don’t involve “signing up for a list” as well. You register an account with PayPal, or your bank, or whatever. Yes, those organizations should (and many do) have verification processes in place. But that should be handled by the data controller, not the ESP. ESPs have many, many problems, but the fixes being suggested here on mailop are overly simplistic and evidence a lack of conceptual understanding of how bulk email is sent in 2022. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
