[squeak-dev] Sending html emails with MailMessage; line length issues
drurowin at gmail.com
Thu Jun 23 16:58:45 UTC 2022
One more thing. I work with SGML a lot, and HTML has a lot of #CDATA where
it doesn't belong that breaks stuff really badly, so you split lines like
Also, parsers like OpenJade work correctly, but web browsers need it
normalized. When I write HTML by hand, I have to run it through the
normalizer. SGML is very complicated, and some of the vendors decided they
weren't going to bother with the content model validation after going
through basic syntactic parsing, so that's how you get escaping bolds and
In case anyone is interested...
In terms of syntax, grossly simplified, you have DATACHAR, which is raw
input, tokens like ETAGO ('</') and NAME ('H1'), and CDATA ('Hi mom!').
There's also B, for whitespace. B works as in Smalltalk. The parser tells
the tokenizer what sort of tokens it can return for the current context.
Some tokenizers cheat and answer B as CDATA, so the parser gets a CR posing
as CDATA and says "Oh! They omitted the start tag(s). I'll add that for
them." and your document is hopelessly corrupted.
Of course, it's significantly more complicated, but this should be good
enough for writing an HTML *generator*.
On Wed, Jun 22, 2022, 13:18 <christoph.thiede at student.hpi.uni-potsdam.de>
> Short side note only: I already have implemented rudimentary support for
> sending HTML messages via MailSender/MailComposition in my image last year.
> Unfortunately, I have not yet found any time to clean up my changes and
> contribute them to the Trunk, but I am attaching a very dirty WIP
> changeset. Maybe this of anyone's interest. I hope that I will be able to
> merge this into the Trunk later this year or so. :D
> But unless we have something like a TextTableAttribute, this approach
> won't work with tables, I'm afraid.
> *Sent from **Squeak Inbox Talk
> On 2022-06-22T10:52:33+02:00, das.linux at gmx.de wrote:
> > STMP servers do what they want with emails
> > in particular if you don't give them a Content-Transfer-Encoding.
> > RFC1341:
> > https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
> > >> "Content-Transfer-Encoding: 7BIT" is assumed if the
> Content-Transfer-Encoding header field is not present.
> > Maybe do base64 or quoted-printable?
> > Look here:
> > https://stackoverflow.com/a/28531705
> > Excerpts:
> > >> SMTP, by definition (RFC 821), limits mail to lines of 1000
> characters of 7 bits each. That means that none of the bytes you send down
> the pipe can have the most significant ("highest-order") bit set to "1".
> > IMPORTANT PARTS ON Content-Transfer-Encoding
> > >> Note that when you choose 7bit, you're agreeing that all of the lines
> in your content are less than 1000 characters in length.
> > >> As with 7bit, there's still a 1000-character line limit [for 8bit
> > >> binary is the same as 8bit, except that there's no line length
> restriction. You can still include any characters you want, and there's no
> extra encoding. Similar to 8bit, RFC 1341 states that it's not really a
> legitimate encoding transfer encoding. RFC 3030 extended this with
> > Also:
> > >> Before the 8BITMIME extension, there needed to be a way to send
> content that couldn't be 7bit over SMTP. HTML files (which might have more
> than 1000-character lines) and files with international characters are good
> examples of this. The quoted-printable encoding (Defined in Section 5.1 of
> RFC 1341) is designed to handle this.
> > Best regards
> > -Tobias
> > > On 22. Jun 2022, at 02:18, tim Rowledge <tim at rowledge.org> wrote:
> > >
> > > I'm trying to send email reports with html tables and having issues
> with *some* mail servers breaking the html in bad places.
> > >
> > > Trying to google stuff about html mail mostly leads to gazillions of
> puff pieces about "Why Your Brand Needs Enhanced HTML Mail!" and so on.
> This leads to early onset brain-rot.
> > >
> > > I'm using MailMessage and providing it with a body of a MIMEDocument
> contentType: 'text/html' content: abigstringofhtml . The html is being
> built by WAHtmlCanvasBuilder but I don't *think* that is the cause of my
> problems. I also use
> > > message
> > > setField: 'content-type' toString: 'text/html; charset=utf8';
> > > setField: 'mime-version' toString: '1.0'.
> > >
> > > Some mail smtp servers seem to be happy; if I send myself an email via
> my rowledge.org server, no problem. If I use an smtp set up on a vanilla
> Ubuntu 20 machine the lines of the html content get split in bad places
> that result in very ugly tables. I haven't been able to find anything that
> suggests smtp settings related to this, nor anything that makes me suspect
> I have to add any other message fields or so on.
> > >
> > > The broken mails look like this -
> > >
> > > To: XXXXXXXX
> > > Date: Fri, 10 Jun 2022 16:48:19 -0700
> > > Subject: Daily Report
> > > Mime-version: 1.0
> > > Content-type: text/html;charset=utf8
> > > Content-type: text/html
> > > Message-Id: XXXXXXXXX
> > > X-DA-Pass: W0T0
> > > X-CTCH-Spam: Unknown
> > > X-CTCH-VOD: Unknown
> > > X-CTCH-RefID:
> > > X-Origin-Country: CA
> > > X-WHL: LR
> > >
> > > <html><head><title>Report</title></head><body
> onload="onLoad()"><h3>Your report, requested at
> 2022-06-10T16:48:19.783908-07:00</h3><table class="table table-bordered
> style="background-color: lightblue"><td>2022-02-14</td><td>340</td></tr><tr
> style="background-color: lightblue"><td>2022-02-02</td><td>374</td></tr><tr
> style="background-color: lightblue"><td>2022-02-06</td><td>340</td></tr><tr
> style="background-color: lightblue"><td>2022-02-28</td><td>306</td></tr><tr
> style="background-color: lightblue"><t
> > > d>2022-01-24</td><td>136</td></tr>
> > >
> > > Note the break at the end where a <td> tag is split by a CR and a
> > >
> > > The non-broken mail
> > > a) doesn't break within a tag
> > > b) has 4k long lines instead of 998 char lines.
> > >
> > > Pointers to explanations, advice, solutions, all most welcome!
> > >
> > > tim
> ["MailMessage HTML.2.cs"]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev