>More for my curiosity than anything else.. Let's assume that MailChimp >has a spam outbreak, an ISP or RBL adds the IP address, and the >receiving MTA treats it with a hard bounce (5.XX). > >On your 'shared' flows, then all other streams, not only the offending >list, would also get the hard bounce.. do you remove everyone that gets >the 5.xx at that point?
We assign an "activity score" to every email address. This score increases with opens and clicks, and it decreases in the absence of opens and clicks. Email addresses with a positive activity score will not be removed on the first hard bounce. Instead, that hard bounce will set the email address's activity score to 0. A second hard bounce would then cause the address to be removed from the list. Additionally, we make an attempt to reclassify certain hard bounces that go out of their way to implicate an issue unrelated to the validity of the email address or the signup. For instance, some bounce messages indicate spam content or phishing links. Feeding those kinds of bounce messages into the regular process that simply removes an address from a list would not be very effective for identifying and removing malicious email. To your point, bounces that indicate IP blocks would also negatively impact users who were not guilty of sending spam over that shared IP. So to answer your question, we have a few ways of addressing hard bounces when those bounce messages indicate the validity of the email address and the signup are not under dispute. >Isn't there some form of 'second effort', eg record the number of 5.xx >received from emails directed to that recipient? To deal with temporary >problems, such as MTA system misconfiguration, resource exhaustion that >might also generate a 5.xx hard bounce? So starting at the bottom... A lot of bounces that result from misconfiguration or resource exhaustion will cause deferrals which our system treats differently than what we call hard and soft bounces. A bounce means that we will stop trying to send a particular piece of content from a particular user to a particular email address, and we may take further action to modify the status of the email address on the user's list. When we get a deferral message, we stop trying to deliver any email to the deferred domain from that sending IP for a period of time. Any emails queued up for that domain on the sending IP will just sit around. We will retry to send email in this queue after a few minutes or a few hours. After a period of days and several attempts to send again, any email that hasn't been sent is removed from the queue. To answer the top part of that question... We do have a tool that records, on a company-wide level, which addresses have bounced in the past. No, we do not use this tool for suppression or list washing. We use this tool to predict bounce rates on new lists. An interesting note about this bounce prediction tool is that it is extremely unreliable on a per email address basis. This means we're very bad at predicting whether a specific email address will bounce in the future just because we've seen it bounce in the past. However, when the results are aggregated at the list level, we can predict a hard bounce rate within 1% +/-. >Aside from putting that work load on the recipient I'd like to think our anti-abuse efforts mean that a lot of recipients don't have to do anything to avoid receiving unwanted mail from us. We have multiple teams with lots of passionate individuals who put in 40+ hours a week on preventing and stopping abuse. It truly is one of our top priorities, but it's highly unlikely that we'll eliminate abuse entirely. There will always be recipients who need to reach out to us and let us know what they want. We do our best. For what it's worth, the request that spurred this conversation asked if we could quarantine certain addresses any time they were added to a list and only lift the quarantine once the user received a DOI confirmation. Honestly, it's a great idea that solves a real problem with our current global opt-out requests. I'm not 100% sure it would play nicely with all of our legal obligations, but it's worth investigating. Implementation is actually more complicated than you might imagine, so I wouldn't count on it getting done any time soon. It is a great idea though. >you have good sales teams ;) As far as I know, we still don't have a sales team. There's just a lot of small businesses out in the world. >... and if they DID want global suppression, I think it >would be easier for the user/admin to simply block it at their end ;) Here's a list of our IPs <https://mailchimp.com/about/ips/> which we publish so people can whitelist or block them as they see fit. To quote that page, "Our servers deliver more than 1 billion newsletters every day, so we work very hard to keep abuse out of our system and maintain high overall deliverability. Nobody's perfect, but we like to think we try the hardest." So anyway, I hope I hit all your discussion points. Cool, Matthew delivery.mailchimp.com On Thu, Jun 4, 2020 at 3:39 PM Michael Peddemors via mailop < mailop@mailop.org> wrote: > On 2020-06-04 12:08 p.m., Matthew Grove via mailop wrote: > > Hi, > > > > Just to clarify, Mailchimp does remove addresses from specific lists > > when we receive a hard bounce. Atro is correct; we do not suppress hard > > bounced addresses globally across all of our users for a number of > > reasons. Each user's list is self contained in that respect. > > More for my curiosity than anything else.. Let's assume that MailChimp > has a spam outbreak, an ISP or RBL adds the IP address, and the > receiving MTA treats it with a hard bounce (5.XX). > > On your 'shared' flows, then all other streams, not only the offending > list, would also get the hard bounce.. do you remove everyone that gets > the 5.xx at that point? > > Isn't there some form of 'second effort', eg record the number of 5.xx > received from emails directed to that recipient? To deal with temporary > problems, such as MTA system misconfiguration, resource exhaustion that > might also generate a 5.xx hard bounce? > > > Then again, if you are looking for global suppression, you can reach out > > to our abuse team to see if that can be arranged. > > Aside from putting that work load on the recipient, there will always be > some innocents with legitimate notifications that sign up with > MailChimp, you have good sales teams ;) And maybe one of the future ones > will be important.. and if they DID want global suppression, I think it > would be easier for the user/admin to simply block it at their end ;) > > But, as a previous poster pointed out, transparency is key.. > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
