I've searched the web on this and I can find two solutions:
Use a URL-shortner.
Use brackets < > to allow insertion of whitespace. This only applies to plain-text emails.
I'm sending HTML emails that contains sensitive information, like password recovery links and auto-authentication links. These secure links are, by their nature, quite long. Easily longer than 70 characters or whatever arbitrary limit is imposed on e-mail bodies.
Obviously I can't use any form of URL-shortning because it would circumvent any secure cryptography technique I've used for the links.
I suppose the largest issue is that the links aren't wrapped nicely by email clients. The nice word-wrapping is supported in CSS3 technique, so there is no way MS Outlook will ever support this.
How do I make it so the links are not visually disruptive and possibly easy to copy-paste in case of email client malfunction?
Example
If the link doesn't seem to work, try copy-pasting it to your browser:
hxxp://development/#auth/YoxOntz0Oj0ExOiJfcmFuG9tbmVzcyI7czoxOTI6kJsYkV0qMGMuZ1pFZVQ5YkRQNDZPR200Unl60dGlpNlhZZC9QcEVeH0lvV2NVVlpWWFcwWlF0VjRyc0p4akYzclJ0GTkJmSlgxco0aEtDS0FuTlBVSXAxUVhCcGdRNGpHMVl5UGZMRFVacDVSQ1BqcU0tKYlNxZ0FqYXpjTkNqTS9LV29xSk4ydGtyeFpNdV0c2VLMERUbEYwc08xUWU5aXR0GOXl0bVFpcjlXeGZjUE100S0o1L1FcmQ4MmhOdm5LUSI7fQ
Additional notes:
I do not want my links to expire. If I want them to expire at all I'd have a time frame of months, not hours. These links are not just password recovery links.
Have you tried the Microsoft proprietary word-break:break-all; ?
<td style=“word-break:break-all;”>
This worked best for me (best compatibility across vendors):
<p style="word-break:break-all;">
<font style="word-break:break-all;">hxxp://really_long_link</font>
</p>
Tested on: MS Office 2007/2010, outlook.com, hotmail.com, gmail.com, yahoo.com (yahoo did not display nicely)
While this was edited to include <p>...</p> I would highly discourage the use of paragraph tags in HTML email if spacing is impotant since email clients interpret these differently.
In Html emails - use html
If you are sending html emails, what's wrong with:
... reset your password ...
If the links are getting mangled when you send html emails - the problem is how you're sending emails, not the recipient's email client.
Use a shorter hash
Is a super long hash (is it a hash, or is it encrypted?) really necessary? Using any hash that is long enough to not be brute-forced before it expires aught to be sufficient. Asking users to copy and paste a string that is obviously going to wrap isn't going to help the user, it's just pushing a development problem onto the user.
Related
What would be the recommended way to securely view emails in a browser (in PHP)?
Emails are highly insecure content and desktop email software obviously implements only a very limited subset of HTML and no javascript at all to prevent attacks. But if I'd take an email HTML source and display it in a browser, javascript code and other stuff would be executed.
I thought a solution would be to send a header like this along with the email source:
header("Content-Security-Policy: sandbox");
But this would prevent me from fetching inline images from the server as I still would need a PHP session id to be transmitted to understand that the user is allowed to fetch this content.
As there are many web email clients out there I wonder if there is a best practice model.
(FYI: I try to implement my own web email tool fitting to specific needs of a larger software suite)
You can address the issue of images by not requiring authentication and then making the URLs hard to guess (ex: <img src="/resources/SomeReallyLongHardToGuessRandomString">).
More broadly though, securely displaying user generated HTML is hard. Like really hard. This is a case where you should use a library. Keep in mind that you might have a user with a browser that is too old for the Content-Security-Policy header. This browser would happily run any scripts on the page. HTML Purifier is my personal choice, but there are others. Also, keep in mind that this is a dependency you will want to update often as people are constantly discovering new bugs.
As an additional line of defense, many sites use a seperate domain for user generated content. For example Google uses googleusercontent.com. That way if something does slip by, they haven't compromised the whole application. Note that this would still be bad, as an attacker might be able to read user content they shouldn't be able to (emails in this case).
I finally decided to modify the HTML source of the email (in my php script) to serve the inline images as base64 encoded data inside the HTML source. Therefore no additional loading of images is needed:
<img src="data:image/gif;base64,R0lGODlhDgE3APf/ALJUMt3W0aMyFPTixGRHOXNXSvnu3b1sSu7SpPLduurTxapEIvbly/bq4+bAffTo31Q1J/369dGafaAtDO3o5ePd2c6Tdfz6+a9...">
This will solve the current problem of displaying emails, because then I can stay my
header("Content-Security-Policy: sandbox");
because it is one major way to prevent attacks to be successful. Additionally, for enhanced security, I plan to look again into roundcubemail and see if I find out how they handle this problem and also use HTMLpurifier to further strip the email source from possible threats.
My client is a restaurant that needs to change a paragraph section (<P>) every day for specials.
There are many people that will be handling it so I have to make it as easy a possible.
I don't think teaching the whole staff how to use a CMS is feasible, so I thought it would be a good idea to make something like an email service, that only updates that bit of text.
So in other words the staff would just have to send an email, and the server would somehow change the text on the HTML page for that day.
Can I do this in PHP code maybe?
I am also open to other ideas to something easy, like a simple login system to just change that bit of text.
I wouldn't recommend setting the text by e-mail. E-mail is an ugly, UGLY format to process, especially if it is sent by humans on every type of broken e-mail clients. The half of the e-mails will be invalid HTML, the other half will be tabulated unimaginably, the third half will contain signatures and there are so many more halves :)
And explaining the e-mail format you expect to the staff (utf-8 plain text with no signatures, etc...), and how to set it on their Outlook Expresses, Netscape Mails, and web clients you never even heard of, will be just as difficult as explaining a CMS.
What I would recommend is a simple form instead. If you open the form the current text could show up in a text field, and upon posting back the form you save it's contents on the server.
You would need to store this text somewhere. There is very few servers that host web applications without some form of database backends, so I'm pretty sure you have some kind of database to store your text in.
Also the form would need some kind of password protection. The easiest would be IMHO to password protect the folder where your php is. It's not too hard in Apache.
Check this link: http://www.groovypost.com/howto/htaccess-password-protect-apache-website-security/
I'm not familiar with your experience in PHP, but I hope you can make a form to edit a database record. If not, then please use google, there are tons of tutorials on it.
You could use imap extension http://php.net/manual/en/book.imap.php it allows you to read emails from email box. usualy, programmers create keywords that act like commands to script, for example, if title of email is match pattern UPDATE pageID then it will process email body as content for this page.
This script will be running with crontab, which is scheduler for unix OS. So you can run it every 1 hour for checking new mail.
maybe your client could send an excel sheet and you parse this email attachment on server side with php.
https://code.google.com/p/php-excel/
One option is to use a blogging platform to post the latest specials. You could then use PHP to grab the RSS output (last feed item) and populate the website. This would take care of the form, log in and security part. It also gives the client a running history.
(if you want to go this route I can post an rss reader php script to help you out)
Alternatively, if you decide to go the email route, put the text between something like this:
<!-- PUT PARAGRAPH HERE -->
Here is today's specials.
<!-- /PUT PARAGRAPH HERE -->
Can be anything really, but bookending it with something constant you can search for in the string will help avoid many of the issues mentioned by #SoonDead above. PHP can convert it into something consistent, but you'll need some php knowledge to make it work.
I am looking for creative heuristics to detect if an HTML email was not just opened, but also likely read.
Currently, we embed an img tag linking to a PHP script, which marks anonymously in the database that the email was opened. (We can assume here that the users we're interested in told Outlook it was OK to display the images.)
This method is okay, but it's hard to tell what it means - if they clicked the email just to get it marked as read, if they keyed through it while skipping through other mails, or if they genuinely read and enjoyed the email.
My latest try was to implement a delay of 10 seconds on the image download before making the database call marking the mail as read, however it seems that Outlook finishes the request in the background, even if they skip out of the email. Does anyone have any creative recommendations that may work better?
It's kind of unethical in my opinion to do this without your user's knowing. That's why so many email clients go to measures to protect against this.
I know this might not really help you, but if your user genuinely read and enjoyed the email couldn't you just add an HTML anchor in the email that they can click on to go to your website and you can add a tracking code to that to figure out who it was / which email address clicked on the link at the bottom of your email. Something along those lines just seems like a better method to me. Maybe that's just me though.
Hmm, tough one without the use of javascript, and as we know, most email clients have their security too high to use javascript.
Not putting much thought into it, could you use PHP's shutdown function, and have the image "loop" load....basically meaning that the image will never completely load because we are stopping it on the server side with a loop. Will Outlook still try and download the image after a timeout - will it timeout?
It seems like you are dealing with two different issues...trying to harness Outlook and trying to do something that most people don't want.
This is why there are offers and links like "click here for 10% off coupon" or "read more".
From a marketing standpoint this would be a true test if people are interested in your emails....but I guess that wasn't your question ;)
Folks,
I have a PHP-based site (using the QCubed framework); as a part of the site, I have a daemon that's sending out several thousand emails a day (no i'm not a spammer, everything is opt-in :)). Emails are sent through a custom framework component; that component serves as an SMTP client. I'm using a paid SMTP gateway from DNSExit.com to get the emails actually delivered.
Those emails are simple HTML-based emails; they really have just simple links inside.
My issue is that these links sometimes (not consistently!) get scrambled during transition. Tags somehow get mixed up, and some links are non-functional in the email. The issue happens on a small percentage of all sent emails; it is not consistent (i.e. the same exact source message HTML may or may not cause the scrambling in transition).
Have any of you seen this? Any thoughts on how to troubleshoot?
Is it possible that you are using temp files to create the emails (or at minimum to create the variable content)? I did something vaguely similar once upon a time. The email text was generated and written to a temp file based on the exact time in seconds. Unfortunately, when sending thousands per day, we were hitting the same second more than once (since there are only 86k seconds available). That might explain a) the small error rate and b) the apparent randomness. For troubleshooting, I'd just see if the error rate increases with the number of emails and go from there.
I ran into a similar problem on a server running sendmail.
I was creating and testing an html email that would one day be mass mailed (opt-in, of course). I had myself a template for the email that was easy for any html programmer to read, but as such was heavy on the whitespace to line everything up correctly. I thought to myself, if this is going to be mass emailed, after the template is rendered, I think I will minimize the whitespace in the file to save on space! So I created a brilliant regular expression to rid any unnecessary to send whitespace from the rendered email.
Upon sending the email to myself, I opened the email and was baffled when I saw that some of the css and html were not showing up correctly, when my previous emails prior to my regexp were. By looking at the original message I noticed that every once in a while, an exclamation mark (!) was appearing seemingly randomly throughout the message, thus breaking any css and html that came in its random path.
Turns out that sendmail doesn't like it if a line in your email gets too long without a line break. When the line does get too long, sendmail will insert an exclamation mark followed by a line break right then and there, just to confuse and confound you.
Why did it not just choose a space between words to line break? Why insert the exclamation mark? Questions I'm afraid, without answers.
My solution?
sudo apt-get remove sendmail
sudo apt-get install exim4
I was having other problems with sendmail like it taking a full 60 seconds to send an email and exim4 just worked and I have never had to think about it again.
If your mail server is using sendmail, this very well could be the problem, if not, thank you for letting me share my story with you. I needed to vent.
When you're sending email you should encode it so every line in the message body is not longer then 76 characters. You could use base64 for this but most systems use the
quoted-printable encoding for text because it generates smaller messages.
Base64 is usually only used for binary data.
The problem is that HTML is not compatible with email. That is why I created Mail Markup Language.
HTML was created to operate with the HTTP protocol as those two technologies were invented by the same person at about the same time. The difference is that HTTP is a single session one way transfer from a server to a client. That never changes as the HTML document always originates on a server, is sent to a requesting client, and once the transfer completes the connection between the client and server is dropped.
Email does not behave in such a way. In email a communication originates at a client, is sent to one or more email serves, and then terminates at a distant client. The biggest difference, however, is that the document does not die with finality of a single transmission instance as is the case with a document transfer over HTTP. A document sent in SMTP can be replied to, forwarded, or copied to multiple unrequested users. This one difference is profound when consideration for an email thread is considered.
The problem is that SMTP and HTTP are different as demonstrated in the prior two paragraphs. This differences is compounded in that SMTP and HTTP have radically different formatting methods for the creation of header data. HTML has header data that is intended to be compatible with the headers of HTTP transmissions and offer no compliance to SMTP transmissions. The HTML headers also do not account for the complexity of an email thread.
The problem is exemplified when email software corrupts a HTML document to add formatting changes necessary to fit the conforming demands of that software and to also write header data directly into the document. This exemplification becomes extremely pronounced when an HTML email becomes an email thread. Since the HTML header data has no method to account for the complexities of an email thread there is no way to supply relevant presentation definitions from a stylesheet that survive the transfer of the document. Each time a HTML document, or a document with HTML formatting, is sent from one email software to another the document is corrupted and each email software device corrupts the prior corruption. Email processing software may refer to either an email client, which certainly will corrupt a document, or an email server, that may only likely corrupt an email document.
The solution to the problem is to create a markup language convention that recognizes the requirements of email header data directly. Those requirements are defined in RFC 5321 for the SMTP protocol and RFC 5322 for the client processing. The only way to properly extend this solution to account for the complexities of an email thread are to provide a convention for a multi-agent DOM.
Paragraphs deleted due to technical inaccuracy and difference between the term multi-agent DOM and the nature of an invented feature not mentioned here even prior to the edit.
EDIT: a multi-agent DOM applies some degree of hierarchy, which may not be necessary to represent an email thread.
Had 2 problems with email data - usually "?" symbol somehow got inside some words, another was UTF and title related. First got "fixed" by changing hosting provider (so it was mail-server related) second one got fixed by changing PHPmailer library.
Try to specify how exactly data is scrambled.
Have you any special attributes in your links? May be title attribute with not escaped quotes inside?
Something like this: Link
I am displaying the email addresses stored in the database on a page using PHP.
The email address on a page is displayed as below:
Email: test#example.com
Now the email address shown on a page should use JS spam protection to hide it from spam bots.
Try an email encoder, or implement one in your script.
you can try to use image (with php-gd lib) write on a image then show this. (like facebook)
Here are some good resources to look at:
Hiding Email from Spam Bots
Displaying Emails for Users, But not Spambots.
Making Email Addresses Safe from Bots
You could probably find more using a Google Search of StackOverflow.com
Oh, and there are ones asking if you 'should' do it:
Does Hiding Emails really make it harder?
Do You Hide Email from Spam Bots on Websites
I'd argue that you're better off not bothering; client-side spam filters are pretty good these days, and by jumping through hoops youjust make thing harder for humans.
That said, the best way is to convert it to whatever kind of format you want, whether it's an image or a simple string substitution:
joe#domain.com -> joeATdomainDOTcom
and then write the address out marked up with some kind of class identifier:
<a href="mailto:joeATdomainDOTcom" class="Email">
<!-- image or link text here -->
</a>
Then use Javascript to decode all the email links and re-write the href attribute to the real address. Most spiders crawling for email addresses won't execute Javascript, so the encoded semi-useless address is all they'll see.
Users with JS enabled will get more or less expected functionality (clickable mailto links) while users without JS will at least get human-readable addresses.
The worst thing you can do is write the unencoded addresses out, and trust some Javascript to hide them.
PHPEnkoder (a port of Hivelogic's The Enkoder)
"Enkoder, which works by randomly encoding a piece of text and sending to the browser self-evaluating Javascript that will generate the original text. This works in two ways: first, a bot must first have a fairly complete Javascript implementation; second, the decoding process can be made arbitrarily computationally intensive."
It's BSD-licensed.
Try http://recaptcha.net/learnmore.html It can protect email addresses with a captcha..never tried it though, but i uses reCaptcha for a login form and it was easy to work with.
Displaying them as pictures is one option. Also requiring the user to pass CAPTCHA test before seeing the e-mail address works too. Combine those two and spam bots will likely never get the e-mail addresses.