Is it possible to have some kind of mini app running in an email.
When the email arrives the email message should contain static text, but also an interactive component where the user can select attachments, fill out a few fields and hit reply.
Yes, but in limited circumstances. If you are planning for an office intranet all running Open Office/MS Office/Lotus/etc then yes. Otherwise very few mail clients willingly support them across the board. If you don't have control over the client software you should stick to the basics.
To ensure delivery and legibility of the e-mail in all clients I'd send simple message in plain text and HTML format (no external images) with a web URL for user interaction.
I'm sorry, but it's not a good idea at all. It would be classed as a trojan, no?
What if:
client views all emails in plain text
web based email client
platform limitations eg windows app on a linux client
Personally, I'd look at exactly one of your recieved emails and then assign it to my blacklist...
Thankfully no.
But you cold possibly do something like it with html.
Not really, no. It depends too much on the end user email client, and most of them won't handle something like this.
The solution is to send a link to a page that does that.
Formatting wise you can still do a lot of things using HTML and basic CSS.
Related
i wonder what is the best solution to send an email from my app.
I have two solutions :
1- using MFMailComposeViewController :
it works well. Easy to use. but use an huge amount of RAM : in activity monitor, when i use this, the RAM allocation grows from ~10 Mo to ~20Mo, and is never freed
2- Setup a PHP-Script that handles sending email.
it works very well too. And it uses very few RAM : around ~3 Mo with this solution.
So, my question is :
does this is allowed by apple ?
Does anyone is using this solution in his app ?
I'm pretty sure apple doesn't care how some email gets sent out when people use your app.
The more important issue is that when sending from the device, using MFMailComposeViewController, you get the following for free:
users see a familiar interface
users send their mail from their own account
users have messages in their sent folder
users can choose to archive a message
Using your own php script, you get:
a lot of extra work to do, and stuff to maintain
either A) always the same sender address (from your script), or B) an address that the user must type in (afaik there is no legal way to get an email address from iOS)
in case B), trying to send on behalf of the user, you will run into spam filters quickly (think about SPF and such)
Looking at these things, the proposed solutions are really not comparable. So the real question is, what kind of email is sent out. Is it feedback sent to you, or is it mail sent on behalf of the user?
The memory concerns are new to me, I never experienced such problems. Do you handle memory management the proper way? If so, there is nothing to worry about. Don't focus too much on the "activity monitor" if you're not actually experiencing problems.
I'll throw in a third alternative here. If you want to leverage a web service for emailing you could leverage an existing email service such as PostageApp (http://postageapp.com/). They have a a library you can use as part of your iOS / Mac app that interfaces with the API which allows you to send email from Objective-C. You can check out the plugin here:
http://dev.postageapp.com/pages/plugins.html. The nice thing about leveraging a service like this is you don't have to worry about the internals of sending email and lets you focus on your application.
(Disclosure: I work for PostageApp and built the plugin)
for my group at the university I'd like to set up a server-sided email-to-rss service.
It should work like that, that different people can send emails to a certain address (nothing proprietary like gmail but a certain imap or pop server) which will the be translated into an rss feed. One main and important feature has to be that one can see the sender of the email in the feed. Furthermore it would be nice (to take the load off the server) if the emails get translated to a feed only once a day or so.
Does anyone has some input on this subject? Are there any scripts/services which will allow that?
Thanks a bunch.
Instead of "reinventing the wheel", you could use a mailing list that supports RSS. Your people can then write the mails to the mailing list and you can then use the mailing list's RSS feed however you intend to.
This should help you find a solution: https://encrypted.google.com/search?q=mailing%20list%20rss
Pick a programming language you're familiar with, then use either an imap library to fetch the E-mails (through cron, every hour or something like that), or if you have access to procmail on your mail server, launch your script as an email arrives (this shouldn't be too much work to handle for a server, unless you're talking a vast amount of E-mail).
The script would just insert the E-mails into a database, before extracting them and outputting the RSS-feed directly from that (this shouldn't be more than a handful of lines of code).
There's a couple of providers that does this for you, although it seems that the most popular ones have disappeared. Advanced Email2RSS seems to be an option, although I have no idea how good they are or if it'll even solve your issue.
I want my web app to send certain mails as HTML in order to include product images.
I could of course provide a text/plain alternative as well, but is it worth the effort in this day and age? Are there common mail clients that don't support text/html, do many people turn it off for some good reason (I suppose spam, bandwidth), are there other reasons such as decreasing the risk of being classified as spam?
I can theorize, but would be interested to hear if someone has statistics, experience or other insight to support or speak against going text/html only.
You are best to send both because:
It helps reduce your spam score, even more so if your text version has the same text and links as your HTML version. This is especially true on Outlook, where no text version almost guarantees it will go the Junk folder.
A lot of people do request a text version on the client-side. Some old Blackberries default to this setting, and Windows Mobile <= v5.
Provide both. HTML in email has a slew of security problems, so those that are security-minded tend to disable HTML email in favor of plain text. Also, reply quoting conventions are fairly well-establised for text/plain data and not for HTML, making meaningful discussions in pure-HTML mail threads ugly.
Since you do have control over the content of the message, please make the plain text version readable. Some MUAs tend to auto-create the text/plain part, and do a horrible job in doing so. So if your messages are intended for customers, make sure the text/plain part is formatted nicely so you do not alienate them.
I believe clients such as iOS mail use the text/plain version to preview the first couple of lines before the user opens the mail.
I think HTML only is OK, but it should be legible without images downloaded. Outlook and Gmail both block images by default to stop tracking and viruses.
You should always have a text/plain alternative. I don't have statistics, but I'm sure that a lot of people disable HTML emails. Including me, because I'm annoyed by all those product images and meaningless fancy newsletters.
Stats I found were that 90% of emails were viewed in html-capable email viewers. If you choose not to include an option for plain text, you could be losing out on 10% of your audience. On the other hand, a well designed html email could more than outperform the 10% loss, so it might be worth the trade off.
I am struggling to get both working on PHP with Hostgator, so I think I'm going to focus on the low hanging fruit (the 90% who view html emails) and not worry about the 10%. Like IE 7, there comes a point where you can no longer support all platforms.
Google does HTML email by default, this includes Google Apps for Business and Google Apps for Educations. Thus millions of Gmail users send and receive HTML email rather than plain text email. Not sure whether there are any better stats than that out there.
Aside from the visual splendor of HTML emails - links are the only thing keeping me from sending plain text emails. They are much simpler for users at times and reduce bandwidth by over 50%. However, forcing my users to copy/paste or (* shiver *) type the URL from the plain text email is not acceptable.
However, it seems like many services such as gmail and hotmail are converting URLs into HTML links. If that's true, then for some lighter emails I could finally switch to plain text (in certain cases) without bothering anyone.
Anyone know what percentage (or what systems or clients) convert text URLs into clickable links?
Some users access via the web (Hotmail/Yahoo/Gmail) while others use clients (Outlook/Thunderbird).
All email progams I know make links clickable, web-based and normal ones.
You should consider putting the links at the end of the mail, and use "[number]" to refer to them:
You should really visit PEAR[1] and friends, PHP[2]!
[1] http://pear.php.net/
[2] http://www.php.net/
That frees you from problems with longer URLs within the text, and it keeps the text readable.
You must not forget one simple fact and that is every mail client make this configurable. So I for one have the option of reading / sending html emails but I don't do that. So it's totally irrelevant how many mail clients support this, the relevant question is how many users have this enabled.
Most services offered online today that claim to "track" e-mails, do so by embedding images in the emails. My questions are:
Is this the only way to do it and if not, what are the other methods?
Are any of the methods actually fool-proof?
Has anybody had any luck with specific software or even an online group?
Yes, this is pretty much the only way to do it. Consider that an email is something that is inherently static. The only way to know if someone has "opened" an email is for the email to send some information back to your server. Most email clients these days support HTML emails, which means that you can get the client to request an image (or anything else) from your server by embedding the proper HTML tags. Other than this, you cannot force an email client to do anything it doesn't want to do. It's a separate program on a remote computer, and you have no control over it.
No, there's no foolproof way. There will always be emails you can't track. If someone downloads their email and disconnects from the internet before reading it, you can't track that email. Most email clients allow you to disable image loading now as well if you want to, so that can block tracking too.
I've usually written my own, so I wouldn't know what to recommend. I imagine most services will be quite similar, so I'd base a product/purchase decision on how easy their front-end is to use.
In addition to pixel tracking, a second way to track open rates is by looking for clickthroughs. If someone clicked through, then they must have opened it. This is infrequent, but it's important not to throw this data away.
More details:
How MailChimp tracks open rates
How CampaignMonitor tracks open rates
Wikipedia on email open rates
Hubspot on open rate issues
Facebook uses a bgsound element in addition to an img element like this:
<img src="http://www.facebook.com/email_open_log_pic.php?mid=999999999999"
style="border:0;width:1px;height:1px;" />
<bgsound src="http://www.facebook.com/email_open_log_pic.php?mid=99999999999&s=a"
volume="-10000" />
This is the best way, and it's hardly ideal - many e-mail clients block images to start with.
No, no methods are foolproof. A foolproof method of detecting if someone had read an e-mail would be a significant privacy issue.
I've used ExactTarget and CampaignMonitor's tracking systems. Both worked pretty well for tracking trends - i.e. twice as many people opened e-mail #1 than #2 - but you never know how many missed opens there are due to images not being shown.
Pixel tracking is the only way to track open rates. Then the links in your emails are also tracked through a redirect service for click rates. Absolutely nothing is going to be foolproof. You will have to use some guess work to figure out your actual open rate since some email clients will only take the text version and not the html and also some clients do not load images by default.
SilverPop is a popular one. They actually use PowerMTA on the back-end. Our company just ended up licensing PowerMTA and writing our own front-end and tracking.
No it's not the only way. Your HTML e-mail can refer to a web server for 'some content' which is then tracked. That could be an image, a stylesheet, some Javascript, etc. Most mail clients hate it and nothing automated is guaranteed to work.
Gain the trust of your recipient and invite them to your website. Track clicks.