This document here: https://docs.sendgrid.com/api-reference/mail-send/limitations
States the following:
Unicode encoding is not supported for the from field.
The to.name, cc.name, and bcc.name personalizations cannot include either the ; or , characters.
So I tried a test email to see what happens. I put emojis in the From name, and I sent to a To name of "John,;;, Doe;". There was no error and the email was successfully delivered.
Am I misreading these limitations? I want to make sure that what I build is correctly validating what it sends to the API, but these limitations don't seem to be correctly stated.
While I don't know exactly what the limitations are within SendGrid, I would imagine those limitations were written for a reason. It may well be the case that SendGrid itself can handle each of those characters, but the mailbox you are sending to may not. Obviously the test email that you sent handled those characters too, but that may not be the case for all mailboxes and you could cause yourself delivery problems if you try to send messages that conflict with these stated limitations.
I would stick within the guidelines for the best possible outcome.
Related
I'm looking for a way to know definitively if an email I receive is in response to a specific email I sent. I manually set the Message-Id of the outgoing message using make_msgid, store this value, and then check the In-Reply-To of an incoming email to determine if it is equal to the original Message-Id I sent.
This approach is basically what is suggested here in this very helpful answer by Mohammad Eghlima.
But I wonder if this approach is "foolproof" and if there is a better way to accomplish this? For example if there are some clients other than outlook, gmail etc. that do not follow this convention of setting In-Reply-To to the Message-Id of the original mail for replies, or if they set their own Message-Id for some reason (ex. Gmail does this if it determines the existing message id doesn't follow RFC standards)?
I've seen some other answers mention other potential methods to accomplish what I'm trying to do - for example, here but most of these questions/answers are from 10 years ago so I'm wondering if there is a better way to accomplish this now.
No, nothing is entirely foolproof. Junior PHP programmers write new email-sending code every day and none of it conforms to any particular set of conventions or RFCs. And then there's Microsoft and Google ... Oh, you are already familiar with them.
There have been no significant developments in email standardization on this particular front in the last decade, so advice from 10 years ago is by and large still relevant.
If anything, the field has been polarized by Microsoft and Google plunging ahead to "innovate" in various aspects of what may charitably be characterized as usability improvements over traditional email, but the motivation has often been to silo in users to prefer or be forced to use their solutions, not standardize anything.
(The efforts to improve e.g. email security through DMARC etc has been better coordinated and standardized.)
The post you link to basically summarizes the information from D. J. Bernstein's excellent email reference resource https://cr.yp.to/mail.html; see in particular the threading conventions at https://cr.yp.to/immhf/thread.html
This Odoo company we're working with basically sends a lot of e-mail. One e-mail thread can turn into 100+ e-mails with different people brought into the conversation (CC'd) at different times. Due to the complexity of their e-mail management, they want to use their Gmail interface (Google Hosted) and CC an e-mail into odoo and they want it to get tracked in a thread. I've basically already done that... they have an e-mail like odoo+res.partner-432#domain.com (although it's hashed to not be easily readable) - they CC this and the full body thread gets included in chatter (mail.message) under respective model / id.
The challenge with this: the chatter messages can get huge very fast, due to their e-mail messages (because each e-mail includes main reply, and all previous history on thread). I've looked into some systems that have a "reply above this line" - and it just takes the latest message. And in those systems, eg. ticketing systems such as Zendesk, help scout, I believe the teams are using the ticketing system (not a gmail) and thus there is much more control over the inbox and incoming email (not to mention, those e-mails are usually 1-to-1, not including groups).
My questions:
Is there any other workaround that you see here to have odoo pull in only the last e-mail reply and not the full e-mail thread? I could probably build something like this: https://github.com/zapier/email-reply-parser - and hook it into odoos e-mail parsing, but that works on text format e-mails only (not HTML)... only. So it's not bulletproof, and I'm not sure it's worth it.
Even if this client DID use odoo 100%, I still don't think it would be possible to get it to work the way they want without major customizations (eg. Odoo's default behavior is to include all past e-mail threads)
I'm curious if anyone here see's any other solutions, otherwise – I doubt there is something here I haven't seen. :) (But very open to be proven incorrect!)
I'm uploading messages into my IMAP mail server via IMAP store operation. However, I would like to add "comments" to these messages so that when I download these emails again I know the they are created by "store". Basically, I need to add text which will be ignored by the formal semantics of parsing RFC822.
The specification of http://www.ietf.org/rfc/rfc822.txt defines how to add comments but I cannot make it working :(
Does anybody has en example of a RFC822 message with a comment in it?
You are probably looking for IMAP's annotations. However, it's an extension which is far from being common -- quite a lot of IMAP servers do not support it.
It seems that having a special "flag" on each message you created is something which would be enough for you. If that is correct, then simply using IMAP flags (or keywords) is what you're looking for. Simply add one special flag, like thisIsProducedByFooSoftware to the APPEND operation. (You said you were doing that via STORE -- that's wrong, in IMAP, STORE manipulates just FLAGS, it doesn't add new messages. New messages are added by APPEND.)
I got a request from my client that they want to add stars (★) to their email subject (They send these mails through the application we made as a part of bigger CRM for them).
I tried to send a test mail, and the email title is displayed nicely in my Gmail account, and I must agree with my client that it is eye catching, but what came to my mind is that this may be a spam magnet, so I googled about it but I can't find the actual "don't do this".
Generaly, my oppinion would be not to use it, but now I have to explain to the client why. My best explanation whould be there is a probability your emails will be treated as spam but I don't have the background for this statement.
Do you have any suggestions about what should I do?
The only information I could find is on the SpamAssassin page of how to avoid false positives. The only relevant part I found was this part.
Do not use "cute" spellings, Don't S.P.A.C.E out your words, don't put
str#nge |etters 0r characters into your emails.
SpamAssassin is a very widely used spam filtering tool. However, simply breaking one of the rules (strange characters) alone wouldn't get an email marked as spam. But combined with some other problems could lead to your email being considered spam. That being said, if your email is a completely legitimate business email, it's likely that few other rules are triggered, and using the special characters wouldn't create a huge problem. That being said, you should probably try out a couple test emails on SpamAssassin and a couple other spam filtering tools in order to come to a better conclusion on the emails you plan to send out.
Simply explain to your client as you have explained to SO: you stated that the star made it eye catching: this doesn't directly mean that it will be treated as spam, but you could explain how that concept COULD be considered spam.
If the star is part of their branding, however, this could be quite a nice way in which your client expresses themselves.
Spam emails are becoming more and more like what one would consider 'normal', so I think they have trial it internally, test the concept.
Talk it over with your client - there is going to be no basis in hard fact with things like this, purely social perception.
More and more retailers are using unicode symbols in their subject lines since a few months. Of course it's in order to gain more attention in cluttered inboxes. Until now, there has been absolutely no evidence that such symbols increase the likelihood of failing spam filter tests. However, keep in mind that rare symbols might not render (correctly) across all mail user agents. Especially keep an eye on Android and Blackberry smartphones, but also on Outlook. In addition, due to a Hotmail bug symbols will render much bigger in subect lines and in the email body within the web front end. In fact, they are beeing replaced by images. All in all, the star shouldn't make any problems. At least, if it's encoded correctly in the subject line. So, go for it.
For the past year at least now a good dozen or so of the users of my site have experienced odd characters showing up in the emails they receive. I've researched the issue numerous times and have pretty much written it off to be some sort of encoding issue on the users' end. That conclusion doesn't really sit quite right with me since I've never been able to replicate the issue.
The odd characters aren't really even characters, they're a series of characters which represent high characters such as periods. =2e, for instance, appears where ever periods should appear. Some other character string appears for each line end. According to what I've researched in the past, this type of encoding is fairly standard and is called Quoted Printable and only very old email software is unable to read it. Each time this occurs I ask the same old barrage of questions about the operating environment the affected user is working with and they are never using an older client so QP should be rendered correctly. There is seemingly no difference between a recipient affected by the issue and one which is not.
The emails that are affected are sent automatically by my web server and no special encoding is applied. Pretty standard sent from an ASP classic application using ASPMail by ServerObjects Inc.
Anyone have any ideas what could cause this, or am I corrected in assuming its an end-user encoding issue not rendering properly??
A little update on this...
I recently found out that if we are to send the mail from our server as plain text rather than HTML mail - the weird characters do not exist. This only occurs when HTML mail is sent.
I have come across this info on their site:
Some of our emails are getting equal signs at the end of lines in some messages. Why?
AspMail can encode high characters using a scheme where the = sign
indicates a character to be decoded follow by the hex string value of
the character to be encoded. This system of course assumes that the client can decode these characters (which most can). This is called quoted-printable encoding. The default for AspMail is not to use QP encoding. Things that trigger automatic QP encoding:
High characters - characters with the following ordinal values 0..31,61,128..255
Long lines of a message body (>255). You can turn wordwrap on to fix this case
Most clients are capable of handling QP encoding. If your client is not capable then you should upgrade your client or you must work within the above limitations to prevent the QP encoding from occuring.
So from what I understand from that is they are pinning it on the end user's client
We have this problem at work. Users will get odd characters, stripped characters, missing content, etc. Most of the time it is due to the email software. CSS in emails causes odd problems with Outlook and Gmail. We had one circumstance where an email was supposed to say, "Hello Bob" and it just said, "Hell Bob".
If the user gets their email forwarded from one account to another then chances are good they will get an email that was filtered by the forwarding account. So if Gmail strips out characters, where ever it forwards that email the recipient will get the stripped out characters.
We had other issues with our emailing service not merging the templates and data correctly but that doesn't seem to be the case here.