Develop Reference

EWS some emails are missing internet message headers

I am working on a windows service that reads the inbox, archives the emails, couples the email to a ticket and put it in the database.
My problem is that we check the internetmessageheaders to see if an email is auto-submitted. But now we get an error message logged to the database every 5 seconds because the internet message headers is null.
for context the inbox is empty and it has worked before.
I did some testing and it worked fine except for 1 email i got in my test mail. It has the email headers that looks like the headers of a sent email and just like a sent email i can't get the internetmessageheaders.
Now i am left wondering if i can get the internetmessageheaders from that email or if i have to build a workaround because internetmessageheaders aren't supposed to be null on an received email

How to forward emails from SendGrid

Overview:
Our use case involves using the SendGrid Inbound Parse to accept, record and process emails. We also need those emails to be forwarded to our ticketing system (i.e. Zoho Desk).
We would really like to be able to forward the unedited email to Zoho Desk, preserving the original From, To, etc.
Problem(s):
When we try to forward the email using SendGrid's SMTP server, and using the MimeKit.MimeMessage.ResentTo("emailchannel#account.zohodesk.com") option, SendGrid is rejecting the forward request because of "Sender Authentication". The error we're getting from SendGrid is:
The from address does not match a verified Sender Identity. Mail cannot be sent until this error is resolved. Visit https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ to see the Sender Identity requirements.
Below is the code we're using:
SmtpClient cli = new SmtpClient();
cli.Connect(_config["SendGrid:Server"], int.Parse(_config["SendGrid:Port"]), true);
cli.Authenticate(_config["SendGrid:Username"],_config["SendGrid:ApiKey"]);
message.ResentSender = null;
message.ResentFrom.Clear();
message.ResentReplyTo.Clear();
message.ResentTo.Clear();
message.ResentCc.Clear();
message.ResentBcc.Clear();
message.ResentFrom.Add(MailboxAddress.Parse(_config["SendGrid:From"]));
message.ResentReplyTo.AddRange(message.ResentFrom);
message.ResentTo.AddRange(from o in matches
select MailboxAddress.Parse((string)o.ticket_addr));
message.ResentMessageId = MimeUtils.GenerateMessageId();
message.ResentDate = DateTimeOffset.Now;
cli.Send(message);
Question(s):
Is there a way with SendGrid we can forward the inbound email to Zoho Desk while preserving the From fields?
I would imagine SendGrid isn't the only company requiring Sender Authentication, as such, how else can we forward unedited emails to a ticketing platform?

Twilio SendGrid developer evangelist here.
SendGrid does require you to verify, via Single Sender Verification or Domain Authentication, email addresses from which you wish to send emails. So you cannot use SendGrid to automatically forward keeping the from email intact.
I have a couple of ideas about workarounds here though.
You could forward from your verified email address and add the original from email address in a reply-to field. I haven't worked with Zoho Desk, but perhaps you could configure it to respect that field instead of from.
Zoho has a guide on how to set up forwarding from various inboxes. Could you host your email with one of those providers and forward incoming emails onto Zoho and to your SendGrid email address for this processing?

Prevent a user from replying to a message

Is there any mechanism in which you can prevent a user from replying to an email message? Here's the use case:
An automated system (C#.net) sends emails to a user. The action of the task
is included in the email message (e.g. RSVP link for "yes" or "no")
Instead of using the buttons/actions in the email, the user replies
to the email.
The email originally sent specifically says that the mailbox in use
is unmonitored. (in bright red box!!!)
The user doesn't actually read the email, and gets pissed off when nobody replies or his RSVP is "lost"
Clearly a user issue. I'm thinking the best recourse might be an automated reply saying the mailbox is unmonitored if a user replies to the e-mail.
Any SMTP conditions/flag which can prevent a user from replying in the first place?

I don't believe there is any setting that you can include in the original email that would stop someone from replying to an email.
If the recipient really wants to reply, they can literally copy-paste the sender's email address into a new email and reply to it that way.
Just wanted to point out that the following hack is not elegant and would result in a bad customer experience. This is the only way I could think of achieving this.
One hack that comes to my mind is that you can try to set MailMessage.ReplyToList property to an invalid email address like - abc#g#g.com. In theory, this will force the customer's email client to reply to the invalid email address instead of the original sender. We can hope that the customer's email client validates that before sending the reply.
I have not tried this myself as I don't have an SMTP server to validate. But if the SMTP server does not validate the ReplyToList value then it should work.
Again this is a super sketchy hack and might not work with all the email clients out there.
You are better off setting up an auto-reply on the mailbox.

Reply-To Feature is not working as expected in GMAIL when two emails are set to reply to header

In our application, we are using Common From Email address to send an email to all the users.
To receive the reply back from the users, we use Reply to Header and we want users to send an email to 2 different users hence we use 2 email addresses in reply-to header.
When we reply to the email from Outlook, it works fine but in GMAIL, emails are going to Common From email address instead of Reply-To Email address.
When I use single email address in the REPLY-To header, functionality works fine. Issue is only when we use 2 email address in reply-to header.
mailMessage.ReplyToList.Add(New MailAddress("1stReplyTo#domain.com"))
mailMessage.ReplyToList.Add(New MailAddress("2ndReplyTo#domain.com"))
mailMessage.From = New MailAddress("commonEmailAddress#domain.com")
mailMessage.Body = "body"
mailMessage.Subject = "subject"
We were using this feature from last few years. But in a recent time we started facing this issue.

SMTP can accepts emails with false sender name

I'm using SMTPClient for sending emails to a SMTP server. But with Send method I can specify any false sender name or email. How can I prevent this?

It's the job of your mail server to decide on what it accepts as a sender email address - that's just a matter of policy.
There is no 'true' email address for a mail client, so nothing that can be enforced at the client.

I think that should be the SMTP server's role to decide whether a sender name is valid or not. In fact, introducing it in your code is a violation of the DRY rule since you'd be replicating the SMTP configuration.
As you can see in http://msdn.microsoft.com/en-us/library/swas0fwc%28v=VS.90%29.aspx, you should only be prepared to catch SmtpExceptions and properly display them to your software's user.

You can't do anything about it in the SmtpClient.
You can do something about it in your application. Send a verification email that the user must click on to validate it's email.
You can do something about it in your smtp server. Check the MX record or the defined SPF policies against the sender domain/ip address.

SMTP is a mail transfert protocol (as the name implies). It's not in charge of authenticating the sender. To authenticate the sender, your need to use certificates, which SMTP supports, but again, just as a mean of transfert. The program itself needs to have the logic to authenticate the sender with the certificate.
You can also use authentication, but in that case it'll be the SMTP server that will match the username/password with an email address.