Automatically set default "From:" account per recipient in Apple Mail - email

The Problem
I use Apple Mail on OS X 10.10 and have two mail accounts configured--one for work, and one for personal. More than once when I have composed a new message (not a reply), I have forgotten to check the "From:" address and sent a work message from my personal account and vice versa.
The Request
I am looking for a way to automatically set the "From:" account based on who the recipient is when I compose a new message. If the email is a reply, I want the default Apple Mail behavior (reply from the account that the message was received at).
For instance, say I want to send a message to my co-worker John. So I compose a new message and address it to his work email. I want Apple Mail to automatically detect his email address and set the "From:" account to my work email address.
Of course, the list of these email addresses would have to be created, but after the initial configuration the behavior should work automatically.
Another example: Say that the same co-worker John and I are also friends, and he sent me an email to my personal account to set up a time to get together outside of work. When I reply to his email, I would like the "From:" account to be my personal account, since this is the account that the email was originally sent to.
I don't understand how this seemingly common sense approach is not standard issue for email clients in 2015! Surely I can't be the only one who wants more than the universal default "From:" account that Apple Mail--and every other mail client--offers.
I've looked at the AppleScript dictionary for Apple Mail and read some threads here that suggest that GUI scripting may offer this functionality, but I don't have any experience with that.
Is there a way to accomplish this?

The trick is getting Applescript to monitor the new messages being created. If you're willing to go the Keyboard Maestro route, you could remap command-N to an Applescript that gets the recipient address then creates a message with the appropriate sender (see http://www.macstories.net/tutorials/automating-mail-signatures-and-senders-with-applescript-and-keyboard-maestro/ and http://shawnblanc.net/2013/04/keyboard-maestro-email-signatures/ for some related examples).
Or run a script after you've entered the addresses. GUI scripting wouldn't be necessary. It would look something like this:
tell application "Mail"
set m to front outgoing message
set theRecipients to to recipients of m
repeat with r in theRecipients
if address of r is in {"mybuddy#fastmail.fm", "my buddy#gmail.com"} then
set sender of m to "Personal Me <personalme#gmail.com>"
end if
end repeat
end tell
Getting Applescript to automatically do this with no intervention would require a daemon or some other way of monitoring events in Mail. Unfortunately there are no hooks built in.

Related

Notify sender of new email address, when it's a Gmail alias

