I have windows 2003 server with about 15 C# windows services sending emails randomly based on some complex business logic. It is a very difficult to find out which application sending emails to whom at what time.
For additional info, the server has McAfee client installed and configured by admin that which application can send emails.
Is there any way I can find out which application is sending email to whom?
If you can't store the information required in a database, then generate log files specific to your need. I'm certain you don't need code to tell you how to have your C# services generate log files that contain all the pertinent information (date/time, service name, email address, type/id or some content identifier). You can then use the logs to generate whatever reporting you need, and if build with configuration, you can turn off the logging once you have enough information to answer the question.
Related
** Edit - Based on further questoins **
I'm writing a c# application, that uses ConfidentialClientApplication. I have set up the application in azure and can connect and get a token.
The software will in fact, reside on a server, it will look something like this:
A backend process will query the mailbox and get either a) A list of messages or b) the first message available
It will download hte message and strip any attachments for further processing
Once the processing is complete, it will need to move the mail to a folder, so that it is not processed again
I want to be able to pass the application, the mailbox name and the password to connect to it, a bit like POP3/IMAP. So far, I can get a token, but anything beyond that, just barks that it doesnt have access, quite rightly.
So how do I take this one step further, and either:
Grant the application access to a specific mailbox using azure portal
or
Configure the application to read the mailbox from a settings file and connect to it?
Many thanks!
Tirm
Here's what I'm trying to accomplish: users have a need to create an email address through a web app (basically, it uses existing information to create custom, unique email addresses). Currently, the web app just generates the name, then they turn it over to us, and we run a PS script on Exchange to create the box. I'd like the box to be created when they request an email on the web app. There's probably like 10 ways to do this, but I'm thinking it would be a webservice that passes the email name to a Windows app on Exchange that executes the script and returns Success/Failure/Etc.. Does this seem viable. I'm not sure how to thread the process of running the PS script. Does anyone have any thoughts? I'm not looking for someone to write the code, but perhaps have some architectural ideas.
There are several methods but the "easiest" one that pops into my head is as follows:
User logs into create-an-address web app
They submit a request into the app which stores the data in a SQL table (if exists)
STSS/DTS package produces a CSV output of date+ new entries and drops it into a Temp directory
Or skip the database and create/append a daily CSV-formatted file direct from the web app.
Scheduled job runs the powershell script which parses the CSV via for-each and creates users & mailboxes as needed. If user exists, only add smtp to existing mailbox or whatever your requirements are
Powershell deletes the file if success or moves to another folder for investigation if failure occurs.
We've done similar data ingestions for various applications and it works well. We add email events into the script for success/failures but we like the database approach because can ingest the CSV status with other STSS packages for historical reporting
It's my first question/post :-/
Background to question:-
I have an ongoing project which is an Azure hosted ASP.NET solution. Its a generic ERP and is intended for small enterprise businesses. An additional requirement came up and I'd like it to be part of the Azure solution (previous attempt to create a VSTO add-in went bad).
I've been asked to automate this process:- Users spend a long time (daily basis) manually saving emails into network shared directories according to what company project the emails relate to. E.g. everytime Sally sends or receives an email, she copies and renames the .msg file from outlook into her "G:/" drive (which is just a network share on the enterprise LAN). Someone else in the enterprise has the job of creating a specific directory structure for sally (and her co-workers) to save the emails in (e.g. Correspondance-In, Correspondance-Out etc..). Staff need to be able to search the directories for messages based on some scraped meta data.
I'm considering an exchange web service managed API application in Azure which has a service that polls the Exchange Server (for every user) with a pull subscription to identify new/changed mails. Each identified mail will be then assessed against a rule that the user has pre registered in my application (i.e. from person x with project ID in the subject field). The application will then rename the email and put it in the network share (also scrape metadata to provide search functionality).
Question:-
a) How do I get my remote application to request the Exchange Server or CAS to export the MailItem to a local network share using exchange web services in the most efficient way? Preferably without having to deploy something into the enterprise.
b) is this a ridiculous solution?
Additional Info:
I expect the typical environment to be quite old. However, I can assume Exchange Server 2007+ and Outlook Clients 2007+ on Win7 (no Office365 though and no sharepoint). I decided to use a pull subscription as it will be a loosely coupled environment and therefore assumed streaming to be not the best fit.
MailItems are likely to contain large attachments (CAD drawings etc) so for obvious reasons, I would like to avoid pulling these across the WAN.
I have investigated the potential to create server side mailbox rules with EWS therefore allowing this exchange server to manage the export - however if I understand correctly, rules don't support exporting MailItems to the filesystem.
I am trying to make a program that will listen to if I recieve a E-mail I got a smtp server and so on.
I want to make a database object with Title and text from the Mail and I might want to evolve it into also saving the attacted file to the database so I can use it it my asp.net program.
I think I need a windows Service that will be listening to the email if it gets a email it will add it to datbase and wait again but I am not sure how to do that. if its possible to program that into my asp.net project then it would be a good thing also
Here is a small design on how I was thinking about it
if you know anything about it feel free to come up with any kind of solutions for me.
Read incoming emails with POP3 or Exchange. I've made something similar before, which was a system where users could add links (a type of linking-scam actually) to different websites. So there was a bunch of people in Asia that had a full-time job searching for relevant sites and emailing a list of these URL's to a specific email-address. A service I had running would check the POP3 inbox every 5 minutes or so and then post these links to the website.
You should make an application that gets run at specific intervals rather than a service, which is much simpler. If you're using Azure as a host you can use the scheduled task service there to make a POST call to a page on your site so you don't have to run the code in a different eco-system. Well, I guess you can do that anyway with scheduled tasks in windows.
Here's a POP3 client for .NET
You could make a C# service that checks the pop3 server in a configured interval, and store them in the DB. There's something like this here:
http://aspsnippets.com/Articles/Fetch-and-Read-emails-from-POP3-mail-server-using-C-and-VB.Net---Part-I.aspx
But as a regular application, you just have to make it to run as service (I think you have a project template for that in VS). You have some info here:
http://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx
Okay I figured out a good solution for this problem friends :)
What I did was I downloaded the EAGetMail and implamentet it. it basicly works for you in a time interval it will check your mail and make a txt file with all the mails so it wont read it again. it also got a aplication field so everytime it runs it will run the selected application.
So I made a console application that runs trough my folder where it will save all my email's as .eml file. It will check for a sub folder called read if its not there then create it and then check the root folder for .eml files read them and save information from it to the database and then move the file to read.
We did not want to use pop3 cuz we wanted the mails to stay intact så we dont lose any information. so we ran for the IMAP4.
and in the asp.net I just run a query that checks the database and use the files.
I am trying to create a simple web email client in C#/ASP.NET. I am trying to use Aspose.Email DLL to connect the to the email server via IMAP and show the emails to the user. Now I am thinking of storing the fetched emails on the filesystem/database or simply fetching and showing these emails on each request.
I think storing email body for all users might increase my database size, but then users would want to page through the results. What is the best strategy to handle emails once fetched via IMAP?
Some regular desktop email clients download emails in advance and store them locally so that they can be displayed more quickly to the user (and for other practical reasons pertaining to search and even navigation, as you mentioned).
Others download the headers only (enough to display a list of emails in a folder) and then download the full body only upon request (when the user opens an email in the list). In the end it's just a tradeoff, and you have to see what works best in your scenario.
Personally I think downloading all emails in a folder at the start is overkill and I've seen clients get stuck for hours downloading emails for particularly large folders. A good option would be to display just enough to show a windowful of information, and get the rest as the user scrolls down - but that's not trivial to implement. Anyhow, the IMAP4 Implementation Recommendations teach you a few tricks to optimise communications with the server and avoid many common pitfalls present in the more popular desktop clients.
If you're worrying about your database growing, you could store only metainformation in the database, and keep the emails themselves on the filesystem (e.g. save them to .eml files). Again, the best solution may vary depending on your particular context.
You can use MailSystem.NET. It is an open-source .NET mail library.