I'm in a process of creating security software that will address a specific type of security problem. In order to do that I would need to gather information about all the mails that are sent using Microsoft exchange. The information needed is mail's sender, receivers and timestamp. Actually I don’t even need to hold the information on real-time just counters for each sender-receiver pair for specific time frame.
How can I do that?
Is there some Exchange's service that I can use to get this information?
Must such a component be installed on each exchange server (hub, mailbox server etc')?
Are there Exchange's logs or internal database that hold such information?
Related
My basic requirement is that I need to create "something" that is capable of intercepting emails incoming/outgoing from our mail server. It cannot be an extension to mail clients. Currently we consider only exchange server. In my research I found below resources that seems to be helpful.
Mail flow and the transport
Delivery agents and Delivery Agent connectors
Transport agents
From these transport agents seems to be quite old. Now I can't figure out what's the best from the remaining options(Mail flow and the transport or Delivery agents and Delivery Agent connectors).
Whatever I develop should be able to read email get some statistics (using mail header(s), amount of attachments etc...) and store it into a custom database. Additionally add some custom headers to incoming/outgoing mails.
Can anyone point me to right direction? Should it be some kind of a service that I can install in Exchange server? (admin center->mail flow-> connectors). For example, can I write it in c# and host it like an assembly? or may be a web hook to a hosted service where Exchange will forward emails in real time etc...
I couldn't find any examples/tutorials except this
If its OnPrem Exchange and you don't have or are considering Office365 then Transport Agents would be the right thing to use. They haven't change since 2013 but are still what is used for this type of thing the last SDK was 2010 but its still valid given the lack of change on the backend https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd877026(v=exchg.140)
Delivery Agents are more for when you have an external gateway that you want to send and receive messages from.
I am writing Exchange ActiveSync client in C++. I use FolderSync command for synchronize list of folders and Sync command for synchronize emails from server.
In IMAP protocol I use command STATUS INBOX (UNSEEN) for getting unseen emails in inbox folder.
Is in Exchange ActiveSync some equivalent command ?
According to the Microsoft documentation only the following is part from ActiveSync:
Support for HTML messages
Support for follow-up flags
Conversation grouping of email messages
Ability to synchronize or not synchronize an entire conversation
Synchronization of Short Message Service (SMS) messages with a user's Exchange mailbox
Support for viewing message reply status
Support for fast message retrieval
Meeting attendee information
Enhanced Exchange Search
PIN reset
Enhanced device security through password policies
Autodiscover for over-the-air provisioning
Support for setting automatic replies when users are away, on vacation, or out of the office
Support for task synchronization
Direct Push
Support for availability information for contacts
But you might wish to implement something via EWS (see here some example).
I am developing MS Exchange client using active sync protocol and i have implemented all the commands, able to fetch, read mails, can also mark as unread or can delete it. But now i want to manage the emails thread wise, so i am wondering if there is any way to manage email thread. I tried to find the thread index property but there isn't such a property like gmail or other imap protocol have. So i am wondering how can i implement it.
I have referred document from https://msdn.microsoft.com/en-us/library/dd299441(v=exchg.80).aspx but didn't get exact solution from there.
If you are using protocol version 14.0 or higher (meaning that the server is Exchange 2010 or higher), each message should have a ConversationId element and a ConversationIndex that you can use to group messages. There's more information in the ActiveSync Conversations Protocol document, [MS-ASCON].
XMPP sends messages only to highest priority resources of a given JID. See 1, 2 and 3
I want to create a client that will check all my current resources (home, work, mobile)
the client will be able to announce itself with one of those existing resources
the hope is that the client will be able to receive messages into multiple devices. This should work.... unless for some reason the service doesn't accept multiple clients with the same resource? is that something specified in the protocol? or something that implementations might choose to allow/forbid?
The full JID is a unique identifier, so you cannot be logged in twice with the same one.
If you want more than one client to receive messages, then this can be accomplished by having both of them (different resources) with the same priority and using a server which supports this type of routing. This is an option under the spec.
XMPP sends messages only to highest priority resources of a given JID.
This depeds on your server configuration or server software. There is also server software wich routes messages to bare jids to all resources.
You get all connected resources f your contacts with the presence. So you could also manual send the message to each resource directly.
I'm designing a system where one server must send messages to lots of independent clients. The clients doesn't know about each other and should not be able to consume, peek or in any other way acquire knowledge about each others messages.
I therefore wonder if JMS / ActiveMq have the ability to control which clients get which messages?
I want all the clients to connect to the same JSM provider (the 'destination') and consume only messages meant for them. This would be a simple setup from the servers point of view.
An alternative would be to acquire webservice endpoints from all the clients and perform ws-calls every time the server have a message for a client. I think this alternative sound 'wrong' as I think ws calls are bloated. There is a great overhead for each ws call, and this server would have to make 1000's of call each day. In my opinion this would be suboptimal for the server...
Short answer: Use Message selector.
Detail answer:
The question doesn't mention about how conversation is initiated. So here my answers for both scenarios.
a) If client initiates the conversation (i.e. Client sends a message to server and waiting for a reply).
This is a request/reply scenario. Messaging/JMS is a decoupled communication system. But request/reply is a common pattern in JMS. It can be implemented using correlation pattern.
A unique identifier(correlation id) is sent part of the request message.
Server receives the message and sets the correlation id in the reply message.
Client uses Message selector to receive the message with the correct correlation id.
b) If server initiates the conversation (i.e. Server sends messages to the clients without client request).
In this case, similar approach can be used.
A fixed client id is assigned to each client.
Server maintains all client ids and sets client id of the recipient as correlation id of the message.
Client uses Message selector to receive the message which has correlation id equals to its client id.
Update about confidentiality.
Following info extracted from this link useful for you to understand JMS security.
JMS does not specify a security
contract or an API for controlling
message confidentiality and integrity.
Security is considered to be a
JMS-provider-specific feature. It is
controlled by a System Administrator
rather than implemented
programmatically or by the J2EE server
runtime.
Two major features of JMS security are Authentication and Authorization. According to my knowledge, JMS security for client access is focusing on protecting the JMS destinations (not the individual messages). As long as a client has access to a destination, the security role assigned to the client is applicable for all the messages belongs to the destination.
Based on this,
Solution 1: If the client code is controlled by a trusted party.
Follow my solutions in my original answer.
This will make sure the message is delivered to the right person. But will not protect anything if the client code is purposely modified to receive all messages.
Solution 2: Assign private destination and user account to each client and configure security such that user account of a client can access only its destination.
Note: Found a link about "Restrictions for message selectors to provide message level authorization". But I think it is a vendor specific custom feature.
Hope this will be helpful.