I am sending out email alerts with a static google map on them. Certain email clients are changing the content of the link so that it no longer works. Specifically, "&" is getting changed to & a m p ; (no spaces)
Google will not accept the link with the substitutions. I have also tried sending %26 in place of &, but google will not accept that. This is only happening on certain systems like AOL and maybe Hotmail.
Here's an example link:
http://maps.google.com/maps/api/staticmap?sensor=false¢er=36.124023600000,-115.170356400000&size=500x300&maptype=roadmap&markers=label:S%7Ccolor:red%7C36.114646000000,-115.172816000000&markers=label:H%7Ccolor:green%7C36.124023600000,-115.170356400000
Is there anyway to tell the email client NOT to change the link, or is there anyway to change the original link to work with Google and bypass the email client substitution?
TIA,
David
Your email program is probably telling the receiving programs what type of message it is. There is a header "Content-Type:" which is usually either "text/plain" or "text/html", with it defaulting to text/plain.
Probably what is happening is that your message is going out as text/html, and the receiving program is rendering as HTML, but first fixing things up so that ampersands get displayed as ampersands instead of as HTML directives. Otherwise, if I send a message that says "John & Carol are having a surprise party", the ampersand will screw things up or not get shown. (I forget right now which.)
It is also possible that your email program is doing the conversion before the message gets sent out and most of the receiving email programs are recognizing the issue and fixing it.
In order to tell exactly what is going on, send yourself one of these alerts and view the source. How you view the source varies depending upon which email program you use to read the message. With GMail, open the message, and in the upper right hand of the message, there is a drop-down "More"; choose "show original". Look for what the content type is and whether the ampersands in the URL are & or &.
Now, as to how to fix it, probably what you are doing right now is just typing the URL into the message. Instead, try making it a link. How you do this will vary depending upon which program you use to compose, but on GMail for example, there is a little symbol like a chain. Press that button and enter in the URL. That will generate HTML something like
<a href="http://mydomain.com/blah/blah?foo=1&bar=2&baz=3>http://mydomain.com/blah/blah?foo=1&bar=2&baz=3</a>
Thus, even if the ampersands get displayed as &, when the user clicks on the link, they will get the URL with proper ampersands.
I can't be certain this will work, as I don't know what email program you are using and thus how it does things. However, I think it is likely to work.
If it doesn't, you might be able to get it to work by sending as text/plain instead of text/html.
Related
I have a contact-us page on a website. It asks for your name, your thoughts and has a check box to ask if you'd like to make your thoughts public. The contents of this page are then emailed to a gmail account. The actual publishing (if okayed) is done manually by a person /monkey. There are no attachments of any sort. There's probably tens of pages like this across the Interweb.
By sanitising, I mean for security /hacking prevention. So removal of strange html characters like < and >, escape characters and semicolons etc. Bogus form input from bots that might attempt cross site scripting stuff when viewed with a browser and things like that. I don't mean profanity, bad spelling or dodgy opinions.
I don't think that there is actually any point sanitising the text as it goes servlet -> smtp servers -> gmail -> Chrome browser. I expect that Google does a far better job at sanitising dodgey email text than I ever could. Is there anything to the contrary?
If you're going to read these e-mails using standard e-mail clients, then it's not going to pose danger, other than usual risks of phishing, tracking, and in worst case injection of dangerous attachment that you shouldn't be opening anyway. E-mail clients already try to isolate and santize any incoming content. However, if you were do display this content elsewhere, e.g. in a CRM or an admin panel of the site, then XSS risk is much higher.
If you're sending HTML e-mail, then all usual HTML escaping rules apply (at minimum change < to <, & to &).
If you're sending plain text email, then any text in there is just text, so you shouldn't need to do anything. However, just in case don't let attacker-supplied text at the very beginning of the e-mail (insert some intro like "user has sent this:"), so they can't insert uuencode header.
Be extra careful about putting user-submitted values in headers such as Subject/From/Reply-To. If your e-mail sending library doesn't handle escaping of these fields, you will have to handle it (e.g. apply quoted-printable). It's also essential to prevent newlines from being inserted in these fields, as this could be abused for header injection and spam (e.g. even if your form has 1-line <input> for name, an attacker can submit a whole formatted e-mail with headers and body in there and make you send whatever they want to whoever they want).
so the problem is:
I have a mailto html tag and when used via IE8 (our clients use it...), before popping up outlook, it shows a warning "This form is being submitted using e-mail. Submitting this form will reveal your e-mail address to the recipient, and will send the form data without encrypting it for privacy. You may continue or cancel this submission".
The problem is that many of the users do not speak english, so our client wants us to either remove this message (we explained them it is a browser constraint, but they still insist on doing it) or translating it to bulgarian. Any ideas which of these is easier to do ? (I mean possible at all). Is there a way to turn this message off from the browser?
You cannot get rid of the message -- as you already said, it is a browser constraint, and entirely outside of your control.
The only way to get rid of it would be to rewrite your site to send the message via a different method. But that's overkill just to get rid of a warning message.
For the record, this isn't an IE8 issue; you'll get the same message under newer IE versions as well (I've seen it myself recently in IE11).
The real question is if your users are Bulgarian, why are they getting English messages from their browser? They should be running Windows and IE localised to their language. If they do that, then the message will show up in Bulgarian.
It's happening in
- Samsung Galaxy Note3 & 4
- Google Chrome browser V39.XX
I am using a link and when click it's launch the mail client
href="mailto:info#gmail.com?subject=Network%20issue"
result: subject=Network+issue
How to remove the plus(+) sign?
Your original approach should work... The only reason that comes to mind behind it not working is perhaps encodings are being mixed up along the way? Take a look at these threads to get a better idea of what I mean:
mailto special characters
Special characters in UTF8 mailto: subject= link and Outlook
I experimented with the base64 approach that is the answer in the second link but was unable to remedy the issue :-\ I tested this on Gmail, Inbox, and Mailbox - all with the same results as what you are describing above.
Maybe something is getting messed up at the Android layer in terms of how the link is being handed off to the mail client of your choice?
If you're rendering using Javascript, try encoding as a URL using encodeURIComponent
const urlEncoded = encodeURI(mailToLink);
before you pass the URL to the mailTo link. Otherwise encode it in the backend first.
This can be done with email addresses that contain special characters too.
I recently learned that webmail clients like Gmail will do alterations on HTML emails, for example adding target="_blank" to <a> tags.
I've also discovered that other alterations happen as well. When I send an HTML email to Gmail (and possibly other web mail clients) from my PHP script, variable values included in the URL of any links are being stripped out. So, for example, this is the value I'm setting in my PHP code:
$mailContent = '<p><a target="_blank" href="https://example.com/confirmation.html?verification=x1x1x1x1x1x1x1x&email=yyyy#email.com">click here to go to the web site and activate your account!</a></p>';
But when the email is received in Gmail, the HTML code comes out like this:
<p><a target="_blank" href="https://example.com/confirmation.html?verification=&email=">click here to go to the web site and activate your account!</a></p>
The values x1x1x1x1x1x1x1x and yyyy#email.com have been stripped out from within the <a> tag.
How do I protect the values of the variables that I want to pass to the URL so that Gmail won't remove them?
Click View original/source on the message in Gmail to see if the URLs looks like they should then. If so you know that the problem is how Gmail is formatting the message for your viewing. If it's mutilated even in the source I was wondering if there's anything in your webpage/php/CMS (do you use one) that changes the code.
You should try URL-encoding as #Crisp said. Here's the W3 reference.
Emailing in html uses Quoted-printable Encoding. The problem with your $mailContent is that the "=" must be represented by =3D
Try adding this:
$mailContent = quoted_printable_encode($mailContent);
This may not be the perfect answer, but if your application allows for it, I have used URL shorteners a number of times.
http://goo.gl/ is my preferred because the API is super easy to implement and google is very fast. I have a function in a class and I just run my url through it and send the return wherever I need it to be.
Another non-perfect answer here but, my problem was that I was including an http url in the html body and apparently is not valid so I changed them to https. This was on a dev environment so no problem on production.
Here is more info about this:
Any URL's in the body of the mail which lead to insecure sites may also need to be removed. Use https://transparencyreport.google.com/safe-browsing/search to validate these links.. All links should be correctly prefixed with "https". https://en.wikipedia.org/wiki/HTTPS Google seem to be rejecting "http". Sometimes, but not always, removing links from any signature can help.
I'm only asking because I tried sending an email (with PEAR) which containd an image whose name was something like "header image_3021" and noticed that it didn't show up in the email.
When I checked the SRC in the recieved email the space was replaced with + and that somehow made the link point to the wrong file. Now, IIRC, + is a correct encoding for spaces in URLs yet the browser could not locate "header+image_2031".
I checked the original content of the email both with Gmail's show original and in the server logs and the space was still there, so the replacement was done either by the browser or by Gmail's rendering process.
I have since modified my upload algorithms to not allow spaces in filenames but I have to ask: What's the best way to make sure the browser will display images with spaces in their file names? Replace them with %20 myself? Let the browser do it? Just disallow them?
Definitely encode them. By doing so, you remove the nuance of how different clients will interpret the string. As #mr alien said, there are out of box php functions that will handle that for you.