I prepared an email that would look interesting, and tried to send it by using Safari. The setup did not come out in the emails the way it looks at the web page. In some web clients only the blue background came out, in others there was no background and the three columns were set one after the other, with the center one last. In other words a mess, and I do not know how to remedy it. Please help.
Many popular email clients (not including Mail on the Mac) have very poor HTML/CSS renderers.
There's really no substitute for testing how your email renders on a wide range of email clients before sending it out. A tool like Litmus can save a great deal of time here.
Or, you can always just send text-only email.
Related
My organization has begun adding obnoxious warnings to the subject and body of any email that arrives from an external address. My organization allows email forwarding, and I forward to gmail. I would like to have the extra text automatically removed before I see them in gmail. This would not violate the policies at my organization. Some ideas I had:
(1) One option would be to set up a gmail filter that edits the message. This feature does not seem to exist.
(2) Another option would be to customize the display so that this particular text is never shown on the screen. Again, there seems to be no way to do this.
(3) I wrote a script in Google Apps to grab to the content of each offending email and send an edited version to myself, but there is no way to make the "from" field show the original sender (perhaps with good reason). I can put that information in "reply to" but the gmail client doesn't show it nicely. This removes the annoying extra text at the cost of the ability to easily see who sent the email. The core of it is this call:
GmailApp.sendEmail("<my_email_address>",newSubject,newBody,{
attachments: message.getAttachments(),
bcc: message.getBcc(),
cc: message.getCc(),
htmlBody: newBody,
replyTo: message.getFrom(),
});
Any ideas? This is becoming a big problem as the "nanny state" approaches, so I'm sure others will appreciate your solution.
Issue
It unfortunately seems that at the day of this post, there is no way of edditing a forwarded email with the Gmail API. Check the documentation to see what you can actually do with the Gmail API in regards to forwarding email addresses.
Workaround
Despite it is not possible to edit a forwarding email address, in your case you are interested in:
Edit the body and subject of the email address.
Preserve the information of who the sender was.
Therefore what you could do is:
Get the email address you want to edit. Get the body, subject and information about who was sending it and store that.
Create a new message where you edit the message you just got and write on the subject the from field that was in the message you just got.
Send that created message to your desired recipient just like it was a forwarding email.
I hope this has helped you. Let me know if you need anything else or if you did not understood something. :)
Apps Script
You can insert messages into your inbox with their original "From" field but a modified body.
Note: Inserting is different from sending because the message is created on the inbox with less validation than sending.
To use this on Apps Script, take a look at the Advanced Gmail Service.
Custom Application
Another idea on how to do this is to use a custom application (in any language you'd prefer) that:
scans your company inbox with IMAP
manipulates the message body to remove the artifacts you don't want
insert manipulated message into your Gmail inbox with the Gmail API
I'm creating my first application that requires me to update the app based on user input. I've been searching for the best way to send input to me. For example, I have a button that when the user presses I would like to send me the information they've added to a text field. Being new to this, I thought this could be done by simply sending the information to a specified email, but from what I've researched I will need some sort of database. Looking through the Apple Developer Documentation I don't even know which topic I should be looking at to figure this out, any help or direction would be very helpful!
You need to setup a server (using an API) to receive the information.
Usually you will use a webservice to receive the info from the app, although there are other ways to do that.
Sending an email through iOs would require the user to accept the email that is being sent, so doesn't look like a good idea.
Take a look at some options available to create webservices (django rest framework or flask), Google's Firebase also can be handy in this situation, since is only integrating it with your app and storing the data you want to store, with easy integration for Authentication and user tracking.
Back in the day Facebook used to let you define URLs that were something like http://facebook.com/send_a_message/user/55/pre_fill/Hi there. When you clicked that link Facebook would open up its Messenger with a "Hi there" message ready to be sent to user 55.
But then Facebook decided that "pre-filling" was bad, and outlawed it across all their APIs. Now there are a bunch of different ways to initiate a Messenger chat session, but they all amount to "start a chat with user 55", not "start a chat with user 55 using some information".
The thing is, I'd like to somehow pass information along with the link. For instance, I might want to have three different links on three different pages, and I want my chatbot to be able to respond differently based on which page the user came from. Since I can't "pre-fill" a message (eg. "Hello, I just came from page A"), I'm wondering if there is any other way to pass auxiliary information.
TLDR
I'm wondering if there's any way I can possibly provide a user with a link that, when they click it, starts up a chat session with my chatbot user, and somehow passes information to it. Using an intermediate proxy (ie. having the link go to my server, and then have my server start the chat somehow) would work, but only if I can associate the information with the user (ie. it doesn't help to know "page A" if I can't associate that with the user once they start chatting).
After researching further it would appear that the answer to my question is no: there is currently no way to pass-along supplemental information.
But here's the good news: when I filed a bug about this (which it turns out I should have filed as a feature request, sorry Facebook) I got a response saying something to the effect of "we couldn't tell you that we are currently developing this, even if we were", which I'm going to optimistically choose to interpret as a sign hope means that this functionality may be coming in the future.
I have seen a disturbing trend where websites are starting to require verification sent to cellphones by text message (SMS). Gmail and Facebook are two of them. What I want to know are the following:
Is it a good idea to start requiring cellphones instead of emails now?
How do I do it on my own website?
Edit
Here are some of my new questions on the topic in response to the answers:
I see that most of you are saying that SMS registrations is ok. But what about the people who don't have cell phones? And why is it accepted to give out your cell phone information freely?
Do those big providers really pay per message to a gateway service? Is it not possible to set up a server with the correct SMS software, or at least buy a subscription directly instead of having a middleman?
Most SMS Gateway services have some kind of API. An HTTP interface seems to be the norm.
Just make sure you sign up for a service that allows receiving of messages because not all do. It's more work for them since they have to send some kind of data back to you.
Some services offer send receipts too which lets you see if the receiver got the SMS.
Some examples follows.
Esendex API docs
TxtLocal
In regard to question number one, I think Commander Keen's advice is sound.
It is a good idea if you want to limit the number of fake accounts. I see it used lots in local newspapers here in Norway. I guess it makes people think twice before posting useless crap on their discussion forums.
But do you really hate your users that much? Gmail and Facebook are big enough now that people will accept jumping a few hurdles to use the service, but you need something really interesting to make the user accept this inconvenience.
SMS is the reason I can't use App Engine ().
The first problem is that some people do not have cell phone. I can use Facebook almost completely without validating cell, but uses CAPTCHA to get through certain actions. Therefore, CAPTCHA is one of the good alternatives.
I personally think, cell phone stuff belongs to cell phones and should not be in the Web.
What if every forum admins and newbie PHP developers in the world used SMS validation and someone hacked (cracked) into their database? Do you trust a small forum? Is anti-fraud measure required so desperately?
If your site is very large and popular, it may be good to get SMS validation.
As a member of CS Networks Support team. I am going to give you some answers.
People use their cell phones as a medium of verification, so the service providers can be sure that registered member is not a bot or something else.
Yes it is true. Big providers pay for SMS gateway services. Yes it is possible to have an infrastructure like that, but it is recommended that you have a team of people that are in this business for a long period of time.
The one main reason for using SMS as a way of authentication is that you link the account to a mobile phone, which effectively reduces the chance of fake user accounts by a very large margin.
To implement this feature, you will need to sign an agreement with a SMS Gateway that has coverage for the countries (and operators) that your customers are located in..
Most SMS Gateways can easily be integrated in your software, and will most often provide you with access to all the mobile operators that you require.
I would not recommend using an email to sms gateway if you can use an API, as these are most often less responsive than using a proper API to send messages, where you will get a live connection with the SMS gateway itself, not an email server in front of the gateway.
Examples of SMS Gateway providers:
PSWinCom - www.pswin.com (Note: I am employed in this company.)
Clickatell - www.clickatell.com
HSL - http://www.hslsms.com/
Answer to 1st question: One reason which I can think of that led Gmail and Facebook to follow this trend is the emergence of bogus accounts. Now-a-days, there are use-n-throw email availabe for free like www.10minutemail.com which gives u an email address for 10 minutes. So the use can take such an email address and start a new account in the site.
But in the case of 'sms'-registration, I dont know of any such use-n-throw service provider. So everyone needs to give his own number for registration. This leads to registration by legitimate users.
Answer to 2nd question: This depends on which language u are using. Moreover, you may need a SMS gateway to achieve this.
Since you dont care about the language, try to look for SMS gateway for sending sms through computer or your web server. Some of the cellphone network providers provide an email service to send sms to a phone. For example, you are sending an sms to +910123456789 of 'xyz' network provider, you just need send the sms in the body of an email with the to-address as +910123456789#xyzmail.com
'xyzmail' part of the mail address will change according to the network provider. Plus this option is not found to be reliabe.
check out TeleSign.com
they offer phone verification solutions that you can implement into your website
phone verification is a way to reduce fraud and spam significantly
There's a trust issue here that goes both ways. If you're the provider of a service that can be spammed, you can trust that your users are people and that their email addresses are legitimate. This is probably irrational. Or you can force your users to trust that you'll deal with their cell number information safely. Many users will feel this is irrational.
And then there are people without cell phones (I happen to be one). Most discussions on the web aren't very important, but if you're trying to foster a discussion on anything important, limiting the discussion to people that have cell phones and know how to receive text messages will limit your discussion to the viewpoints of the rich and technologically savvy. If you're providing an important service like email, a texting requirement sets up a barrier to entry and saps the democratizing power of the web. It amounts to shunting the cost of your spam problem onto the disadvantaged. To me, that's unacceptable. Again, though, if your site is just inane pop culture or a marketing exercise, as most are, who cares, go right ahead.
I want to write a program that analyzes your fantasy baseball team and notifies you of recommended actions, possibly multiple times per day. The problem is, you aren't playing fantasy baseball on my site, you're playing on yahoo, or cbs, or espn, etc.
On the majority of these sites, fantasy teams and leagues are not public, so you must be logged in and a member of the league to see the teams in the league.
All that I need is the plain html for the team page on each of those sites to be sent to my server, where I can then parse and analyze the file and send user notifications.
The problem is that I need username/password combinations to easily get this data to my server when I need it, and I think there will be a lot of people who wouldn't want to entrust their yahoo/espn/cbs password to me.
I have come up with several possible ways to solve this problem:
The most obvious way is to ask for their credentials for the site on which their team is hosted. Then I could just programmatically log in and request the data I need. I'm guessing a number of people would be comfortable giving me their credentials, and a number of them not so much.
Write a desktop client, which the user then downloads. The client would require their credentials, but it could then basically do exactly the same thing that the server based version would do, log in, request the page, and send the page back to my server. The difference being that their password would never need to leave their desktop. Their computer would need to be on, and this program running for this method to work.
Write browser add-ons that navigate to the page I need, use the cookie that is saved from a previous login to login to the site, and send the page back to my server. This doesn't require my software to ever ask for their password, but if the cookie expires I am hosed, and I don't know much about browser add-ons besides.
I'm sure there are other options, but these are what I've come up with so far.
I have two questions:
1. What are the other possibilities for this type of task?
2. Am I over-estimating people's reluctance to give me their yahoo (for example) password? Is option (1) above the obvious choice?
It was suggested in the comments that I try yahoo pipes, and that looked like a promising suggestion so I explored it a bit. Having looked now at this, I don't think that is an option. So, it looks like I'll be going with option 1.
This is a problem I grappled with a couple of years ago when I wanted to do the same thing. Our site is http://benchcoach.com and the options we were considering were the following:
Original we considered getting the user's credentials and login. We would then log in and scrape their league and team info. The problem there is that after reading several of the various terms of service, this would definitely be violating the terms of service. On top of this, Yahoo! was definitely one of the sites we were considering and their users have email (where we could get access to sensitive data), and Yahoo! wallet. In addition, it would be pretty trivial for Yahoo/ESPN/CBS to block our programmatic logins by IP Address.
The solution we settled on (not 100% happy but it does seem to work) was asking our users to install a bookmarklet (like delicious, digg or reddit) which would post the current html page to our servers, where we could parse the data and load our database. If they were still logged into their Yahoo/ESPN/CBS account, we would direct them directly to the pages, otherwise, those sites would prompt for authentication. Clicking the bookmarklet once more, would post the page to our servers.
The pros of this approach was that we never collected anyone's credentials so any concern of security would have been alleviated. Secondly, it would make it impossible for Yahoo/ESPN/CBS to block access to our service since we would never be connecting directly to their servers but rather the user's browser would be posting the contents of their browser to our server.
The problems with this is that it takes 2 clicks to post a page to our site. For head to head leagues, we needed 3-4 pages so it would take our user 6-8 clicks to sync their league to our servers. We're still looking at options for this.
One important note is that I ran into the product manager of the Yahoo Fantasy Football site at a conference a year ago. We talked about how we were getting the Yahoo data, and he confirmed that getting credentials would violate their TOS and they may stop us. While I don't think they would have, it would have made it hard to invest time and energy to develop this only to have them block our site and pissing of users by closing their accounts.
A potentially more complicated answer could possibly be done with (for example) yahoo pipes.
Hypothetically, you create a pipe which prompts the user for their credentials and provides them with a url which contains their scraped data. They enter this URL in their site, and never have to provide their credentials directly. Even better, for the security-conscious, it would be possible to examine what the pipe was actually doing before entering any information.
The downside would be increased complexity (as well as you'd have to write and maintain the pipe). Having said that, you could provide a link directly to the published pipe from your site, to make things as easy as possible.
Option 1 is the obvious choice. People who trust your site will provide the details. There is no other way you can login to other site while screen scraping.