-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
html email rendering as plain text #22
Comments
Thanks @adamaltman, does this happen with all HTML messages or just occasionally? I can sort of reproduce it, but only when the HTML email follows a plain text email. When it happens, the broken HTML message contains the previous plain text email at the start (and I assume the headers), which is why MIME parsing fails. I'll fix that anyway, but does it sound like it might be the same bug? |
Right now it happens with all HTML messages. |
Ok thanks, I'll have another look Out of interest, do you know if the SMTP client is using pipelining? |
Ian - I'm not sure. The client is a php web application. The library it uses for email is: http://swiftmailer.org/ |
No problem, thanks, I'll see if I can reproduce it a bit more consistently. |
I have the same issue with a Drupal (PHP) website + PHPMailer library. |
Would either of you be able to provide MailHog logs demonstrating the bug so I can replay the SMTP conversation against my MailHog to reproduce it? If you don't want to post it here, if possible could you e-mail them to me instead? email@iankent.co.uk Thanks |
I have the same issue using a Rails application, i'm willing to provide logs if you guide me to their location or how to log them Thanks for this awesome program, mailcatcher is sadly not really maintained and doesn't work for ruby 2.2.0 so this is a very good alternative! |
Thanks @JanStevens, that would definitely be useful! It'll depend on how you're running MailHog - if its from the command line, the logs should be going to STDOUT, so redirecting to file or piping to tee should work. Let me know if its Docker and I'll give it a go, to be honest I hadn't even considered how logging would work for the Docker container builds (and I'm no Docker expert!!). |
I'll keep this open for now, but I hope the latest release has fixed it - but couldn't reproduce it reliably anyway so not entirely sure. |
Sadly, no. At least in my case. MailHog version: 0.1.2 Linux amd64 I will sent you a log file in a minute. |
Think I've got it this time, but I'll keep the issue open for now |
Great work Ian. |
Oke still doesnt work for me, I've send you an email with the output. If you need more information then please let me know! thanks! |
Thanks @JanStevens, I'll have a look asap. |
I'm having this same issue. The headers look correct but the email is being rendered in plain text. Is there a way to force all emails to be rendered as HTML as a workaround? |
Same problem here. All my emails seen as plainText. It would be the perfect tool otherwise |
Simple php code :
I only see the "Plain text" and "Source" Tab in the MailHog web interface MailHog log : 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Starting session Thank you' 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Storing message IWU1gnlVnECkLLBj2hXoMRBD8ycJRYAnjMRiZFl9OrQ=@mailhog.example 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Sent 80 bytes: '250 Ok: queued as IWU1gnlVnECkLLBj2hXoMRBD8ycJRYAnjMRiZFl9OrQ=@mailhog.example\r\n' Got message in APIv1 event stream 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Received 6 bytes: 'QUIT\r\n' 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] [PROTO: MAIL] Processing line: QUIT 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] [PROTO: MAIL] In state 6, got command 'QUIT', args '' 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] [PROTO: MAIL] Got QUIT verb, staying in MAIL state 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Sent 9 bytes: '221 Bye\r\n' 2016/03/25 11:19:58 [SMTP 127.0.0.1:50089] Session ended Sending content: { "ID": "IWU1gnlVnECkLLBj2hXoMRBD8ycJRYAnjMRiZFl9OrQ=@mailhog.example", "From": { "Relays": null, "Mailbox": "www-data", "Domain": "ginza", "Params": "" }, "To": [ { "Relays": null, "Mailbox": "test", "Domain": "test.fr", "Params": "" } ], "Content": { "Headers": { "Content-type": [ "text/html; charset=UTF-8" ], "From": [ "Test \u003cnoreply@test.fr\u003e" ], "MIME-Version": [ "1.0" ], "Message-ID": [ "IWU1gnlVnECkLLBj2hXoMRBD8ycJRYAnjMRiZFl9OrQ=@mailhog.example" ], "Received": [ "from localhost by mailhog.example (Go-MailHog)\r\n id IWU1gnlVnECkLLBj2hXoMRBD8ycJRYAnjMRiZFl9OrQ=@mailhog.example; Fri, 25 Mar 2016 11:19:58 +0100" ], "Return-Path": [ "\u003cwww-data@ginza\u003e" ], "Subject": [ "Test html email" ], "To": [ "test@test.fr" ], "X-PHP-Originating-Script": [ "1000:functions.php" ] }, "Body": "\u003chtml\u003e\u003cbody\u003eThis should be html email\u003cbr/\u003eThank you\u003c/body\u003e\u003c/html\u003e", "Size": 246, "MIME": null }, "Created": "2016-03-25T11:19:58.484317981+01:00", "MIME": null, "Raw": { "From": "www-data@ginza", "To": [ "test@test.fr" ], "Data": "To: test@test.fr\r\nSubject: Test html email\r\nX-PHP-Originating-Script: 1000:functions.php\r\nMIME-Version: 1.0\r\nContent-type: text/html; charset=UTF-8\r\nFrom: Test \u003cnoreply@test.fr\u003e\r\n\r\n\u003chtml\u003e\u003cbody\u003eThis should be html email\u003cbr/\u003eThank you\u003c/body\u003e\u003c/html\u003e", "Helo": "localhost" } } |
+1 Happens for me too |
+1 For me too with the basic example from PHP website Example #4 Sending HTML email. |
I think the problem is that some messages have |
Nice shot ! |
Maybe we can add an other control over the content (html tags) if the Content-type is blank ? |
I have the same problem with a Drupal installation sending emails. Looking a bit in the Drupal system, I see that it send content-type with a lower "t". Is it possible to fix this? |
Can you fix this line - https://github.com/mailhog/MailHog-UI/blob/master/assets/js/controllers.js#L458 Instead of this: need to use something like this:
Because some messages have "Content-type" header, while MailHog checks only "Content-Type" Also I can't find controllers.js locally (Ubuntu) to fix this file. Do you know the location where I should search? |
Sorry, thought I'd fixed this... #113 turns out it was a different bug! controllers.js is inside MailHog-UI - https://github.com/mailhog/MailHog-UI/blob/master/assets/js/controllers.js there's a bunch of places where it treats headers incorrectly - more than happy to accept a PR to fix this one, but otherwise I'll have a look at cleaning that mess up asap! edit: afaik, to be RFC compliant in its header handling it can just lowercase everything before the comparison/lookup (I think it was defined in RFC822, but seems to be missing from the updated RFC2822 and RFC5322 - if anyone knows where its now covered it'd be a great help!) |
Any news on this? Also seeing everything in plain-text |
I'm finding that HTML tab doesn't display on version 0.2.1-4 - only the Plain text and Source tabs. The email body looks like: This is a multi-part message in MIME format.
The Content-Type header appears to have the right case to match the javascript. Does anything appear glaringly obvious that I'm missing here? |
I'm also seeing HTML emails in plain text. |
I have the same problem with HTML emails. |
Experiencing this consistently today with a Woocommerce site. If I have time I will help troubleshoot but does anyone want logs if I supply them? |
I am getting this as well with a Drupal 8 docker install. Regardless if I send in html or not. Been debugging, but not getting anywhere. I changed some info to remain anonymous, I see the mailhog.example.. not sure If that is causing the issue?
|
Oh man! I installed MailHog just to work on Woocommerce emails and now I find this issue! 😭 |
This might help in the meantime |
@hellerbenjamin Thanks I will use this. |
Hi, I'm facing similar issue as the mail body is shown encoded. I'm using mailer lib from dart |
I'm also experiencing this issue in Drupal if anyone has any suggestions. I'm using https://www.drupal.org/project/swiftmailer to send HTML emails but no luck.
|
Using MailHog with plain PHP and having the same issue. Using |
Having the same issue also using UTF-8. Interesting; The 'MIME' tab shows and it shows each part as 'unknown'. When downloading the email as EML file, and opening it in apple mail, it renders as expected. I'd love to drop a mailhog version, but 'mailhog --version' doesn't give a number, its blank. |
Same issue. Using multi-type emails and it doesn't display the HTML tab at all and the MIME type just gives an error: Error: null is not an object (evaluating 'data.MIME.Parts.length') Content-Type: multipart/alternative; boundary="1623876169.D35aAB6D0.32925"; charset="us-ascii" MIME-Version: 1.0 MIME-Version: 1.0 |
I put a paid bounty on this in hopes it'll get bumped in priority. https://www.bountysource.com/issues/7463217-html-email-rendering-as-plain-text |
try to prepand body an "\r\n". |
The mail receive identifies to parse on the boundary just fine, but the web interface just throws everything into the plain text tab and ignores the boundary and Content-Type headers. |
This is still an issue in Summer 2022, I cant see how this will allow us to continue with Mailhog. Any updates? I have the issue from nodemailer |
Also having the same issue with |
For people who are using javax.mail, make sure to set the content type right before Transport.send.
This is probably it's your mail library problem, not mailhog's problem. Make sure to debug and find out where the content type header is reset to text/plain. Best of luck! |
In case it helps - I was experiencing the same using spring and JavaMailSender. Mailhog would not render the html. The email was being sent as Content-Transfer-Encoding: quoted-printable which ends up inserting a bunch of "3D"s into the html which I initially thought was the problem. After doing some more reading I realized that quoted-printable was correct and wasn't the issue. I finally realized there was a leftover thymeleaf tag in the html as I previously had been using thymeleaf to populate it. Looking at the source of the email in mailhog this is what the offending tag looked like:
After removing it mailhog was able to render it as html without issue. So perhaps there's a problem if your html has either:
Just a guess but at least removing the tag got the html rendering. |
Actually after doing a little bit more investigation I think it may be an iframe rendering issue. Mailhog (correctly) iframes the email body and inspecting the iframe in chrome developer tools shows that the html is there and being rendered inside the iframe. However, the height of the iframe is 0. So perhaps it's just chrome refusing to display some invalid html inside the iframe? Again, just a guess. |
I was having the same issue, my HTML was not rendering but when I add space between Content-type and text/html it started rendering HTML too. $headers .= "Content-type:text/html;charset=UTF-8" . "\r\n"; New $headers .= "Content-type: text/html;charset=UTF-8" . "\r\n"; |
Mailhog is not actively maintained, I recommend switching to https://github.com/axllent/mailpit |
Agreed with e-belair. Mailpit. |
When MailHog receives an email, which is html, it renders it as "plain text". I don't know why this happens, and how to render it as html.
Here is an example of part of the headers, as well as a screenshot:
The text was updated successfully, but these errors were encountered: