ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
Commodore
Commodore
835 views

setup a separate GWIA for IMAP?

Jump to solution

We have one server with a Post Office and a primary domain. We have another server with a GWIA, a secondary domain, and web access.  The GWIA is configured for SMTP to our mail security relay provider.

Our current Salesforce app that forwarded our internal sales emails out to Salesforce is no longer.
The new provider that Marketing wants to use only allows IMAP directly to their server.
I do not want the PO connecting directly to their server.

I am thinking a solution would be to setup a second GWIA for use with IMAP only to send messages to their specific server(s)/domain, and I only want it to communicate to those servers/domain and nothing else (like Hotmail, Gmail, etc.).

Do I need a separate domain as well on this GWIA?

How do I set up the PO and make sure that the specific sales messages go to the IMAP GWIA and the rest to the SMTP GWIA?

We used to us a forwarding address that would sent out via our SMTP relay to the 3rd party servers and forward to Salesforce.  Internal sales staff would just use a template for those sales messages. Now I would need a way to tell the PO to hand off either to the IMAP for specific messages and the rest send via the SMTP to our relay provider.

Not sure if this can be done?  Or is there an easier way to do all of this?

Kind regards,

Val

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

@Rimser @iliadmin 

Hi Val,

You said this third party application needs access to your user's mailboxes to retrieve the Salesforce related email. Is it enough to be able to retrieve the email or is it important that it be retrieved from the owner's mailbox? We are assuming is is sufficient that all the required email be available in single mailbox but you haven't confirmed that.

For security, I agree that restricting access to specific GroupWise components in the DMZ is the safest approach. I agree with Diethmar that providing IMAP access via the GWIA is the preferred approach rather than accessing the post office directly. Having a second GWIA provides additional security capabilities. For example, you can have your firewall restrict external access to this one application (or a limited number of additional locations) so that you don't have IMAP open to the whole Internet.

Assuming a single mailbox will work, you have a few options how to collect appropriate Salesforce email.

  1. You can forward or CC (BCC) email to that mailbox.
  2. You can save a copy to a folder shared by the user in the DMZ as Diethmar suggested.

You may be able to automate the process by creating appropriate GroupWise rules for each user.

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.

View solution in original post

20 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Hi Val,

in my eyes you mix SMTP and IMAP. SMTP is for sending mails, IMAP for getting mails or for asking mails.

So please explain your request!

  • I.e. your new provider wants to access an internal mailbox in your company. So you can offer IMAP via your GWIA; you can limit IMAP access to this single mailbox. Your existing GWIA can do this.
  • You have to forward all mails for one account to your new provider. So create a rule for this account and forward all incoming mails to your provider's external mailbox.
    In this case it can happen to create a second GWIA if you want to use "flatward" only in this case.

If you explain your request, maybe I have another idea ..

 

Diethmar Rimser
This community is more powerful if you use Likes and Solutions
0 Likes
Commodore
Commodore

We have 8 sales staff right now who use Salesforce.  We were syncing their sales related emails to Salesforce via a 3rd party app called iHance,  which has disappeared. We "synced" by automatically BCCing to a forward address for iHance, and those emails went out with all our other SMTP email via the GWIA.  The 3rd party app received the emails and got them into Salesforce.  We also stripped off attachments before sending them using our mail security relay.

