Topics

moderated User-friendly message rejection after attempt to post to a locked thread #suggestion


 

I'm having deja-vu and may have requested this in the past, but if so, I'm repeating the suggestion now after a message I got from a group member yesterday who had tried to post via email to a locked thread:

"my email got destroyed by the locked thread (the “message failed”response spit it back to me with all kinds of code, all chopped up). I’m so upset (also devastated and exhausted). While I love this group, it was always so complicated, difficult, etc"

How hard would it be to send a simple rejection message to the tune of "This topic has been locked" when the topic has been locked, instead of spewing the bounce code back at the person? The member above at least got to the "reason" section of the bounce, but some people don't see it and just email me about their failed attempt to reply to a message.

Thanks and Happy New Year!
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

On Mon, Jan 1, 2018 at 08:33 am, J_Catlady wrote:

How hard would it be to send a simple rejection message to the tune of "This
topic has been locked" when the topic has been locked, instead of spewing the
bounce code back at the person?
The bounce message is created by the member's mail provider. This way (rejection during SMTP session) avoids backscatter thus decreasing chances of blacklisting entire groups.io confusing it with spammers.

https://en.wikipedia.org/wiki/Backscatter_%28email%29


 

But Groups.io does recognize that a thread is locked, just as it recognizes that a thread is moderated. When it’s moderated, it sends the message to pending and let’s a mod act on it, including reject it and send a rejection message. Could groups.io treat a reply to a locked thread as if the thread were moderated and the messsge rejected, and use a canned rejection message to the effect that the thread is locked?

Sent from my iPhone

On Jan 2, 2018, at 12:56 AM, Lena <@Lena> wrote:

On Mon, Jan 1, 2018 at 08:33 am, J_Catlady wrote:

How hard would it be to send a simple rejection message to the tune of "This
topic has been locked" when the topic has been locked, instead of spewing the
bounce code back at the person?
The bounce message is created by the member's mail provider. This way (rejection during SMTP session) avoids backscatter thus decreasing chances of blacklisting entire groups.io confusing it with spammers.

https://en.wikipedia.org/wiki/Backscatter_%28email%29


--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

In other words, I’m suggesting not bouncing the message at all. Just catch it and send it back nicely, as with a moderated thread.

Sent from my iPhone

On Jan 2, 2018, at 3:22 AM, J_Catlady <@J_Catlady> wrote:

But Groups.io does recognize that a thread is locked, just as it recognizes that a thread is moderated. When it’s moderated, it sends the message to pending and let’s a mod act on it, including reject it and send a rejection message. Could groups.io treat a reply to a locked thread as if the thread were moderated and the messsge rejected, and use a canned rejection message to the effect that the thread is locked?

Sent from my iPhone

On Jan 2, 2018, at 12:56 AM, Lena <@Lena> wrote:

On Mon, Jan 1, 2018 at 08:33 am, J_Catlady wrote:

How hard would it be to send a simple rejection message to the tune of "This
topic has been locked" when the topic has been locked, instead of spewing the
bounce code back at the person?
The bounce message is created by the member's mail provider. This way (rejection during SMTP session) avoids backscatter thus decreasing chances of blacklisting entire groups.io confusing it with spammers.

https://en.wikipedia.org/wiki/Backscatter_%28email%29



--
J



Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


Bob Bellizzi
 

It would seem that a Reply to the message e.g. "We're sorry but that thread is locked." would seem to be fairly simple.

--

Bob Bellizzi

Founder, Fuchs Friends ®
Founder & Executive Director, The Corneal Dystrophy Foundation


 

On Tue, Jan 2, 2018 at 11:00 am, Bob Bellizzi wrote:
It would seem that a Reply to the message e.g. "We're sorry but that thread is locked." would seem to be fairly simple.
Lena is implying (I think) that there's a technical issue with this because the message is bounced. She's way more savvy than me as far as email technicalities, but I'm not sure an attempted message to a locked topic has to be bounced. If there is actually some technical issue, I'm suggesting a workaround of eliminating "locked topic" internally, at least with respect to replies via email, and treat a locked topic as special case of a moderated topic for which all replies are rejected. 
 
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

