I came across this as the only other thing I could find that resembled what I'm asking: http://office-outlook.com/outlook-forum/index.php/t/84123/
I'm sending an email through Office 365's SMTP server as a notification that a form was submitted to my company email address (me#company.com) from our company RSVP email address (rsvp#company.com). I am setting the From Name to be the full name of the person filling out the form and the reply-to email as the person's email address textbox.
Here is an example of what part of the message header might look like:
To: <me#company.com>
From: Test User <rsvp#company.com>
Reply-To: <test.user#gmail.com>
In Outlook, since rsvp#company.com is an actual mailbox within our company, it automatically displays the sender name as "RSVP" (which I suppose is what was set when the mailbox was created). Is there a way to bypass this and display the sender name in the message header instead?
No. Exchange always resolves all sender and recipient names to their primary SMTP address and default name. Just the way Exchange works.
You can extract MIME headers and modify the message sender related properties on the client side after the message is received using Extended MAPI (C++ or Delphi) or Redemption (I am its author - use RDOSession.CreateOneOffEntryID / RDOSession.GetAddressEntryFromID / set RDOMail.Sender and RDOMail.Get_SentOnBehalfOf / RDOMail.Save). Note that OOM will not let you set the sender related properties even using MailItem.PropertyAccessor.
Related
Is it possible to change the From Name of an email (not the sending address) when sending an email from Outlook Exchange?
Is there any add-in that can help us achieve this?
I can see with Exchange only admin can change the sending from name. Is there an alternative?
In general, you can't do that out of the box. The latest version of hosted (M365) Exchange allows to configure a mailbox to send as one of its proxy SMTP addresses, but the sender display name will still be the same.
You can try to use an addin like Proxy Manager (I am its author) - besides allowing to send through any of the mailbox proxy addresses, it also allows an end-user to change the sender display name.
Found a very similar question here: Email aliases not returned as "To" address in logic app
TLDR: From within a logic app "When a new email arrives" trigger, How do I get the original alias that the email was sent to?
I have a logic app that creates a ticket based off an email sent to an outlook box. Now I want to be able to choose aspects of the ticket based off of whether or not the email was sent to the mailbox itself or an alias of the mailbox. The problem I'm having is that by the time logic apps gets a hold of the email, the alias address has already been replaced with the actual box's address ("alias1#place.com" -> "actualbox#place.com").
The actual mail in the inbox has the original email's alias information in the headers, but I can only get them by looking at the properties in outlook. I've tried to get the original "To" internetheader information both within logic apps (by exporting the email to blob storage and looking at headers there) and with the Microsoft Graph API. Sadly, the email exported by logic apps doesn't have the alias information and Graph API has pretty much every header but "To". At least one other person has lamented the lack of To
That said, the actual email still has the original alias information. Can someone help me get that information in logic apps without jumping through too many hoops? A many hoop solution is welcome if none other can be found though.
Use the Export email (V2) action from the Office 365 Outlook connector. This will give you the full message with original headers (including the actual To address)!
The flow here is, trigger on the incoming email, as you already are, then add the export email action providing the message id from that trigger to pull this specific email.
From there, you you'll have one big "body" property which you'll need to interrogate to find the To address.
Caveat on this though, it doesn't work when emails are sent between mailboxes in the same Office 365 tenant. Exchange Online will "helpfully" go, "I know that address... this is the address you wanted!"
What API are you using? In Outlook Object Model / MAPI / EWS, you need to retrieve the PR_TRANSPORT_MESSAGE_HEADERS MAPI property (DASL name http://schemas.microsoft.com/mapi/proptag/0x007D001F)
We arrived at a many hoop solution.
The "Primary" email box now has some rules that look at the internet headers mentioned above (Message -> Properties -> look for 'To:').
If it finds an alias there, it will put the email in a corresponding folder for each alias.
Then we have logic apps listening to each of the alias folders which will then send the email's information to the _Core logic app that does the actual processing.
We are getting a lost of spam /phishing e-mails where the [From] is showing our own domain (e.g. "john#foobar.com"), but the [Mail From] (return-path) in the e-mail header is showing "root#foo-574401.hostbar.com".
Question is now, which e-mail address is actually considered by the Exchange Online block list and could someone point me to the corresponding documentation of Microsoft?
In case the block-list does not consider the [Mail From] we need to setup an transport-rule to address those kind of e-mails?
Ok, found it:
See Microsoft documentation Sender filtering procedures
Sender filtering filters inbound messages by comparing a list of
blocked senders to the value of the MAIL FROM command in SMTP
connections. For more information about sender filtering and the
Sender Filter agent, see Sender filtering.
See also Sender filtering
Sender filtering compares a list of blocked senders that's maintained
by the Exchange administrator to the value of the MAIL FROM command in
SMTP connections to determine what to do with inbound email messages
from those blocked senders. Sender filtering in Exchange Server is
provided by the Sender Filter agent, and is basically unchanged from
Exchange Server 2010.
I have mailbox "user1#somemail.com" and I manually changed MailItem.Sender field to "user2#somemail.com" and sent it to "user3#somemail.com". I discovered strange situation that i see email in "SentItems" folder in "user1#somemail.com" but "user3#somemail.com" not receive this message. I checked logs in Exchange server and i donæt see any error messages. Just for prof i did the same but not change MailItem.Sender property but used SentOnBehalf standart functionality. And "user3#somemail.com" receive it so issue not in permission. Just for check i used OutlookSpy and compare two emails(one email that i sent using SentOnBehalf standart functionality and outher email where i changed MailItem.Sender). You can see diferrences following. Can somebody say me where is my fault and why user not receive email when i change MailItem.Sender:
The Sender property is not meant to take a string value. You need to set it to an AddressEntry object for a user that has permissions to send from any of the loaded accounts in the current Outlook profile.
See MailItem.Sender Property:
http://msdn.microsoft.com/en-us/library/office/ff869056(v=office.15).aspx
My problem: one of our customers wants us to accept their appointments by using icalendar .ics MS outlook generated attachments. We need to reply with another .ics attachment, so that his (ms exchange?) system records our acceptance. We have no MS software in the company, do not use Google or Yahoo calenders, and this is needed rarely, once a month or so.
Ideally, I would prefer a web based service where I can paste their .ics formula (starting with VCALENDER...) and generate a reply which I will send as an attachment from mutt. Another possibility is a command line script which I can apply from within mutt directly.
you would need to send the answer according to the RFC 6047 (here for the full length)
to give you an idea of what the RFC states, see below:
MIME Message Format Binding
This section defines the message binding to the MIME electronic mail
transport.
The sections below refer to the "originator" and the "recipient" of
an iMIP message. In the case of a "request" method, the originator
is the "Organizer" and the recipient is an "Attendee" of the event.
In the case of a "response" method, the originator is an "Attendee"
and the recipient is the "Organizer" of the event.
The [RFC5322] "Reply-To" header field typically contains the email
address of the originator of the scheduling message. However, this
cannot be guaranteed because the sender of the iMIP message might not
be the originator of the scheduling message and the sender's "Mail
User Agent" (MUA) might not enforce iMIP semantics by translating the
originator's address into the "Reply-To" email header field.