Hi,

I would really appreciate an option that triggers a notification to group owners and moderators each time a file or a photo is uploaded.

Is it possible to have this programmed?

Victoria

Mark -- Just reporting on a possible system bug.

A poster on GMF recently used the [relatively new] "Account Merge" function, with an owner email address as the "from" account. In so doing inadvertently left two of her groups without an owner. I know there is a safeguard to keep this from happening with the "Account Delete" function but it seems that this safeguard has not been carried over into merge.

I've suggested that she send you a separate note at support but I felt I would mention it here as well.

Thanks,
Bruce

On Mon, May 14, 2018 at 04:28 pm, Mark Fletcher wrote:

But now, you can also export the activity logs. It's a HTML file, one log entry per line.

Could the exported activity log include a date/timestamp for each entry?

I realize that doing so might require using a different format from HTML or at least inserting a delimiter of some kind.

Thanks,
Bruce

So, with both options enabled (below) which one rules in case of opposite selections by Group owner and account owner?
And, by account owner do you mean Subscription owner (for a single group) or Account owner (which is the base account of a person at groups.io?

--

Bob Bellizzi

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

On Tue, May 15, 2018 at 09:28 am, Mark Fletcher wrote:

It was a different issue, involving the activity log export. It's been fixed and I generated an export for your group.

Yes, I have it now. Thanks!

Bruce

Currently, numbers in a column get sorted as if they were alpha characters.  I'd think a column type of 'numeric' could fix that.

I'm far from certain that Photo Albums always being listed by creation date would actually be of much help; it certainly wouldn't have been of any help on the Group that I Moderate, because each album - having been somewhat randomly named by its originator - rarely bore any relationship to its contents. (You might be lucky and not have this problem!) Listing by creation date would also not address the problem of someone adding to an existing album, resulting in some material in that album being much more recent than the album itself.

We had a (major?) problem when we migrated from Yahoo in that our Files and Photos total exceeded the 1GB allowance, so some rapid deletions were required to make some room. Since then I have been right though both sections trying to rationalise their contents, with most if not albums being renamed so that their name reflected what was actually in them, and also making sure that "like material" was in one album, not spread over a number of different albums. (Again your requirements may differ.) I was surprised just how much space I released by deleting duplicate and near - duplicate material.

What would really have been helpful would have been the ability to move photos between albums without having to download them and then upload them again to a different Album; apart from being more than a little tedious this also removes the attribution of each photo thus moved, and more work is required to make sure (insofar as it is practicable) that the originator's name is mentioned in the accompanying text. (Moving Files between Folders in the Files section is easy; the means of moving them is made available.)

I put this up as a suggestion, and it seemed that others supported it, but I have no idea whether Mark has put it on his "to do" list, much less where on that list it might be; there are a lot of competing priorities.

With there being nothing to prevent group members naming Albums (or Files) as they wish it seems to me that it is more or less inevitable that both Photos and Files sections will become more and more chaotic as time passes, unless Group Owners and Moderators take it upon themselves to "manage" the process retrospectively; I suspect that trying to enforce any sort of order in advance (by "instructions") is doomed to fail.

If anyone has found a solution to that I would very much like to hear it!

Chris

In most of my hobby groups the use of Photos is the most important feature next to the messages themselves.
Over time with very active and groups with a complex pursuit,  we need better ways of locating specific photo
albums.  Currently it appears that the only mechanism is to view the list of ALBUMS in  alphabetic order.
Because of the attachment of the album names to representative thumbnails it is horribly difficult to find
specific albums that you do not know the name of.   It is not uncommon to have more than one hundred
photo albums and I think we need at a minimum a way to sort by date created  or by album name or by
creator name  and when showing the sort list it would be better NOT to show a representative thumbnail.
This way would allow many dozens of albums to be shown together for easy perusing by the viewer
and ideally we could scroll the list up and down etc.  when looking for an album to look at.
Thanks
Scott ... a very new member/user here

On Mon, May 14, 2018 at 10:32 am, Mark Fletcher wrote:

Please try again, it should be fixed now.

Sorry to report that something is still amiss...any export exceeding ~100 MB continues to fail for my group.

Bruce

I think it much more likely that the subscriber using the affected service would know about the problem.

I think there is one case where this might not be true and something for Mark, et. al. to think about.  I know that there is a thread in this group regarding AOL marking everything as SPAM from groups.io (I do not use AOL so I can't speak directly to this).  I wonder if this is due to extended SPF validation.  If so, this would lend itself to the possibility of the groups.io sysops to manually add domains to the automated DMARC "list".  I would recommend it not be made generally available as it would increase their workload tremendously but it would allow them to accommodate larger, consumer-targeted mail providers without having to go through training of thousands of users.

1. The default for groups.io is to not "munge" the From address.
2. if a group owner has enabled "munging", all messages sent via their group have "munged" From addresses to give everyone in their group a common experience.
3. If a domain has DMARC set, messages sent to the domain have From addresses automatically "munged".
4. If a domain is manually flagged (such as aol.com), messages sent to the domain have From addresses "munged" which accommodates larger consumer domains using extended SPF checking.
5. if a user has set "munging" on for their account, all messages sent to their account have From addresses "munged" which accommodates smaller domains and corporate domains using extended SPF and internal domain checking w/o DMARC.

Using this ordering, it should simplify detection of whether to "munge" or not.  It is important to note that we are only talking about munging From addresses.  ReplyTo is independent and should not munged.  ReplyTo should be based on group settings as it is today.

Hope this is a good clarification of how to address various scenarios we might see with a minimum of impact to both group-owners and group members.

Pete

You misunderstand. I mean for that option to apply to messages TO that subscriber, not FROM them.

My thought is that users whose email service has this characteristic might want to be able to join any group - and not be reliant on convincing owners/mods to opt to munge header-Froms.

You are correct, I did not understand your statement.  I still prefer to give the group owner the ability to say "I would like my group to appear as X to all my members" instead of having to deal with individual issues.  As I say, it is the default on Y! groups which many of us are migrating from so the fewer issues we have to deal with in our migration, the better.  I like your differentiation, however, on what the effect is at the account level.  Let me see if I can properly summarize:

Account level option: If enabled, all messages sent -to- that account will have the "munged" From address.

Group level option: If  enabled, all messages sent -via- the group will have the "munged" From address giving all members the same experience.

Both options are excellent and provide group owners the flexibility to easily manage their group experience to their members while giving individuals the ability to say "I can compensate for my provider so I have a good experience across all my groups.io groups."  To me, having both options covers all bases with a minimal impact on users and group owners.

Thanks for your clarification.

Pete

Pete,

Also, the individual user doesn't know that someone else has an SPF
filter that is looking at both SMTP and header from addresses to
further reduces SPAM.

You misunderstand. I mean for that option to apply to messages TO that subscriber, not FROM them.

My thought is that users whose email service has this characteristic might want to be able to join any group - and not be reliant on convincing owners/mods to opt to munge header-Froms.

So doing -both-, in my opinion, would be optimal but a minimum should
be for group owners to set it and not leave it to individuals to
understand how their provider is configured.

I think it much more likely that the subscriber using the affected service would know about the problem. Group mods/owners have enough to cope with without making them responsible for knowing the ins and outs of every email service - or even for knowing what services their members use.

But in any case, if it seems desirable to give the group some input to the option (groups on the topic of Exchange or Office-365 usage may represent use cases for this), then I would suggest doing it like a subscriber's Time Zone: the group's Default Sub Settings tab can provide a default that applies to new accounts that join the group. This way users with established accounts would not suddenly have their preference changed merely by joining a group where that is set.

Shal

I like all but 3 should not be a premium/enterprise option.  I would want it for my basic group which got transferred from Y! groups for 3 reasons:

1. There are over 700 members comprised of people mostly unaware of the mail server options they have and are used to things working with the Y! group construct.
2. While I can turn it on for my account so I can see my messages, this does fix the issue of other people's addresses failing SPF validation when they have not turned it on.
3. Many people create rules so if the message is from groups.io with the group keyword in the subject, the email is moved to a specific folder.  Without that indicator, their could be private messages, for instance, being put into the wrong folder.  Simply a convenience in my reason #3.

Also, #2, I think, should read "users from smaller sites -not- implementing DMARC" since, it is my understanding, groups.io automatically enables it when it sees DMARC configured for a domain.

Pete

How about both a group setting and an individual setting?

1. If a user is using a known-must-munge site like yahoo.com, the checkbox is on the user's settings, checked, and grayed out (disabled).

2. If a user is using something else, the checkbox is still on the user's settings, unchecked by default, but the user can check it. Then users from smaller sites implementing DMARC can also go and fix things themselves.

3. A group level checkbox can also be available that applies it to all messages sent to the group. This might be a premium/enterprise option, given that basic groups could just ask problem users to go fix it themselves.

JohnF

I think that would be better as an account option that could be enabled by the affected recipients, similar to the Message-ID munging option (I always want copies of my own messages) for Gmail users.

I disagree since the reason it exists at all now is because it is beyond the individual user's control (DMARC accommodation).  Also, the individual user doesn't know that someone else has an SPF filter that is looking at both SMTP and header from addresses to further reduces SPAM.  As I said in my post, if this is an option at the group level, the group owner can make the decision for this to be common for all group members or as it is now, automatic for those providers that support and have well-defined DMARC settings.  If you want to -also- add the ability for users to enable this on their accounts, I think that would be great, too!  This removes those users from being at the mercy of group owners who do not want to provide global support.

So doing -both-, in my opinion, would be optimal but a minimum should be for group owners to set it and not leave it to individuals to understand how their provider is configured.  I would add that in the case of the individual control, users should be able to do it at the account level, not at the individual subscription level (the later would never get done or done properly).  Users must be given the least amount of pain to be a member of a group and group owners can manage how their groups appear to the users.  Group owner option does achieves these 2 goals for groups; account-level option aids users who otherwise have no control within groups that don't do this.

Pete

On Mon, May 14, 2018 at 10:25 am, Mark Fletcher wrote:

I think perhaps the best thing to do is to add a checkbox, separate from Reply To, that when checked will munge all From lines in messages to a group. Perhaps call it 'Convert All Email From Addresses To Be From Groups.io' with the help text being: "Only use this feature if you use Office 365 and have had complaints from users about email spoofing.'

I would use a more generic "Only use this feature if you have had complaints from users about blocked emails or emails marked as SPAM for no apparent reason."  I believe this extends beyond Exchange servers (definitely beyond Office 365) to provider servers that do extended SPF checking and internal domain checking to prevent/reduce phishing attacks and spoofed email address attacks for users.  While primarily corporate servers will have this protection in place, it appears there are commercial vendors that do similar SPF checking and internal domain blocking independent of DMARC.

Pete