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<br>
<br>
But unless we have something like a TextTableAttribute, this approach won't work with tables, I'm afraid.<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-06-22T10:52:33+02:00, das.linux@gmx.de wrote:<br>
<br>
> STMP servers do what they want with emails<br>
> <br>
> in particular if you don't give them a Content-Transfer-Encoding.<br>
> <br>
> RFC1341: <br>
> https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html<br>
> <br>
> >> "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.<br>
> <br>
> Maybe do base64 or quoted-printable?<br>
> <br>
> Look here: <br>
> https://stackoverflow.com/a/28531705<br>
> <br>
> <br>
> Excerpts:<br>
> <br>
> >> 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".<br>
> <br>
> IMPORTANT PARTS ON Content-Transfer-Encoding<br>
> <br>
> >> Note that when you choose 7bit, you're agreeing that all of the lines in your content are less than 1000 characters in length.<br>
> >> As with 7bit, there's still a 1000-character line limit [for 8bit encoding]<br>
> >> 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 BINARYMIME.<br>
> <br>
> Also:<br>
> <br>
> >> 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.<br>
> <br>
> <br>
> Best regards<br>
> -Tobias<br>
> <br>
> <br>
> > On 22. Jun 2022, at 02:18, tim Rowledge <tim at rowledge.org> wrote:<br>
> > <br>
> > I'm trying to send email reports with html tables and having issues with *some* mail servers breaking the html in bad places.<br>
> > <br>
> > 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.<br>
> > <br>
> > 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 <br>
> > message<br>
> > setField: 'content-type' toString: 'text/html; charset=utf8';<br>
> > setField: 'mime-version' toString: '1.0'.<br>
> > <br>
> > 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.<br>
> > <br>
> > The broken mails look like this - <br>
> > <br>
> > To: XXXXXXXX<br>
> > Date: Fri, 10 Jun 2022 16:48:19 -0700<br>
> > Subject: Daily Report<br>
> > Mime-version: 1.0<br>
> > Content-type: text/html;charset=utf8<br>
> > Content-type: text/html<br>
> > Message-Id: XXXXXXXXX<br>
> > X-DA-Pass: W0T0<br>
> > X-CTCH-Spam: Unknown<br>
> > X-CTCH-VOD: Unknown<br>
> > X-CTCH-RefID: str=0001.0A742F2A.62A3D849.0002,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0<br>
> > X-Origin-Country: CA<br>
> > X-WHL: LR<br>
> > <br>
> > <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 table-hover table-condensed"><thead><tr><th>AggregateDataRecordDate</th><th>AggregateDataRecordStatusNormal</th></tr></thead><tfoot><tr><td></td><td></td></tr></tfoot><tbody><tr style="background-color: lightblue"><td>2022-02-14</td><td>340</td></tr><tr style="background-color: lightyellow"><td>2022-02-22</td><td>306</td></tr><tr style="background-color: lightblue"><td>2022-02-02</td><td>374</td></tr><tr style="background-color: lightyellow"><td>2022-01-23</td><td>136</td></tr><tr style="background-color: lightblue"><td>2022-02-06</td><td>340</td></tr><tr style="background-color: lightyellow"><td>2022-01-01</td><td>170</td></tr><tr style="background-color: lightblue"><td>2022-02-28</td><td>306</td></tr><tr style="background-color: lightyellow"><td>2022-02-23</td><td>306</td></tr><tr style="background-color: lightblue"><t<br>
> > d>2022-01-24</td><td>136</td></tr><br>
> > <br>
> > Note the break at the end where a <td> tag is split by a CR and a space.<br>
> > <br>
> > The non-broken mail<br>
> > a) doesn't break within a tag<br>
> > b) has 4k long lines instead of 998 char lines.<br>
> > <br>
> > Pointers to explanations, advice, solutions, all most welcome!<br>
> > <br>
> > tim<br>
> <br>
> <br>
["MailMessage HTML.2.cs"]