Topics

moderated A 554 Bounce code not recognized as bouncing on first occurrence #bug #fixed


 

On Sun, Feb 9, 2020 at 10:49 PM, J_Catlady wrote:
you also needed four in a row,
Meaning, four in a row of the "one bounce within every consecutive four days"
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

On Sun, Feb 9, 2020 at 10:44 PM, JediPirx wrote:
The dates of the bouncing events
were spread out over months, not consecutive days
The bounce days don't have to be consecutive. They just have to satisfy the conditions I mentioned. But yeah, that's basically the reason. The bounces were too spread out. You'd get a couple that satisfied "at least one bounce within every consecutive four days," but you also needed four in a row, and you never got four in a row so it would go back to square one and start recounting.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


JediPirx
 

Thank you for the explanation. The dates of the bouncing events
were spread out over months, not consecutive days so conditions
were not met, as you have stated.

Stan/jp

-----------------------------------------------------------------

Subject : Re : [beta] A 554 Bounce code not recognized as
bouncing on first occurrence #bug #fixed
Date : Wed, 05 Feb 2020 14:51:52 -0800
From : J_Catlady <@J_Catlady>
To : main@beta.groups.io

On Wed, Feb 5, 2020 at 02:30 PM, JediPirx wrote:

Why did GIO not flag these 10 users/email addresses last year ?
I do not know.

