Подскажите либу чтоб формировать multipart email

Короче захардкодил работу с протоколом. Портянка зато понятно

Такое врядли существует, поскольку сформированное в памяти сообщение затем оттуда же (из памяти) и отправляется в сокет.

Единственный вариант это самостоятельно формировать raw файл c письмом и вручную же отправлять, самостоятельно подключаясь к SMTP-серверу:

From: sender@example.com
To: recipient@example.com
Subject: Multipart Email Example
Content-Type: multipart/alternative; boundary="boundary-string"

--your-boundary
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Plain text email goes here!
This is the fallback if email client does not support HTML

--boundary-string
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<h1>This is the HTML Section!</h1>
<p>This is what displays in most modern email clients</p>

--boundary-string--

А зачем такое надо хоть?

Такое врядли существует, поскольку сформированное в памяти сообщение затем оттуда же (из памяти) и отправляется в сокет.

В сокет можно прекрасно писать поток. Прочёл Х кб, перевёл в b64, послал, следующие взял и т.д.

А зачем такое надо хоть

Потому что приходится отправлять много жЫрных файлов. А учитывая особенности питонячьего гц, иммутабельность строк (соответственно плюс перекодирование = плюс строка) и прибавку к размеру сообщения от b64 можно влет съесть 100-150 метров на поток на штатной либе. Это ппц как мешает, приходится сильно зажимать число отправляющих тасков в проде и выделять больше памяти на тестовых стендах.

Я в толксах вонял недавно на этот счёт, про unbound read, запихивание файлов в память, вот это все. Не надо так делать без крайней необходимости

Не помню на память спецификацию SMTP, но вроде нет там никакой поддержки «потоковости» вообще.

Еще вот в качестве пищи для размышлений:

Keep in mind that even if you increase the attachment limit on your server, your mail will still probably be rejected if you send it to other domains, as most sites keep the attachment size rather low.

The reason mail admins don’t like to accept large attachments is that SMTP is a store-and-forward system, so any large attachments have to be copied (sometimes multiple times) on every server that touches the mail.

Не помню на память спецификацию SMTP, но вроде нет там никакой поддержки «потоковости» вообще

Любое соединение является потоковым. Smtp кстати будет жрать пока не получит строчку-точку, даже размер не обязательно указывать

Keep in mind that even if you increase the attachment limit on your server, your mail will still probably be rejected if you send it to other domains, as most sites keep the attachment size rather low

Да знаю, знаю, 20 метров в inbox это жесть. Но это бизнес-требование. Плюс если мы не сможем скормить серверу клиента стометровый ппц и клиент пойдёт жаловаться - есть железобетонный аргумент что проблема на его стороне и пусть спросит своих админов, а файл вот, лежит на s3, ссылка в письме. А если не отправить два-три метра - сказать уже нечего, клиент недоволен и уходит к конкуренту. Тут как любят говорить либералы «рынок порешал». Моё дело чтоб хоть на бэке это не рвало систему

Не очень понял, ты либу хочешь? https://www.vmime.org/ подойдет?

FEATURES OVERVIEW
Here are some of the numerous features supported by VMime:

RFC-2822 and multipart messages

...

Да уже норм, написал все руками. Меня просто бомбило что абсолютно все питонолибы пихают абсолютно всё в память и создают по 5-6 копий этого всего включая b64-аттач. В итоге на отправку одного фигового письма тратится больше памяти чем у всех летающих на орбите спутников вместе взятых.

Vmime видел, но там коммерческая лицензия (для бизнеса) и доп геморроя с её получением испытывать лениво