It seems like most popular email clients don't include the X-Mailer header. Is there any good method to determine if an email was sent by a popular client, such as Gmail, Outlook or Apple Mail?
As mentioned in the comments, the User-Agent header can be used to determine the client MUA.
If this header isn't present in any of the emails being tested, this answer suggests that you could also check other fields like the message-id since some email clients will generate a message-id of their own.
Some more information about different useful headers can be found here.
Related
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 am trying to send some emails, through hotmail (outlook.live) smtp server. I am building an app that is somewhat an email client and I need to send some custom headers to provide some functionality.
The thing is that, while other email servers (only tried with Gmail and aol) accept custom headers or other rfc described headers (custom like, X-test and rfc described "Comments" or "Keywords") hotmail does not, the email sent does not contain those headers while the ones received from Gmail or aol contain the custom header.
Does hotmail require something extra or in a different format? Or they just remove them?
Like many web apps, we use Postmark to send all notifications for server side events. Many of our events are grouped and related by something simple and logical (think multiple replies to the same issue, like in GitHub).
Right now, every email sent for these related events is it's own email thread. My question is: how do I send these emails so that related ones get pushed into the same thread?
I'm not sure if this is something at the Postmark level (like include a previous message ID) or if this is something I do with SMTP (like I should format my subject better and inline previous responses), so that's why I'm seeking guidance. Also, every Google search about: "Postmark email threads" returns concerns over the thread safety of the Ruby Gem.
For more information, the app is written in PHP and right now we are znarkus/postmark-php for sending emails and jjaffeux/postmark-inbound-php for parsing inbound ones. However, I am more than willing to add any extra packages if they help me in my quest.
Thanks in advance!
You can add a few SMTP headers with the original Message-ID that most clients use to link together replies. If the original email had a Message-ID header of <123#mail.example.com> the new email you send out should keep the subject line the same and add headers of:
In-Reply-To: <123#mail.example.com>
References: <123#mail.example.com>
And that should inform clients that the two emails should be threaded.
Edit:
The value for these headers should be the SMTP Message-ID header, which is slightly confusing because it is a separate concept from the Postmark MessageID value, which is just a UUID for the email.
The SMTP Message-ID header is always in the form an email address, because that's how it's supposed to be formed, but doesn't have to be related to the from address.
I have been playing with email headers. I am trying to include a record identification number in the email header so that if I send an email and then it is replied to, the reply that I receive will be automatically allocated within my email client based on the record identification in the header.
When I have tried to do this, on reply to my email the original header including my record identification is deleted.
Is there are better way to do this? I was thinking I could just add it to the subject however I would rather the identifier be invisible to the user.
Address tags might be what you're looking for, if your email client supports it. You would put the tag in your reply-to address, not in an email header. I don't think you can expect your headers to remain in the reply.
Matching replies with the original message is exactly what the standard Message-ID: header is for. It's a unique string that identifies the email, and it's generally included in replies. You needn't -and shouldn't- invent any new headers nor any special processing of existing headers for this. (If you want to understand all the gory details, look at the email RFC documents.)
If they're not displaying for you, the problem is not that the information isn't there, but rather that your email-program isn't very smart. (Or maybe you have to turn on some option in the email program...)
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".