I have a button to send an e-mail message. This opens a new e-mail but the problem is that the subject and the body text are not added to the e-mail message. This is what I have so far that is not working:
<input style="background: #4a5e70; color: #ffffff;" type="button" value="REQUEST INVITE" onclick="window.location.href='mailto:me#any.com’;” subject=“Request%20invite;body=Hallo%20you;”/>
In almost every language (PowerShell is one exception), text strings are delimited by typewriter quotes (' and ") not typographic quotes (‘, ’, “ or ”). You should replace your quotes like so:
onclick="window.location.href='mailto:me#any.com?subject=Request%20invite&body=Hallo%20you'"
The onclick attribute is written as a single string (delimited by double quotes) whose href whose value is a single string (delimited by single quotes) expressed as a URL-encoded query string.
Note also that you can’t rely on mailto links working unless users have configured a local email client correctly.
See the Mailto Wikipedia article and this related question for more information.
Related
I am using java mail api to send "text/plain" content-type emails over smtp. I am using email templates that are stored in database. In order to put line breaks in the email body, I am using \r\n. However, when the email is received the \r\n are not converted to line breaks instead they appear as text \r\n.
For example:
This line is followed by a carriage return.\r\nThis is a new line.
in the template email body appears in the received email as
This line is followed by a carriage return.\r\nThis is a new line.
instead of
This line is followed by a carriage return.
This is a new line.
I have tried using just \n and that too does not work. How can I resolve this problem?
I get same problem,
And when I add "space" before newline, It's work
But that's mean create tag " pre " for each line.
If the template contains the line breaks as separate backslash and 'n' characters, you're going to need to do something to convert it to a real "newline" character. Ditto \r. Better would be to store the template with real carriage return and newline characters to begin with.
I have a similar problem to this question, but could not find any useful information in the answers.
I'm trying to send an email to a recipient with a display name Lastname, firstname using the Quoted-Printable encoding. The exact header, as seen in the source of the received email, is:
To: =?UTF-8?Q?"Lastname,=20firstname"?= <email#example.com>
However, Outlook displays it like this:
Effectively interpreting the comma as a separator between recipients, even though it's enclosed in a Quoted-Printable encoding.
When there is no comma, the header is properly interpreted.
Am I doing something wrong, or is it impossible to use commas in a display-name?
Note: I'm currently using Amazon SES and the ZF2 Zend\Mail component, but the tools should not matter, I'm only interested in the correct header format and will adjust my tools or code accordingly.
What you are seeing is not correct behavior as far as I can tell, but the workaround should be obvious: QP-encode the comma. The double quotes are redundant and should be omitted:
From: =?UTF-8?q?Lastname=2C_Firstname?= <email#example.com>
(As such, it is obviously insane to put the last name first; but e.g. Outlook connected to Active Directory seems to insist on this silly anti-convention.)
The standard way to format the 'From' email header is
From: John Doe <john.doe#example.com>
But what to do if there's a comma in the name?
From: John Doe, chief bottle washer <john.doe#example.com>
If I do that, my MTA automatically converts this into:
From: John#this.server.com, Doe#this.server.com, chief bottle washer <john.doe#example.com>
My first guess is to use double-quotes around the full name, but I can't find any official documentation confirming this and I'd like my emails to be readable by all email clients.
To elaborate on the answer by #Fls'Zen, yes the proper method is to enclose the name in double-quotes.
From a practical point of view there's no harm in wrapping all names in double-quotes, just be sure to escape a double-quote if it appears in the display name \" (or just replace with a single-quote). But if you want to be completely by the spec, you shouldn't use the double quotes if you don't have to.
For all the dense details, E-mail header fields are defined by RFC 5322. The relevant section for multiple originators in the From header is 3.6.2, and the relevant sections for quoting delimiters is 3.2.1 and 3.2.4.
When the following regular expression matches, then an email display address must be quoted.
[^-A-Za-z0-9!#$%&'*+/=?^_`{|}~\s]
For ASCII characters, this can be done by escaping any double quote characters with a backslash, and enclosing the string in double quotes. For non-ASCII characters, the more complex MIME escaping is required.
E-mail header fields are defined by RFC 5322. The relevant section for multiple originators in the From header is 3.6.2. The relevant sections for quoting delimiters is 3.2.1 and 3.2.4.
Apologies if this has been answered already. There are similar topics but none that I could find pertaining to Cocoa & NSStrings...
I'm constructing a clickable URL to embed in an HTML email to be sent via the MFMailComposeViewController on the iPhone. i create the url then use stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding to polish up white space, etc. then add some surrounding HTML to get:
view
All's well so it's appended to emailBody. However once [mailComposer setMessageBody:emailBody isHTML:YES] all the & become & which isn't ideal within my URL.
can i control this? is there a better encoding algorithm? my HTML is a bit rusty perhaps I'm using the wrong encoding? I'm sure on the server I could parse the & back into & but looking for the Cocoa way...
Thanks!
Actually, & should always be encoded as & in HTML attributes. Including links. Including form value delimiters. So it's done exactly what you want, even though you didn't know you wanted it.
Look at it this way: in your URL, you have &age=53... That's interpreted first as a character entity, and only after that doesn't work is it interpreted as an ampersand followed by more character data.
The W3C spec is quite clear on this:
Authors should use "&" (ASCII decimal 38) instead of "&" to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use "&" in attribute values since character references are allowed within CDATA attribute values.
That should settle it: use & not &.
Are you calling MFMailComposeViewController's
setMessageBody:isHTML:
and what do you set isHTML to?
Depending on it's setting it might very well be that MFMailComposeViewController is trying to help you out be encoding the entire message body...
Either don't encode the body yourself or make the entire body HTML.
Sites like Facebook have the user's name in the subject line that sent you a message.
Because of this, what escaping would you do on user entered values in a message subject? Or would you just not allow anything other than a-z, 0-9, period, comma and single quotes?
You need to be careful with email headers, 8 bit chars are a bit of a no-no. (mail servers will reject them).
The proper way to do it is to MIME encode your subject lines and make sure the ASCII char \n is not in the subject line (technically multi-line subjects are possible, but I'd imagine plenty of mail clients would have problems)
See http://en.wikipedia.org/wiki/MIME#Encoded-Word for more info.
Escaping is needed if there are forbidden characters. The subject is terminated by a NL so this is the only (ASCII) character that shouldn't be put in the header.
See also rfc821
It’s the same problem with contact forms.
If you look at an email header you get e.g. this:
Subject: user123 has sent you an invite
From: "User123" <user123#example.org>
You have to make sure that user names do not resemble values of an email header. If it’s possible for a user to name himself “To: spamreceiver1#example.org, spamreceiver2#example.org, spamreceiver3#example.org, spamreceiver4#example.org” you have to clean the input.
A search for “contact form spam” should show you what to do. You should at least remove all occurrences of "To:", "Subject:", "From:" etc.