In view I rendered two links that have mailto. Both of them have body attributes passed to mailto. One has short body text, other very long. When I click on link that has shorter body, it works and outlook opens. Link with longer body does not work (I clicked and nothing happens). But that happens only in chrome. In other browsers both links work. I noticed that in Chrome page source longer body text is made shorter with some notation. This might be the issue.
Does anyone know how to solve this problem? Any help would be appreciated.
Checking for spaces (and removing them) between the colon and the recipients, and between multiple recipients.
Variables that can be used with mailto:
mailto: set the recipient, or recipients, separate with comma
&cc= set the CC recipient(s)
&bcc= set the BCC recipient(s)
&subject= set the email subject, URL encode for longer sentences, so replace spaces with %20, etc.
&body= set the body of the message, including line breaks. Line breaks should be converted to %0A.
A MailTo Generator can be found here.
Related
Is there a way to separate email content (body text) from an added signature using IMap packages?
IEnumerable MailList = Client.Search(SearchCondition.Unseen());
var email = Client.GetMessage(MailList[0]);
string body = email.Body;
Thanks
This is a rather difficult problem.
For text/plain, you can look for the line "-- " (three characters, including the trailing space). For text/html, you can look for the CSS classes gmail_signature and moz-signature. For all mail, you can look for trailing text that matches the trailing text of the previous message from the same address.
However, none of this is foolproof. Lots of HTML sigs don't use those CSS rules (Outlook, for example, uses no relevant CSS), lots of plaintext sigs don't use --, and lots of middlecrapware inserts text after the signature so the "trailing text" may not be the at the very end.
When I use Mailkit to send emails, I noticed that it automatically decides to encode both the content as well as headers. Now, the content encoding is perfect however some email clients have difficulty decoding the headers which are like.
Is there a way to instruct the client to not encode certain headers?.
List-Unsubscribe:
=?us-ascii?q?=3Chttps=3A=2F=2Fbarlinkar=2Eus19=2Elist-manage=2Ecom=2Funsubscribe=3Fu=3D8c60690?=
=?us-ascii?q?5a7e637766f218816b&id=3D2e47bac84d&e=3D407e758886&c=3De27229afde=3E=2C?=
=?us-ascii?q?_=3Cmailto=3Aunsubscribe-mc=2Eus19=5F8c606905a7e637766f218816b=2Ee27229a?=
=?us-ascii?q?fde-407e758886=40mailin=2Emcsv=2Enet=3Fsubject=3Dunsubscribe=3E?=
X-Report-Abuse:
=?us-ascii?q?=3Chttps=3A=2F=2Fmailchimp=2Ecom=2Fcontact=2Fabuse=2F=3Fu=3D8c606905a7e637766f218?=
=?us-ascii?q?816b&id=3De27229afde&e=3D407e758886=3E?=
To: k****#****.***
EDIT: Jstedfast pointed out some errors and I fixed them but the overall result is the same.
I doubt the problem is that the header value is encoded. Your value is invalid to begin with.
Here's the raw value that you are using:
https://barlinkar.us19.list-manage.com/unsubscribe?u=8c606905a7e637766f218816b&id=2e47bac84d&e=407e758886&c=e27229afde>, <mailto:unsubscribe-mc.us19_8c606905a7e637766f218816b.e27229afde-407e758886#mailin.mcsv.net?subject=unsubscribe>List - Unsubscribe - Post: List - Unsubscribe = One - Click
Do you see anything wrong with that?
First, each URL should be enclosed in <>'s. Your first URL is missing the leading < character.
Secondly, you are including the List-Unsubscribe-Post header in the value of the List-Unsubscribe header. They need to be 2 distinct headers.
In other words, the receiving client is probably getting confused as to what the value is supposed to be because it is completely borked.
I have a textarea saving to a database that I'm using to send as the body of an email.
I allow tokens to be used as placeholders for information pertaining to that message.
If I don't touch the placeholders at all the email sends just fine with the line breaks exactly as they are in the textbox (the email is being sent in plain text).
However, when I start using the replace function, the new line characters start disappearing and all the lines get pushed together.
For example.
Body.Replace("%procedure%", CurrentOrder.Description);
Will replace the text %procedure%, but will also remove the newline at the end of the line. Even if the newline isn't directly after the text being replaced.
Any ideas?
edit:
For now, I'm just replacing "\n" with "<br />" and sending the email as HTML. I would rather keep it as plain text as I don't have control over the recipients at all.
EDIT 2: It appears to be an issue with outlook itself, not the email. I just viewed the exact same email in gmail, and the format was correct.
Outlook removes new lines unless the line ends with two spaces.
If you're testing the emails to an account that uses Outlook try adding two spaces before your new lines and see if that fixes it.
If its for HTML I would first of all replace the new lines with BR tags:
String str = str.Replace(Environment.NewLine, "<br/>");
either that, or instead of using a multiline textarea, use a JQuery or AJAX HTML Editor or something.
Maybe you could swap in a place holder (like above, and then swap it out?)
My web application sends emails to users. The email contains a link for further user action. Our security standards require that the link in the email cannot be clickable. However, the email clients recognize https:// in the email and auto-link the URL.
Any idea on how to stop the email clients to auto-link. I am thinking if I skip the https://, it may stop the auto-linking. But, if I have to keep the https:// is there any way to avoid auto-linking.
The link in the email is dynamically constructed in the c# code.
I know this thread is old, but I just had this issue myself, and wasn't thrilled by the gif image fix. If you're working with HTML emails, a slightly nicer solution is to break up the link text with a non-rendering tag that tricks the parser. I'm a fan of a simple non-existant <z>:
https<z>://securesite.</z>com
It even works in Stack Overflow posts: https://securesite.com.
Hope this helps someone.
I too wish to disable this, as I believe this is a "valid" use as to not wanting auto-linking (one reason is the designer wants it that way, and they are currently paying the bills).
In email sent that has no images, the header has the domain name in it:
EXTRANET.EXAMPLE.COM
I even put inline styles to make sure it stays white on a black background:
<span style="font-size: 1.5em;padding: 0.5em 0;text-transform: uppercase; font-weight:bold;color:#FFFFFF;text-decoration:none;">EXTRANET.EXAMPLE.COM</span>
Gmail makes this a link, adds an underline and also turns it bright blue instead of the intended white.
At first I tried replacing the dots with . which made it look fine, but didn't fool the Gmail parser.
So, I added a spanned space which work just fine (i.e. it fools Gmail's parser):
<span style="font-size: 1.5em;padding: 0.5em 0;text-transform: uppercase; font-weight:bold;color:#FFFFFF;text-decoration:none;">EXTRANET<span style="font-size:0.1em"> </span>.<span style="font-size:0.1em"> </span>EXAMPLE<span style="font-size:0.1em"> </span>.<span style="font-size:0.1em"> </span>COM</span>
Just create a plain <span> tag around the colon (<span>:</span>) or something like that :)
Replace the actual text with a small GIF image that looks like text.
Email parsers will not recognize text within an image.
My application has a similar security requirement. The solution we used was to add an underscore to the beginning of the URL (_http://).
Sorry to dredge up an old question, but I just tried the answer suggested by pieman72, and found that it didn't work within Outlooks 2007–2013. However, wrapping the individual elements of the URL within table cells did fool the Outlook parser:
Visit <table><tr><td>www.</td><td>website</td><td>.com</td></tr></table> for more information.
I ran a sample message through the Email On Acid test suite and found that it eluded the parser on all the major e-mail clients which automatically convert URLs (Outlook, iOS, Android 2.2, etc.) I did not run any deliverability tests.
#raugfer suggests in another answer: wrap the email/URL with an anchor.
<a name="myname">test#email.com</a>
Quoting from that answer:
Since the text is already wrapped in a hyperlink, Gmail gives up and
leave it alone. :)
(Note: also worked for Apple mail client.)
Necroing the question, I know, but it's relevant... I'd like to present a reasonable scenario where Gmail's auto-linking (at least - haven't tested other clients) doesn't make sense.
A client has an application form on their site, where visitors fill out some personal information and submit it. The system then sends a notification email to the client, presenting the information the visitor supplied.
I'm wanting to enhance the email sent to the client by adding a <textarea> at the bottom, with the fields the visitor filled out presented in CSV format so that the client can simply copy it all and paste it into a spreadsheet.
Gmail, however, fails to recognize that the URLs and email addresses are inside a <textarea> tag, and "helpfully" adds the ... link code around the URL/email - inside the <textarea>. This results in the raw HTML link code showing up in the <textarea>.
This is what i did:
Replace all instances of "." with <span style=""color:transparent; font-size:0px;"">[{</span>.<span style=""color:transparent; font-size:0px;"">}]</span>
Replace all instances of "#" with <span style=""color:transparent; font-size:0px;"">[{</span>#<span style=""color:transparent; font-size:0px;"">}]</span>
These characters stopped it parsing links and email addresses, but aren't visible to the user. The negative is that when you copy and paste an email for example, you end up with: "test1{[{.}]}domain{[{.}]}com"
.
I have an ASP.NET/C# application, part of which converts WWW links to mailto links in an HTML email.
For example, if I have a link such as:
www.site.com
It gets rewritten as:
mailto:my#address.com?Subject=www.site.com
This works extremely well, until I run into URLs with ampersands, which then causes the subject to be truncated.
For example the link:
www.site.com?val1=a&val2=b
Shows up as:
mailto:my#address.com?Subject=www.site.com?val1=a&val2=b
Which is exactly what I want, but then when clicked, it creates a message with:
subject=www.site.com?val1=a
Which has dropped the &val2, which makes sense as & is the delimiter in a mailto command.
So, I have tried various other was to work around this with no success.
I have tried implicitly quoting the subject='' part and that did nothing.
I (in C#) replace '&' with & which Live Mail and Thunderbird just turn back into:
www.site.com?val1=a&val2=b
I replaced '&' with '%26' which resulted in:
mailto:my#address.com?Subject=www.site.com?val1=a%26amp;val2=b
In the mail with the subject:
www.site.com?val1=a&val2=b
EDIT:
In response to how URL is being built, this is much trimmed down but is the gist of it. In place of the att.Value.Replace I have tried System.Web.HtmlUtility.URLEncode calls which also results in a failure
HtmlAgilityPack.HtmlNodeCollection nodes =doc.DocumentNode.SelectNodes("//a[#href]");
foreach (HtmlAgilityPack.HtmlNode link in nodes)
{
HtmlAgilityPack.HtmlAttribute att = link.Attributes["href"];
att.Value = att.Value.Replace("&", "%26");
}
Try mailto:my#address.com?Subject=www.site.com?val1=a%26val2=b
& is an HTML escape code, whereas %26 is a URL escape code. Since it's a URL, that's all you need.
EDIT: I figured that's how you were building your URL. Don't build URLs that way! You need to get the %26 in there before you let anything else parse or escape it. If you really must do it this way (which you really should try to avoid), then you should search for "&" instead of just "&" because the string has already been HTML escaped at this point.
So, ideally, you build your URL properly before it's HTML escaped. If you can't do it properly, at least search for the right string instead of the wrong one. "&" is the wrong one.
You cant put any character as subject. You could try using System.Web.HttpUtility.URLEncode function on the subject´s value...
Using the URL escape code %26 is the right way.
Sadly this is still not working on the Android OS because of bug 8023
What I ended up doing for my case was eliminating the &.
www.site.com/mytest.php?val1=a=b=c. Where the 2nd and 3rd = would be equivalent to www.site.com?val1=a&val2=b&val3=c
In mytest.php I explode on ? and then explode again on =.
A total hack I know but it does work for me.