Re: [mailop] Anyone have any contacts at Intuit?
Hi Michael, We (Mailchimp) are part of Intuit, and we've been working on understanding Intuit's sending practices. I'll reach out to you off-list. Cool, Matthew delivery.mailchimp.com On Thu, Jun 23, 2022 at 4:55 PM Anne Mitchell via mailop wrote: > > > > A small (abuse) matter appears to have arisen. > > > > I may have a contact at Intuit, they are in the legal department (if they > are still there), but it's a start. I've sent of an email and will let you > know if I can make an intro asap. > > Anne > > -- > Anne P. Mitchell, Attorney at Law > CEO Institute for Social Internet Public Policy > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Board of Directors, Denver Internet Exchange > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > Prof. Emeritus, Lincoln Law School > Chair Emeritus, Asilomar Microcomputer Workshop > Counsel Emeritus, eMail Abuse Prevention System (MAPS) > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Force double opt in for marketing list companies per email address
Tim, I believe *X-MC-User* and *List-ID* should help you identify those issues. Matt, if you think we're not handling a hard bounce properly, I'd like to get that worked out. Do please reach out off-list so we can troubleshoot the issue. Cool, Matthew delivery.mailchimp.com On Fri, Jun 5, 2020 at 10:04 AM Luke via mailop wrote: > Atro, > > I did not forget that we know each other. I remember meeting you and Pekka > for the first time in Dublin back in 2015. > > I appreciate the added perspective here. It sounded like you were > suggesting that ESPs do not suppress invalid email addresses. But it sounds > like you are aware that ESPs do suppress invalid email addresses, but you > believe they should suppress them across their entire user base. That is a > different discussion. Unfortunately, this is fraught with all sorts of > issues. The primary one being the unreliable nature of SMTP responses. Just > one example that is top of mind is Telstra/Bigpond. They will return "5xx > No such user" when one of their users has a lapse in payment. The mailbox > becomes valid again when the user pays their bill. Another example: when I > was at SendGrid, we did some analysis on bad addresses. We took every > address that returned some flavor of "no such user" in a 6 month period. We > then looked at how many of those addresses came back and engaged with mail > at a later date (the following 6 month period). It turned out that > something like 1% of invalid addresses would come back to life and become > engaged with email again. Also, we were careful to not take a single pixel > load or a single URL firing as "proof" the mailbox was back to life. Now, > 1% is a small number, but it was 10s of millions of addresses. It would > simply not be appropriate to permanently suppress these addresses on behalf > of 80,000-100,000 distinct senders and organizations using SendGrid to send > their email. > > Its hard for me to hear things like "ESPs don't suppress addresses" when I > worked at an ESP where we had discussions about whether it was ethical to > charge people for trying to send to addresses that we were suppressing on > their behalf. ESPs suppress bad addresses, just not the way you would like > them to. That is a discussion worth having, we just need to be clear on the > terms of the discussion. > > Luke > > On Fri, Jun 5, 2020 at 1:21 AM Atro Tossavainen via mailop < > mailop@mailop.org> wrote: > >> On Thu, Jun 04, 2020 at 07:48:45AM -0700, Luke wrote: >> > I cant tell if this the thing about ESPs not removing bounces is a joke >> or >> > not. All of the major ESPs have logic for adding bad addresses to >> > suppression lists. Of course their users can choose to unsuppress, but >> ESPs >> > certainly remove bounces. Seems like most people here should know this. >> > Maybe I'm missing something about your comment? >> >> Luke, you're sounding like you've forgotten we know each other IRL, >> and the same goes for you and my biz partners Pekka and Catherine. >> >> We timeout new domains for a year or more, in accordance with >> >> https://www.m3aawg.org/documents/en/m3aawg-best-current-practices-for-building-and-operating-a-spamtrap-ver-120 >> >> We started out doing this in such a way that the domains didn't have >> a way of receiving any email at all (no A and no MX, resulting in the >> sending mail server having to tell itself NXDOMAIN), but already for >> a long time this is done so that they do have a mail server that is >> responding >> >> 550 5.1.1 No such user >> >> to every attempt to deliver any email. >> >> I agree that that should result in very little to no ESP mail when such >> a domain eventually comes out of timeout, which would result in our not >> having a business at all. Not the case. >> >> >> > >> > On Wed, Jun 3, 2020, 11:30 PM Atro Tossavainen via mailop < >> mailop@mailop.org> >> > wrote: >> > >> > > > For me, it was noticing how, despite getting 550'd for an extended >> > > period of >> > > > time, Mailchimp just keeps hammering away at the address, never >> dropping >> > > it >> > > > from the list. That, too, is not the behaviour of a responsible >> ESP. >> > > >> > > As I keep saying, we would not have a business at all if any ESPs >> actually >> > > removed bounces. So thank you to everyone who doesn't. If there are >> > > entities that do, I don't know which ones they are. :-D >> > > >> > > Way back when, some people who are also on this list kept complaining >> > > that simply keeping domains registered without an A and MX (causing >> > > NXDOMAIN for mail delivery) is not a proper bounce, because you (as >> the >> > > sending entity) are somehow not able to trust the results your own >> > > servers produce, but have to get third party validation for the fact >> > > that an address doesn't exist (which I think is totally >> bass-ackwards), >> > > but anyway, we started 550 5.1.1'ing addresses during the timeout >> period >> > > of new domains we acquire, and still, no change. >> >
Re: [mailop] Handling of Hard Bounces - Topic Change
fect, 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
Re: [mailop] Force double opt in for marketing list companies per email address
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. In the past, allowing each user to bounce an address independently has caused some receivers to believe that we are not responding to hard bounces at all. That's not true, but I definitely understand where the perception is coming from. Of course, there is always a remote possibility that some misconfiguration on our side is causing us to reclassify your specific bounce message. You can compare our *X-MC-User* header to verify that we are not suppressing the address at the user level. If you think this might be the case, feel free to reach out to me off-list, and we'll troubleshoot the issue. Then again, if you are looking for global suppression, you can reach out to our abuse team to see if that can be arranged. Cool, Matthew delivery.mailchimp.com On Thu, Jun 4, 2020 at 11:13 AM Luke via mailop wrote: > I cant tell if this the thing about ESPs not removing bounces is a joke or > not. All of the major ESPs have logic for adding bad addresses to > suppression lists. Of course their users can choose to unsuppress, but ESPs > certainly remove bounces. Seems like most people here should know this. > Maybe I'm missing something about your comment? > > On Wed, Jun 3, 2020, 11:30 PM Atro Tossavainen via mailop < > mailop@mailop.org> wrote: > >> > For me, it was noticing how, despite getting 550'd for an extended >> period of >> > time, Mailchimp just keeps hammering away at the address, never >> dropping it >> > from the list. That, too, is not the behaviour of a responsible ESP. >> >> As I keep saying, we would not have a business at all if any ESPs actually >> removed bounces. So thank you to everyone who doesn't. If there are >> entities that do, I don't know which ones they are. :-D >> >> Way back when, some people who are also on this list kept complaining >> that simply keeping domains registered without an A and MX (causing >> NXDOMAIN for mail delivery) is not a proper bounce, because you (as the >> sending entity) are somehow not able to trust the results your own >> servers produce, but have to get third party validation for the fact >> that an address doesn't exist (which I think is totally bass-ackwards), >> but anyway, we started 550 5.1.1'ing addresses during the timeout period >> of new domains we acquire, and still, no change. >> >> There is also the issue that anything that Operator X finds out while >> processing data for Customer X1 cannot apply to Customer X2 because >> anything to the contrary makes Operator X a DATA CONTROLLER in their >> own right from the perspective of the GDPR and what did I say about >> that just a few messages ago? >> >> -- >> 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > ___ > 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
Re: [mailop] MailChimp and TLS
Hi Ken, We have a mix of older and newer server configurations. The older ones can't handle TLS and maintain their current output, but we wanted to go ahead with TLS where possible. We will be working to update all servers and make TLS more consistent, but it'll take a little time. Cool, Matthew delivery.mailchimp.com On Fri, Dec 7, 2018 at 5:46 PM Luis E. Muñoz via mailop wrote: > > > On 7 Dec 2018, at 11:14, Ken O'Driscoll via mailop wrote: > > > It would be super helpful if any mailbox provider here could tell me > > what > > they see with MailChimp regarding TLS. > > I looked at a hundred random samples dating back to mid November. I saw > exactly zero that used TLS inbound. The sample comprises a few receiving > domains, unrelated among themselves and what appear to be multiple > mailing lists / customers of MailChimp. > > Best regards > > -lem > > ___ > 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
Re: [mailop] What do other ISP / ESP do about the MailChimp spam problem?
Hi, this has been a great discussion from all sides. I’m probably too biased to weigh in on the original question, but we do listen to all the input and feedback here. Without getting too into the weeds, a few details and information gaps have surfaced that I hope to be able to clarify. You can find our complete IP space at https://mailchimp.com/about/ips/, and you can find our active IP space in the TXT records for servers.mcsv.net and spf.mandrillapp.com. Our goal is to be so good that it's not valuable to block us, but if you think blocking is the way to go, we don’t want to make it technically difficult. We're not perfect, and I understand that admins get fed up. >Most likely there is some way to tell different customers on mailchimp In fact, there are several ways. Any of these headers will help you narrow down specific users and/or campaigns. Worth noting that campaign identifiers include user info as well. User-level identifiers: X-MC-User (Mailchimp) X-Mandrill-User (Mandrill) Campaign-level identifiers in Mailchimp: Feedback-ID X-Campaign X-campaignid >And I'm smart enough not to report abuse to all the spamtraps so they're (probably) not merely listwashing. We make every attempt to avoid listwashing. From my perspective, people reporting abuse are a valuable source of feedback. If we blind the vocal reporters, then we’re making it more difficult to find spam being sent to the rest who aren’t calling out issues. When you report abuse on a list collection issue, our most common response will be to quarantine the list pending a double opt-in re-confirmation. If the user has pristine stats and a history of sending with us, we’ll also likely have a conversation about any recent changes to their list. I’d also like to note that there is a side-discussion going on about a Chinese ESP. It might help to pull that into its own thread. It might be causing confusion. Also, others might be avoiding this thread and missing some cool info :) Cool, Matthew delivery.mailchimp.com On Wed, Nov 7, 2018 at 6:33 AM Vladimir Dubrovin via mailop < mailop@mailop.org> wrote: > 06.11.2018 21:15, Michael Peddemors пишет: > > Like any organization, when the volume of unwanted exceeds the volume > > of wanted, you flag them... and let customers 'This is not junk' the > > ones they want. > > It means having the rule with up to 50% of false negatives. If we use > rules like this we have all mail send from abroad in the SPAM folder. > > Cross-boundary and cross-lingual mail are really special cases, you > always have higher SPAM ratio for mail originating from different > country, especially if it has different language. It's not because > different countries are more used by spammers, it's because of low HAM > volume you have from abroad. Believe me, this situation is even worse in > opposite direction, because your antispam filters are not good with > outgoing spam in Russian or Chinese. > > -- > Vladimir Dubrovin > @Mail.Ru > > > ___ > 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
