Status as of Monday February 9th, 2009
New Page 2
Testing Status Issues:
- Issue 1:
New environment with Telus is a shared MS Exchange 2007 server. Current standards for security require SMTP authentication. This authentication was never deployed within the current Bell connection model and can not be disengaged in a shared environment. All companies and vendors would be required to make coding changes to their programs in order to support SMTP authentication, and then distribute these changes, therefore this is not an option for the community.
Status:
Resolved with 3rd new solution.
- Issue 2:
CSIO Standards allow for only one attachment within an email. That attachment is in fact policy data to be processed by the receiver. MS Exchange 2007 is adding plain text attachments to these emails. Although these attachments pose no risk to processing of data, some systems of the companies and vendors will see these attachments as either more policy data or "SPAM", and therefore need to be removed. This removal will require special changes to the Exchange server with help from Microsoft directly.
Status:
Resolved with 3rd new solution.
- Issue 3:
Currently most parties connect to CSIOnet with a MS VPN connection that is installed with all MS Windows O/S. Although this configuration is standard on a workstation connecting to Bell, the configuration at Bell is not standard. Through testing we have learned that Bell's configuration is proprietary and custom built for CSIO and their other customers. That configuration, due to privacy and security, will not be shared with CSIO or Telus by Bell. We were also able to learn that some of the connection models use technology no longer available or supported, and therefore needed to find another solution.
Status:
Unchanged - stable
With the mandate of providing CSIOnet via a VPN connection, and not providing an internet connection, the next and better option was to move to a browser based SSL VPN connection. What this means is that all parties using CSIOnet have the task of getting to the internet in what ever means they choose. This could be via a dial-up modem, high speed connection, T1....after which, that party will need to go to a URL for CSIONET.COM and login there. This login will then create the more secure VPN connection to Telus. What ever software is being used currently will need to look for the SMTP and POP servers to exchange policy data. Most, if not all, software currently performs this today and does not have a custom coded connection to Bell.
- Issue 4:
During testing we found that the Exchange server was requiring authentication for the id and the domain. i.e. be0001a@broker.edi.csio.com. Currently under the Bell solution, only the id is authenticated and it has been found that most parties have coded to send only that information. Random surveys with those currently using CSIOnet have found that this is easily changed by the end user, however, our goal is make as few changes as possible.
Status:
Resolved with 3rd new solution
- Issue 5:
Currently when emails are sent, the subject line is all on one line. Global communication standards mandate that this can "wrap" or "fold" to a second line.
Status:
Resolved with 3rd new solution
- Issue 6:
Approximately eight insurance companies require a direct connection to Telus. This would be an IPSec firewall to firewall connection. Under the Bell connection this was a frame relay connection and a costly connection, approximately $1800.00 monthly and monitored by Bell. The Telus solution is a current supported technology, and if managed by Telus, approximately $670.00 a month. Getting connection requirements from both sides of the connection model has been difficult.
Status:
All parties with this connection are connected.
Issue 7:
Stress testing – mass files and policies sent and received – have been timing out in the connection to Telus.
Status:
Resolved with new 3rd solution
Issue 8:
Delivery Notification from the Qmail server (3rd solution) does not support Positive delivery notification. i.e. it does not notify if a successful delivery has taken place, only if there is a failure in delivery will a notification take place.
Status:
The new James Apache solution does support positive notification and has been successful in testing thus far. We are looking for more confirmation from more testers.
Issue 9:
Files are sent in sequence of generation but received out of sequence.
Status:
Resolved with the new James Apache solution. Two members have confirmed this success and we are looking for further member confirmation.
Issue 10:
Line feed issues are causing some errors in the header of the files.
Status:
The new James Apache solution addresses this issue, however, another issue has arisen in that the original code for connection to Bell required RFC standard support but was not fully implemented. We have one party who is experiencing issues because the standard is not fully supported and Netscape messenger did not fully enforce those RFC standard rules. We are looking for confirmation that all other parties are fully supporting the RFC standard to determine our next steps.
|
