Topics

moderated Group Setting to Enable From Address via groups.io #suggestion


Pete AE5PL
 

We have a number of users who are either using email via on-premise Exchange, hosted Exchange, or Office 365 business/enterprise.  Exchange checks both the envelope-From address (SMTP FROM) and the header-From address (actual From address in email) for both SPF and internal domain blocking.  While this is not true of all mail server software, it is true of all Exchange server versions which encompasses the vast majority of enterprise and business email servers.  Recently (within the past year), Office 365 finally implemented DMARC on their servers for North America customers but not all customers have had the knowledge or initiative to properly implement it.

With that background, I am appreciative of the group.io team in implementing auto-change on the header From address for detected DMARC reject domains.  However, most Exchange installations do not implement DMARC because it would need to be implemented via third-party software and would require DNS changes. Most Exchange email users do not have access to any of this to make alterations and therefore are stuck with emails they originate getting bounced when sent back through groups.io or having other peoples' emails getting bounced due to SPF failure.  While you may disagree with how Microsoft implemented SPF and domain validation, it is what it is and has been this way for over a decade (don't expect any changes now).

I am requesting that, in addition to the Reply to Group setting, we have the ability to turn on the "via groups.io" setting for all users in a group.  This would allow group owners to resolve this issue with business-class mail servers for their individual group(s) without adversely affecting other groups.

Thank you for hearing my request.  Hopefully we can see a resolution with relatively little pain to groups.io and our users.

Pete


 

On Mon, May 14, 2018 at 6:09 AM, Pete AE5PL <HamLists@...> wrote:
We have a number of users who are either using email via on-premise Exchange, hosted Exchange, or Office 365 business/enterprise.  Exchange checks both the envelope-From address (SMTP FROM) and the header-From address (actual From address in email) for both SPF and internal domain blocking.  While this is not true of all mail server software, it is true of all Exchange server versions which encompasses the vast majority of enterprise and business email servers.  Recently (within the past year), Office 365 finally implemented DMARC on their servers for North America customers but not all customers have had the knowledge or initiative to properly implement it.

With that background, I am appreciative of the group.io team in implementing auto-change on the header From address for detected DMARC reject domains.  However, most Exchange installations do not implement DMARC because it would need to be implemented via third-party software and would require DNS changes. Most Exchange email users do not have access to any of this to make alterations and therefore are stuck with emails they originate getting bounced when sent back through groups.io or having other peoples' emails getting bounced due to SPF failure.  While you may disagree with how Microsoft implemented SPF and domain validation, it is what it is and has been this way for over a decade (don't expect any changes now).

Thank you for that explanation! This has been something that I've been dealing with for a year now, and I was unable to get an explanation of what was going on from anyone, mainly because I think most people didn't understand what was happening.

 
I am requesting that, in addition to the Reply to Group setting, we have the ability to turn on the "via groups.io" setting for all users in a group.  This would allow group owners to resolve this issue with business-class mail servers for their individual group(s) without adversely affecting other groups.

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.'

Thoughts?

Thanks,
Mark


 


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 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.
 
Shal


Pete AE5PL
 

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


Pete AE5PL
 

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


 

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


Pete AE5PL
 

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


 

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


Pete AE5PL
 

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 AE5PL
 

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


Bob Bellizzi
 

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?

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.
--

Bob Bellizzi

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


 

Bob,

So, with both options enabled (below) which one rules in case of opposite selections by Group owner and account owner?

The way I wrote it the Account setting would have precedence; the group setting would be a default applied only to  accounts that had not already made a selection.

The way Pete wrote it the result would be the logical OR of the two - munge the header-from if either or both of the group and the account say to.

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?

I mean account - affecting all of the user's subscriptions. That's because the issue is a characteristic of his/her email service, affecting whether of not messages from others are delivered to him/her.

Shal


Pete AE5PL
 

So I guess this fell on deaf ears...  I was hopeful I could bring other groups over from Y! as I am not fond of where they are at this point but this is a deal killer for anyone on an enterprise system including Office 365 (Business and Enterprise) that are using Exchange and have their servers properly tightened to prevent spoofing of internal domains from outside sources.  If Mark is considering the fixes discussed here (group-level and user-level), I would hope to get an update as to potential implantation timeframe (loose, not exact).  Thanks.


Pete AE5PL
 

Also, I was incorrect in stating that Office 365 implemented DMARC.  They have not.  They have implemented signing but not actual DMARC screening so they will fail, as well.


Panagiotis Georgopoulos <panagiotis.georgopoulos@...>
 

I would certainly agree with that as I am facing bouncing problems with my corporate mailing service and I, and other colleagues, don't receive any messages to groups.io that we sent.  


Dj Merrill
 

I'm curious, did either one of these options ever get implemented?   I am running into the same DMARC issues others have mentioned and having these two settings available would seem to be very useful.

Thanks,

-Dj


On Tue, May 15, 2018 at 06:24 AM, Pete AE5PL wrote:
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.