locked Re: How does groups.io deal with "bouncing members"?


On Tue, Oct 21, 2014 at 4:01 PM, Shal Farley <shal@...> wrote:

I'm curious about the cases you find uncertain.

We get bounces two ways. One is during the SMTP transaction, when we're sending the email out. The receiving email server responds with a non-2xx error code. Those are easy enough to parse; we have a status code and (generally) one line of reason. Anything non-5xx we treat as soft. For 5xx bounces, we have a few patterns we match against to determine if it's really a hard bounce. If we get a match (ie. Yahoo will return 'This user doesn't have a yahoo.com account'), we treat it as a hard bounce. Everything else, soft (and we log it for later analysis and inclusion in the match patterns).

The other case where we receive bounces are (some time) after a successful SMTP transaction is complete, we get the message sent back to us, using the envelope address. Those are the difficult ones to parse, because there's really no widely used standard.

Because I had no examples of modern bounces from the second scenario when developing the bounce system, we currently treat all bounces received that way as soft bounces, and we log the messages for later examination. And up to now, we've received no bounces this way. I'm actually not sure how many mail servers operate this way anymore.

> If we receive soft bounces for someone for 8 days, we also change
> their status to Bouncing and stop sending email to them.

In the case of an RBL problem the member may be having some fraction of the messages bounced, and the rest delivered. How does your mechanism work in such a case? Is a single bounce in each of eight consecutive days sufficient to change the status, or does it require eight days with all messages bounced, or something in between?

Right now, it's 8 consecutive days of all bounces. A single success resets things. I don't know if this is the right solution. Thoughts?

> If we receive no response after sending 4 of these bounce reports to
> them, we automatically unsubscribe them from all groups they are
> subscribed to.

If such an address happens to be the sole owner of a group, what happens to the group (if anything)?

We have a constraint such that the sole owner of a group cannot be unsubscribed from the group, so nothing would happen (at some point a mechanism will need to be developed for instances when group owners disappear/etc, but with the service being so young right now, it's not a priority).


Join main@beta.groups.io to automatically receive all group messages.