Because the conditions back then for setting a member to "bouncing"
were not satisfied. You need either a hard bounce, or at least one soft
bounce within every consecutive four consecutive days after the first
soft bounce, plus at least four soft bounces total, for the member to
be flagged as bouncing. Those are all 554.30 codes in what you posted,
and they did not (until the recent bug fix) count as a hard bounce. So
you needed other condition. Looking quickly through the dates in your
example (and bear in mind I'm looking quickly), it does not seem that
the bouncing dates conditions were satisfied.

If the above were to happen today, the member would be set to
"bouncing" because 554 now qualifies as a hard bounce and you
would not need all those date conditions.


 

Duane,

Or in other words, according to what you wrote, the probe bounces are possibly not *supposed* to be tracked in the Activity Log; but the experience now (the bug I'm bringing up) is they are currently, for whatever reason, actually triggering  "is bouncing" entries there.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

On Thu, Feb 6, 2020 at 09:34 AM, Duane wrote:
The bounces of the probes wasn't logged in the Activity Log, but was logged in the member's Email Delivery History as of July/August last year.
Thanks for the sanity check. I remember someone having requested that they be tracked, and tracking bouncing of the probes could indeed be very useful (as I just wrote in the separate thread about this specific situation, separate from 554). I think the Activity Log tracker did not, before that change, have to worry about being triggered for further bounces until the probes themselves started being tracked, because there were no furhter bounces *of group messages* (since none are sent). But that could be exactly the problem: now that the probes themselves are handled by the bounce system, an "is bouncing" status gets triggered for them, too. 
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Duane
 

On Thu, Feb 6, 2020 at 10:58 AM, J_Catlady wrote:
If I recall the ancient history correctly (and I may not), bouncing of bounce probes themselves did not used to be tracked/logged.
Based on my limited investigation, you're partially correct.  The bounces of the probes wasn't logged in the Activity Log, but was logged in the member's Email Delivery History as of July/August last year.

Duane


 

John et al,

I'd already started a separate topic for the multiple "is bouncing" entries bug. I just posted an update in it, but I'll repeat quickly here and then move over there from now on: After an account is marked as Bouncing, the system stops sending group emails to it. The subsequent multiple "is bouncing" log entries I/we are seeing are due to bounce probes themselves bouncing. If I recall the ancient history correctly (and I may not), bouncing of bounce probes themselves did not used to be tracked/logged. And as long as they weren't, the "is bouncing" trigger did not have to be checked for subsequent messages, because there were none. But with the probes themselves being tracked by the bounce system, I think the trigger should be calmed to not activate for a bounce probe message.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

On Thu, Feb 6, 2020 at 04:55 AM, Chris Jones wrote:
in most if not cases recently examined the "554.30 account disabled" report is always accompanied by a total lack of "recent" activity, where there is no sign of any posts having been made in the last 5 years or even more
Exactly. It's been very useful in finding these cases.
And yes, as you say, the issue is the contiguous list of bounces, but not recorded as bounces: recorded (erroneously) as bounce-status changes.
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

You also certainly do not want a log entry for every message a member bounces. That would be an unholy mess. The “is bouncing” should really only be logged when the account’s status changes to Bouncing. And that is the bug: instead, it is logged repeatedly.


On Feb 6, 2020, at 6:34 AM, J_Catlady via Groups.Io <j.olivia.catlady@...> wrote:

ps Rhe reason I say there has been no status change is that there are no intervening entires “x is no longer bouncing.” Granted thst in itself could be a logging bug (I.e., the account did unbound but was not logged), but it doesn’t appear to be.


On Feb 6, 2020, at 6:26 AM, J_Catlady via Groups.Io <j.olivia.catlady@...> wrote:

John,

I agree with you on the general principle of the log entry. But I think the problem is with the language of the entry. “X is bouncing” implies a change in status when there has been no change. So I find it extremely misleading. 

The solution is either to ditch the log entry once the account has already been marked as bouncing, or change subsequent entries after the actual status change to indicate that the account has just bounced another messsge. But because if the complications with and definitions of the Bouncing status, I would favor simply not logging subsequent bounces. I think it could be tricky.


On Feb 6, 2020, at 4:17 AM, John Pearce <jponsalt@...> wrote:

It is great that this has been set for a hard bounce.  I hate going through the group one by one to inspect the mail history.  I have to be honest, I'm still not clear on the anomaly you are referring to.  Probably because I see only what appears to be logical to me.  One bounce, one user mail history activity log entry, and one group activity log entry.  Per bounce and continues to log them each bounce, even when a person is already marked as B and the following bounces continue to log either from a bounce probe or maybe a new message from the group.  This seems logical to me that both logs contain an entry.  Updating the user mail history without a log entry once a person is already a B seems to unnecessarily complicate the code required from Mark.  And some people would think, hey, there's something wrong here, there's no entry in the group activity log!  Depends on how your mind works.  As a life long operating systems programmer on large scale IBM computers (since the 70's) I hate to see things complicated for very thin reasons even though they are valid.

J

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

ps Rhe reason I say there has been no status change is that there are no intervening entires “x is no longer bouncing.” Granted thst in itself could be a logging bug (I.e., the account did unbound but was not logged), but it doesn’t appear to be.


On Feb 6, 2020, at 6:26 AM, J_Catlady via Groups.Io <j.olivia.catlady@...> wrote:

John,

I agree with you on the general principle of the log entry. But I think the problem is with the language of the entry. “X is bouncing” implies a change in status when there has been no change. So I find it extremely misleading. 

The solution is either to ditch the log entry once the account has already been marked as bouncing, or change subsequent entries after the actual status change to indicate that the account has just bounced another messsge. But because if the complications with and definitions of the Bouncing status, I would favor simply not logging subsequent bounces. I think it could be tricky.


On Feb 6, 2020, at 4:17 AM, John Pearce <jponsalt@...> wrote:

It is great that this has been set for a hard bounce.  I hate going through the group one by one to inspect the mail history.  I have to be honest, I'm still not clear on the anomaly you are referring to.  Probably because I see only what appears to be logical to me.  One bounce, one user mail history activity log entry, and one group activity log entry.  Per bounce and continues to log them each bounce, even when a person is already marked as B and the following bounces continue to log either from a bounce probe or maybe a new message from the group.  This seems logical to me that both logs contain an entry.  Updating the user mail history without a log entry once a person is already a B seems to unnecessarily complicate the code required from Mark.  And some people would think, hey, there's something wrong here, there's no entry in the group activity log!  Depends on how your mind works.  As a life long operating systems programmer on large scale IBM computers (since the 70's) I hate to see things complicated for very thin reasons even though they are valid.

J

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

John,

I agree with you on the general principle of the log entry. But I think the problem is with the language of the entry. “X is bouncing” implies a change in status when there has been no change. So I find it extremely misleading. 

The solution is either to ditch the log entry once the account has already been marked as bouncing, or change subsequent entries after the actual status change to indicate that the account has just bounced another messsge. But because if the complications with and definitions of the Bouncing status, I would favor simply not logging subsequent bounces. I think it could be tricky.


On Feb 6, 2020, at 4:17 AM, John Pearce <jponsalt@...> wrote:

It is great that this has been set for a hard bounce.  I hate going through the group one by one to inspect the mail history.  I have to be honest, I'm still not clear on the anomaly you are referring to.  Probably because I see only what appears to be logical to me.  One bounce, one user mail history activity log entry, and one group activity log entry.  Per bounce and continues to log them each bounce, even when a person is already marked as B and the following bounces continue to log either from a bounce probe or maybe a new message from the group.  This seems logical to me that both logs contain an entry.  Updating the user mail history without a log entry once a person is already a B seems to unnecessarily complicate the code required from Mark.  And some people would think, hey, there's something wrong here, there's no entry in the group activity log!  Depends on how your mind works.  As a life long operating systems programmer on large scale IBM computers (since the 70's) I hate to see things complicated for very thin reasons even though they are valid.