On Tue, Jan 2, 2018 at 11:08 AM, J_Catlady <j.olivia.catlady@...> wrote:
On Tue, Jan 2, 2018 at 11:00 am, Bob Bellizzi wrote:
It would seem that a Reply to the message e.g. "We're sorry but that thread is locked." would seem to be fairly simple.
Lena is implying (I think) that there's a technical issue with this because the message is bounced. She's way more savvy than me as far as email technicalities, but I'm not sure an attempted message to a locked topic has to be bounced. If there is actually some technical issue, I'm suggesting a workaround of eliminating "locked topic" internally, at least with respect to replies via email, and treat a locked topic as special case of a moderated topic for which all replies are rejected. 
 

Yes, Lena's correct about backscatter.

Overview: If someone emails us a message that we aren't going to accept, for whatever reason, we need a way to tell them that. There are two ways to do so. The first way, which is what we do, is to not actually accept the email, and instead return to the sending server an error message. The other way is to accept the email from the sending server, then throw that email away and generate a new email with the error message and send it to the person who sent the message in the first place. This makes for much nicer looking error messages, but can be abused by spammers in a process called backscatter.

The problem, at least with Gmail, is that they display horrible error messages when we don't accept a message. They do display the error that we return to them, but it's surrounded by all sorts of scary/misleading text. It's a bad experience all around.

I have played around with different error codes and messages to try to get Gmail to display something nicer. The best I can do is if I prepend "5.1.1 The email account that you tried to reach does not exist." to any error message, it will display something like "That account doesn't exist or isn't accepting email". So, you end up with errors like : "5.1.1 The email account that you tried to reach does not exist. Your email address, markf@blahblah, is not subscribed to that group. To subscribe, send an email to....."

Surprisingly, Yahoo Groups still accepts all emails and generates and sends out new error emails. We did that back in the day because of technical reasons (it was originally based on qmail, which accepts all messages). I would have thought they would have changed that by now because of backscatter.

So, I don't know what to do. To generate nice errors, we risk backscatter. And I don't know how much of a risk that is.

Thanks,
Mark


 

Mark,

I am suggesting handling a rejected message differently *only in the case of a locked thread*, not in the case of a general bounce. I understand the need to reject a message without letting it go through the system in the general case, but when a thread has been locked, that seems to me, at least naively, to be a completely distinct situation, more akin to a rejected message when the member or the thread is on moderation, with no danger of spammers. Why can't that case be treated differently? I don't understand the danger from spammers in that case. And the poor group members receiving these nasty bounce messages back are flummoxed. They don't understand the message (*even though* the term "locked topic" appears way down in the fine print) and they don't understand what they did wrong, and they start reporting "bugs" to me etc. It is nasty. Treat spammers that way, but do we need to treat group members that way? I am still missing something... 

--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

J,

I understand the need to reject a message without letting it go
through the system in the general case, but when a thread has been
locked, that seems to me, at least naively, to be a completely
distinct situation, more akin to a rejected message when the member or
the thread is on moderation, with no danger of spammers.
Part of the difference is the human judgement involved in a rejection. A moderator is unlikely to send a note back to a spammer. And even much less likely to do so more than a few times to the same spammer.

If the from address of the message is forged (spoofed) then those rejection notices would be a form of backscatter. But because they are generated by a human they are likely to be limited in number. Not so an automated response. If a spammer can effectively send you a message by forging your address to a message that will be sent on to you (in the form of a rejection notice) by Groups.io then that's the kind of backscatter that could get out of hand, which is what Mark is trying to avoid.

Shal


Glenn Glazer
 

So, I am also in the camp of making the message more human friendly. I understand HTTP status codes and so on, but only a tiny fraction of my group members do and they find the bounce message frightening, as Mark noted. 

I have two alternatives to suggest:

  1. As a slight modification to the alternative Mark describes, if a message is from member in group, send back new email with nice message, else drop on the floor. 
  2. Have an option that messages that go to locked threads go to a moderation queue and the humans can determine what is backscatter and what gets a nice message.

I realize that 1. risks backscatter, but until there is evidence of such, there is no way to evaluate that risk and it just may be a case of being too timorous.

A bonus to 2. is that each group could design its own lock message as a preference.

Best,

Glenn


Sarah k Alawami
 

I'm in favor of option 2 personally. I'd rather hold the messages then either reject them all, or maybe let one or 2 through, or not depending on the case.

Sarah Alawami, owner of TFFP. . For more info go to our website.
For stuff we sell, mac training materials and  tutorials go here.
and for hosting options go here
to subscribe to the feed click here

