SMTP Headers in VB.Net without Redemption - vb.net

I'm writing a mail component for a VB.Net app, and need to handle mails differently that are "Sent on Behalf" of someone. Although the Outlook Object Model exposes "SentOnBehalfOfName", it doesn't expose the email address for that party. Supposedly it's in the "OtherHeaders" field of the SMTP header, but I don't see an easy way to get to those through the Mailitem object. Am I missing something simple?

You could look up the name in AD or the GAL ?
or you could look up the PR_SENT_REPRESENTING_EMAIL_ADDRESS via a MailItem.PropertyAccessor id you are using 2007

our hacky workaround right now has been to construct a dummy reply. the reply-to field is populated based on the sentonbehalfof name, so then we can grab it and destroy the dummy. inelegant for sure, but it works

Related

C# Add-In (VSTO .NET): Add domain name to outlook junk-email list

With the Outlook UI you can add an email address to your junk-email list, you can add a domain name as trusted domain, but you can't add a domain name to your junk-email list. You must manually edit the email address in your junk-email list to achieve that, so I wrote an Add-In to do this for me, but cant find the method to do that. Apparently the Outlook object model doesn't provide anything for that.
Is there a code workaround for this fatal limitation?
That is correct. Outlook Object Model does not provide any means to access or manipulate Junk Email settings.
You can try to use Extended MAPI (C++ or Delphi) to build the MAPI server side rule that lists all the blocked senders, but it is definitely not for the faint-hearted.
If using Redemption (I am its author) is an option, it exposes RDOJunkEmailOptions object (returned from RDOSession.JunkEmailOptions, RDOAccount.JunkEmailOptions, RDOExchangeMailboxStore.JunkEmailOptions), which allow to add blocked senders using RDOJunkEmailOptions.BlockedSenders.Add.

Outlook VBA - How to get email item from user input

Although Im quite experienced with Excel VBA, Im not so much in regards of Outlook VBA (started yesterday, literally), so Im uncertain on how to get this simple task accomplished:
I created some coding to get a specific e-mail from the Inbox and then parse it and forward - that part is all good and well. Currently the code autodetects and retrieve the e-mail item using a set of parameters to filter through the Inbox. However, now I need to expand this code so that it can work with any e-mail item, and not only with that specific e-mail.
My idea is to get the user to input which e-mail item he/she wants to parse and forward, instead of getting the code to look in a specific place. How can that be done? The user input methods that I use regularly are InputBox (which returns a string) and GetOpenFileName, none of them suitable to pointing to a mail item within Outlook.
I thought about making the code work with the currently open e-mail item, but often the users have several e-mail items opened at once - forcing them to leave only one open for the code to work is not viable. Also, the code will be ran by people who have little to no IT expertise, so requesting things such as paths is also not an option. Is there any method for this?
I figured that working with Active MailItem is the way to go, as #niton suggested as well. I used a coding very similar to the one in this post, although I had to develop the handlers in case the user has other types of Objects active at the moment (AppointmentItems, for instance) or have multiple items selected. Final solution wasn't that much elegant - I was wishing for some sort of system input box where the user could point to the mail or something, but this works.

vb.net addin outlook positem

I am working with vb.net addin outlook 2010. I have an exchange server 2003. We have a public folder that is used to store client emails. Our system send emails to clients and when they reply, it is saved in a public as a postItem not mailItem. I do not know how that happen.
I need to convert that postItem into mailItem because I want to start a workflow with that message.
I am able to get most of the field from PostItem, but I am not able to get CC and TO. I do not know what property from PostItem keep that information.
Are you actually copying data? HAve you tried to just reset the MessageClass property from IPM.Post to IPM.Note?
The Outlook PostItem does not have CC or BCC properties.
I just look at the MSDN reference and I don't see TO field either.
Here is the PostItem documentation:
http://msdn.microsoft.com/en-us/library/office/ff865387.aspx
Without seeing your code, I have no idea why your received email saves as PostItem.
Can you post the routine that saves to the public Exchange folder?

Is there a way to programmatically fetch your email address for an Outlook addin?

as the title says, I'd like to be able to get my own or whoever's email address the user of the add in may be, and store in in a string variable.
Take a look at this
http://www.c-sharpcorner.com/UploadFile/hirendra_singh/accessing-outlook-contacts-list-in-C-Sharp/
Its in c#, but should be able to help you nevertheless!

Outlook VSTO attach meta data

I am writing an Outlook addin that inserts content into an email, and I have a emailSent event that I would like send an event back to my server letting me know some content was shared.
Is there a way to attach some meta information to the email (or the word doc, which is what you are creating in outlook) so that I can grab that meta info so I can send it back to my server.
Right now, the only way I think I can do it is to search through the email on the send event looking for my content with regex and pull out the info i need, but that seems cumbersome, and also means I need to run the regex for every email sent, even when they haven't added my content.
There is the concept of MAPI user properties, which you can add to an Outlook item. Since Office 2007 the object model allows access to them. If your add-in must run also with older Outlook version, you should recurr to use Redemption (which I prefer also for higher office versions because it has more flexibility, albeit a greater footprint in distribution).
See UserProperties Interface on MSDN.