MSGraph Email Poller

Overview

Need to poll emails from your Exchange server? This smart service can be used in a poller process and extract the data from the Microsoft Exchange server. Messages are stored in the Appian Document System, as well as the attachments. Meta data is stored in a database table for further processing.

This plug-in provides an alternative to sending emails to an Appian process model when inbound email integration is requested. Instead of the email being forwarded to Appian, this plug-in reads the emails directly from the Exchange mailbox using the MS Graph API as described below:

  • Reads the mailbox using the MS Graph API
  • Convert the email to an EML file stored as an Appian document; Item attachments (calendar invites, messages) are kept in the eml file, File attachments removed from it and stored separately in the document management system.
  • Store all email file attachments as separate Appian documents
  • Store all email metadata (subject, author, recipients, etc...) into a set of tables in the database

Key Features & Functionality

All information how to deploy, configure and use the smart service is in the 'MS Graph Mail Poller.pdf' document in the downloaded zip. Extract the files in the ZIP and follow the instructions in the document.

Anonymous
Parents
  • Is there any other way to capture BCC recipient as our mailbox is configured in bcc in the sender end.. 

  • No, there is not. As specified in RFC 2822, a bcc recipient can be implemented by the sender in one of 3 ways: 

    The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
       addresses of recipients of the message whose addresses are not to be
       revealed to other recipients of the message.  There are three ways in
       which the "Bcc:" field is used.  In the first case, when a message
       containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
       removed even though all of the recipients (including those specified
       in the "Bcc:" field) are sent a copy of the message.  In the second
       case, recipients specified in the "To:" and "Cc:" lines each are sent
       a copy of the message with the "Bcc:" line removed as above, but the
       recipients on the "Bcc:" line get a separate copy of the message
       containing a "Bcc:" line.  (When there are multiple recipient
       addresses in the "Bcc:" field, some implementations actually send a
       separate copy of the message to each recipient with a "Bcc:"
       containing only the address of that particular recipient.) Finally,
       since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
       sent without any addresses indicating to the recipients that blind
       copies were sent to someone.  Which method to use with "Bcc:" fields
       is implementation dependent

    Seems like for your use case the sender used the first version of it.

    The poller will extract the field if it is there, but it is up to the sender to implement what it puts in the bcc field

Comment
  • No, there is not. As specified in RFC 2822, a bcc recipient can be implemented by the sender in one of 3 ways: 

    The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
       addresses of recipients of the message whose addresses are not to be
       revealed to other recipients of the message.  There are three ways in
       which the "Bcc:" field is used.  In the first case, when a message
       containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
       removed even though all of the recipients (including those specified
       in the "Bcc:" field) are sent a copy of the message.  In the second
       case, recipients specified in the "To:" and "Cc:" lines each are sent
       a copy of the message with the "Bcc:" line removed as above, but the
       recipients on the "Bcc:" line get a separate copy of the message
       containing a "Bcc:" line.  (When there are multiple recipient
       addresses in the "Bcc:" field, some implementations actually send a
       separate copy of the message to each recipient with a "Bcc:"
       containing only the address of that particular recipient.) Finally,
       since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
       sent without any addresses indicating to the recipients that blind
       copies were sent to someone.  Which method to use with "Bcc:" fields
       is implementation dependent

    Seems like for your use case the sender used the first version of it.

    The poller will extract the field if it is there, but it is up to the sender to implement what it puts in the bcc field

Children
No Data