I have a G Suite account for, let's say, domain.com. I have a user with email address me#domain.com. Today I added a new domain to the account new-domain.com and set up an email alias for my user, which is me#new-domain.com.
Since "New Domain" is my new company name, I want to transition to the new email address and eventually get rid of the old one. To help avoid confusion during this transition, I want anyone who emails the old address (me#domain.com) to get an auto-response like "Please use my new email address in the future...".
What I've Tried
The most obvious thing would be to setup a Vacation Responder, but Gmail doesn't let you specify which address it's for. So there's no way for me to easily specify that responses should only be going to senders emailing me#domain.com. G Suite does have an advanced setting in Gmail where you can quarantine messages. I've tried to use that to quarantine Vacation Responders coming from the new address, but that's not working either because the new address is now the default one, and thus emails coming in to me#domain.com get a Vacation Responder from me#new-domain.com.
To me, this seems like a pretty common situation - transitioning users from one domain to another - and using an alias so users can just have one inbox to check. Does anyone know how to get this to work, or is there some other best practice I could be following?
From my knowledge, your options are to use the Gmail Routing to block incoming mail to specific users or groups and to set it to 'reject message' and add a message informing them of this change.
-a little crude but workable.
Alternatively ensure users reply use their new primary email and ensure there is a long enough transition period for people for external responders to change over.

Email open tracking

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/

Automated database tracking of Undelivr email in ColdFusion?

Given there is a "FAILTO=''" option for cfmail, triggering an email to be sent to that email if the email didn't get delivered...
Is there a way to somehow assign an ID or tracking # to an email, store it in a database with that ID... then update the status of that email if it fails?
I'd like to track bouncebacks... preferably WITHOUT sending the FAILTO to a POP3 or IMAP and then checking it with cfimap...
Is there any alternate way of handling this?
Maybe an event gateway that is triggered upon email failure?
UPDATE: I've decided to take a different approach, utilizing the sendgrid API.
I'm hoping that lends me with a few more tools than CF offers.
The short answer to your question is unfortunately no.
A longer version with a possible solution:
The failTo email address populates the return-path in the email header, this then 'should' be used by mail servers for bounce backs (however see - http://www.bennadel.com/blog/1899-GMail-Seems-To-Ignore-The-Return-Path-Header-Defined-By-The-CFMail-FailTo-Attribute.htm for an example where it doesn't)
So you are going to need to monitor an Imap or pop account to see your mails, however you can set up an event gateway to monitor this, with detailed instructions here - http://www.alagad.com/documentation/imapGateway/ImapWatcher%20Gateway%20Documentation.pdf
What you're left with is needing to identify which mail matches which bounceback, when I've done something similar in the past I used unique id's for the failTo email addresses at a domain I owned. If you set that up and then use your listener cfc to look for the id in the return-path.
So your sending code would work along the lines of:
Generate unique id
Send mail
Add row to database with unique id
Your listener.cfc would then need to inspect the email returned and if it finds the unique id update the row with whatever information that you're after.
Hope that that at least helps even if you'll need to set up some other bits.
You could use a directly watcher on the undelivr folder to log the failed emails, only really a solution if its own server and not a shared server though.
As far as I know once it leave the spool and is off to your SMTP server CF assume it's been sent correctly.
The email will trickle down the chain of SMTP servers/relays and if anything happen the only instruction they have is to bounce it back to the from address or failto address if present. CF isn't listening at this point so it can't respond.
We use an external tool called Glock email processor to handle exceptions. It's not free, but works pretty well. You can find it here: http://www.glocksoft.com/email-processor/
You need to configure it to check the failto address and from there you can take many actions. I got it setup as a three strikes system.
Email address bounce, I increment a counter in my email table, at 3 I deactivate that email from the system.
Nothing you can't do yourself with cfpop though.

Contact form emails; from, reply-to, ...?

We are developing a contact form for a SaaS application; each instance of our application will have a contact form to contact the instance owner.
Our first version sends email from a generic SaaS email address (i.e. contact#saas.com) to the owner of the instance (i.e. user#example.com).
This works, but of course if user#example.com replies to the email, the answer gets sent to contact#saas.com . I'm wondering what's the best practice here:
Setting the from: message to the email address filled out in the contact form would enable replies to be sent easily to the person who sent the contact form- but then, we cannot tell people to add contact#saas.com to their whitelist to avoid spam filtering
Setting the reply-to header seems better, but I'm wary that some clients will misinterpret reply-to
Including an explanatory text in the message seems inconvenient, but workable
Allowing instance owners to read contact forms through their admin panel seems too much work (but completely spamfilter-proof, albeit inconvenient)
I'm leaning towards 2. Thoughts?
Alex
I'd definitely go for option 2 . From-Header / Envelope-From should make it clear that the message originated at your service (and allow proper bounce handling etc) . I'm not aware of any current mail clients that cannot handle reply-to header correctly. to be on the safe side you could mix in option 3 and clearly state that the message was sent from address sender#example.net via your webform.
Proper whitelists should work if you put the real sender in Sender: and/or the envelope sender; but then again, in an ideal world there would be no Microsoft.

How to "Reply to this email to comment" like Facebook?

A forum-like app I'm working on will send an email notification to the thread starter when a new replied is received. It would be nice if the owner can just reply the email to add a new reply to the thread.
How can I implement the feature, i.e. "reply to this email to comment" like Facebook?
Option A: scan the subject line/body? I don't like it 'cause what if the user modified the subject line by mistake?
Option B: use a unique reply-to e-mail address that links to the thread ID. Is this a common function for mail server? like set up a *#addComment.domain.com ? Or does the app server needs to setup a new email account before sending the email with reply-to?
Any other options?
Thanks!
Using strings in the subject and body can be easily erased by a user of the system.
Use plus addressing (reply+UNIQUEIDENTIFIER#yourapplication.com) as the REPLY-TO address in the mail message. With CFIMAP you can retrieve the messages and parse the TO.
Wildcard domain (replyto#UNIQUEIDENTIFIER.yourapplication.com) is also an option, but if your email server supports plus addressing I would go that route.
You could stuff the thread ID or the parent message ID (the message that is being replied to) in the Msgessage-ID: header of the email, or a custom email header, and put the processing after accepting the message.
However, using custom Reply-To: addresses is quite common.
an option is to embed an identifier in both the subject and the body of the original email. something small, like bit.ly's 6-8 character code. that way, they're less likely to mess it up, and you have the safety of the email body, which most people leave in anyway.
Using a custom email header is not advised as there is no guarantee that any server along the route would not strip it off (or simply fail to pass it on). A friend who worked at a huge email data center for AT&T said the techs there warned him off that idea.
This may also be true of the Message-ID: -- don't know.