Background:
I work for a defense contractor, and would like to setup DOORS such that it can email users. I have been able to get DOORS v9.x to email, BUT the our virus protection (McAfee) will not let door.exe to use port 25. Our IT policies are handed down from Corporate and I could get an exception to the policy on a single computer (i.e. if the server sent the email) but getting IT to change the whole policy would be next to impossible.
Questions:
Does anyone have any ideas that would allow me to programmatically tunnel through the DOORS connection to the server and email from the server?
If this is not a possibility, do you have any other ideas to use a 'bridge' between DOORS and the server?
I have been able to 'piggyback' on Outlook, but again there might be some corporate issues there, not sure yet. This method is still using the individual computer and I would prefer to email from the server if possible. If I can accomplish this I could email at certain times using active dxl columns and triggers.
Thanks
HiLbiLy - Mon Mar 15 08:50:16 EDT 2010 |
|
Re: DOORS email Mathias Mamsch - Mon Mar 15 18:39:14 EDT 2010
My understanding is, that when you set the DOORS server up to send emails, then the server itself will send the mails using the configured mail account (I might be wrong there). So there would be no need to change the complete policy, since you only need an antivirus exception on the DOORS server for the doorsd.exe process. This sounds much like the "bridge" between the DOORS server and the client that you described.
In another case (where the email server needed authentification, which doors did not support) we had to implement our own email gateway. We did it in python and used the DXL socket functions to connect to it. The email gateway would then forward the email to the mailserver.
In any case you will need the clients to be able to connect to a gateway (firewall policy change?) and you need the gateway to be able to connect to the mailserver (more policy change). Maybe using Outlook as "piggyback" is a very clean solution for this. I cannot imagine "tunneling" a connection through the corporate firewalls will give less "corporate issues", than automatically sending mails per outlook.
Regards, Mathias
|
|
Re: DOORS email PaulHutchinson - Tue Mar 16 07:42:01 EDT 2010 Mathias Mamsch - Mon Mar 15 18:39:14 EDT 2010
My understanding is, that when you set the DOORS server up to send emails, then the server itself will send the mails using the configured mail account (I might be wrong there). So there would be no need to change the complete policy, since you only need an antivirus exception on the DOORS server for the doorsd.exe process. This sounds much like the "bridge" between the DOORS server and the client that you described.
In another case (where the email server needed authentification, which doors did not support) we had to implement our own email gateway. We did it in python and used the DXL socket functions to connect to it. The email gateway would then forward the email to the mailserver.
In any case you will need the clients to be able to connect to a gateway (firewall policy change?) and you need the gateway to be able to connect to the mailserver (more policy change). Maybe using Outlook as "piggyback" is a very clean solution for this. I cannot imagine "tunneling" a connection through the corporate firewalls will give less "corporate issues", than automatically sending mails per outlook.
Regards, Mathias
My understanding is as follows:
1. The DOORS client is hard-coded to send data through port 25 to communicate with the SMTP server when sending e-mail notifications. Any other port could theoretically be used (in the range 1-65535) but DOORS does not allow a port number to be specified.
2. McAffee antivirus has a security option called "Prevent mass mailing worms from sending mail" that blocks any communication using port 25. By default this option is activated and in most companies users cannot modify this setting.
3. A DOORS client running on a PC where McAffee is installed (with the aforementioned option activated) will report the following error when attempting to send an email notification: "An error has occurred during the automatic e-mail notification process. Could not open a client socket to the specified mail server."
4. The antivirus security settings on the SMTP server are not the issue here (in this case outgoing traffic through port 25 will need to be allowed for communication with other SMTP servers and the antivirus software will almost certainly be configured accordingly)
In summary:
Core DOORS functionality (email notification) is effectively crippled because the port number cannot be configured to be compatible with a standard option in one of the world's most widely-used antivirus programs.
Solutions:
1. Send an enhancement request to IBM asking them to make the port number configurable (if enough people do this they may decide to act)
2. Create an alternative email mechanism (e.g. using Outlook automation)
|
|
Re: DOORS email HiLbiLy - Tue Mar 16 08:57:29 EDT 2010 PaulHutchinson - Tue Mar 16 07:42:01 EDT 2010
My understanding is as follows:
1. The DOORS client is hard-coded to send data through port 25 to communicate with the SMTP server when sending e-mail notifications. Any other port could theoretically be used (in the range 1-65535) but DOORS does not allow a port number to be specified.
2. McAffee antivirus has a security option called "Prevent mass mailing worms from sending mail" that blocks any communication using port 25. By default this option is activated and in most companies users cannot modify this setting.
3. A DOORS client running on a PC where McAffee is installed (with the aforementioned option activated) will report the following error when attempting to send an email notification: "An error has occurred during the automatic e-mail notification process. Could not open a client socket to the specified mail server."
4. The antivirus security settings on the SMTP server are not the issue here (in this case outgoing traffic through port 25 will need to be allowed for communication with other SMTP servers and the antivirus software will almost certainly be configured accordingly)
In summary:
Core DOORS functionality (email notification) is effectively crippled because the port number cannot be configured to be compatible with a standard option in one of the world's most widely-used antivirus programs.
Solutions:
1. Send an enhancement request to IBM asking them to make the port number configurable (if enough people do this they may decide to act)
2. Create an alternative email mechanism (e.g. using Outlook automation)
Paul,
You are correct. Basically everything in DOORS is client side instead of server side. The two solution that you provided I have explored: I have talked with IBM (UGGG) and they have given me nothing, and I have explored 'piggy backing' on Outlook (I have had some success). I was really hoping there would be a third solution: I could create a dxl that would move along the DOORS client-server connection, create a VBScript on the server which would be an email script, and then run the VB script on the server. Is this possible? Ideas?
Thanks
|
|
Re: DOORS email achao - Wed Apr 07 16:59:08 EDT 2010
It would be a lot easier to persuade your company to exclude doors.exe from the "Prevent mass mailing worms..." rule than getting IBM to change DOORS.
We have convinced our IT security to modify our McAfee settings.
In my opinion, the enhancement request is to have the "DOORS" server send emails from than the client. Changing the port to something other than 25 is not a good idea. Our ports are locked down and you do not want DOORS email using some other standard ports.
-Amy
|
|