This content is likely not relevant anymore. Try searching or browse recent questions.
Google Group: Emails Being Sent to the Group Show with Group Alias as "from" 0 Recommended Answers 5 Replies 45 Upvotes
We are using google groups to receive emails from hundreds of users across the internet and then forward those emails into our jira service desk instance.
Google Groups Name: this_email
One problem we just encountered and this is inconsistent, is that for some users, when they send an email to this_email@domain.com, when we receive the email in our gmail inbox, the "from" email address is the google groups alias, and not the sender. I think I have gone through all of the google group settings to make sure that the sender shows up as the from, but we still see instances where it shows up as "User email via [Google Group Name]
With regard to jira, I am following up with them as to why their handler is reading the from and not the "reply to"
The sender shows up as the "reply to", however, the jira email handler is reading the "from" email addresses and we need the "reply to" to match the "from" email address.
Details
Recommended Answer Recommended Answers (0)
All Replies (5)
Recommended Answer
I am also having this problem, but the sender’s name appears in email received on my iPad, but only the group name is shown as the sender on that same email that is received on my iPhone. So I assume it could be a setting under my control on my iPhone. I looked at all settings under “mail”, and they are the same on both devices. Any clues on how to get the sender’s name to also show on my iPhone?
recommended this
marked this as an answer
Recommended Answer
Also having this issue.
Emails received in Gmail app show with sender details.
Emails received in Mac Mail show with the group name.
Emails received in Mac Mail show with the group name.
This is a new issue, which I noticed starting only about a week ago - so didn't start at the same time as the Mac OS update.
recommended this
marked this as an answer
Recommended Answer
Similarly experiencing this issue (although with forwarding the emails into a different software). Highly frustrating as there doesn't appear to be any rhyme or reason determining which emails this occurs for.
recommended this
marked this as an answer
Recommended Answer
I'm not positive that you folks here are talking about when in an email you see "via <group@domain>" instead of who it was actually sent from but I inquired with Google support about this when they first introduced this behavior over a year ago for the same reasons you've listed here, ingesting into software presents issues with linking cases to reporters and thus replying to them. I would suspect that the DMARC policy for your domains has become more strict and that is why you are now seeing this behavior present itself.
tl;dr to get around it you will need to come up with something to pull the from address off a different header in the email or ingest your email from a user account instead of a group.
The 'Via' will only be displayed if two conditions are met:
1. The sending domain has a DMARC strict policy, meaning 'p=quarantine' or 'p=reject' in their DMARC TXT record in DNS with their domain host.
2. The email has an automatic 'HOP' from the sending server to the recipient server.
2. The email has an automatic 'HOP' from the sending server to the recipient server.
With this in mind, you will typically encounter the 'via' in the following types of emails.
1. Emails sent to Google Groups.
2. Emails sent to a user which has automatic forwarding to another account.
2. Emails sent to a user which has automatic forwarding to another account.
Now, the explanation as to why this occurs in the above conditions and types of examples. In order to understand the holistic approach, it's necessary to comprehend DMARC technology.
1. DMARC policy is the only way to 100% prevent spoofing as it builds on SPF and DKIM email authentication, and if any of these fail, DMARC activates.
2. With a DMARC policy set to 'p=none' you are only monitoring traffic and no action is taken on emails which fail SPF and DKIM beside the routine spam tags. However, with DMARC policies set to 'p=quarantine' or 'p=reject' the emails can and will bounce as the end recipient server must validate email authentication; SPF and DKIM and these can/will fail since the server which relayed the message (last HOP/Google) is not the 'From' sending server.
3. Now, SPF checks are done to the envelope sender/return path and not the 'FROM'. thus, can pass with end recipient, but DKIM fails since the sending domains DKIM key was checked by the (HOP server) and thus, the end recipients server activates the sending domains DMARC policy due to a DKIM fail.
4. So, to avoid legitimate messages activating DMARC per an automatic relay through Google servers, our engineers implemented the rewriting of the 'From' address to use the local domain (HOST of the HOP) and if it has DKIM, resigns the email to avoid a DMARC activation with the end recipient as the end recipient server now validates solely on the (HOST of the HOP) domain which will pass SPF and DKIM and not activate the original senders DMARC policy.
2. With a DMARC policy set to 'p=none' you are only monitoring traffic and no action is taken on emails which fail SPF and DKIM beside the routine spam tags. However, with DMARC policies set to 'p=quarantine' or 'p=reject' the emails can and will bounce as the end recipient server must validate email authentication; SPF and DKIM and these can/will fail since the server which relayed the message (last HOP/Google) is not the 'From' sending server.
3. Now, SPF checks are done to the envelope sender/return path and not the 'FROM'. thus, can pass with end recipient, but DKIM fails since the sending domains DKIM key was checked by the (HOP server) and thus, the end recipients server activates the sending domains DMARC policy due to a DKIM fail.
4. So, to avoid legitimate messages activating DMARC per an automatic relay through Google servers, our engineers implemented the rewriting of the 'From' address to use the local domain (HOST of the HOP) and if it has DKIM, resigns the email to avoid a DMARC activation with the end recipient as the end recipient server now validates solely on the (HOST of the HOP) domain which will pass SPF and DKIM and not activate the original senders DMARC policy.
recommended this
marked this as an answer
Recommended Answer
Hi Bradley
We are having this issue but do not have DMARC in place on our domain. The issue only appears sometimes, so I'm wondering: If the external "From:" domain has DMARC in place and sends to one of our Groups, will Google still show as sending "via"?
We are having this issue but do not have DMARC in place on our domain. The issue only appears sometimes, so I'm wondering: If the external "From:" domain has DMARC in place and sends to one of our Groups, will Google still show as sending "via"?
recommended this
marked this as an answer
This question is locked and replying has been disabled.
Link to post
Delete post?
This will remove the reply from the Answers section.
Notifications are off
Your notifications are currently off and you won't receive subscription updates. To turn them on, go to Notifications preferences on your Profile page.
This reply is no longer available.
Badges
Some community members might have badges that indicate their identity or level of participation in a community.
