Re: [Emailcore] Ticket #14: G.7.8. Review different size limits

[Steffen Nurpmeso <[e-mail]>]

John Levine wrote in
 <[e-mail]>:
 |According to Steffen Nurpmeso  <[e-mail]>:
 |>|>Especially since presence of non 7-bit clean data imposes MIME
 |>|>encoding, anyway?
 |>|
 |>|Hm.  You might want to investigate the 8BITMIME SMTP extension, defined \
 |>|in
 |>|1993 and supported by every MTA I've looked at in this millenium.
 |>
 |>I have these RFCs (i have 6152 locally, it obsoleted 1652).  But
 |>i do not think i have ever encountered usage of this myself.
 |
 |I see unencoded UTF-8 in mssages bodies all the time. ¡Hola! 😕

Your MUA created the according MIME headers, but whether it used
the 8BITMIME SMTP extension when passing this over to a MTA, that
is here the question.  Some may not, the one i took maintainership
of for example surely never did, yet supports 8bit and simply
passed it over, and whereas i changed the default content-
transfer-encoding the SMTP code is more or less unchanged in
released versions.  (That will change with the next, whenever that
is, i am late by half a year at minimum, but 8BITMIME not yet in
there, so you maybe even earned a credit in defiance of your
invalid mail address.)
I have not encountered problems from the SMTP side when actually
trying out aka using these defaults (years ago), so it seems there
are quite liberal SMTP engines around.

 |>|PS: I don't feel strongly about lifting the 1000 octet limit but I \
 |>|would like |to understand how widely it's enforced by mail receivers.
 |>
 |>I would assume transmission is rejected for any such email?
 |
 |Not that I've ever seen but I haven't looked very hard.  I think it's
 |more common to stuff in a \r\n and continue.

You surely do not change body content but by doing the full MIME
dance right.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)