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 <mailop@mailop.org> 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. >> > > >> > > 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
