I have asp.net MVC 3 application that sending various emails such as client registration, activation etc
Currently using smtpclient and smtp server authsmtp.com. In last 3 months there was number times application used to hang when sending email and smtp is not responding.
I am now required to review the process and improve with following improvement.
1.) Application should not hang when smtp server is not responding.
2.) Queue email for later delivery if smtp server is not available. Re-try delivery for next 24 hours
3.) Add extra logging for email queued, sent or failed (After 24 hrs)
I would like to know what will best option to implement the above requirement.
The application is hosted in windows azure environment.
I thought to use MSMQ as provides message queueing and I can log the details once each task is started and completed.
Reference : http://dotnetslackers.com/articles/aspnet/Sending-email-from-ASP-NET-MVC-through-MVC-and-MSMQ-Part1.aspx
The problem is that MSMQ is not supported on windows azure.
Please advise ?
Thanks
There is an example on WindowsAzure.com that covers a similar topic as this http://www.windowsazure.com/en-us/develop/net/tutorials/multi-tier-web-site/1-overview/
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'm facing kind of SMTP mail problem sending through the application using coding as below
SmtpClient SMTPServer = new SmtpClient("smtp.office365.com");
SMTPServer.UseDefaultCredentials = false;
SMTPServer.Credentials = new System.Net.NetworkCredential("xxx#xxx.org","xxxxx")
SMTPServer.Port = 587;
SMTPServer.EnableSsl = true;
So been using this method 2 years ago until recently where we face email not able to send out intermittently with error message "Smtp Error: Failure sending mail". There are times where emails could send out with only average 12 emails per day. Plus, the sender email address from the application is active with correct credential login and password.
I checked our Windows 2008 R2 server and tested with our disabled firewall on server. Problem still persists. And there were no patches update to the server as well.
Is there anything to do with authentication type level? Or certain communication protocol conflicts? How do I check further to determine the root of cause? Our firewall already allowed the port 587 to send out.
There could be many issues to check. You say that the application is sending emails as a "client" to an Exchange 365 SMTP server to sent onwards, that's what the example looks like.
Check that Exchange is not rejecting the request. Microsoft can be very picky about application clients connecting directly. Look in the logs.
Check that your email application client uses TLS 1.2 or above. Many SMTP servers will reject requests below that level.
Exchange might be insisting on a STARTTLS for negotiation on credentials, so check if that is the issue.
Check that the application client is whitelisted in MS Exchange 365 if it is rejecting requests.
Check that the user you are connecting as has privilege to accept connections from remote clients. I often lock this down to prevent brute force password attacks.
Normally I would test all this out on the command line first. Get an email client for your OS like:
sendemail-1.56 by Brandon Zehm <caspian#dotconf.net>
Which is very good at initiating a connection to a remote server. Test from your application client email server and see what happens.
We have an utility for sending an email to customers. Currently we are using outlook for sending an emails, But once we send multiple email at a time we get the following error msg.
DEBUG SMTP: MessagingException while sending
com.sun.mail.smtp.SMTPSendFailedException: 432 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded
After debugging its found that we can't send 3 mails at a time. So thought another approach to send msgs by queuing the request and process the 3 request at a time while keeping other in buffer.
Note: Don't want to use any msq queuing service (like rabbitMQ etc)
Your suggests/inputs will be really helpful for me.
Thanks
If you are using MS Office SMTP (I guess from the error message), there is a limit on concurrent connection.
Documentation
Under the new limit, up to three concurrent connections are allowed to send email messages at the same time.
For some security reasons that I can't have a public accessible server to receive data from slack.
So, this is what I'm planning to do:
Inbound message from slack: using RTM API
Outbound message to slack: using RTM API or Web API
Questions:
Any better alternatives?
Any restrictions? (AFAIK, buttons and drop downs can't work)
If Web API reach rate limit, can I use incoming webhook as a backup plan?
RTM only approach
Yes, that would work. With only the RTM API you are limited to:
receiving and responding to messages
Other RTM events.
You can't use any interactive functionality like:
Interactive components (buttons, menus, datepickers)
Dialogs
Rate limit on message posting
Using the webhook as "backup" to circumvent the rate limit is not an option, since the rate limit of posting max 1 message per second applies to all form of message posting.
From the documentation:
In general, apps may post no more than one message per second per
channel, whether a message is posted via chat.postMessage, an incoming
webhook, or one of the many other ways to send messages in to Slack.
Alternatives
You did not give any details about the reasons why your app can't expose an endpoint to the public Internet. But you might want to consider using a VPN tunnel like ngrok.
Yes! Socket Mode
There is a new alternative from slack, Socket Mode, which doesn't require a publicly accessible server.
Note: this is only for private apps.
With Socket Mode you have an API token and your server uses it to communicate with Slack's servers and create a two way socket connection. This means your Slack Bot's code can run on a machine behind a firewall and not require any inbound ports to be opened.
Slack message delivery requires an acknowledgement once you get the message, or else they may retry to deliver it.
Limitations
Socket Mode has two main limitations:
Apps using Socket Mode are not currently allowed in the public Slack App Directory.
Socket Mode is only available for apps using new, granular permissions. If you created your app on or after December of 2019, good news: your app already uses the new permissions. Otherwise, you may have to migrate your classic Slack app to use granular permissions before turning on Socket Mode.
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH