Error 501: Line too long

[falco467]

The RFC for Mails requires all lines in the Message to not be longer than 1000 characters (including CR+LF).
If I create a Message with this library, I would expect line-breaks to be added automatically to conform to the standard.

But the library does not add line-breaks to the message body and this emails are rejected by many mail servers with the error "501: line too long"

Example code:

const mimeText = require('mimetext')

const msg = mimeText.createMimeMessage()
msg.setSender('test@example.org')
msg.setTo('test@example.org')
msg.setSubject('This message will be rejected')

msg.addMessage({ contentType: 'text/html', data: 'x'.repeat(2000) })

console.log(msg.asRaw())

This message will contain a single line with 2000 characters, breaking the spec.

[muratgozel]

hey @falco467 thanks for pointing this out, im aware of this line limit, its just difficult to apply this limit in html emails because of html tags got broken randomly. i will leave this issue open and believe eventually it gets solved.

[LarsFronius]

Experienced this issue myself and since resurrected the MailComposer of nodemailer which gets this right: https://github.com/nodemailer/nodemailer/blob/master/lib/mail-composer/index.js
This is just meant as a hint where to look for.
I tried implementing this in MIMEText myself, but swapping libraries out was in the end the much quicker way forward for this project.

[falco467]

hey @falco467 thanks for pointing this out, im aware of this line limit, its just difficult to apply this limit in html emails because of html tags got broken randomly. i will leave this issue open and believe eventually it gets solved.

This is not a problem at all. Soft-Linebreaks will be removed by the email-client before interpreting the HTML.

From the RFC:

Lines of Quoted-Printable encoded data must not be longer than 76 characters. To satisfy this requirement without altering the encoded text, soft line breaks may be added as desired. A soft line break consists of an = at the end of an encoded line, and does not appear as a line break in the decoded text. These soft line breaks also allow encoding text without line breaks (or containing very long lines) for an environment where line size is limited, such as the 1000 characters per line limit of some SMTP software, as allowed by RFC 2821.

So the code to fix this can be very simple: Just insert a soft line break ("=\r\n") after every 997 characters (or 73 to be maximally compatible).

[falco467]

If you look at the source code of news-letters in your inbox, you will find most of them have soft linebreaks all over the HTML, breaking tags and attributes without any problems.

[paresy]

This one has caught us totally off guard. The same happens if you add an attachment which is base64 encoded. Any delivery to GMX (a large mail provider in Germany) will just reject everything with an attachment 😄 . The problem is real.

Anyway -> Thanks for the great library -> I will work around it somehow.

This is my workaround to preprocess my attachments data fields before sending it to MIMEText.

let insertLineBreaks = (base64String) => {
    const lineLength = 76;
    let result = '';

    for (let i = 0; i < base64String.length; i += lineLength) {
        result += base64String.slice(i, i + lineLength) + '\n';
    }

    return result.trim(); // Removes the last unnecessary newline
}

if (attachments) {
    for (let index in attachments) {
        attachments[index].data = insertLineBreaks(attachments[index].data);
    }
}

[styxlab]

Running into the same with GMX, here is my workaround which is a simplified version of @paresy's idea:

   const message = createMimeMessage()

   ...

   attachments.forEach(({ filename, contentType, data }) => {
       message.addAttachment({ filename, contentType, data: data.replace(/(.{76})/g, '$1\n').trim() })
   })

[falco467]

Running into the same with GMX, here is my workaround which is a simplified version of @paresy's idea:

   const message = createMimeMessage()

   ...

   attachments.forEach(({ filename, contentType, data }) => {
       message.addAttachment({ filename, contentType, data: data.replace(/(.{76})/g, '$1\n').trim() })
   })

If you simply replace it like this, the line breaks will be there in the output document and might break certain file formats. To make sure the line-breaks are removed by the parser, they need to be prefixed with an equal sign "="

data.replace(/(.{76})/g, '$1=\n').trim() // These soft line-breaks will be automatically removed by the receiver

[styxlab]

@falco467 Your suggestion makes sense, however, some programs cannot open PDFs when I add the = while I do not have these issues when I omit the =. There must be more to it.

[falco467]

@falco467 Your suggestion makes sense, however, some programs cannot open PDFs when I add the = while I do not have these issues when I omit the =. There must be more to it.

That is very strange. Are you using a standard E-Mail Client (like Apple,Outlook,GMail) to download/open the attachments? They should strip the escaped newlines.

[lezuber]

Went with paresy`s solution which works for the clients which used to bounce with this error on base64 attachments.
@muratgozel Please at least add a warning to the readme. This issue cost us multiple hours.

[lezuber]

I ran into two more issues. Can reccomend everyone migrating to nodemailer if possible. All issues resolved out of the box, no tweaking required.