Is there a predefined protocol / API that will allow me to create a plugin component for exchange (let's say 2007+)?
I need to write a simple spam filter that will communicate with the exchange server and receive every mail that is received by that server. If the mail doesn't pass a check, it will be deleted from the server before being delivered to the user. If it is ok, it will be placed in the user's inbox.
I am looking for a protocol that supports the following:
subscribe to receive a notification whenever an email arrives to the server (before the email is placed in the users' in-box.
get the content of such emails.
have the ability to block further processing on some emails (so they are blocked before reaching the inbox).
Thanks in advance,
May be u can write a transport agent(Exchange Server 2007onwards) which will monitor and act on all the emails flowing through the organisation.
You can get most of the details of an email via a transport agent depending on the event at which u trigger the agent.
Here's a link which gives a thorough documentation.
http://msdn.microsoft.com/en-us/library/exchange/bb204097(v=exchg.150).aspx
You can check body/subject and if it doesn't comply with any of the organisational policy,just clear off all the recipients and the email delivery won't happen.
Related
Background: I was handed the reins for our company's AWS account to implement a process to make sure our SES delivery report notifications can get acted on instead of just being filed away or deleted.
That said, the first hurdle is that the email address associated with our company's helpdesk keeps receiving all Amazon SES notifications for bounces, complaints and delivery failures. This creates a mess for our support staff in having to wade through these emails individually, and our ticketing system doesn't have the capability of auto-forwarding emails even though I can categorize them based on rules when they arrive.
I have read through all the knowledge base articles for SES notifications as well as ~380 forum topics relating to email notifications, but I didn't see an answer posted this question even though it had been asked a handful of times.
What we've done:
Set up a dedicated email inbox for these requests so we can then process them correctly (that we want to divert these messages to).
Created an SNS topic with the new email address as its endpoint and applied it to all categories, but the emails still kept going to support, so that clearly wasn't the solution.
Removed all hard-coded references to these emails from our software code, but we still get individual Amazon SES notifications to the helpdesk (~30 a day).
Simple idea, but AWS is pretty intimidating especially for our small company where no one has taken the time to learn through the ins and outs after first setting it up (fire and forget).
Edit for clarity, the emails I'm trying to redirect are "Delivery Status Notification (Failure/Delay)" and "Undeliverable:..."
Here's how i got this to work:
Under "AWS SNS"
Create an SNS Topic
Create a subscription to the topic that sends an email to your desired "catch address"
Confirm this subscription by clicking the link sent by AWS to this address
Under "SES Management - Identity Mangement"
Verify a domain or email address
At the domain/email address go to Notification and DISABLE Email Feedback Forwarding
Same place select your SNS topic for Bounces and Complaints
Under "SES Managment - Email Receiving"
Create a Rule set and then create a rule with the domain or email address above
Make the action the SNS rule above
When sending mail be sure that the From address is using the domain/email address above. All bounces and complaints should now end up in the catch address inbox. ALL OF THIS must be setup in the same region.
These notifications are configured either at a verified Domain level or at a verified email address level. This page has info on it. At the bottom, it talks about how you can confirgue to have messages sent to email or a SNS topic. You probably have a notification setup on your domain or the specific email address you are using.
You'll find all this in the SES section of the AWS Console under the Identity Management section. Make sure you check both the Domains area and the Email Addresses area.
You make the feedback address differ from the sender by setting the Return-Path header in your message (subject to a few other rules):
From the developer guide:
If you used the SMTP interface to send the message, then notifications go to the address specified in the MAIL FROM command.
If you used the SendEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified the optional ReturnPath parameter in your call to the SendEmail API, then notifications go to that address.
Otherwise, notifications go to the address specified in the required Source parameter of SendEmail.
If you used the SendRawEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified a Source parameter in your call to the SendRawEmail API, then notifications go to that address. This is true even if you specified a Return-Path header in the body of the email.
Otherwise, if you specified a Return-Path header in the raw message, then notifications go to that address.
Otherwise, notifications go to the address in the From header of the raw message.
My goal is to develop an Exchange listener that will intercept the organization mail box for new mails and for each mail it would do some logic.
After i've researched the subject online - i saw that there are two primary ways to do that:
Configure a new MTA (Mail Transfer Agent) that will be situated before the exchange server and will intercept the SMTP messages.
Use EWS API to subscribe to a new mail event and run the login on the listener
in this way i have 2 basic problems:
Is there a way to subscribe to all mailboxes on the exchange server? without looping all the users ?
How i can block a client to read his email before my listener handled it ? (can i move the whole incoming mail to a special default folder that the users wouldn't have an access to it - some king of hidden folder ?
Is there other way besides the two that i mentioned to fulfill the demand ?
Thanks!
You can use a Transport Agent on Exchange https://technet.microsoft.com/en-us/library/bb125012(v=exchg.150).aspx which allows you to capture/proces messages while they are in the Transport pipeline. The advantage of this over what you have described in 1. is that you capture every message sent/received on the server including internal messages.
Is there a way to subscribe to all mailboxes on the exchange server? without looping all the users ?
No you need to managed your subscriptions per mailbox folder
How i can block a client to read his email before my listener handled it ? (can i move the whole incoming mail to a special default folder that the users wouldn't have an access to it - some king of hidden folder ?
All clients are equal on Exchange so you cant prioritise a client or block access to a new messages (you can block the client entirely) , in theory you could move all messages that arrive to NON_IPM_Root folder with an Inbox rule which means the user couldn't see them but you might want to consider the implications of what happens when your process fails, this could also be disabled by the user at any time when they create a Inbox rule themselves.
User wants to send read receipts with all external emails. I've set up a mailbox rule in Outlook to do the following:
Apply this rule after I send the message
notify me when it is read
except if sent to *Bristol* //Dynamic group for office contacts
or except with #"domainname" in the recipient's address
To stop read receipts on internal emails I've set a rule with ECP via "Mail Flow" > Rules to:
IF
the message type is *Read receipt*
AND
The sender is located *Inside the organization*
AND
The recipient is located *Inside the organization*
THEN
Delete the message without notifying anyone
However it is still requesting read receipts for internal contacts.
Outlook and Exchange 2013
Your rule will only stop the delivery of read recipients not the prompting for which is controlled by a property within the message itself.
You could write a Transport Agent https://msdn.microsoft.com/en-us/library/office/dd877026(v=exchg.150).aspx that could do this by basically processing every message that passes through the Hub (or hubs servers) using the TNEF parser find the PidTagReadReceiptRequested and set it false for those Internal recipients. Probalby the best sample for this type of thing would be http://blogs.msdn.com/b/mstehle/archive/2009/01/13/howto-sample-transport-agent-add-headers-categories-mapi-props-even-uses-a-fork.aspx .
The other way that may work is to Setup a Rule Programatically that using the tagAction http://www.dimastr.com/redemption/rdoruleaction.htm#RDORuleActionTag . In theory you should be able to modify a MAPI Property with this action but there are complexities around this and I've never use it.
Cheers
Glen
In our SaaS application each company (tenant) is given their custom domain like companyName.ourapp.com
We would like to provide some email services like:
Ability to send and receive email notifications from info#companyName.ourapp.com and similar addresses
Ability to create new email accounts in clients' subdamains at runtime, programmatically, when needed. For example we would have separate emails created for each "opening" so that emails sent to this address would be parsed info would be extracted
Similar tasks
For now I just don't even know on where to look and how this could possibly work.
As far as I understand email it should be some kind of custom mail server (SMTP) serving all sub-domains and having API we can use to send emails, list and retrieve messages etc.
Please suggest how it may work and is there any components out there we can use to implement this.
There are three options for this.
Create an email server and programatically configure it to accept or deny the specific accounts. Then use cron to poll via pop3 or imap and download the messages for the account. You can then send them on for the customer or handle them in your web app.
Create a script that is fired by the email server as it receives each email. The script can then handle what to do with the email as it's received.
Use a third party to receive the email via HTTP Post at your app. Using CloudMailin for example would allow you to create a custom authorization filter that would call your app in realtime and determine if the given account exists and messages should be accepted for it.
I wrote a blog post for Rails about receiving incoming email, however the principals would apply to any programming language and framework.
I have a web app that only registered users can use, therefore I should have a valid e-mail address for the creator of the message.
One part of this web app will allow a user to create and send a e-mail message to an e-mail address that the user enters. My web server will be creating and sending the e-mail, however if there is a delivery problem with the e-mail I would like the bounce to go to the user's e-mail address instead of the server. This will allow the user to know that there was a problem delivering the message and they can take the appropriate action.
Would setting the "return-path" attribute to the user's e-mail address handle this?
As RFC2821 says:
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
So yes, all standard compliant servers should account for the Return-path you set.
You could set up windows service on your server to periodically check BadMail folder and parse the bounced messages and resend them to the original sender. This solution would work in most cases. I don't think return-path would help in every instance (if it would at all), because different mail servers handle bounces differently.