We have an app that sends emails on behalf of our clients. All emails are sent via Sendgrid. As part of this we have verified our email sending domains via DKIM and SPF.
When our clients send email, it is constructed as follows:
from: Tom Smith <email-service#ourserver.com>
reply-to: tom.smith#email.com
This works in the vast majority of cases, but there are situations where the "reply-to" is not being respected - recipients are clicking "Reply" in their email clients and the reply is coming back to us.
Is there something that we are missing here. Do we need to explicitly set a FROM or SENDER header? Or something else?
Related
When a user unsubscribes from an email in gmail, it seems gmail sends an email to the sender with:
`subject`: "unsubscribe"
`body`: "This message was automatically generated by Gmail."
`to`: u+(somesuperlongrandomstring)#domain.tld
`from`: (Email of user who unsubscribed)
Similarly, when a user unsubscribes from an email in Apple Mail, it seems Apple Mail sends an email to the sender with:
`subject`: (blank)
`body`: Apple Mail sent this email to unsubscribe from the message "(Subject of email unsubscribed from)".
`to`: u+(somesuperlongrandomstring)#domain.tld
`from`: Email of user who unsubscribed
We use mailgun to handle unsubscribes already, but as of 28th March 2022, these emails from both providers now make it through our email routing.
Does anyone know how to tell gmail or Apple Mail to not send these emails? They are redundant because mailgun is already handling the unsubscribe using the list-unsubscribe header as you'd expect.
Alternatively, does anyone know how to set up Mailgun so these messages aren't passed through routes?
So Mailgun didn't provide any help, sadly. But looking through their documentation, and the headers of these emails, it seems possible to use their Routes to hide the emails completely.
The three clues are:
Emails always coming in the format u+(...)#domain.tld
Gmail unsubscribes always have the subject "unsubscribe"
Apple Mail unsubscribes always have the header: X-Apple-Unsubscribe:true
As such, you can create a route as such to capture and discard these emails using a custom route with the raw expression set to:
match_recipient("u\+(.*)#domain.tld") and (match_header("X-Apple-Unsubscribe", "true") or match_header('subject', 'unsubscribe'))
It's sad that Mailgun stopped doing this themselves, but at least there is a solution with their tooling!
I have a web application that will be used by committee chairs to communicate with committee members over email. All these users will have e-mail accounts external to the web application and domain the web application is hosted on. Any replies from members need to be directed to the e-mail of the committee chair user, not an account on the domain of the web application. The only two methods of accomplishing this that I've come up with are
In the from of the e-mail, use the e-mail of the sending user. E-mail applications for many of the committee members block this as spam.
Use an account such as no-reply#applicationdomain.com, and then include instructions in the e-mail of the correct address that replies should be sent to. Users often get confused and don't send replies to the correct address.
Are there any alternatives I am missing?
Traditionally, this was the purpose of the Sender email header. If you want an email to be From the user, but sent by you, you would just set the Sender header to an email address on your domain but have From be the user. Also, the SMTP envelope sender should also be on your domain. Then, you would be properly declaring that you're the sender of the message for anti-spam purposes, you'll receive any bounce messages, but email clients will know that the email is reportedly from the "real" user, and will direct replies accordingly. Generally, email clients would report both Sender and From, saying something like "From my-server#website.example.net on behalf of real-user#example.com", though obviously the details depend on the email client being used.
Refer to What's the difference between Sender, From and Return-Path? and OpenSPF Web Generated Email Best Practices for more information.
However, now DMARC has come along. It has made the decision that verification should be based only on the From header. The theory is that there's no way for an end-user to know whether a particular Sender is in fact authorized to send mail "on behalf of" the user listed in the From header. While it probably isn't the decision I would have made due to how it ignores the traditional Sender, it's something that needs to be dealt with now, as if the domain of the user listed in the From has a DMARC record that is set to q=reject, then nobody else, including your web form that's trying to send mail with the complete approval of the user, can send mail that's From that domain. More and more domains are turning on DMARC, and as they do so your form won't be able to send email From them, regardless of what other headers are set.
The only other alternative, then, is to have email be From your application entirely, but set the Reply-To header to where the email program should send replies to. Also, the SMTP envelope sender should be your application, and ideally be set to an address that can handle bounce messages or other errors. You shouldn't need to include any instructions, as the Reply-To header is very well supported among email clients as indicating where replies should be directed.
Refer to the DMARC FAQ entry "Why are messages I send on behalf of visitors to my website being blocked?".
We offer a function to send an article by email to a friend's personal email. We would like the friend to be able to continue the conversation simply by replying to the email.
To avoid yahoo, hotmail, etc. to flag the emails as spam due to dmarc policies violation, we follow this recommeandation.
So our header looks like this:
From: "John Doe via the Example Website" <service#website.example.com>
Reply-To: "John Doe" <john#firstmailboxprovider.com>
To: "Bob Smith" <bob#secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"
Unfortunately, many (lots) of email clients simply skip the Reply-to parameter. So, many people are responding to us instead of their friend.
What is the recommendation?
Notes:
Respect of Reply-to header seems to be client dependent (not destination domain dependent).
Many solutions are unfortunately no more bulletproof in 2016: Potential issues using member's “from” address and the “sender” header
Can't you include the friend's email in body?
That way the user can click on it to reply.
Perhaps send to "both" so they can reply-to-all?
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.
On our mailing application we are sending emails with the following header:
FROM: marketing#customer.com
TO: subscriber1#domain1.example
Return-PATH: bouncemgmt#ourcompany.example
The problem that we are facing is that some email servers will bounce back a message immediately and use the from or reverse path (marketing#customer.example) instead to our bounce mgmt server. We want to know if we modify in the header the reply-to to be the same as the return-path if we will be able to catch all bounces.
Any other ideas are welcome?
We are using the following documents as references:
VERP
RFC
Bounce Messages
SMTP Log Parsing to get Bounces
EDIT 1: A few more bits of information to see if we can get this resolve.
We want to know at what point the email server relaying the message will choose to use the reply-to versus the return-path. We have notice that when the first SMTP server relaying the message gets rejected it sends it to the reply-to, but when it happens after one hop it sends it to the return-path.
Let's start with a simple example. Let's say you have an email list, that is going to send out the following RFC2822 content.
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's say you are going to send it from a mailing list, that implements VERP (or some other bounce tracking mechanism that uses a different return-path). Lets say it will have a return-path of coolstuff-you=yourcompany.com#mymailinglist.example. The SMTP session might look like:
{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com#mymailinglist.example>
{S}250 2.1.0 me#mycompany.com....Sender OK
{C}RCPT TO:<you#example.com>
{S}250 2.1.5 you#example.com
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
.
{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel
Where {C} and {S} represent Client and Server commands, respectively.
The recipient's mail would look like:
Return-Path: coolstuff-you=yourcompany.com#mymailinglist.example
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's describe the different "FROM"s.
The return path (sometimes called the reverse path, envelope sender, or envelope from — all of these terms can be used interchangeably) is the value used in the SMTP session in the MAIL FROM command. As you can see, this does not need to be the same value that is found in the message headers. Only the recipient's mail server is supposed to add a Return-Path header to the top of the email. This records the actual Return-Path sender during the SMTP session. If a Return-Path header already exists in the message, then that header is removed and replaced by the recipient's mail server.
All bounces that occur during the SMTP session should go back to the Return-Path address. Some servers may accept all email, and then queue it locally, until it has a free thread to deliver it to the recipient's mailbox. If the recipient doesn't exist, it should bounce it back to the recorded Return-Path value.
Note, not all mail servers obey this rule; Some mail servers will bounce it back to the FROM address.
The FROM address is the value found in the FROM header. This is supposed to be who the message is FROM. This is what you see as the "FROM" in most mail clients. If an email does not have a Reply-To header, then all human (mail client) replies should go back to the FROM address.
The Reply-To header is added by the sender (or the sender's software). It is where all human replies should be addressed too. Basically, when the user clicks "reply", the Reply-To value should be the value used as the recipient of the newly composed email. The Reply-To value should not be used by any server. It is meant for client-side (MUA) use only.
However, as you can tell, not all mail servers obey the RFC standards or recommendations.
Hopefully this should help clear things up. However, if I missed anything, let me know, and I'll try to answer.
Another way to think about Return-Path vs Reply-To is to compare it to snail mail.
When you send an envelope in the mail, you specify a return address. If the recipient does not exist or refuses your mail, the postmaster returns the envelope back to the return address. For email, the return address is the Return-Path.
Inside of the envelope might be a letter and inside of the letter it may direct the recipient to "Send correspondence to example address". For email, the example address is the Reply-To.
In essence, a Postage Return Address is comparable to SMTP's Return-Path header and SMTP's Reply-To header is similar to the replying instructions contained in a letter.
for those who got here because the title of the question:
I use Reply-To: address with webforms. when someone fills out the form, the webpage sends an automatic email to the page's owner. the From: is the automatic mail sender's address, so the owner knows it is from the webform. but the Reply-To: address is the one filled in in the form by the user, so the owner can just hit reply to contact them.
I had to add a Return-Path header in emails send by a Redmine instance.
I agree with greatwolf only the sender can determine a correct (non default) Return-Path.
The case is the following:
E-mails are send with the default email address: admin#example.com
But we want that the real user initiating the action receives the bounce emails, because he will be the one knowing how to fix wrong recipients emails (and not the application adminstrators that have other cats to whip :-) ).
We use this and it works perfectly well with exim on the application server and zimbra as the final company mail server.