J

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Chris Jones
 

On Thu, Feb 6, 2020 at 12:17 PM, John Pearce wrote:
I'm still not clear on the anomaly you are referring to
Unless I am much mistaken (always possible!) the anomaly is that while the individual member's Email Delivery History appears to be correct the group - wide Activity log can show a contiguous list of several bounces for the same member that cannot be correlated with message traffic within the group.

I haven't looked to see if this phenomenon is apparent on any member subscriptions that are set to Special Messages only or if it can also occur with those with less restricted settings.

If I get the chance I might try a further analysis later, but as I said previously my main references are the individual's Activity and Email Delivery logs; as it would be perfectly normal to have Special Notices only as a setting if the person concerned interacted with a group (or groups, plural) using the web UI. If I found a member with a serious bounce problem but with evidence of recent posting activity my initial instinct would be to leave the membership in place and try to investigate further.

That said in most if not cases recently examined the "554.30 account disabled" report is always accompanied by a total lack of "recent" activity, where there is no sign of any posts having been made in the last 5 years or even more.

Chris


John Pearce
 

It is great that this has been set for a hard bounce.  I hate going through the group one by one to inspect the mail history.  I have to be honest, I'm still not clear on the anomaly you are referring to.  Probably because I see only what appears to be logical to me.  One bounce, one user mail history activity log entry, and one group activity log entry.  Per bounce and continues to log them each bounce, even when a person is already marked as B and the following bounces continue to log either from a bounce probe or maybe a new message from the group.  This seems logical to me that both logs contain an entry.  Updating the user mail history without a log entry once a person is already a B seems to unnecessarily complicate the code required from Mark.  And some people would think, hey, there's something wrong here, there's no entry in the group activity log!  Depends on how your mind works.  As a life long operating systems programmer on large scale IBM computers (since the 70's) I hate to see things complicated for very thin reasons even though they are valid.

J


 