The listen page is found here

Our telegram channel is also a good place for an announce only in regard to podcasts, contests, etc.

Finally, to become a patron and help support the podcast go here

On 22 Apr 2019, at 16:09, Glenn Glazer wrote:

So, I am also in the camp of making the message more human friendly. I understand HTTP status codes and so on, but only a tiny fraction of my group members do and they find the bounce message frightening, as Mark noted. 

I have two alternatives to suggest:

  1. As a slight modification to the alternative Mark describes, if a message is from member in group, send back new email with nice message, else drop on the floor. 
  2. Have an option that messages that go to locked threads go to a moderation queue and the humans can determine what is backscatter and what gets a nice message.

I realize that 1. risks backscatter, but until there is evidence of such, there is no way to evaluate that risk and it just may be a case of being too timorous.

A bonus to 2. is that each group could design its own lock message as a preference.

Best,

Glenn


 

Glenn,

1. ... if a message is from member in group, send back new email with
nice message, else drop on the floor.
If the message is from a non-subscriber it should be given an error at connection time (not accepted then dropped) using the existing error code/text for non-subscriber messages -- unless the group is set to allow non-subscriber posts.

If the group is set to allow them, then a message to a locked topic from a non-subscriber should be handled the same as one from a member.

I realize that 1. risks backscatter, but until there is evidence of
such, there is no way to evaluate that risk and it just may be a case
of being too timorous.
This belongs in a different topic, but I've come to believe that Groups.io ought to be doing DMARC-like authentication on inbound group postings and email commands before accepting them. That would (I think) eliminate the risk of backscatter were Groups.io to accept the message and separately send back a "nice" error message.
https://beta.groups.io/g/main/topic/24836368#18077

2. Have an option that messages that go to locked threads go to a
moderation queue and the humans can determine what is backscatter
and what gets a nice message.
This seems to me to be the same as moderating the topic, rather than locking it.

Shal


 

On Tue, Apr 23, 2019 at 12:50 AM, Shal Farley wrote:
2. Have an option that messages that go to locked threads go to a
moderation queue and the humans can determine what is backscatter
and what gets a nice message.
This seems to me to be the same as moderating the topic, rather than locking it.
I still have not heard what's infeasible about my original suggestion, which is to treat locked topics as moderated topics but wherein all posts are rejected automatically by the system and sent a canned "this subject is locked" rejection notice. 
 
--
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,

I still have not heard what's infeasible about my original suggestion,
Read back through the topic for the word "backscatter", starting with Lena's message of 2018-01-02.

Automatically sending back a message runs the risk of allowing spammers to deliberately trigger this response, targeting group members.

Shal


 

On Tue, Apr 23, 2019 at 10:44 PM, Shal Farley wrote:
Automatically sending back a message runs the risk of allowing spammers to deliberately trigger this response, targeting group members.
Shal,

Ok, I read Lena's message about backscatter, and yours explaining it, and I am missing something. It seems unrealistic/overly pessimistic to assume that spammers would somehow find and send messages to locked topics. Even if they were somehow able to do that (which could only occur in unrestricted groups anyway), how would this "target group members"? Do you mean they would spoof various group members' email addresses in order to connivingly and deliberately send messages to locked topics in their name, just so that the group members would get the rejection message? I considered myself cynical, but even I am not as cynical as that. Or perhaps I'm actually overly naive and trusting. :)
 
--
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


Brian Vogel <britechguy@...>
 

Being someone who deals with spam management on a daily basis, I have to say that I find the idea that spammers would do what is proposed highly, very highly, unlikely.

It's not something that would be of any value to them in any way I can think of.  They want their message out there, and no matter what they'd get back from trying to e-mail to a locked thread if it isn't a posted message they'd almost certainly move on.   Spam is a "drive by" activity using the broadest and quickest scatter and run methods possible.

When they get a rejection message they move along.
--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


 

J,


Do you mean they would spoof various group members' email addresses in order to connivingly and deliberately send messages to locked topics in their name, just so that the group members would get the rejection message?

That is the scenario, as I understand it. Rejection notices typically contain a copy of the rejected message, in this scenario that would be the payload.


I considered myself cynical, but even I am not as cynical as that.

It is a concern (as Mark said), not a proven threat that I know of.

