开云体育

Received from Michael Pavan at 10/3/2018 06:45 PM UTC:

There is good explanation here -> /g/GroupManagersForum/wiki/Help-Mock-up#Bounce-Handling

Understood, interesting - but useless to Subscribers/Members if they never see, read, or understand them.

Useless due to never being seen only if members of this group - GROUP OWNERS - do nothing to make this info available to subscribers BEFORE (sometimes AFTER) they're bouncing. Reading is the responsibility of the member. Same for understanding or seeking someone to explain. I think it starts with Group Owners managing their groups by communicating with their members.

The member sending an email to groups.io would not do anything as groups.io cannot do anything about the member's email provider that is bouncing the emails.

It would resurrect an account from the "virtual limbo" and restart trying to deliver messages to the Subscriber/Member again.

That's an action for AFTER the member has taken action to resolve the cause of bouncing. There's no point to sending mail (including more than several bounce notices) from Gio to a mailbox that's refusing mail from Gio.

I see the GroupName+unbounce@... email address as having the exact same effect as responding to a Bounce Probe,

Not the same at all!

It's just something designed to let a member bypass the step involving correction of the root cause of the problem. It will just be a source of complaint when members who do nothing to correct the root cause send mail to GroupName+unbounce and it doesn't work because the real problem hasn't been cured. No solution for the member, more complaints to Group Owners, some of whom, not understanding the issue, will bring them here. That's just a big LOSE-LOSE for all.

The only problem with bounce probes is that until the bounce condition is fixed - via member action or via serendipity - a bounce probe won't be received. So Gio sends several probes in hopes that serendipity will intervene and let one of them thru, and that failing waits for the member to notice the problem and correct it.

How does the member know he has a problem and how to correct it? The Group Owners should either point their members to the info at the link above BEFORE problems arise, or AFTER members contact them. I'd probably provide members of a knitting group this info AFTER they report a problem. For a group about computer programming, probably BEFORE. It's a matter of who would likely take time to understand it BEFORE having a problem vs needing to be desperate before reading any of it. Just saying.

without the often insurmountable burden of the Subscriber/Member having to find the likely also mis-marked as a SPAM message Bounce Probe email, as it would be in a message from the Owner's private email address and likely would have been received in their Inbox.

It's not a substitute for finding that bounce probe message unless the root cause of the bouncing has been cured.

What you're proposing is an alternative approach that doesn't push the member to look for the bounce probe in his Junk folder where he could also see and mark other messages from Gio as NOT JUNK before responding to the bounce probe. That's NOT GOOD... because it results in that member's ISP reinforcing its notion that Gio is a source of junk/spam... and when those "spam/junk" messages are eventually deleted from the Junk folder rather than marked as NOT JUNK by the member, there's a fair chance a message will be sent automatically by the ISP to Gio notifying Gio the member has marked a message as spam... leading Gio to UNSUBSCRIBE the member. At that point you can forget minor stuff like bouncing because now he's unsubscribed from the group. And now he's twice as peeved and twice as hard to help or deal with in any manner.

Little problems turn into bigger ones when they aren't PROPERLY addressed by those responsible for addressing them. Gio knows what it's doing here... and they need to continue to do it at least until they're way "too big to block."

Plus if anyone, not necessarily that particular Subscriber/Member, had successfully interacted with that Email Provider to recognize Groups.io as NOT as SPAM ENGINE, such a Subscriber/Member would be all set. My thought is that most of us use Email Providers that other persons also use, meaning that not every client of every Email Provider that incorrectly labeled Groups.io as a SPAM ENGINE would have to educate every Email Provider.

That seems logical... until you understand that contact by "other persons" should solve a problem for others really says, "Someone else will handle it and others (my member) rides along for free." The big problem with that is that "someone else" is worn out - or is as incapable as your member - so it too often winds up that nobody handles it. Another problem is that as likely as not it COULD be only the bouncing member's email that is being blocked... because he really did mark a message as spam. People really do that. And in that case there isn't "someone else."

The only time I wouldn't lay 100% of the responsibility to resolve the bounce condition on the member is when the reason is due to a broader "policy decision" by the ISP - a decision to bounce ALL Gio email as a source of spam, or more likely a source of "too much email." That isn't likely to be resolved without direct contact between Gio and the ISP. And that cause will only be discovered by the member (or Group Owner) looking at the member's email activity record to see the reason for bouncing... and that may still require the member to call the ISP if the reason is an obscure AUP Code vs plain English... and depending on the code Gio may need to call the blocking ISP. That was the case back in I think August involving blocks by RoadRunner/Spectrum (my ISP) and AOL. I called Spectrum Tech Support, got the meaning of the AUP Code describing the reason for blocking, and Mark made the call. Blocking stopped.

All in all, bottom line as I see it is that there is no satisfactory solution for a member unwilling or unable to cooperate in solving his bouncing problems.

Jim H