Repudiation issue within Outlook/Exchange

Well, you could trace the IP in the SMTP header? If you have static IPs in your network that should be quite simple, and if you use dynamic IPs you can look up the DHCP logs to find the computer used. Then it's just the matter of linking the computer to a person, which can be done by matching the login times with the time the mail was sent.

Hi,

The SMTP Header scenario depends on the transport mechanism the client is using to connect to the Exchange server for sending the email i.e POP3/SMTP or MS Exchange transport (RPC) which is the default in a LAN type environ.

In an MS Exchange environment; If you dealing with an email between 2 accounts that reside on the same mail server - where RPC is used for connectiuvity (default) the Mail internet Header would not show any SMTP Headers to help id the sender's machines - It would be blank.

This is because connections to the Exchange server from the local Outlook client in a LAN type environment would be over RPC not SMTP (by default).

If you are dealing with an email sent between 2 accounts hosted on 2 different mail servers (where SMTP is the delivery mechanism between the 2 exchange servers is over SMTP); the Internet Mail Header would show you the IPs' of the mail servers not the IP of sending client.

Using Internet mail Headers in such circumstances You will not be able to ID who sent email from that 'shared' account, but may be able to identify the server it was sent from, unless you use POP3 with SMTP as the transport method between the Outlook Client and the Exchange server; then the SMTP header info will also record the IP of the sending client machine. One Caveat being one is assuming here that no IP spoofing has occurred prior to the email in question being sent.

Avail transport methods for Outlook client includes 'MS exchange' (RPC); POP3(with SMTP), IMAP4, HTTP, 3rd party.

Also; take a look at RPC & IMAP logging & Object Acces (auditing) in MS.

Thanks & Regards,

You could get a somewhat limited audit trail using smtp and pop with exchange. However, I think you will notice a big performace hit – if you have a good size organization. I also believe you could capture more details in MS Exchanges audit logs. However, the amount logs and traffic to wade through will be enormous - and again you are going to take a performace and throughput hit.

There are two concepts - mailbox with a community user and password – everyone logins as Support Services, or shared profiles - each user logins as themselves and access the common mailbox or data store. Only the first will "hide" the true identity of the orginal user.

I understand the need for this setup - however this causes a security identity problem. There is not a clean solution. The best is a procedural solution. Only one computer is allowed the Support Services account. That computer is operated by the shift leader or person filling that position. Procedurally, the shift leader has responsibility for the shift lead computer and email account. Only shift leaders have the userid and password. Outgoing shift leader logs out and oncoming shift leader logs back in {creates audit record}! That is part of the transfer of authority. If shift leaders change - then the password changes and the shift leaders sign for the new password.

Any other solution requires duplicating inbound emails and creating outbound aliases. Then there is the actual message management headache - duplicated responses or no responses from various users.

You would not think that something this simple would not have such a complex or impossible solution. I fought this problem going back to the initial Exchange release and NT 3.5. The situationt has only gotten more complicated and difficult! Wish you luck!

You could load something like GPG or the commercial PGP, and require that all outbound e-mail are to be signed.

Issue a private key for each individual who uses the same mailbox, and stress the privacy of such keys.

This would, in essence, force a "log in" per e-mail.

A terrribly weak mitigating solution, to a horrible problem, but a solution.

Yes, use send on behalf rights and remove send as rights. Send on behalf shows what mailbox the message was sent from as well as who sent the message. Instructions below. Don't forget to remove the send as right, as this seems to superseed send on behalf.

http//www.cryer.co.uk/brian/msexchange/exch_howto_grant_send_on_behalf_of.htm