Configuring Incoming Email

Configuring Basic Incoming Email Monitoring

With incoming email monitoring, you support posting replies to discussions via email. With this feature enabled, the application retrieves email that lands in a mailbox you specify and uses the email's contents to post a discussion reply.

Replies posted via this feature must be emails that are replies to notification email. Although sent as text in email, the reply content will appear in the community as if the recipient had posted it with a web browser. This way, users can post when they're unable to log in to the community but are able to read content through their notifications.

Notification emails sent from the application will include a token in the subject line. The token is needed for the application to correlate the incoming email with its reply thread. Users should take care not to alter the token.

Fastpath: Admin Console > System > Settings > Email Server (Incoming tab)

Here's how it works:

Someone posts a discussion message (either a new thread or a reply to an existing one).
The community sends email notifications to those people who have requested them.
After reading the content of the post in the notification email, someone replies to the notification email with their response (taking care not to delete the token in the subject line).
The email is received by the host described in the incoming email monitor settings.
Watching for email received at that location, the application locates the discussion thread to which the reply belongs and posts the reply to the community.

Note that this feature supports only discussion replies -- posts of new content and replies to other kinds of content aren't supported. To support those features, use the advanced incoming email feature.

Note: This feature isn't supported when the notification reply is a digitally signed email.

When you configure this feature, start with settings for your incoming email server.

Setting	Description
Client Protocol	Protocol (POP3 or IMAP) that clients use to retrieve email from your mail server.
Mail Server Host	Host name, such as imap.example.com.
Mail Server Port	Port number that clients use to reach your server.
Email Account to Monitor	Specify the email account on the incoming mail server that the application should watch for content. For example, monitored_account@mail.yourdomain.com. This email address also serves as the reply-to address if the content is sent out from Jive.
Account Username	Email account user name.
Account Password (Optional)	Account password if the server requires one from clients.
Use SSL	Select this if the server encrypts the connection between the web nodes and the SMTP server with Secure Sockets Layer.
Mail Folder Name	If the client protocol is IMAP, enter the server-side folder name (if any) that email lands in when it is received.
Delete Unrecognized Email Messages	Select this to remove messages that aren't intended for the application.
Inbox Check Frequency	Set this to a value that makes sense for your community. For very active communities (particularly when many people author by email), you might want this to be a lower number so that the application is more responsive with emailed posts.

Select Enable Incoming Email Monitoring to turn on the reply-by-email feature for discussions.

Configuring Advanced Incoming Email Monitoring

With the advanced incoming email monitor, you can set up the application to support posting most kinds of content via email. This includes replies to content as well as new content. This feature overrides the incoming email monitoring feature. When you enable advanced incoming email monitoring, incoming email monitoring is unavailable. The advanced feature includes the functionality of the basic feature (although it works differently).

When posting content via email, a person uses one of a number of email addresses that are specifically designed for posting a particular kind of content in a particular place (such as a space or social group).

Here's how it works:

Using a browser, a person goes to the place (such as a space, social group, their profile, and so on) to which they might want to post content.
The person clicks the Create by email link to display a list of the content types in that place that they can post via email.
After selecting check boxes for the content types they want, the person downloads vCards representing each of the content types (they can also email the vCards to themselves).
In their email application, the person uses the vCards to add the email addresses to their email address book, where they're available when they want to post via email.
To post content, the person creates an email with the content they want to post, then sends the email to the address they downloaded as a vCard.

Content types supported by this feature include the following (depending on what your license allows):

For Replies	For Creating New Content
Discussion replies	Discussion threads
Document comments	Documents
Blog post comments	Blog posts
Direct messages	Status message updates
Shares	Announcements
	Project tasks (native Jive tasks)
	Video

Network Requirements

With this feature enabled, the application receives email directly, rather than checking for messages dropped in a particular mailbox. Because of this, configuring this feature requires setting up email routing so that Jive receives emails containing content. Note that this might require your email server administrator to prepare the system.

You'll need to configure email servers and route requests on port 25 to the port on which the application is listening. Here are the details:

Configure email servers so that messages with content are sent to the community. Here are two likely configurations:
- You've deployed Jive to a server where the DNS A record of the server doesn't have a corresponding MX record.
  Example: Your community is deployed to community.example.com. It's unlikely that an MX record exists for the DNS A record community.example.com, so you most likely don't have to add or configure any DNS records. Mail transfer agents will first attempt to look up an MX record for community.example.com; if they don't find one, they'll use the "implicit" or "fallback" A record.
- You've deployed Jive to a server where the DNS A record of the server does have a corresponding MX record and so you've created a separate DNS A record specifically for this email functionality.
  Example: Your community is deployed to example.com/community. DNS A record for 'example.com' probably already has a corresponding MX record that handles mail for mail for the employees of example.com. To work around this, you'll need to create a separate DNS A record such as 'community.example.com' which points to the same IP address as the server that Jive is deployed on, then (optionally) create an MX record that points to the A record 'community.example.com'. If you don't create an MX record, email transfer agents use the A record as a fallback.
Open inbound connections to port 25 on the server where Jive is deployed, then use iptables to forward inbound requests on port 25 to the port you specify in the feature's configuration (by default, port 2500).
Ports 1024 and below are considered privileged ports on Unix systems. (You're forwarding requests to another port to avoid running the application as root to access the privileged port, which isn't recommended.) The following is a sample iptables command to forward requests on port 25 to port 2500:
```
iptables -t nat -I PREROUTING -p tcp --dport 25 -j REDIRECT --to-ports 2500
/sbin/iptables-save
```

Configuring to Receive Email

After you've set up email routing to ensure that Jive will receive content email, you'll want to configure the application to handle email sent to it. You do that in the Admin Console.

Fastpath: Admin Console > System > Settings > Email Server (Advanced Incoming tab)

Setting	Description
Mail Server Host	Host name, such as example.com. Destination email addresses will take a form specific to the content type, such as status@example.com. This is typically the domain used to reach the community via a web browser.
Mail Server Port	The port on which the application should listen for incoming email.
Valid IPs	IP addresses from which content email should be accepted. Use this setting to limit the locations -- such as relay servers -- from which content is allowed. Leave this blank to accept email from any server.
Email address prefix	Ordinarily, it's a good idea to leave this one blank. The prefix is a value prepended to the reply-to address in the message header (so it isn't ordinarily seen by users); the underlying default value is "jive". You might want to enter your own value here if you have multiple community instances and want to use the prefix to disambiguate among emails sent to them. In that case, each instance would have a different prefix.