Date   

moderated Re: More mod-permission granularity #suggestion

 

On Sat, Feb 8, 2020 at 10:31 AM, J_Catlady wrote:
and member activity logs
typo, they only see that if they have access to the member list - but the rest holds
 
--
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


moderated Re: More mod-permission granularity #suggestion

 

Adding to this: The activity logs (group and member) should also start to have granularity, which should match the moderator viewing granularity that is now in effect or that comes into effect. Currently, every mod sees 100% of the group and member activity logs. Every mod can see when members are rejected and accepted, even if they have no access to the member list or pending member notices. Every mod can see (via the group activity log) the text of every message-rejection notice that any other mod sends out to members. Etc.
--
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


moderated Re: Ad blocker warning #misc

Dave Sergeant
 

On 7 Feb 2020 at 14:46, Mark Fletcher wrote:

The links were
googleadservices.com links, of the type where the text is the same as
the URL itself.
But why were those googleadservices links in ther message in the first
place? Do we presume it was an open group and some spammer had posted
them? Most of us try and avoid these sort of links which is why we have
ad blockers in the first place. Not the sort of thing I would expect
normal posters to have in their messages.

Dave

http://davesergeant.com


moderated Site updates #changelog

 

Changes to the site this week:

  • CHANGE: Standardized on the term member; we used subscriber and user previously. Several tweaks to the group settings page. Changed NuM to NMM.
  • INTERNAL: Much work to support moving from Elasticsearch 5 to Elasticsearch 7, including optimizations for full reindexing.
  • BUGFIX: Introduced and then fixed a bug that caused errors when trying to join a subgroup.
  • CHANGE: The text when creating a group said that new members would be NuM 2, but the group was created with NuM 1. All new groups are now created with NuM 2.
  • API: Removed sub_group_access from /creategroup endpoint.
  • CHANGE: Removed the Create Subgroups dropdown when creating a new group since subgroups are now a premium feature.
  • INTERNAL: Switched from one SSL certificate for all enterprise domains, to individual certs for each domain.
  • BUGFIX: Changed how we sort messages in the Messages/Expanded messages view to use message created date instead of object date, to account for groups that had messages imported that were not strictly date ordered (or that already had messages in the archives).
  • NEW: Rate limiting joining groups and other things to help detect/prevent the mass subscription attacks we were seeing this week.

Have a good weekend everyone.

Mark


moderated Re: Terminology change #update

 

On Fri, Feb 7, 2020 at 3:56 PM Duane <txpigeon@...> wrote:

You didn't catch it on the member record where it says "Override: new user moderated" under Posting Privileges. ;>)

Good catch. Fixed!

Thanks,
Mark 


moderated Re: Main group members struggling to join subgroup #bug

 

Hello,

Yes, this was a bug that I so very thoughtfully introduced on Wednesday as collateral damage from my efforts to deal with the dude who kept trying to subscribe to lots of groups with the bogus yahoo and aol email addresses. It has now been fixed and the offending programmer has been flogged.

Thanks, Mark


moderated Main group members struggling to join subgroup #bug

Bruce Bowman
 

Mark -- GMF members have recently reported difficulties in voluntarily joining an unrestricted subgroup. When they click the "Join this Group" button on the subgroup home page, it forces them to re-enter their email address, and subsequently complains that the address is already registered with groups.io and they need to log in. This occurs even if they are already logged in under the correct address. 

I've confirmed this behavior in my own test group. Unless I'm missing something, it really does seem like a bug.

FYI,
Bruce


moderated Re: Terminology change #update

Duane
 

On Fri, Feb 7, 2020 at 05:49 PM, Mark Fletcher wrote:
Please let me know if you have any questions.
You didn't catch it on the member record where it says "Override: new user moderated" under Posting Privileges. ;>)

Duane


moderated Terminology change #update

 

Hi All,

As part of the writing process for the manual, our tech writer has been suggesting some changes to make things more consistent. In the group settings page, for example, I use the terms users, members and subscribers for the same thing. I've changed them all to members. The only real change other than the group settings page is that the setting formerly known as NuM or new user moderated is now NMM, or new member moderated.

Please let me know if you have any questions.

Thanks, Mark


moderated Re: Ad blocker warning #misc

Duane
 

On Fri, Feb 7, 2020 at 04:46 PM, Mark Fletcher wrote:
The more you know...
We went through something similar almost 5 years ago with the GIO login page, https://beta.groups.io/g/main/topic/47008  My fault that time.

Duane


moderated Ad blocker warning #misc

 

Hi All,

