We Keep Coding

Sending an email to outlook with emoji characters using C#

I have a user input on a web page.
They are able to type a message and send.
The message gets sent to them via SMTP and the client they'll be using is outlook.
The problem I am getting is that emoji [😂🐱‍👓🤷‍♂️👍] are coming through as varying amount of ?? question marks.
There's also a number of problematic characters that come through when they paste content from work like special quotes and the em dash which is often substituted in word when people type a dash.
I know outlook supports emoji as I can type them in with Windows + ; and send them fine. But this is getting mangled somehow when I send it through the SMTP client.
Debugging is showing the emoji correctly before sending it through the SMTP client.
Any ideas what I need to do to get it to send without resorting to stripping these characters out? I'd like for people to be able to use these emoji if they like.

Thanks to #Steve for making me reconsider the obvious 🙌
Turns out all I needed to do was set the BodyEncoding to System.Text.Encoding.UTF8 on the message.
Setting the IsBodyHtml property to true was not enough.
Not sure what the default is for this to not work without setting it to UTF8 but oh well.
mail.BodyEncoding = System.Text.Encoding.UTF8;
https://learn.microsoft.com/en-us/dotnet/api/system.net.mail.mailmessage.bodyencoding

Is it possible to open the device default mail composer with blank email address?

I have tried
Device.OpenUri(new Uri("mailto:"));
but the result is an exception thrown because there is no email address specified as "mailto:name#domain.com".
What I need is just open a blank email composer, that is, with blank subject, body, to:, cc: etc. it's ok to have from: field.
Or should I resort to native implementation?

If that exception is in there, there probably is no way around it.
Instead of inventing the wheel again yourself have a look at the Xamarin.Plugins.Messaging NuGet package. It can compose e-mail messages as well as other types of messages. I'm not a 100% sure but you could try to create an empty e-mail with that and save you the trouble of implementing it yourself.

Outlook Add-In - Custom Headers for Email Tracking

We have written an Outlook add-in in C#, that appends a custom header to outgoing messages.
This add-in has to use a library called Redemption to bypass Outlook's security to modify the headers, and this is all working great.
Our problem lies when sending outgoing mail through an exchange server. We use the additional header as such:
Add a References header with an email address that includes an ID for tracking with our system.
This is a standard email header that all mail clients should pass on when replying to messages. So replying to a message will automatically keep the new message tracked.
All of this works just fine if you send an email from an IMAP account setup in Outlook such as GMail.
Problem is, if you send mail via an Exchange account, the Exchange server overwrites the References header and uses it's own proprietary headers: Thread-Index and Thread-Topic. Email standards suggest to use References and In-Reply-To headers. See this link on this issue.
Does anyone know a way around this? Some algorithm to gain us the following:
Add a header (of any name or kind) to emails that includes a 10-digit ID and 3 letter prefix
Replying to this email from all (or most) mail clients preserves the custom header

I think the following algorithm is going to solve our issue:
Our Outlook add-in will set the References and an arbitrary X- header
Our mail filter will look for References, if found use it (if outgoing mail server was Exchange, it will not be present)
If our mail filter finds the arbitrary X- header and a Thread-Index, it will store the data found in the X- header.
Later if the email is replied-to several times, the mail filter will use the Thread-Index to look up the past info to keep the email tracked.
For those wanting to know internals of the Thread-Index header, it is a Base64 encoded string. The first 22 bytes are the original unique portion and each reply adds an additional 5 bytes on to it. We only use the first 22 bytes to identify the email.

check if email address really exists with a service via ajax (not regularexp) real time if it reallly exists

I like to check the validation of an email address with ajax by onblur? (asp.net,c# and...json or anyother I don't know)
I thought it could be possible with json and calling a webservice. but are there any (free)services to call? or I have to write my own? Hope you understand me what I want.
Thanks

If you just want to validate the format of an email address, you can do it using regular expressions in javascript without having to do any ajax calls. Check out this related thread
If instead, you want to check whether an email address is real, I'm afraid it isn't possible. There isn't a database of all existing email addresses.

The whole notion of whether an e-mail address "exists" is somewhat ambiguous. Does an auto-responder address "exist"? Does an address which can receive mail that is immediately discarded "exist"? Some mail servers can be effectively probed by initiating a mail delivery session and seeing if the mail server rejects the address as illegitimate. More savvy mail servers may quietly accept and discarded mail destined for "bogus" addresses to prevent address validation (i.e. to keep spammers from getting "good" addresses). What you're asking is non-trivial, and there's not really a clear cut answer.

There's no real way to confirm an email really exist other than sending it an email and seeing if you get a bounce-back (And even then some domains have catch-all's configured so it may not actually be an email).
You can validate the format of it to make sure it looks vaguely like an email. To truly validate an email takes an ungodly complex regex (I've yet to see one that truly encompasses the scope), but a simple check that'll rule out most keyboard-mashing is pretty easy. I typically use:
^[A-Za-z0-9._%+-]+#[A-Za-z0-9.-]+\.[A-Za-z]{2,6}$
There's a lot of fake emails it will accept, but it does a reasonable job of forcing the user to enter something legitimate. Be wary if using a more complex regex that you don't accidentally ban any legitimate addresses, the email spec is very broad in what's allowed.
You could also try doing a DNS lookup on the host portion of the email (After the #) for an extra level of protection, but I'm not sure how much you'll get from this as you'll just force them to lie with a real domain name.

Force mail client to use text rather then HTML through mailto:

I'm using SubVersion and TRAC on a C# project I am working on, and I have my TRAC system setup with a email address that can be used to create tickets. In my program I've added a simple "FeedBack" button in my program which sends an email to this address. To open the email I'm just "starting" a mailto link as shown below.
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
string ver = assem.GetName().Version.ToString();
System.Diagnostics.Process.Start("mailto:foo#bar.com?subject=<Provide a title for your feedback here>&body=< Describe the problem you are having or enhancement you would like to suggest here. Please be as descriptive as you can, and if possible list out the actions that will replicate the problem >%0D%0A%0D%0A%0D%0AVersion: "+ver);
The problem I'm running into is if the user is using Outlook and their copy of Outlook is setup to HTML the ticket that gets created ends up having a bunch of HTML code that I have to clean up. Is there some way to notify whatever mail client is handling it to send the email as text rather then HTML?

There's nothing you can do (besides education) on the client - there's nothing in mailto to control a client side program. And, frankly, with the proliferation of web-based email - I think mailto is showing it's age.
Outlook should send a mime/multipart message, with both plain text and HTML parts. I'd guess you could extend or patch Trac to only grab the text/plain portion.
Otherwise, just create a form in your app to capture the email info. Again, if someone is using Hotmail or GMail - mailto is not likely to work anyway (or will open up their unconfigured Outlook Express, where they will dutifully type up an email and press Send. Only it won't go anywhere, because no SMTP servers are configured - so it will languish in the Outbox for years. Not that they will notice though...).