So now the only way it seems to do this is via an IMAP connection from their server to our PO/user accounts? with this one alternative app.  (ugh, I do't like that). We would only want certain messages being pulled to the new 3rd party app server, not everything in the user's mailbox.

Does not seem at all easy to do, or secure.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

@iliadmin wrote:

We have 8 sales staff right now who use Salesforce.  We were syncing their sales related emails to Salesforce via a 3rd party app called iHance,  which has disappeared. We "synced" by automatically BCCing to a forward address for iHance, and those emails went out with all our other SMTP email via the GWIA.  The 3rd party app received the emails and got them into Salesforce.  We also stripped off attachments before sending them using our mail security relay.

So now the only way it seems to do this is via an IMAP connection from their server to our PO/user accounts? with this one alternative app.  (ugh, I do't like that). We would only want certain messages being pulled to the new 3rd party app server, not everything in the user's mailbox.

Does not seem at all easy to do, or secure.


Hi Val,

I read your original post and this one and I'm still confused. This is what I understand:

  • Certain of your sales staff emails were sent to iHance which has/had its own email address.
  • iHance would interface with Salesforce and update Salesforce with information from the emails.

Is this correct?

So now the only way it seems to do this is via an IMAP connection from their server to our PO/user accounts?

That implies you are retrieving email from their server. In this case, to whom does their refer?

We would only want certain messages being pulled to the new 3rd party app server, not everything in the user's mailbox.

Pulled implies retrieving or reading. Are you saying that you are going to allow a third party to access your employees mailboxes to take what they want?

As Diethmar pointed out you will have to be more specific about what you would like. I find your description much to ambiguous to understand.

 

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commodore
Commodore

Hi Kevin,

Correct on the first point.

As to the second, from what I have read in their documentation THEY (the new 3rd party app) would be retrieving the message from US.  So they would have to have the user's password, they would make a scheduled connection and they would pull messages to their system, to be integrated into the user's Salesforce account.  The user would also have to manage the password changes with the app when their Groupwise password would change.

I DO NOT want to allow anyone to access our mailboxes except the users!   But I may be forced to allow this if at the end of the day management says just do it. I have explained to them we will have to expose our user's passwords, the entire user mailbox, and our PO in a way we do not want to do, ever.  We have Groupwise and we use SMTP and e-mail security, and it all lives behind a firewall for a reason, it is more secure.  We'd be completely bypassing all of that in my mind by using this app. 

If I had to do this, I would think I'd have to have these users on a completely separate setup for Groupwise email--on their own PO and GWIA--separate from the rest of the company Groupwise, but I don't think that is a good solution.  But I just don't know if there is anything else that is better if forced to allow this app to be used.

Does this make more sense?

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Hmm, running a bundle of domain, post office and GWIA for this purpose is not a bad idea. This environment will run in your DMZ. All you need is a communication possibility for both domains (MTA <-> MTA via port 7100). If you have to move users from A to B than you have to open POA ports too for this activity.

If there is a chance to forward those mails via SMTP to their system and they have to play around to bring it into their app, then it's easier for you.

(not really smart: if you forward these mails to gmail and they have to use IMAP via gmail?)

Diethmar Rimser
This community is more powerful if you use Likes and Solutions
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

@iliadmin wrote:

Hi Kevin,

Correct on the first point.

As to the second, from what I have read in their documentation THEY (the new 3rd party app) would be retrieving the message from US. 

I DO NOT want to allow anyone to access our mailboxes except the users!  

Does this make more sense?


Yes, Val, I now understand what you were trying to explain but, no, it doesn't make any sense to me at all! I can't believe that any company would permit a third party unfettered access to their employee's mailboxes.

The first thing I would do is contact this company and ask to speak to their support staff (or the pre-sales guys) and get whole story. Sometimes trying to glean information from a website is not the best approach.

I would also ask for a customer reference. Contact them and find out how they interface with this app. If it has to work as you describe, I would consider creating a new mailbox on your own system and forward (BCC?) all appropriate emails from your sales staff to that one mailbox then allow this third party organization access to the one mailbox that only has the email they need.

If you don't allow your own users IMAP access to their mailboxes, I would try to use an obscure high (5-digit) port and tell them that's how they get IMAP access! 🙂

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commodore
Commodore

The SMTP would have been my preferred setup as that is exactly what we had with iHance. Those messages were sent VIA our normal SMTP using a forward address, so they left the GWIA to our security ventor, and then from the security vendor to the app via the forwarding address.  No problem, worked like a charm for years.

In this new app setup, the app must fetch the messages from the user's mailbox, from a specific folder (so the user also has to remember to move them to that folder, but what if they are left in there and the app happens to check before the user can move them Well, the app will grab them as they will be new mail to the app.  That's a problem.) The company will have our staff's Groupwise usernames and password s(encrypted, they say) and no one has access to the credentials (uh huh). 

I can't believe companies just allow this type of access to the internal mail systems.  It's crazy.

As to the Gmail...well that's something to mull over.  Not an option we would wanto use as we do not allow forwarding of company email to personal accounts and visa versa.

 

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

@iliadmin wrote:

As to the Gmail...well that's something to mull over.  Not an option we would wanto use as we do not allow forwarding of company email to personal accounts and visa versa.


I can understand why your company might have such a policy. If they are that concerned about privacy I would discuss this situation with whomever created/approved that policy. I'm pretty sure they would want to have a say in this...

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commodore
Commodore

Kevin:  Already discussed. with management, they are in agreement. I was the creator of the policy, and I handle the security and IT policies for the company.  My goal is to find a way to make this work securely so that we are still able to track the leads, cases, and e-mails in Salesforce without exposing our internal mail system to a cloud app system.

Rimser:  when you say "need a way to connect (MTA<->MTA), what are you thinking of occurring?  Is it something like:  the staff would forward messages to a designated mailbox on the new DMZ po, and that MTA would have an IMAP connection for the 3rd part app to use to pull the messages?  Could it be set up to be a one-way connection, i.e, outbound only from the internal Groupwise server? How would I set that one way connection up? Not sure how to tell primary MTA to forward to a PO on another MTA?  Never done anything like that before.

0 Likes
Commodore
Commodore
I have been speaking with a rep from their company and they've told me "all their customers do it", and it is their only way of getting the messages. They specifically told me they do not use a forwarding address like iHance did and they won't be setting one up.
0 Likes
Commodore
Commodore
I also like the idea of the port number. I've been known to use them.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.