Yeah, we've run into all sorts of problems with the automatic bounce handling for Google Groups that way as well, there are a lot of bounce messages where you have to read them, and they're often in languages beyond English (and not always ascii, or munged because the should be ascii and something breaks inbetween) or whatever. And that's on top of services with outages giving out "unknown user" temporarily to virtually everyone. I think the current groups setup is 3 probes after that to verify. Probes used to be an actual specific test message, but are now just special handling of the next messages on the group, so they may could be very spread depending on the group traffic.
We found a lot of places where the probe messages would get through, but the actual group messages would be rejected for various content based reasons, hence the change. Automated bounce handling is kind of a mess. And I recognize the benefits of bounces being in the user's language (we did a bunch of work to do that when we figured out certain countries always marked their english bounce messages as spam), the whole thing just adds to the mess. Brandon On Thu, Feb 28, 2019 at 6:42 AM Al Iverson <[email protected]> wrote: > It can be tough to square the "how dare you ever do this" responses > from a couple of big ISPs versus the personal and direct experience of > other big ISPs having meltdown scenarios where they give false > positive "user unknown" bounces for periods of time. Been there, done > that. > > Truth be told, everybody else's stuff breaks sometimes. We do > implement a counter-based bounce mechanism here for that very reason. > We also have a domain list where we can opt-domains out of this and > say that we "trust" the user unknown bounces from those domains, for > those who might get unhappy about that. > > An ESP who wants to make sure because they've been burned before is > not necessarily the devil here, folks. > > Regards, > Al Iverson > > On Thu, Feb 28, 2019 at 9:30 AM Arne Allisat <[email protected]> > wrote: > > > > We (web.de, GMX, mail.com) are clear in our response. > > > > We state if recipient mailbox either not exists "5xy Requested action > not taken: mailbox unavailable“ or is out of storage "5xy Requested mail > action aborted: exceeded storage allocation, Quota exceeded“. > > If you do not stop sending to unavailable mailboxes we’ll block you > sooner than later. > > > > We also state this in our mail policy: > https://postmaster.web.de/en/email-policy > > > > Best regards > > Arne > > > > > > Arne Allisat > > > > Head of Mail Application Security > > Product Management Applications > > > > 1&1 Mail & Media GmbH | Brauerstraße 48 | 76135 Karlsruhe | Germany > > E-Mail: [email protected] | Web: www.1und1.de > > > > > > > > Am 27.02.2019 um 22:01 schrieb Maarten Oelering <[email protected] > >: > > > > Hi Marco, > > > > I am curious what false positives you encountered. > > > > We suggest to classify bounces using multiple features, the text, the > enhanced status code, and the status code. If the bounce is clearly an > invalid address, then remove it after the first bounce. For example when > the text contains “mailbox” or a synonym, and “unknown” or a synonym. > Bounces which are ambiguous, or with inconsistent features should be > treated as soft bounce. > > > > Maarten > > Postmastery > > > > On Wed, 27 Feb 2019 at 17:27, Marco Franceschetti via mailop < > [email protected]> wrote: > >> > >> Hello, > >> > >> We at contactlab are considering a change in the deactivation of hard > bounces. > >> Currently, we suppress not existing mailboxes at the first hit. > >> > >> We are aware of a small percentage of false positives. > >> > >> Recent admissions criteria for Certified Senders states: > >> "The CSA sender must take email addresses from mailing lists, if, after > sending to this address, > >> the mailbox is identified as non-existent; at the latest, however, this > must occur after three hard > >> bounces". > >> > >> We are evaluating to remove not existing mailboxes from the lists of > our clients after the second hit instead of the first one. > >> > >> Do you have any considerations, suggestions about this? > >> > >> Marco > >> > >> > >> Marco Franceschetti > >> Head of Deliverability | ContactLab > >> [email protected] > >> Via Natale Battaglia, 12 | Milano > >> contactlab.com/it > >> > >> _______________________________________________ > >> mailop mailing list > >> [email protected] > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > _______________________________________________ > > mailop mailing list > > [email protected] > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > > > _______________________________________________ > > mailop mailing list > > [email protected] > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > -- > al iverson // wombatmail // miami > http://www.aliverson.com > http://www.spamresource.com > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