A group owner was having a problem. There were some links in messages that were just not showing up in their browser, both when reviewing pending messages on the website and when viewing the archives on the website. The links were googleadservices.com links, of the type where the text is the same as the URL itself. The links really were in the messages, but the group owner could not see them in their browser. The owner figured out the problem; they were running an ad blocker, and the ad blocker was removing the links.

I would not have been able to figure this out myself. So if you ever come across something like this, it could be an ad blocker.

The more you know...

Mark


moderated Re: sbcglobal.net blocking us #update

West Coast Compañeros Staff
 

Mark & All,

I just received this message from AT&T in response to the complaint I lodged yesterday (2/6/20). I also gave all my AT&T users (att.net, sbcglobal.net, pacbell.net, etc.) some boilerplate text to use to send their own complaints and shared it also with the GMF group. (See https://groups.io/g/GroupManagersForum/message/29053.) I hope AT&T removes the block sooner than 24-48 hours, but I'm glad that they are at least responsive to our complaints. (I've munged the abuse_rbl e-mail address below.)

Robert R.

Thank you for contacting the AT&T Postmaster.

The mail-server IP address(es) associated with your request will be removed from the block list within 24-48 hours from the date of this letter.  AT&T and its affiliates do NOT intentionally block legitimate mail in the course of our anti-spam initiatives and regret any inconvenience this may have caused.  If the IP that was recently blocked begins to exhibit the characteristics of a compromised network object or is compromised by an offender of Acceptable Use Policies, the IP address will be blocked again.

ADMINISTRATORS:  Please thoroughly check your IP logs before requesting removal.  You must determine that all traffic from the blocked IP is actually from your mail servers to ensure your network is not compromised.  Administrators who fail to do this may experience subsequent and more resolute blocking.

Thank you for helping AT&T Internet Services network combat spam in all its forms.

Regards,


AT&T Postmaster
Chief Security Organization
abuse_rbl@ abuse-att.net
https://www.att.com/postmaster/


moderated Re: sbcglobal.net blocking us #update

Jim Wilson
 

There was a post yesterday regarding this discovery on GMF.

The only thing that can be done is to send emails to:

    abuse_rbl AT abuse-att.net <<< (the email address cannot be hot-linked here 🙄)

In your email, you should request that they please whitelist the Groups.io email server, web01.groups.io at 66.175.222.12 because it is a legitimate server used by tens of thousands of users and groups.

The more people who send an email, the sooner it will be resolved, IMHO.

Jim


moderated Re: sbcglobal.net blocking us #update

William Halte
 

Mark, 

My users at prodigy.net are getting the same message as the sbcglobal.net accounts. The error message " ff-ip4-mx-vip1.prodigy.net: 553 5.3.0 flpd575 DNSBL:RBL 521< 66.175.222.12 >_is_blocked.For assistance forward this error to abuse_rbl@...".  I have directed my users to contact AT&T as directed by the message. 

Hopefully, they will be more responsive then Cox.net in fixing the issue.

Bill 


On Thu, Feb 6, 2020 at 11:34 AM Mark Fletcher <markf@corp.groups.io> wrote:
Hi All,

Since yesterday mid-day, sbcglobal.net has been blocking us. I have attempted to contact them, but no response so far. If you are an sbcglobal.net user, I ask that you contact them as well.

Thanks,
Mark


moderated Re: sbcglobal.net blocking us #update

Duane
 

On Thu, Feb 6, 2020 at 12:34 PM, Mark Fletcher wrote:
sbcglobal.net has been blocking us
This also includes the related domains such as att.net  (lots of complaints on GMF about this ;>)

Duane


moderated sbcglobal.net blocking us #update

 

Hi All,

Since yesterday mid-day, sbcglobal.net has been blocking us. I have attempted to contact them, but no response so far. If you are an sbcglobal.net user, I ask that you contact them as well.

Thanks,
Mark


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

 

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


moderated Re: Need for Better Quality Photo Viewing #done

Duane
 

On Thu, Feb 6, 2020 at 10:10 AM, epiplan wrote:
There must have been, originally, a reason to do this, I'd guess to do with bandwidth, but is that reason still valid with today's superfast optical broadband, 5G, unlimited data contracts and cheap data storage?
It's been this way for almost 5 years, https://beta.groups.io/g/main/message/2366  You may have an unlimited, high-speed connection, but not everyone does, including me.  You also need to remember that GIO has to serve these images, so that could be part of the concern.  I'd rather that pictures be a bit distorted in the view mode than to have serious delays when reading/responding to messages.  If I need more detail, which I seldom do, I just select Download.

Duane


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

 

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


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

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