Sending an email from a server isn't quite as easy as sending it from a client.
I know I can choose to send plain text or html, but I want to keep things as simple as possible.
I have a link in the email that the user should click to reset their password.
When I send the whole link, and check my gmail, it becomes a hyperlink automatically.
My guess is that this isn't the case in all email clients.
What are my options for sending a link in plain text format?
Is the only way to be sure to have a clickable link to use html?
If I use html, what is the minimum markup I must have?
If you send your email in plain text, then your URL will be plain text. It's plain text, you can't dress it up.
If you send it as HTML, just use a simple anchor tag and use the URL as both the href and the text. That way if a mail client removes the link at least the user will still be able to copy/paste the url.
Another option rather than simply including urls inline in your text is to use a markdown-ish syntax that allows you to separate the two. For example, using citation-style link references (a la the way SO does it in this editor) could be done like so:
Hello, this is a plain email that links to a [cool page][1].
Sincerely,
Joe
[1]: http://foo.com/cool_page
I've seen it done this way and it works well, especially if you have a lot of links.
There is a syntax similar to angle-addr as defined in RFC2822 and mailto URL Schema defined in RFC2368.
RFC2396 mentions using angle brackets as delimiters around URI in text documents and protocol fields:
The angle-bracket "<" and ">" and double-quote (") characters are
excluded because they are often used as the delimiters around URI in
text documents and protocol fields. The character "#" is excluded
because it is used to delimit a URI from a fragment identifier in URI
references (Section 4). The percent character "%" is excluded because
it is used for the encoding of escaped characters.
delims = "<" | ">" | "#" | "%" | <">
Example derived from real-world usage:
From: alpha#beta.com
To: theta#omega.com
Content-Type: text/plain
Some introduction text
The text I want to display in this link<https://some.target.dom/ain#place?i=want&to=go>
The rest of my plain text message
To send html emails you have to provide full structured html page with no relative links (only full urls) for any resources(images src, styles and href link attributes).
But text emails are good enough for their purposes, in web mail clients links are found in mails text by browser, and standalone mail clients do this work by themselves.
Related
My web application sends emails to subscribed users.
The email is formatted as an html page and contains html addresses specified as plain text (not inside href tag).
The intent is for the email client to display the html address as simple text, one that the user can "paint" with the cursor and copy to clipboard
This works just fine in some email clients (for example yahoo). However,
other clients (for example, MS outlook and gmail) detect these pieces of text, and display the html address as a link, making it difficult for the user to do the paint-copy-paste described above.
I tried the following:
wrap the text in CDATA block - gmail then disregards the whole block
escape the html address (instead of http://... --> http://...) - makes no difference (still make a link out of text)
any ideas?
you could but a double :: to disable the parsing:
http:<span style="display: none;">:</span>//google.com/
This will not show the second : and should avoid the parsing.
EDIT:
This will work:
http<span>:</span>//google<span>.</span>com/
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.
I need to hide a 30 character string inside the HTML of an e-mail so when a user replies, their reply can be linked on our server to that 30 character string. We don't want to add the string to the subject or body of the e-mail where it's visible to the user. We also don't want to hide the text which would result in accidental selecting of the 30 character string.
The problem:
Many e-mail clients (like gmail) reduce HTML e-mail content to just the basic tags, making it difficult to find a tag that can hold an arbitrary string. This means we can't create an arbitrary tag, only use standard tags.
Our best solution:
Hide the string in the "title" tag of a table in the e-mail, like this -
<table title="30_character_string">
The solution above works in most cases. Most e-mail clients don't strip out the title tag, making it a viable option.
Why we're stuck: This isn't the best solution because sometimes e-mail clients get very restrictive and eliminate even the title attribute.
Can you help? What is the most successful way to hide an arbitrary string in the body of an HTML e-mail? Is there a better solution for this sort of linking?
If you put the value in markup, plain text replies won't work. Consider a "smallprint" section on the bottom of your email below your signature.
Dear User,
Email content
Regards,
Logo and such
ReplyIdentifer-xxxxxxxx.
If you don't care for that, add a div to the bottom of the email (again below the sig). ANd again, it will be on the bottom of the email where the user will rarely even care to look.
<style>.hide{display:none;}</style>
<div style="display:none" class="hide">ReplyIdentifer-xxxxxxxx.</div>
In this case, you only see it if the email client removes css AND style tags.
Checking some HTML emails I've received & Gmail seems to allow a <head> tag within the e-mail HTML. You could include the info in a <meta> tag within the head of the email.
What type of account are you reading mail in to? If it's also Gmail, you could make use of their ability to allow abritary strings in your emails address after a plus symbol. Override the reply-to header that you set on your out-going mail to youraddress+uniqueID#gmail.com
EDIT: Staying along the lines of e-mail headers though (which feels like it should be the right way to do this), if you make sure to generate a unique Message ID header for each copy of the mail going out, the In-Reply-To header that you get back should be unique to that recipient and that message. Gmail respects the Message ID header & provides the appropriate reply header in response, as should most (all?) mainstream clients/services
Here's my scenario:
I'm trying to embed a hyperlink in the body of an email that will be generated using the mailto hyperlink. So I will have something like this:
<a href="mailto:someemail#test.com?subject=Email Subject&body=Click
<a href=%22http://www.google.com%22>Here</a> to go to google.com">Click Here to open
Outlook and with generated email</a>
The problem is, this scenario will open outlook but the email will actually appear as:
Click Here to go to google.com
the http://www.google.com will be clickable in the email but the anchor tag will also show up and it is ugly.
I'm not sure if this is possible, but can I somehow create this hyperlink in a way that Outlook won't catch the URL address and automatically create the anchor tag around it?
You can't do this. See the specification for mailto: URIs, which says:
The special "body" indicates that the associated
is the body of the message. The "body" field value is intended to
contain the content for the first text/plain body part of the
message. The "body" pseudo header field is primarily intended for
the generation of short text messages for automatic processing (such
as "subscribe" messages for mailing lists), not for general MIME
bodies. Except for the encoding of characters based on UTF-8 and
percent-encoding, no additional encoding (such as e.g., base64 or
quoted-printable; see [RFC2045]) is used for the "body" field value.
As a consequence, header fields related to message encoding (e.g.,
Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST
be ignored. The "body" pseudo header field name has been registered
with IANA for this special purpose (see Section 8.2).
I'm looking to add some Chinese characters in a mailto: email link.
I've tried
Email
but when I click on the link the Outlook subject line shows:
调查亨德森 / Inquiry
I've also tried
Email
but I get the same result as above.
I realize this may be an Outlook issue but I'm interested in finding out the correct way to implement this functionality.
Raw URL Encode
To encode mailto links / standard links with special characters you can use the php function rawurlencode
If you are looking for an online tool try http://www.cafewebmaster.com/online_tools/rawurlencode
Using your example:
Email
would convert to:
Email
Since subject is in mail header, there is no way to know what encoding you are using. You need to use MIME Mail header extension defined in this RFC,
http://www.ietf.org/rfc/rfc2047.txt
The subject in Chinese would look like this,
Subject: =?GB2312?B?u7bTrbLOvNPDwLn61bm74Q==?=
But more and more clients assume UTF-8 encoding now. You might want try that also.
It's cumbersome but possible, here is a good article that discusses both the standard compliant way of an ideal world and real world scenarios with Internet Explorer.
For your text in comment #1, please enable the "Tool->options->mail format->International Options"->"Enable UTF-8 support for mailto: protocol"
I've been trying to put non-ASCII characters in subject lines for a while now. The bottom line is: it does not work reliably.
My (limited) understanding of why it does not work is that the standards say that email is 7-bit ASCII. The MIME standard gets around that by encoding the contents of the email differently. However: the subject line is not part of the contents. It's a header.
Because the default charset of outlook is gb2312, so when you encode the subject, you must translate the Chinese character to gb2313, then encode it.
In a word, the charset which you pass must be consistent with the default charset of outlook.