Email package splits lines incorrectly / upgrade mailcomposer #8425
Comments
Thanks for reporting this! It would be amazing to get For starters, it would involve bumping the version in Let us know if this is something you could look into! EDIT: I just saw the comment about why the version is pinned to such an old version. Still should be investigated.
|
I've marked this as |
Shall we just update the mailcomposer to 4.0.1? Is there any specific API changes that need to be applied to email package? PS: #6267 sounds related to this too. |
My sense is that, while the API may have changed, the Email package uses so little of the API that it's probably fine to just upgrade. Just needs to be tested. I haven't modified Meteor before, so I'm not familiar yet with the testing harness, so if others have time feel free; otherwise, I will try to look at this. |
Agree on the API. I haven't validated whether this can be reduced (maybe we can just remove some of dependency?), but the increase is ~500KB. It's a server-only package, so it's not a huge impact to the client, but it is a large increase. Given this factor, it'd be reasonable to first consider an alternate package to use in its place, assuming there is something compatible. |
Nodemailer https://nodemailer.com is quite popular if considering another package. |
Nodemailer is actually what replaced mailcomposer (at least according to mailcomposer's Github which is linked from NPM package mailcomposer). However, I'm not sure that EUPL 1.1 code is compatible with Meteor's MIT license, but I don't quite understand how NPM-included packages work in this regard... Any experts?
NPM package mailcomposer still lists that part as MIT licensed... |
Inspired by the mimelib vs. mimelib-noiconv comment, I found nodemailer-noiconv, which is an old (0.2.4, 4 years old) version of nodemailer that seems to be smaller (176K) than the In fact, the root issue is with |
@edemaine EUPL v1.1 compatibility https://joinup.ec.europa.eu/software/page/eupl/eupl-compatible-open-source-licences Hmh, MIT is compatible distributed under EUPL v1.1, but not distributed under MIT, as far as I understand that. How much other packages in Meteor actually depend on this? Could email package be just recommended for users in Meteor guide for example? I understood that Meteor wants to go more npm way in future, is that correct? Community nodemailer (aka "nodenvelope") is though MIT-compatible, https://github.com/nodenvelope/nodenvelope |
Licencing: Dropping email package: I like the My conclusion of the feasible options:
The first choice is IMO reasonable, as |
@edemaine Thanks for the analysis. As you said, the My vote here would be to move forward – for starters, by bumping the |
I've mostly finished this PR, including a bunch of new test cases, all now passing. But there is a catch: the simplesmtp library we use to actually send email (not represented in the tests) relies on the old (0.1) mailcomposer API for getting the message as a stream, and sadly it is deprecated. simplesmtp recommends migrating to smtp-connection, but that is distributed under EUPL... (All of these packages are written by the same person. Perhaps I should write to him...) |
One option is to use smtp-connection@3.2.0 which is licensed under MIT... This might be an actual reason to switch from mailcomposer to Nodemailer (capped at version 3 to get MIT license), so that we can use a consistent version of packages. smtp-connection is part of Nodemailer. Instead of mailcomposer, we'd need to use Nodemailer's buildmail directly I think...
OK, I found that mailcomposer (latest, @4) + smtp-connection@2 lets them share nodemailer-shared (@1.1.0) and nodemailer-fetch (@1.6.0), reducing size from 1636K to 1460K. So I'll continue with this choice. |
Good deep dive @edemaine |
PR complete: #8495 |
* Switch from mailcomposer 0.1.15 -> 4.0.1 (latest, still MIT license). * Switch from simplesmtp (which only supports mailcomposer 0.1) to smtp-connection (which supports any mail composer). * Use smtp-connection@2 (instead of latest) which shares nodemailer-shared codebase with mailcomposer 4.0.1. * Add test for long header lines (the original bug being fixed here) * Add extra test for HTML + text messages * Document some extra options arguments supported by new mailcomposer
* Switch from mailcomposer 0.1.15 -> 4.0.1 (latest, still MIT license). * Switch from simplesmtp (which only supports mailcomposer 0.1) to smtp-connection (which supports any mail composer). * Use smtp-connection@2 (instead of latest) which shares nodemailer-shared codebase with mailcomposer 4.0.1. * Add test for long header lines (the original bug being fixed here) * Add extra test for HTML + text messages * Document some extra options arguments supported by new mailcomposer
* Switch from mailcomposer 0.1.15 -> 4.0.1 (latest, still MIT license). * Switch from simplesmtp (which only supports mailcomposer 0.1) to smtp-connection (which supports any mail composer). * Use smtp-connection@2 (instead of latest) which shares nodemailer-shared codebase with mailcomposer 4.0.1. * Add test for long header lines (the original bug being fixed here) * Add extra test for HTML + text messages * Document some extra options arguments supported by new mailcomposer
Try this on Meteor server (without MAIL_URL set, so that it prints to stdout):
The result is this:
Unfortunately, this behavior seems incorrect. Specifically, there are 8 spaces before "onto multiple lines", but there should be only one. According to RFC822, "Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char." So while I only asked for one space before "onto" in the subject, I got 8 instead.
Specifically, this results in an actual error when setting MAIL_URL, producing actual email, and reading it in an email client. At least in Pine, the subject gets eight spaces in the middle, which looks rather silly. I don't know for sure that it will render incorrectly in all email clients, but it certainly isn't following the RFC822 spec.
I tried to reproduce this error in
node
usingmailcomposer
, but it seems to implement RFC822 correctly:produces:
I couldn't get Mailcomposer 0.1.15 (as used by Meteor) to work at all in Node. Presumably the bug got fixed between 0.1.15 and the latest version, which is 4.0.1 (!). Could we please upgrade?
The text was updated successfully, but these errors were encountered: