I've made a contact form with Webform module. But it doesn't send HTML emails. I have installed HTML mail, Mail MIME modules. HTML mail module's send test works fine, but mail from Webform is always converted to plain form instead of HTML. I've tried to set email headers using this function:
function mytheme_webform_mail_headers($variables) {
$headers = array(
'Content-Type' => 'text/html; charset=UTF-8; format=flowed; delsp=yes',
'X-Mailer' => 'Drupal Webform (PHP/'. phpversion() .')'
);
return $headers;
}
But it still doesn't work.
Edit: I've found that setting header works, so the mail is send as HTML, but the problem is, that content of email is converted to plain format (all HTML tags removed and "formatted" respectively)
it's an old post, but maybe still useful:
http://drupal.org/project/mimemail
this modul adds a checkbox to select, weather you want to send html-mails or not
Looks like this should be a built in feature (as it was in Drupal 6 version of the webform module) but there are some issues with the Drupal 7 version. The webform module code points to issue https://drupal.org/node/1043086. Keep an eye on that thread for an update.
Probably, You should use mailsystem module together with htmlmail module, to define the email processing spesially for Webform module.
http://drupal.org/project/mailsystem
http://drupal.org/project/htmlmail
Related
I needed to generate a newsletter e-mail server-side. I researched various options, but I picked React (server-side rendering) because of good TypeScript support and my familiarity with that technology.
Generating an e-mail that displays correctly in GMail (or any other popular client) is a very tricky subject, as one needs to use small (and legacy) HTML subset. But that's a separate issue.
So I've crafted a test e-mail with React SSR, using the subset of HTML supported by GMail. To be sure, I've validated it with W3 Validator and it was successfully checked.
But when I sent the generated HTML output to a GMail address and displayed it in the GMail desktop web application, the output was a mess. In the mail HTML presented in the browser, some elements had missing inline CSS properties, while other were outside of their original parents.
How can I generate an e-mail using React that doesn't break in the GMail web application?
React renderToString function (and the similar ones, too, probably) emits a single-line minified HTML output without any line length limit.
For reasons beyond my reasoning, such single-line HTML documents can "break" GMail HTML parser and cause glitchy output.
But, on the other hands, resources online actually recommend e-mail HTML minification, as whitespace can (reportedly) be interpreted inconsistently across e-mail clients. So pretty-printing HTML output doesn't sound like a good idea.
A solution is to re-minify the HTML document, but with a line length limit. To be safe, I've put the limit quite low. I've used a popular html-minifier package.
import * as React from "react";
import { minify } from "html-minifier";
import { renderToString } from "react-dom/server";
export const renderMyMail = (params: MyMailParams): string => {
const reactHtmlString = renderToString(MyMail({ params }));
const reminifiedHtmlString = minify(reactHtmlString, { maxLineLength: 255, keepClosingSlash: true });
return reminifiedHtmlString;
};
Now, the e-mail displays correctly in GMail web application.
I have tried the following code to send an email from an Universal Windows Platform app. It works fine when I use EmailMessageBodyKind::PlainText. However, as indicated in the code below, EmailMessageBodyKind::Html seems to launch the email client with no content. Does anyone know what else needs to be set to get this to work - the documentation is sparse 8 (
using namespace Windows::Storage::Streams;
using namespace Windows::ApplicationModel::Email;
using namespace Windows::Security::Cryptography;
auto bin = CryptographicBuffer::ConvertStringToBinary(
L"<html><body>this <b>is</b> text</body></html>",
BinaryStringEncoding::Utf16LE);
auto memStream = ref new InMemoryRandomAccessStream();
concurrency::create_task(memStream->WriteAsync(bin)).then(
[memStream](unsigned)
{
auto email = ref new EmailMessage();
email->To->Append(ref new EmailRecipient(L"test#gmail.com"));
email->Subject = L"Email Report";
auto randomAccessStreamReference = RandomAccessStreamReference::CreateFromStream(memStream);
email->SetBodyStream(EmailMessageBodyKind::Html, randomAccessStreamReference);
EmailManager::ShowComposeNewEmailAsync(email);
}
);
Well, I got some bad news for you.
It is not possible to do so using EmailManager.ShowComposeNewEmailAsync
Regarding using SetBodyStream with EmailMessageBodyKind.Html, we have this from MSDN forum:
Currently, the EmailMessageBodyKind.Html won't work for create a new
HTML e-mail and there is no other way as a workaround, I've checked
the internal resource, this API is used for populating messages from
App server and save e-mail message into local folder.
The thing is: EmailManager.ShowComposeNewEmailAsync uses mailto to send the message and, as stated in some other question already answered here:
Section 2 of RFC 2368 says that the body field is supposed to be in
text/plain format, so you can't do HTML.
However even if you use plain text it's possible that some modern mail
clients would render the resulting link as a clickable link anyway,
though.
That being said, you're relying on the mail client to render that HTML for you.
I've tested this using Windows 10 Mail Client, Gmail and Outlook (both the later on a web browser), and all of them failed to render a simple HTML <b> tag on the mail body, showing it as plain text instead.
Now, for the alternatives (from that same MSDN forum thread):
Note that if I use the ShareDataContract (DataTransferManager), I am
able to set the HTML in the request and it will appear in the email
body if the user chooses to share via Mail. However I would like to
skip the Share UI and go directly with composing an email with
recipient already populated, HTML body, and image attachments.
One alternative is to persist the HTML body to a file and then include
that file as an additional attachment, however that is not ideal
The DataTransferManager successfully formatted the HTML message. Here's a small sample of how your sample code would look like, adapted from MSDN:
void YourView::ShareHtml()
{
DataTransferManager^ dataTransferManager = DataTransferManager::GetForCurrentView();
auto dataRequestedToken = dataTransferManager->DataRequested +=
ref new TypedEventHandler<DataTransferManager^, DataRequestedEventArgs^>(
this, &YourView::OnShareHtml);
DataTransferManager::ShowShareUI();
}
void YourView::OnShareHtml(DataTransferManager^ sender, DataRequestedEventArgs^ e)
{
DataRequest^ request = e->Request;
request->Data->Properties->Title = "Email Report";
String^ html = L"<html><body>this <b>is</b> text</body></html>";
String^ htmlFormat = HtmlFormatHelper::CreateHtmlFormat(html);
request->Data->SetHtmlFormat(htmlFormat);
}
The limitations of this approach are:
You cannot force the user to select e-mail as the sharing option
You cannot previously specify the mail recipient.
How can I open the default compose mail window from the user's mail app from within a Qt app?
I found there is some class for mobile with Qtmobility, but I don't have access to this class as I'm working on a desktop app.
I also found people to use a URL sheme with a mailto in it. This isn't working for me because the html is stripped at some point, probably because of the url being too long and the html is not rendered in html but in plain text.
How can I precompose a mail in Qt and open the default mail app?
There is no built in way in Qt to send email with HTML formatting. The Mailto method will work for unformatted text, e.g.
QDesktopServices::openUrl(QUrl("mailto:?to=recipient#example.com&subject=The subject of an email&body=Here is some email body text", QUrl::TolerantMode));
But this cannot be used for html formatted text.
If you absolutely need HTML you will need to look at the options for your platform(s):
MAPI for Windows
AppleScript and Mail.app on OSX
Mail on Linux
Old topic but :
You could also try another way, as I did, using a web service.
I have a php web service that send email to a specific mail address, so I just send the message data to this web service, that will handle the rest for me.
This is to abstract yourself of using a desktop software that most of the time users don't have ( we all use gmail anyway, so you know ... ).
In php :
// sending mail to my#address.com
$headers ='From: sender#address.com'."\n";
$headers .="Reply-To: replyto#address.com"."\n";
$headers .='Content-Type: text/plain; charset="iso-8859-1"'."\n";
$headers .='Content-Transfer-Encoding: 8bit';
mail('my#address.com', '[TAG] mail subject', "some body text.", $headers);
Careful of security though !
My ActionHandler.ashx file should be POSTed yet upon entry to ProcessRequest the context.Request.RequestType is always "GET".
Background:
This HttpHandler currently works OK (i.e. clicking a link in an email causes my ActionHandler.ashx to be entered and the querystring is processed correctly). For example:
https://mdwdata/CorporateBrain/ActionHandler.ashx?Action=MarkComplete&ID=1024~nzmewoojgnn&CUID=13
is the URL for the link shown as Mark-Complete in the image just below:
But now I am trying to improve it by following this advice in a previous SO thread :
"In the body of the email, instead of sending a link, include an HTML form that contains a button which performs a postback to your server."
Problem Summary: When I click the Submit button, my handler is entered with verb GET not POST (hence, I have no access to the hidden form data in the Request.Form collection.
Here is a snippet (image) of the email body
If I can get the Submit to post the hidden form variables to my handler, then of course I would remove the links. In the debugger, I verified the form data and it looks good me:
I added this line to my web.config file:
<add path="ActionHandler.ashx" verb="GET,POST" type="System.Web.UI.SimpleHandlerFactory" validate="true" />
Also, my email client is Thunderbird.
What would cause the request to be GET instead of POST?
The short answer to this problem is that Thunderbird does not POST to the URL in the Action attribute of the HTML form tag. Even the newest version of Thunderbird (version 31.2.0) "ignores" the POST and requests the URL via GET.
The construction of the HTML form is properly done and other email clients I have tested work fine:
Microsoft Office 365 Outlook Web App
Google GMail
So, I guess I am doing it "right" but some email clients apparently don't support this (even my favorite which is Thunderbird).
I am working on a script that e-mails some formatted html and images to recipients. Using MIME::Lite, I figured out a way to send the css file and the image file it uses as attachments. The image comes out at the end of the mail message - as an attachment. The following line appears to work:
<link href="cid:style.css" rel="stylesheet" type="text/css" />
My question is what should be the syntax for the following lines (in the file style.css)? Following does not work.
body {
background-image:url("cid:bgLine.png");
background-repeat:repeat-x;
}
Furthermore, how can I stop the mail client from showing the image by itself? Script I am using follows:
my $msg = MIME::Lite->new( From =>"from\#company\.com",
To => "to\#company\.com",,
Subject =>"Action Required",
Disposition =>'inline',
Type =>'multipart/related');
$msg->attach(Type => 'text/html', Data => qq{#htFileContents});
$msg->attach(Type => 'text/html', Id => $cssFileName, Data => qq{#cssFileContents});
$msg->attach(Type => 'image/png', Id => $imageFile, Path => $imageFile);
$msg->send("sendmail","/usr/sbin/sendmail -t");
Having the mail client access an URL for the css or the image file from an http server is not an option. The e-mail needs to be self-contained. TIA for an example showing the syntax.
This won't really work. Even if by some miracle you were able to get your attachments to see and talk to each other, Outlook won't support background images, Gmail will strip out your linked css file and any embedded css, and hotmail will not support css backgrounds.
Sounds like you need to host an HTML email somewhere that accepts dynamic parts, and trigger the send from within your application, passing it the dynamic parts to fill in before sending. Check out a tool like Lyris Listmanager or something.
There is no connection between the title and the posted question above.
Anyway, in order to send emails, showing safely images, that are attached in the email, it just not enough to refer the images with some cid: URLs.
Attaching the images to the email has the following specifics:
Replace the external URLs to images with the URLs of an attachments in the email.
The email to generate is not just multipart/mixed what is construed by default of JavaMail, but MIME multipart/related type, in order to allow the email client to use the images.
The attachments for the images must be have
Content-Disposition: inline; filename=... header, in order they not to be shown as attached files, but to allow the email client to use them.
ContentID:unique-name#domain header, where the unique-name and domain have to be replaced with actual values and keep < and >!
Example: ContentId: logo.png#paysafe.com
The references in the HTML part of the email message (the message body) happens through cid:content-id URLs, where content-id is the the value of the ContentId header of the attachment holding the image
Example:
References:
https://javaee.github.io/javamail/docs/api/ for the mail protocol-specific properties.
https://www.rfc-editor.org/rfc/rfc2392 - defines the CID: URL schema and the use of addr-spec
https://www.rfc-editor.org/rfc/rfc822 - defines addr-spec in the form: local-part "#" domain
https://www.rfc-editor.org/rfc/rfc1806 - defines Content-Disposition header
https://www.rfc-editor.org/rfc/rfc2387 - The MIME Multipart/Related Content-type - vital for image inlining