Currently mails are HTML only, which is very annoying and unnecessary. Loads of clients don't render them and my spamassassin even moved them straight into the junk folder (and it was right to do so, see report below).
I think HTML mails are evil and totally not necessary in a development tool like this. So instead of fixing them I'd suggest to directly switch to plain text mails.
Spamassassin report for the record (tested on password reset mail):
* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
* 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
* See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
* for more information.
* [URIs: example.com]
* 1.3 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words
* 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 2.0 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME
* headers
* 2.0 TO_NO_BRKTS_HTML_ONLY To: misformatted and HTML only
nd2s
All 45 comments
Thanks your feedback!
By reading this section in your error report: http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
I believe it has nothing to do with HTML thing.
But, it is good idea to add a config option whether use HTML or plain text e-mail.
unknwon
on 17 Aug 2015
The section you quoted was irrelevant. Spamassassin assigns points to mails. If a mail has >x points (4 in my case) it is marked spam. The DNS thing caused 0 points, this was just some info.
Relevant parts are after that: TO_NO_BRKTS_HTML_ONLY, MIME_HTML_ONLY (gogs mails have no plaintext part at all, they HAVE to have that, even if you are sending additional HTML), and so on...
nd2s
on 17 Aug 2015
Relevant parts are after that: TO_NO_BRKTS_HTML_ONLY, MIME_HTML_ONLY (gogs mails have no plaintext part at all, they HAVE to have that, even if you are sending additional HTML), and so on...
Ah... OK, I see! Sorry I've never used something similar before. :joy:
But still, I hold on opinion that add a config option about whether use HTML or plain text version e-mails.
unknwon
on 17 Aug 2015
OK, thanks for the quick reply anyway. :)
Then this ticket should be a bug "plain text part missing in HTML mails + add option for text-only mails". For HTML configured mails it should send both parts, for non-HTML the plain text part only.
nd2s
on 17 Aug 2015
No problem.
For HTML configured mails it should send both parts
Do you have an example of a e-mail that has both parts?
unknwon
on 17 Aug 2015
These are normal multipart messages, with one part being text/plain and another one text/html. Text-only mails could then just not attach the text/html part.
I don't know what email package gogs uses, but most should be able to handle that.
Modified example from second link:
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=utf-8
...plain text version of message goes here....
--boundary42
Content-Type: text/html
.... html version of same message goes here ...
--boundary42
Theoretically it could make sense to use Content-Transfer-Encoding: base64 in the text part and encode everything base64 so you don't have to escape "special" characters - but the email package should just do that out of the box anyway.
nd2s
on 17 Aug 2015
Thanks for your explanation! I'll try to find a good package in Go.
unknwon
on 17 Aug 2015
Hi @nd2s !
New implementation of mailer module in Gogs has been pushed to develop, please help test and see if problem has been solved. Thanks!
unknwon
on 17 Sep 2015
Sending is working fine and mail is (technically) formatted correctly. But the content you are sending is wrong. You are just putting the raw HTML in there and that's what people get to see in the mail: loads of HTML tags. It has to send a text-only template without the formatting.
(That's why I suggested to drop HTML support because it's just unnecessary work to maintain two template versions for every message, without HTML yielding any additional value.)
nd2s
on 17 Sep 2015
@nd2s thanks your confirmation!
For you concern, there is always a link give a quick access for you to specific location on the site.
Without this kind of links is very inconvenience. :dizzy_face:
unknwon
on 17 Sep 2015
Not sure if I fully understood you there: do you mean you want to be able to just click on a link in the mail? All email clients I've ever used make links in plain text mails clickable. They just parse the text for URL format and then link it. So this shouldn't be a problem.
Edit:
nd2s
on 17 Sep 2015
@nd2s Hmm.. I see.
Let do some more work tomorrow.
unknwon
on 17 Sep 2015
Thank you for your work. I updated the previous comment with a screenshot of an example of a Github plain-text mail with linked URL.
I'm surprised that no one else is commenting on this issue.
nd2s
on 17 Sep 2015
@nd2s I think GitHub maintains two version of templates. Because what I have is:
unknwon
on 17 Sep 2015
Close now but open for continuing discussion.
unknwon
on 9 Dec 2015
Discussion? It's broken - what more do you want to discuss?
nd2s
on 9 Dec 2015
Good to know you're still here!
unknwon
on 9 Dec 2015
Plain text part of email has HTML tags in it. When I switch to plain text view in Thunderbird, I see the following at the end if the text:
<br>-<br> <a href="http://hostname/gogs/user/repository/issues/8">View it on Gogs</a>.
Plain text emails don't require tags around links, strings matching http://hostname are underlined by the client. I would end plain text part this way:
View it on Gogs.
http://hostname/gogs/user/repository/issues/8
Does anyone have time and experience in Go to modify email template?
kolesar-andras
on 16 Dec 2015
@kolesar-andras: The problem isn't modifying but writing them. At the moment HTML templates are used for the plain text part as well.
I would, also #997 (two fundamentally important tickets imho) but unfortunately I don't have time at the moment. Maybe next year, but I hope someone else finds time before that.
There also should be notifications when a ticket gets closed and things like that. The whole email-related system needs some attention.
nd2s
on 16 Dec 2015
:+1:
ddevault
on 9 Jan 2016
HTML email is really a big no no. Just remove the HTML from the template and send a plain-text message. There's no added value.
dakira
on 20 Jan 2016
...or at least "convert" the html templates to plain text by stripping the tags? maybe replace
by newline..
t-oster
on 27 Jan 2016
@t-oster Yes... that's what I'm planning to do... :smile:
unknwon
on 27 Jan 2016
@t-oster @Unknwon You can't just strip tags, links etc. would be messed up.
nd2s
on 27 Jan 2016
I am not talking about blindly removing all tags. I talk about smothing like PHP's strip_tags function or jQuery's .text() function meaning you remove the tags but keep all the text-nodes
Of cause Links should be appended with their "src" attribute, so the link stays there in plain text.
t-oster
on 27 Jan 2016
Can we check mail template for spams - http://www.emailspamtest.com/
Though content would partially be dynamic, but we can make sure the fixed template content does pass spam test.
rskumar
on 10 Mar 2016
I vote for having HTML along with TEXT (that why most 1st class email clients supports HTML).
And user has option in mail client to only see TEXT version of that mail.
rskumar
on 10 Mar 2016
Can we check mail template for spams - http://www.emailspamtest.com/
Though content would partially be dynamic, but we can make sure the fixed template content does pass spam test.
Thanks, but what does this to do with Gogs?
unknwon
on 10 Mar 2016
@Unknwon using that service you can optimize mail templates so that the resulting mails will less likely be classified as spam.
dakira
on 11 Mar 2016
@dakira OK...
unknwon
on 11 Mar 2016
@rskumar @dakira: mails would be fine if there were correct plaintext parts. No need for some service.
@Unknwon I don't understand why you removed the "bug" tag. The system currently sends HTML code in mails. So every user that reads text mails sees code (= a totally broken mail)!
nd2s
on 22 Mar 2016
I agree with @nd2s. There are only two valid options, either plaintext-only mails or mails that have both, plaintext and html. Everything else is broken, hence this is a bug.
dakira
on 22 Mar 2016
Sending HTML emails is a bug in general. Plaintext emails will work fine for any reader.
ddevault
on 22 Mar 2016
@SirCmpwn While I agree, this is just an opinion. Any email sticking to RFC1521 is perfectly acceptable, leaving it to the user which part of the multipart-message to display. Sending html-only, though, results in many problems.
Lets say you subscribe a mailinglist to a bug. That mailinglist will strip the html parts, leaving an empty message.
dakira
on 22 Mar 2016
As stated in #2928, one problem here is that the text/plain version of the mail is instead still HTML
strk
on 5 Apr 2016
One suggestion from #2928 is to keep the existing HTML templates for emails, and use a html-to-text library to generate the text/plain part. https://github.com/jaytaylor/html2text/ was mentioned, but there may be others.
zorun
on 5 Apr 2016
Just don't send HTML emails. HTML emails are the devil and you should feel bad for using them.
ddevault
on 5 Apr 2016
I agree with @SirCmpwn, no HTML mails for me please.
strk
on 5 Apr 2016
@zorun : Let's not do that, that's just messy.
nd2s
on 5 Apr 2016
I just installed gogs and tested the email to find that you're sending html-formatted mail in text/plain MIME parts. This is a violation of RFC 2046, which you can read at https://tools.ietf.org/html/rfc2046. The relevant bit says "text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort." Because gogs sends a text/plain MIME part that contains HTML formatting commands, gogs does not comply with the RFC.
The standard way to handle the problem you are trying to solve is to send _only_ the text/plain MIME type and to write urls in the plain text: "Please go to http://gogs.example.com/foohash3b4c62c to complete registration." Email clients will interpret this appropriately and render the link in such a way as to permit the user to select or click on it as needed.
I recommend dispensing with text/HTML parts and simply using templates that produce plain text. The HTML as you are currently using it is not adding much use because you use it only for paragraphs and bold text. Email clients will interpret line breaks in the exact same way they will interpret your current paragraph tags.
jvasile
on 9 Apr 2016
@jvasile see also #2928
strk
on 9 Apr 2016
@Unknwon why is this marked as "dont send pull request"?
ddevault
on 9 Apr 2016
@jvasile see how you like https://github.com/gogits/gogs/pull/2954
strk
on 10 Apr 2016
What is the status of this issue right now?
unknwon
on 8 Jul 2016
I believe this is now fixed, defaulting to Text emails and allowing ENABLE_HTML_ALTERNATIVE config to also include alternative HTML
strk
on 8 Jul 2016
Related issues
bastiao
路
125Comments
truongsinh
路
81Comments
floorish
路
81Comments
mohsenk
路
49Comments
nasali
路
50Comments
Most helpful comment
I just installed gogs and tested the email to find that you're sending html-formatted mail in text/plain MIME parts. This is a violation of RFC 2046, which you can read at https://tools.ietf.org/html/rfc2046. The relevant bit says "text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort." Because gogs sends a text/plain MIME part that contains HTML formatting commands, gogs does not comply with the RFC.
The standard way to handle the problem you are trying to solve is to send _only_ the text/plain MIME type and to write urls in the plain text: "Please go to http://gogs.example.com/foohash3b4c62c to complete registration." Email clients will interpret this appropriately and render the link in such a way as to permit the user to select or click on it as needed.
I recommend dispensing with text/HTML parts and simply using templates that produce plain text. The HTML as you are currently using it is not adding much use because you use it only for paragraphs and bold text. Email clients will interpret line breaks in the exact same way they will interpret your current paragraph tags.