On Wed, Feb 5, 2020 at 02:30 PM, JediPirx wrote:
Why did GIO not flag these 10 users/email addresses last year ?
I do not know.
Because the conditions back then for setting a member to "bouncing" were not satisfied. You need either a hard bounce, or at least one soft bounce within every consecutive four consecutive days after the first soft bounce, plus at least four soft bounces total, for the member to be flagged as bouncing. Those are all 554.30 codes in what you posted, and they did not (until the recent bug fix) count as a hard bounce. So you needed other condition. Looking quickly through the dates in your example (and bear in mind I'm looking quickly), it does not seem that the bouncing dates conditions were satisfied.

If the above were to happen today, the member would be set to "bouncing" because 554 now qualifies as a hard bounce and you would not need all those date conditions.


 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


JediPirx
 

I would just like to squeeze in some more data to this topic to
show it is not just related to users with special-notice delivery,
as well as other observations.

For me, the bounce code seems to be working.

Stan/jp/elgio

--------------------------------------------------------------------

Transfer of my group from YG to GIO occurred on Thu 2019/11/14.

In 2019 there were 2 occurrences of multiple bounces : 14 Yahoo
email addresses on Fri 2019/11/15, and 118 Yahoo email addresses
on Wed 2019/11/20. Since then, quiet.

Looking at Admin-->Activity logs last week, 10 users started
bouncing as of Jan 30, 2020. These were triggered initially by
messages I posted followed by bounce probes.

Of the 10 users, 9 have email addresses on yahoo.com and 1 has an
email address on yahoo.co.uk. Basically, all Yahoo. Of the 10 users,
6 have Single-Delivery set, and 4 have Full-Digest-Delivery set.
The oldest account is from 2003-07-03 and the newest is from
2018-06-09

Then looking at the Email Delivery History for each user, multiple
entries were seen dating back to Sat 2019-11-16, just 2 days after
my group arrived in GIO. Here is the Email Delivery History for
one such user, the remaining users are the same.

Why did GIO not flag these 10 users/email addresses last year ?
I do not know. The accounts were already disabled by Yahoo in
2019.

--------------------------------------------------------------------

05:17 Bounce probe mta7.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4032.mail.ne1.yahoo.com

Jan 31 Digest #9 mta6.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4308.mail.bf1.yahoo.com

Jan 23 Digest #8 mta5.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4393.mail.ne1.yahoo.com

Jan 21 Digest #7 mta6.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4390.mail.bf1.yahoo.com

Jan 1 Digest #6 mta7.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4222.mail.gq1.yahoo.com

2019-12-28 Digest #5 mta6.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4356.mail.gq1.yahoo.com

2019-12-09 Digest #4 mta5.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4223.mail.ne1.yahoo.com

2019-11-20 Digest #3 mta5.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4312.mail.bf1.yahoo.com

2019-11-19 Digest #2 mta5.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4222.mail.bf1.yahoo.com

2019-11-16 Digest #1 mta6.am0.yahoodns.net: 554 delivery error:
dd Sorry, your message to <...>@yahoo.com cannot be delivered.
This mailbox is disabled (554.30). - mta4078.mail.bf1.yahoo.com


 

On Wed, Feb 5, 2020 at 08:58 AM, Chris Jones wrote:
I think I have seen these anomalous Activity log entries prior to the recent bugfix.
Exactly right. The bug (of multiple "is bouncing" log entries) pre-existed, but I only see it manifested now because of the fact that this special-notice member was finally noted as bouncing because of the 554 finally categorized as a hard bounce. 
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Chris Jones
 

On Wed, Feb 5, 2020 at 08:59 AM, I wrote:
I'm not currently aware of any "anomalies" but I'll have a closer look later; for the moment other off - line activities have to take precedence!
Off - line activities completed (for now!) I have had a more detailed look and now think I have seen the anomalous Activity log entries mentioned; they only seem to arise for a very small number of bouncing members, manifesting as a greater number of recorded bounces than group traffic can account for.

As it happens I do not use the Activity log entries as part of the weeding process, relying on the member's activity and email delivery records as the guiding factors in whether or not to delete them from the group.

Also (FWIW) I think I have seen these anomalous Activity log entries prior to the recent bugfix.

Chris


 

John,

You are right. There's one 554 for the group guidelines, and three for bounce probes. So the log entries are not, as I formerly suspected, coming from other groups. They are coming from the bounce probes themselves.

So although my bug report still stands in that I don't think separate log entries "is bouncing" should be created once the member is already blue "B," the underlying reason I guessed for the multiples (group guidelines from multiple groups) is incorrect. I am seeing more or less what you are seeing in the email delivery history, except that there are more bounce probes in my member's case, probably because I sent one by hand.

I'll go into my bug report thread and correct this.

Thanks.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


 

On Wed, Feb 5, 2020 at 08:27 AM, John Pearce wrote:
Are these from Yahoo
Yes
does is say 554.30 This mailbox is disabled
Yes

So any bounces previous to the fix did not show up in the bouncing member list as the frequency of once a month was not enough to trigger bounce processing.
Exactly, and that's why this is showing up only now. The multiples are probably because it was the first of the month and group guidelines are sent out on that date, mostly as special notices, and she is a special-notice member in my group (and probably the others). 

Then the frequency is reset because there were not enough bounces within a few days.  So they would never have gotten the blue "B" in the first place.  That is the change, that they show up with a blue B now and are placed in actual bounce status

Yes. I am intimately familiar with the bounce handler. All of that is correct, and that's why only now does the member show up (finally) as bouncing, despite month upon month of these bounces. Too much time in between.

I've sent a bug report, which you may have already seen. I think the bug, finally recognized only now because of the "perfect storm" of 554 bug fix and monthly group guidelines, is that the bounce handler should not create a new log entry in a group "is bouncing" if the member is already marked as bouncing there.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


John Pearce
 

Are these from Yahoo and does is say 554.30 This mailbox is disabled?  Remember this bounce code from yahoo indicates that the yahoo account has not been used for at least 1 year.  So any bounces previous to the fix did not show up in the bouncing member list as the frequency of once a month was not enough to trigger bounce processing.  Then the frequency is reset because there were not enough bounces within a few days.  So they would never have gotten the blue "B" in the first place.  That is the change, that they show up with a blue B now and are placed in actual bounce status where before they did not.  You should give us some cut and pastes so we can see what you are seeing.  Here is what I get for a member.  Note on the 1st there are two.  One for the message and one for the bounce probe.  The member activity log and the group activity log both match what you see below.


Feb 4 Bounce probe mta6.am0.yahoodns.net: 554 delivery error: dd Sorry, your message to xyz@... cannot be delivered. This mailbox is disabled (554.30). - mta4045.mail.bf1.yahoo.com
Feb 1 Bounce probe mta6.am0.yahoodns.net: 554 delivery error: dd Sorry, your message to xyz@... cannot be delivered. This mailbox is disabled (554.30). - mta4153.mail.ne1.yahoo.com
Feb 1 [maganak] Group Guidelines mta7.am0.yahoodns.net: 554 delivery error: dd Sorry, your message to xyz@... cannot be delivered. This mailbox is disabled (554.30). - mta4277.mail.bf1.yahoo.com