开云体育

I have Subscribers/Members who are bouncing and I've sent Bounce Probes which have not been responded to.

If I send them an email from my personal (non-Groups.io) email address, can I do better than to:
-Send them another Bounce Probe.
and say:
-You are bouncing.
-Bounce Probes sent to you have not been responded to.
-Those Bounce Probes may have gone to your SPAM or JUNK folder, you should try to find the latest Bounce Probe which I just sent and respond to it.

I would prefer to be able to tell them that, alternatively they can send an email to:
[email protected]

Is this an option?
If not, has it been suggested yet?
If so, what is the status of the suggestion?

Michael,
Resolving a bounce condition requires action on the member's side of things.? They or their email provider have to do something so that the provider does not bounce incoming emails sent from groups.io.
Until that is done, bounce probes are useless (other than proving the messages are still being bounced).
There is good explanation here ->?/g/GroupManagersForum/wiki/Help-Mock-up#Bounce-Handling
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.
Thanks
Toby

On Wed, Oct 3, 2018 at 01:33 PM, Michael Pavan wrote:

I would prefer to be able to tell them that, alternatively they can send an email to:
[email protected]

Is this an option?

Bouncing status reflects groups.io's ability to deliver messages, not receive them. For example, if a subscriber's mailbox is full, it is possible for that subscriber to post messages to the group while being unable to receive. Establishing an "unbounce" address would not help situations like this and will only cause accounts to immediately start bouncing again.

Regards,
Bruce?
--
The system Help is your friend.??/static/help

Resolving a bounce condition requires action on the member's side of things. They or their email provider have to do something so that the provider does not bounce incoming emails sent from groups.io.
Until that is done, bounce probes are useless (other than proving the messages are still being bounced).

Especially if the Subscribe/Member never sees them.

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.

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.

I see the GroupName+unbounce@... email address as having the exact same effect as responding to a Bounce Probe, 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.

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.

I would prefer to be able to tell them that, alternatively they can send an email to:
[email protected]

Is this an option?
Bouncing status reflects groups.io's ability to deliver messages, not receive them. For example, if a subscriber's mailbox is full, it is possible for that subscriber to post messages to the group while being unable to receive. Establishing an "unbounce" address would not help situations like this and will only cause accounts to immediately start bouncing again.

In other words, it would be no more or less effective than replying to a Bounce Probe - which is exactly my point, just that it would be easy and more likely to get to the bounced Subscriber/Member.

I wasn’t trying to solve everything about this problem, just that in this case Bounce Probes often are not received and/or found by Subscribers/Members. Such a ‘command’ email address could be a more successful alternative to the Bounce Probe. It would not be a replacement for the Bounce Probe, just another tool to try (manual, for when automatic has failed).

Other aspects of the problem which even Bounce Probes also fail to remedy, such as a full mailbox, could maybe be addressed by including that explanation in the Bounce notices sent to Subscriber/Member and Owner, as well as in the Bounce Probe (and so notified, the Owner could include it in their private email outreach, perhaps with text suggested by Groups.io).

On Wed, Oct 3, 2018 at 06:33 PM, Michael Pavan wrote:

I have Subscribers/Members who are bouncing and I've sent Bounce Probes which have not been responded to.

Have you looked at your "Bouncing" members to try to get some clue as to why they are bouncing? I will accept that in some cases the information is less than entirely helpful, but in many cases it reveals (one way or another) that the recipient account no longer exists.

On the group I moderate we had > 600 bouncers, and I simply finished up deleting about 500 of the memberships in question. So far no - one has complained.

In addition, I cannot work out from your posts on this subject if you are conflating bounce problems with messages being interpreted as spam, which is an entirely separate problem.

Either way there is a finite limit to the time and effort I (and my fellow moderators) will expend trying to micromanage members; ultimately they have to take responsibility for their own actions, or lack of them.

Chris

On Wed, Oct 3, 2018 at 04:36 PM, Michael Pavan wrote:

In other words, it would be no more or less effective than replying to a Bounce Probe - which is exactly my point, just that it would be easy and more likely to get to the bounced Subscriber/Member.

You are missing the point.

Group owner intervention in this case is of course a good idea, but having the subscriber send an unbounce request without having done anything to resolve the problem accomplishes nothing.

In principle, if they haven't already done something to resolve bouncing status, they will not receive the bounce probe, and therefore cannot respond to it.?
?
Regards,
Bruce
--
The system Help is your friend.??/static/help

Michael,

If I send them an email from my personal (non-Groups.io) email
address, can I do better than to:
... and say: -You are bouncing.

If they are "Bouncing" (blue B after their address) then Groups.io will be sending them periodic bounce probes. If and when one gets through and they respond to it they'll be automatically unbounced.

If they are "Bounced" (red B) then Groups.io has given up on sending bounce probes.

If your personal email gets through to them you can also suggest that they visit your group's pages on Groups.io. When they log in there they'll see a banner at the top of the page with instructions for unbouncing their address (account). However that will only work if they've solved whatever problem at their email service caused the bounces in the first place.

If their email is working now, the "Email me a link to log in" button on the site's Log In page is a quick and easy way for a member to log in (even one that has never been to the site before). But they do need to be able to promptly receive the message sent to them.

I would prefer to be able to tell them that, alternatively they can
send an email to: [email protected]

Is this an option?
If not, has it been suggested yet?

It isn't, and I don't recall that it has been suggested.

I suspect that if the idea is taken up Groups.io would send a bounce probe in response, rather than simply resuming group messages. There are a couple reasons for this, but the primary one is as Bruce mentioned: the bottom-line question is whether the member can /receive/, not whether they can send.

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.

The automatic bounce probes provide that function.

I see the GroupName+unbounce@... email address as ... without the
often insurmountable burden of the Subscriber/Member having to find
the likely also mis-marked as a SPAM message Bounce Probe email,

Messages marked as SPAM weren't bounced - that's a different subject entirely - any message delivered to the member's Spam folder must first have been accepted by the email service.

As to your concern that the Bounce probe will end up in the member's spam folder, that's something you can address in your off-list message to the member. For what it is worth, I suspect bounce probes are actually /less/ likely to be diverted to the member's Spam folder than group postings are.

Shal


--
Help: /static/help
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list

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

My suggestion was that a Subscriber/Member sending an email to [email protected] be equivalent to responding to a Bounce Probe. My intention was that it would only do whatever a Bounce Probe and response could do. It is just an alternative to the 'Bounce Probe and response’ process - especially for people who do not know what a SPAM or JUNK folder is, and/or who are not comfortable with accessing the web / website.

As such, all the explanations of why it would not work, are essentially saying that responding to Bounce Probes do not work. If Bounce Probes do not work..., never mind.

Michael,

As such, all the explanations of why it would not work, are
essentially saying that responding to Bounce Probes do not work.

The key difference is that receiving the bounce probe demonstrates that the member's email address is receiving from Groups.io - that is the whole point.

If the member's email address cannot receive the bounce probe then there's no point in restoring message delivery - they will also bounce.

It is just an alternative to the 'Bounce Probe and response’ process -
especially for people who do not know what a SPAM or JUNK folder is,

If diversion to the Spam folder is a problem for the bounce probe, then it will likely be a problem for the group's messages as well. But diversion to Spam is a different problem, usually with a different cause, than message rejection.

Shal


--
Help: /static/help
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list