I admit it does seem far-fetched that a miscreant would put together the pieces necessary to exploit this particular suggestion. Perhaps ironically beta itself seems like one of the juicier targets because it has public archives, unrestricted membership, and (formerly) generous use of thread locking; yet even so it seems unlikely to me. However, once someone figures it out history has shown us that the dark corners of the internet are pretty good at sharing "how-to" info and packaged scripts to exploit anything they can.

Shal


Glenn Glazer
 

On 4/24/2019 08:32, Shal Farley wrote:
I admit it does seem far-fetched that a miscreant would put together the pieces necessary to exploit this particular suggestion.

This I agree with. And furthermore, the way around all of the speculation is to make it a feature that individual groups can turn on or off as a preference. So, for those groups for whom it works and want this, great and if some spammer is attacking a group, they can turn it off temporarily or permanently without impairing the usage by other groups.

The same holds true, incidentally, of my other suggestion to send it a queue, by which I meant a different queue than the regular moderation queue. The idea would be that it would be easier in a separate queue to select all and send the group's customized locked thread message than to have to pick them out of the general moderation queue.

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


Brian Vogel <britechguy@...>
 

This also ties in, and pretty directly, with another feature request I made:  Hide Topic Function

The need to hide a topic, per se, is separate from this topic.  But the fact that one cannot delete a topic after locking it, and having it remain somehow stored by Groups.io as locked, without any trace of it being visible to anyone is not.

Locked topics should not only be able to have some sort of "human comprehensible" message of the "You can't post to this topic because it's locked" nature sent out, but if one locks a topic there should be a "locked list" maintained even if the topic itself is deleted afterward.   Locked is locked, and should not be volatile based on the presence or absence via deletion of the material that triggered a topic to be locked in the first place.

While I'd like to have the capability to hide a topic for its own sake, when it comes to locked topics that I wish to have purged from the archive I'd far rather do that than hide it just so that no one can post to it again.

It strikes me as entirely feasible (and I may be wrong) to maintain a history of all locked topics for a group, even if said topic were subsequently deleted, so that "late entries" cannot revive it from the dead when replying to it.   I know individuals can create a separate topic to try to revive or extend something, but that is taken care of by the moderators making clear that it will not be tolerated and immediately locking the revival attempt.  (Then, if I had the option, deleting it if it would keep it locked, or at the very least hiding it to keep it out of the archive view).

--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel


Leeni
 

Just an added side note about lock topics while you can't delete them, you also can't start a new message from an email if your email has the same subject line as the locked messages.
 
Example: My groups are Creative Design groups
Graphics are shared
A member starts a topic and the subject line reads Easter Eggs and that topic is auto locked after one day.
 
Now another member a couple days later shared Easter Eggs and names their subject Easter Eggs.
 
Their email would be rejected saying that the subject is locked.
 
Leeni
 
 
 
 
 

-------Original Message-------
 
Date: 4/24/2019 12:31:45 PM
Subject: Re: [beta] User-friendly message rejection after attempt to post to a locked thread #suggestion
 
This also ties in, and pretty directly, with another feature request I made:  Hide Topic Function

The need to hide a topic, per se, is separate from this topic.  But the fact that one cannot delete a topic after locking it, and having it remain somehow stored by Groups.io as locked, without any trace of it being visible to anyone is not.

Locked topics should not only be able to have some sort of "human comprehensible" message of the "You can't post to this topic because it's locked" nature sent out, but if one locks a topic there should be a "locked list" maintained even if the topic itself is deleted afterward.   Locked is locked, and should not be volatile based on the presence or absence via deletion of the material that triggered a topic to be locked in the first place.

While I'd like to have the capability to hide a topic for its own sake, when it comes to locked topics that I wish to have purged from the archive I'd far rather do that than hide it just so that no one can post to it again.

It strikes me as entirely feasible (and I may be wrong) to maintain a history of all locked topics for a group, even if said topic were subsequently deleted, so that "late entries" cannot revive it from the dead when replying to it.   I know individuals can create a separate topic to try to revive or extend something, but that is taken care of by the moderators making clear that it will not be tolerated and immediately locking the revival attempt.  (Then, if I had the option, deleting it if it would keep it locked, or at the very least hiding it to keep it out of the archive view).

--

Brian - Windows 10 Pro, 64-Bit, Version 1809, Build 17763  

     Presenting the willfully ignorant with facts is the very definition of casting pearls before swine.

              ~ Brian Vogel