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.
Related
Java 8 here, although this really is more of a generic Exchange/SMTP question I suppose.
I purchased a domain name and Office 365 support from GoDaddy, and as a result, have several email addresses through them. Let's say one of these is support#myapp.example.com.
I am writing a Java 8 app that will allow users to send emails to this support address (through the app). I will likely use the excellent Simple Java Mail library, which wraps the Java Mail API. And so somewhere in my app there will be some code that looks something like:
Email email = EmailBuilder.startingBlank()
.to("MyApp Help Desk", "support#myapp.example.com")
.withSubject("Support Ticket #12345")
.withPlainText("Something went wrong inside the MyApp!")
.buildEmail();
Mailer mailer = MailerBuilder
.withSMTPServer("smtp.host.com", 587, "user#host.com", "password")
.withTransportStrategy(TransportStrategy.SMTP_TLS)
.withProperty("mail.smtp.sendpartial", true)
.buildMailer();
mailer.sendMail(email);
Pretty straight-forward stuff, right? Except I'm confused about one simple thing: which SMTP server am I using here? Would I use the Microsoft Exchange server that my GoDaddy account provides me, or would I choose something else?
That depends a little bit on what you want to do.
If you just want to make one attempt to send the mail, you connect to the mail server that accepts mail for support#myapp.example.com. It sounds like this is an office365 server owned by Microsoft that accepts mail for myapp.example.com. There should be public DNS records for that domain. I haven't used the Simple Java Mail library, but from your pseudocode, I assume it does the DNS lookups for you.
It sometimes happens that an application encounters errors when trying to send an email. For example, somebody could restart your app server in the middle of the smtp conversation, or reboot your router, or something else. It's pretty common to use a Mail Transfer Agent (MTA) such as Exchange to help make this process more robust. If the MTA fails on the first delivery attempt, it will retry delivery for some configurable period of time. In your case, you could send the email to your Exchange server, and it would route the email to myapp.example.com.
(In this case, Exchange is sort of acting as a Mail Submission Agent (MSA), but that's kind of a nitpick.)
Hope this helps.
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.
I was setting up two new Exchange 2013 servers with MBX/CAS roles and added them to the existing send connectors that route mail through a smart host. Apparently the guy who quit before I started never got the networking team to whitelist the IPs for these servers. Now, I've got a small chunk of mail sitting here that won't send because of this. My networking team says that they can't do anything about it until tomorrow night. I'm afraid that some business critical mail may have got caught before I noticed what was going on. My question is, how can I re-route the mail stuck in these queues to go out through the send connectors from the previously implemented Exchange servers?
First of all, you should remove these servers from the send connectors to avoid more messages being stuck. You can either remove them from GUI console or by using cmdlet Set-SendConnector
Check here for more details about Set-SendConnector
Secondly, you should export those messages stuck in queue as .eml files by using Export-Message cmdlet.
Check here for more details about how to use Export-Message
At last, you can put all these .eml files under Pickup or Replay folder on any working transport servers. The transport service will pick up all eml files there and submit them to re-transport.
Check here for more details about Pickup and Replay folder
Closely monitor the queue and ensure all emails are delivered, then you are good!
All of a sudden, our exchange server has started sending out emails to .com.br addresses from accounts that do not exist in our organization. For example:
sadfjkh32#myorganization.com
sasdfsdkh4352#myorganization.com
sadhdf#myorganization.com
Please help.
You should review your recieve connector configuration to make sure you are not allowing someone to relay mail over your server.
Aditionally use the message tracking in esm and look for those emails.
Try to find the source IP address of those emails, meaning where they are generated.
Are they generating from an application server on your network. Maybe a scanner device, a pc...
As soon as you find the ip address you will have a better idea what is going on
Liran Zamir
We are building a web app that should be able to receive SMS messages and store the information contained in it in database.
Which methods have you used? Which service providers are out there that can assist?
http://www.clickatell.com/ are massive and it works exactly like it says on the tin. You pay for a phone number and sms messages sent to that end up hitting a URL on your site to deliver them just like someone posting a form.
I'd recommend using a service such as TextMarks. TextMarks is free, and lets you pick a keyword for your service that allows users to route messages to you through TextMarks' shared short code, 41411. The only catch here is that they reserve 20 characters in each message for short advertisements to pay for their services.
If you ever outgrow their ad-sponsored services, you can upgrade to a premium version that doesn't include ads.
Another (cheaper) alternative is to have your users send text messages to an email address like sms#yourapp.com. Then you can have a background thread that's looking at the email account and puts the messages into the database.
I've implemented and tested this approach with major US carriers with everything from smart phones to pay-as-you-go "crappy" phones without a hitch.
When the user sends the SMS to your email address you get the SMS email gateway address (e.g. 8055551234#vtext.net) so you can send response messages.
The only downside is that it's a bit more difficult to find the "send to email address" options on most phones, but it is (basically) free for you. This is especially helpful for reducing costs while testing out workflows. Those ~3 cents for each SMS add up pretty quickly, especially during automated testing.
When you want to support SMS numbers you can configure most SMS gateways to send an email to an address, so you won't have to change your infrastructure to support a "real" SMS messages.
I haven't done it yet, but I guess you could also setup an Asterisk system on your server, then get a regular VOIP acccount (which Asterisk hooks into) and configure the Asterisk server to forward all SMS to your application. This article might help setting up the Asterisk server.
I've had experience using MX Telecom as an SMS Gateway. Essentially they posted data to our web service every time we received an incoming SMS. The application in question was also sending SMS messages as well and we just did an http GET to a web page of theirs.
I can't speak to the business end (i.e. cost), as I was just in charge of implementing the features - but working with an SMS gateway is really very simple from a development perspective.
+1 on sebastian i was jsut writting pretty much the same
if you are working with ruby you might want to have a look at adhearsion
You can use SMS gateway software which will receive SMS messages through a GSM modem or 3G dongle connected to a PC and POST them to your website via HTTP. Eg: this software