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
Related
I have to create email tracking system, but the problem is that when the sender opens an email this is counted as an opening by the recipient.
When I send an email through Polymail (or some other tools for tracking emails), then in the 'sent' folder I have an email without a tracking pixel, but the recipients of this email have the pixel and at the same time everyone have different code inside (I think, to determine which of the recipients opened the email).
How is this possible? The sender and the recipients have different contents of the same email. Can this be implemented using smtp / imap / gmail-api?
For standard IMAP/SMTP setups (specifically: not GMail), the message is submitted twice, once to SMTP to be sent, and again to IMAP to be placed in the Sent mailbox.
There is no requirement that these be the same: in fact, in normal use, the BCC header, for example, is submitted to IMAP, but not SMTP.
GMail, and a few others, while trying to be helpful and save bandwidth, do the copy automatically, but make it impossible to supply different versions. (Unless you want to try to find the duplicates and delete them out of band).
Current Email protocols don't send any kind of ACK to the Sender when mail is opened. So you need to put some kind of analytic tool inside the mail contents to keep the track of it.
Some suggested methods and widely used tool is Bananatag.
Alternatively, you can use custom Google Analytics for the same. Refer here https://dyn.com/blog/tracking-email-opens-via-google-analytics/
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.
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.
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.