I have a website that allows visitors to fill in a form with their name, email address, and a question, and this is sent as an email message to the nominated website member.
The email messages are plain text and contain a 'Reply-To' header with the name and email address provided by the visitor. They are sent from noreply#mydomain which is managed by Google Workspaces.
Here is an edited snippet of the relevant headers:
Date: Wed, 10 Nov 2021 11:25:55 +0000
Subject: Question
From: My Business <noreply#mydomain>
Reply-To: Visitor <visitor#theirdomain>
To: Member <member#theirdomain>
When this is working correctly, the recipient receives the message from noreply#mydomain, and when they click the reply button in their email client, the reply will be addressed to the visitor. Most email clients are compliant and this arrangement has worked reasonably well for many years.
However, over the last few days a number of website members with gmail addresses are replying to the noreply#mydomain address. I have sent myself a test message through the website, and when I click the 'Reply' button on the received message, the reply is addressed to noreply#mydomain. This occurs on Gmail for web, Android and ios.
I have also noticed that gmail is no longer displaying the account name for the noreply#mydomain account. It's there in the headers, but only the address is displayed in list view and message detail view.
I have opened up older messages from 2017 (these are the most recent ones I have) and they still display and create a reply correctly. I have compared headers, and both pass SPF and DKIM. The major difference is the new message contains ARC- headers that weren't implemented in the past.
Does anyone have any ideas how I can fix this problem?
Related
I have a community where users can send emails to each other and/or multiple users.
Problem: I often get the feedback that emails are being received, not even in the Spam folder.
Currently I do the following:
From: noreply#mydomain.com
To: recipient#gmx.com
Reply-to: sender#yahoo.com
The problem is that I see from bounces that emails are rejected because the "From" and "Reply-to" do not match.
What I tried?
Putting the original sender address "sender#yahoo.com" in the "From" field. Result: Even more emails get rejected by the servers, because I am not allowed to send emails on behalf of this user (I totally understand that behaviour from the mail-servers)
Removing the "Reply-to" Header. Result: Users click on reply and send answers to "noreply#mydomain.com" and they never get to the intended recipient.
What I plan to do?
Next idea that I have is to send emails from #mail.mydomain.com and have a individual user hash for each sender. e.g.:
From: h7ga310acc8de509a7d884ab#mail.mydomain.com
To: recipient#gmx.com
When the recipient hits the reply button and replies to h7ga310acc8de509a7d884ab#mail.mydomain.com, then I need to send a new email with the content of that email to sender#yahoo.com, if this was the user assigned to h7ga310acc8de509a7d884ab#mail.mydomain.com
My questions:
Is this a "Best practice" or are there better solutions?
Are there any tools/libraries (preferrably in typescript) which would help me to do this last step of email forwarding to the original sender
Thanks a lot for all kind of feedback, thoughts, links to helpful pages, etc.
I am building a ticketing system where users can raise a support ticket and agents can reply to the particular ticket and when the agent replied to a particular ticket I will send the reply to respective user email (email service using SendGrid).
My question is when the user replied to the agent email I will fetch that email with SendGrid inbound parser but I am stuck that how to uniquely identify for which ticket user has replied. I have two ideas attaching JWT in the header or unique email address resemble ticket id (ticket-id-2654654#example.com) but I don't what will work
You could send a custom Message-ID Header (RFC 2392) with your E-Mail. Responses to your E-Mail should then contain a References and/or In-Reply-To header containing the Message-ID of the E-Mail that was answered.
Edit: Just tested it with Zendesk and Zammad. They both seem to identify responses in that way.
You mention having a unique email address, not unlike a VERP (Variable Envelope Return Path) address. VERP is most pertinent if it's dealing with bounces, since it refers to the address used for the SMTP MAIL FROM:,
MAIL FROM:<ticket-id-2654654#example.com>
in particular it is helpful to identify which emails bounce - the email likely never arrives in a mailbox at the remote end. Note that the address used during the SMTP conversation like this will be recorded at the top of the received email with a 'Return-Path:' header.
Assuming an email doesn't bounce then how to ensure an email with a recognisable identifier comes back:
MysteriousPerson's custom Message-ID: header suggestion is excellent; also specify a VERP address in a Reply-To: header - so one or both of the identifiers you put there should be found in the reply to decode which ticket/user the original message was sent to. You have the choice of using the same VERP address in the From: header or something more human-friendly, depending on what you want the recipient to see. Since Reply-To: is specified, client software will use that for replies.
The main RFCs on SMTP and message format are likely to be helpful if you're not already aware of them.
I have a survey form that people submit the hours they work and it sends their response in an email to me and then CC's two other people. The script was authorized by me to send the emails and has worked fine for a long time until a couple days ago when now I am getting a reply back from all three emails saying Message blocked. Any idea why these are being blocked?
MailApp.sendEmail("myemail#gmail.com",emailSubject,"", {htmlBody: body, cc: "anotheremail#gmail.com, thirdemail#gmail.com"});
If I only send the email to myself then it works perfectly fine. If I include even one CC email address I get the block.
Reporting-MTA: dns; googlemail.com
Arrival-Date: Mon, 12 Nov 2018 04:57:05 -0800 (PST)
X-Original-Message-ID: <000000000000eb73c1057a773c96#google.com>
Final-Recipient: rfc822; myemail#gmail.com
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp; Message rejected. See https://support.google.com/mail/answer/69585 for more information.
Last-Attempt-Date: Mon, 12 Nov 2018 04:57:05 -0800 (PST)
Using GmailApp.sendEmail(emailAddress, subject, message) solves this.
This seems to be an issue with all new GSuite accounts as discussed here:
MailApp.sendEmail() in Google Apps Script not sending email
It is particularly frustrating that Google has no response to this huge shortcoming for over 4 months!
This likely happens when Google algorithms find any suspicious link in the body of your email. You can consider removing any links from the email and try sending the message again to confirm the issue.
The Google support site has more information.
I do not have a clear answer in here; I just want to be able to converse with devs in the same tough spot between a Google algo and a client having his business interrupted.
#amit: First that link you sent does not cover the actual situation. Second I ran my code for a second time manually and it processed everything perfectly so the content is not the sole trigger for this rejection.
To elaborate:
I made a survey tool for a client (with google biz account) that inputs the results in a google sheet with multiple tabs that receive rows of data. Once a day each tab generates a "day summary" of those results and sends it in an email.
It has 1 TO and 2 BCC targets. The body of the text contains multiple email addresses as clickable links. This worked fine till a few weeks ago.
Now today, without changing anything, the emails were sent out with no bounce/rejections. My conclusion is that it is indeed Google's preventive anti-spam filters doing. Just not as simple as "containing links".
Perhaps it's the time? As I see your email, and mine are sent at 3/4 AM, correct? Perhaps it has to do with the CC/BCC emails never being opened? As my BCC targets are both my client's own email addresses (in gmail).
It really sucks that there is no actionable info from Google on this error.
We have an application that allows users exchange messages, and delivers the message through email. But we don't reveal sender's email, instead; every time a message is sent out a new email address gets generated for the "From" field. Something similar to the way Facebook or LinkedIn send out messages.
Everything works fine, except the recipient's email client caches all these email addresses.
For instance, if Jack sends two messages to Jill, the sender's addresses can be: a123#FakeEmail.com and a456#FakeEmail.com, so next time Jill composes a new message and starts typing Jack's name, the email client suggests two addresses for Jack.
So my question is, how we can prevent email caching on client's machine? Is there something similar to HTTP header Pragma: no-cache for SMTP?
Thanks
Nivresh
OK, here is what I ended up doing. To prevent Outlook and other mail clients from suggesting several dummy email addresses generated for the same contact name, I add a special character to the beginning of the sender's name. This can be a space or if you use Unicode, you can add a zero-width space (\u200B) to the beginning of the name.
So in my example, the email is sent from "\u200BJack" which will be shown as "Jack". The dummy email address will be saved in mail client under the name of "\u200BJack" and when the recipient later on tries to send an email to Jack, email client won't suggest this address.
Hope this helps someone.
I'm working on a web application. A user will create an email message that will be sent to another person.
I would like the e-mail that gets sent to appear from the user's name and e-mail address of the user on my system. And if they reply to the e-mail then it should go directly to the sender's email address.
However I am worried about the email message looking like spam to email filters along the way.
Is there a proper way to do this?
I noticed on a "contact" page on a WordPress blog that something very similar is done. The e-mail headers look like:
To: email#domain.com
Subject: [Test Blog] =?UTF-8?B?aGVsbA==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From:=?UTF-8?B?aGVsbA==?=<sender#senderdomain.com>
Message-Id: <20090207234737.39C9522802F3#web7.sat.wordpress.com>
Date: Sat, 7 Feb 2009 23:47:37 +0000 (UTC)
Return-Path: donotreply#wordpress.com
What is interesting is that the display name in the "from" tag and the name that shows up in the subject line is encoded. I do not know if this helps with the spam filters or not, but thought it was at least worth mentioning.
Also, who would receive an undeliverable notification in this example? Would it go to sender#senderdomain.com or would it go to donotreply#wordpress.com?
Basically all you need to do is set the From header to the email address of the user sending the email. The value of From is what is displayed in a recipient's email client. Most spam detection systems in place today look only at the message content, not the email headers, so you currently wouldn't have that much of a problem based on what you set the From header to.
However, there are some systems which are gaining popularity which could prevent you from sending email with somebody else's email address - most notably SPF, the Sender Policy Framework Basically, a mail server that implements SPF will check the domain of the From address of each email it receives and check with that domain directly to see if it authorizes the email. For example, if your server is mydomain.com, the email address of the user is abcdef#gmail.com, and the recipient is blah#example.com,
mydomain.com contacts example.com via SMTP to try to send the email
example.com looks up the SPF records for gmail.com
example.com checks whether mydomain.com is on the list of domains allowed to send email with the domain gmail.com
If it's not, the email is blocked
Also, I found a forum post suggesting that Return-Path is the intended destination for undeliverable notifications. Apparently that header is set based on the value of the SMTP MAIL FROM command.
Setting email fields is generally trivial, but the exact method of doing so depends on the language and framework you are using, which you don't mention. Usually it is a matter of creating a new email object, and just doing something along the lines of:
email.from = "From Name <fromemailaddress#example.com>";
You can set the specific from address to your user's, if you like, it is not at all uncommon though I personally am not a fan. You could also set the from field to something like: "Sender Name (via Your Site Name) <yourresponseaddress#example.com>".
Don't do this.
It really depends on how your mail relay is set up, but actually just don't do it. From header should contain the email address that sent the email, in your case webmaster#whatever.com. If you want people to reply to a different address, you can always use the Reply-To header. Here are some notes.
If I understand the standard (RFC 822) correctly, this is exactly what the Sender header is for (see ยง4.4.2. SENDER / RESENT-SENDER). Still, I'd go with a different approach and use your sites official contact address in the From header and put the user's address in the Reply-To header. Maybe add some boilerplate text that clearly states where the mail is coming from.
One further advice besides the technical stuff: don't let anonymous users use this facility, you'd become a perfect platform for spamming. Also, out of kindness, you probably want to make sure that your (registered) users know that their email addresses are exposed to the recipients.
Be aware that doing this will make spam filters more suspicious of your email. Combined with suspicious looking content your email may get filtered.
Whoever is in the "From" header will receive the undeliverable notification.
For the filtering - it really depends more on the subject and body of your message than the From address. So with that said, a couple ideas....
Use HTML encoding rather than Plain Text with simple formatting (I know there's probably an argument going the other way but in my personal experience HTML gets through more often)
Always include a footer with ("This e-mail was sent to you from ... blah blah") to identify it; if you don't want people to know it's coming from your system (i.e. really impersonated from the "From" user) then you need to find a more legit way to take care of the requirement.
If at all possible, use a real address from your system as the "From" address with the address of the user as the "Reply-To".