i have the current scenario:
my app generates for each user an
valid system email address of form
lets say: uuid#website.com
when an user has a problem/question he can send an
email from any address to that
predefined system email address
the app should receive the emails sent by the user and process them(check for spam, insert in db)
in this scenario a possible first solution that i had in mind was to pool the emails addresses on a 15 minutes period, process them(spam or not spam) in an external desktop app(or similar) and insert them in a database.
because i want to do this in .net, C#, SQL server 2008, and it should run on a webserver is the below solution possible using WCF?
i create a WCF webservice that when an email is received by an email address it captures it and starts the processing procedure.
One problem i see with WCF from the start is that i don't think that it can auto react, the only way i used wcf until now was only for calling it directly and receiving a result. So i think another layer should be put between the email server and the wcf service and that layer should "react" when something is received.
the main idea is to process the emails as they arrive not to be pulled out of the inbox periodically.
any pointers? thank you
You are right. A web service cannot capture anything for you. You will have to call(using an .ashx/or etc) the web service. That is what the web services are for, to be called.
the app should receive the emails sent by the user and process them
It sounds like you are looking to develop an email client; if so, then how about:
Create an email client app (for instance here)
Create a windows service, to help process the mails.
Assuming that you've tailored the client program, the windows service would work-with the client, look for new messages, and processes them accordingly.
For email client examples, checkout:
This answer
And this article
If connecting to Exchange 2007 SP1 or later Exchange Web Services looks like the best approach:
Read MS Exchange email in C#
Related
We have a desktop application that needs to send emails on behalf of our clients (institutions), to our client's clients (real people).
After investigating about creating an intermediate web service that will hold our secret key, and retrieve oauth2 tokens on demand from the desktop app, then the desktop app uses that token to make google api calls to send emails.
I've come to the bulk mail guidelines
and I'm afraid the mails would get marked as spam (as they will have different senders)
We need to make something like thunderbird but only for sending notification mails.
Is there any other way to do this? How so?
Using Gmail for this is NOT going to go well.
Instead, as you are working on behalf of institutions you will do better to pick one of two options:
Require your clients to provide credentials for their own smtp servers as part of the setup process for the application.
Run your own smtp server (which is NOT trivial, but still doable) and require your clients to include your server's address in the appropriate places in their DNS so your server shows as legitimate sender for their domain.
As the main systems administrator at a small college, I've had to do both kinds of setup for various applications.
If you go option 2, get a real server with a real IP. I've had application vendors request to add SPF records for whole AWS ranges, and I am NOT going to approve that.
I have created a WCF SOAP web service in C# and a C# application. Other users will work with the application and are trying to get information from a local database via the web service.
Now is it possible that the web service can go down. Then I want as quickly as possible, let's say getting an email.
I can let the application which is by the users sending an email when they don't get a connection with the web service, but there are more than 10.000 users. And I don't want to get 500 emails when there are 500 online.
Is there a better solution for getting an email when my web service is down?
I would suggest a sort of heartbeat program that runs on another server / location.
This will not only test the server, but also your internet connection for example;
Will work even when the power is down.
There are programs to do this already. The only I know is Microsoft System Center and Nagios.
There are a lot of monitoring software packages out there if you want a pre-made tool. The company I work for uses New Relic. (http://newrelic.com/server-monitoring).
If you add a simple function to your webservice, that simply returns true, you can call it periodically (maybe every minute?). If it times out, your service is down, and your monitoring program can email you.
I have a web application from which emails should be sent after specific actions. I have some alternatives for handling this I'm not sure which one is the best.
The first is that, when a user does an action the email is being sent directly from the ASP.NET application. But I think this is not a really reliable system because if the SMTP server is down or something else happens, the user just gets a feedback that his action cannot be completed.
As an alternative I was thinking about implementing a queuing system for what I have some ideas:
Push emails to send, into a database table, and a service application periodically checks for new messages, then sends them. On successful send it marks the email task completed.
Use MSMQ for queing. In this case the whole email could be passed as a message; or the other way is to store the message with attachments into a db table, and pass only the data which is required to query the db table and send the message. In this case I don't have to deal with size limits of MSMQ (because of attachments).
something else, like a local WCF service to notify the service
Which way you think is the best?
Use MSMQ is not good solution since has a limitation of 4 MB of each size. http://blogs.msdn.com/b/johnbreakwell/archive/2007/08/22/why-is-there-a-4mb-limit-on-msmq-messages.aspx
Worse case scenario, if MSMQ is failed like it process throw error or suddenly shutdown, it will loss many message. In my case, this solution is good when hardware and software is instaled in almost ideal
Use database and window service is better since it is a simple and doesn't need much effort.
I usually use a combination of database and file. The database contains table to save a header information and a flag that message has been action (either success or error or else) and files contains message (either html or plain) and attachment in original format.
When process is run to send, it is quicker to assemble a message from files rather than from querying blob/clob.
Since they are using file system on the application, you can add hardware like server or components or else to add availibility of the system easily.
Database can be added too, but it will cost you more license in databse software.
I add a test send email after send email in x times to make sure it is works well; this test email is send to my self or dummy inbox and an application to check the test email that is the same email that send and receive. If it is the same, sending pending email will continue again
Another way if you are using MS Exchange, you can use message queue by utilize its web service to queue send. This is an easy way but you need license.
You can see on MSDN library how to utilize MS Exchange web service.
You can use an email server like hmail. In order to push emails into a queue, you can push them to a mail server. To do that, you can write a windows form application that has a timer object that checks every row that has a Status 0(not sent) in email table. When the thread sends it to the mail server, it will be marked as 1(sent).
You can also classify your emails if you use DB. Different actions can send different emails. You can store this info in DB also so that your windows form application thread will now which email template to send.
I have many applications across an enterprise environment and they all use different methods of sending emails. Some send directly through an exchange server, some queue up locally in an SMTP queue and others call a a web service that then sends the email.
I'm trying to decide on the best way to get guaranteed delivery of emails. If our Exchange server goes down, then the applications that send to it directly can no longer send emails, also any emails sent during the down time never get anywhere. I would also like to implement a universal templating solution that all applications can share.
Are there any pre-built solutions to this problem, or do you have an insight on how to handle this issue?
We solved this by creating a web service that sends all our emails. This web service uses the
System.Net.Mail.SmtpDeliveryMethod.PickupDirectoryFromIis
setting, which essentially saves the files to a spot on the disk, tries to send them via the main SMTP server, and if the server is unavailable, they sit in the directory until it BECOMES available.
Guaranteed delivery, as long as the web service is up. Since we have redundancy checks in place, this is almost never an issue. If it is, we treat it as an error in code and handle it.
edit - added
I forgot to mention that XSS is a concern even in an email, so be sure to use something like the Microsoft.Security.AntiXss library, which contains functions like GetSafeHtmlFragment to strip out potentially dangerous scripts before outputting html to an email.
http://msdn.microsoft.com/en-us/security/aa973814.aspx
http://msdn.microsoft.com/en-us/library/aa973813.aspx
I have heard good feedback about Postmark. Maybe a service like that could be solution as it has several integration points.
http://postmarkapp.com
We have used HMailServer (on windows platform) which is freeware. Configured the max retries to too many & used external smtp to relay the emails. our applications ques up emails on the HMailServer and that server relays it further. with the max retries configured to be many if at all the main smtp servers are down we can assure that the email are delivered - but though there is no gurantee if there is huge downtime with main smtp relay servers.
I do this by queuing email to a SQL server database. Any ACID compliant database will work or you can use MongoDB with 'safe mode' inserts but if you really need guaranteed then use SQL server or MySQL. This way if your mail gets into the database it is 'guaranteed' not to be lost and your app doesn't have to think about it. You could use a web service or just make a shared assembly with a static public method in a class to drop your email in the db for you.
Include a column for status like 'new', 'delivered', 'recipient mailbox temporarily full', which you can represent with numeric values and keep a TimeToSend column, which starts out as the time when the email is queued in the database.
Then you have a mail app, that you can have run once a minute as a windows scheduled task. Make it as a console app. When it loads, it checks if an instance of it already running and if there is one, it exits. When running:
1. Attempts to deliver each mail to mail server. Query the database for all mail where the TimeToSend is older than now.
2. If mail is delivered to mail server, mark it logical deleted.
3. If any mail can't be delivered, advance the TimeToSend column for them to 10 minutes from now.
4. Delete records from table that are logically deleted. You can do this in the app or you can do it by having a sql job do it.
As mentioned earlier, you can utilize a web service that you can usually POST JSON to using an HTTP request. Here are a bunch of choices:
PostageApp (Ours!)
SendGrid
PostmarkApp
Amazon SES
They all have different feature sets and offerings, so definitely give them all a spin and figure out which you prefer.
(Full Disclosure: I am the Product Manager of PostageApp.)
I have a couple of web applications which all utilize sending emails whether it be by contact form, or some kind of notification updates etc.
The problem I have found is that there isn't really any way to track the emails which are being sent from the web applications, so I've come up with a possible solution:
It's pretty straight forward really - instead of having each web application sending the emails themselves I would like to unify the process by creating a central Email Sender Service.
In basic terms, each application would just create a row in a 'Outbound Emails' table on the database with To,From,Subject,Content data.
The Email Sender Service (Win Service) would then pick the emails from the outbox, send them and then mark as sent.
Even though I would store 'basic email' information (to,from,subject,content) in the database, what I would really like to do is also store the 'MailMessage' object itself so that the Email Sender Service could then de-serialize the original MailMessage as this would allow any application to fully customize the email.
Are there any problems with using the MailMessage object in this way?
Update: Another objective, is to store a log of emails that have been sent - hence the reason for using a database.
A far better architecture is to have the applications call some sort of public interface on the send email service. The service itself can then be responsible for recording send in a database.
This architecture means that the database becomes internal to the service and so reduces the coupling between your applications (each application knows about a relatively small public contract rather than a database schema). It also means that if you do find some problem with storing MailMessage objects in the database then you can change the storage method without updating all of your clients.
Why use the database? Simply have the applications call your email service directly, providing all information.
If you'd like to queue up the sends, then you can use a net.msmq binding with WCF, which will store the requests in a reliable queue that the service would read from. All of this would be done for you.