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
