On 30/03/2021 13:07, Hector Santos wrote:
On 3/30/2021 7:31 AM, Jeremy Harris wrote:
Summary: 8BITMIME has been irrelevant for years.
You send it.
+1, we totally assume 8 bit!! We have nothing that needs 7 bit
masking.
We dont either, but RFC 6152 (written in 2011) has the text that [if the
server does not advertise 8BITMIME support]:
"then
the client SMTP must not, under any circumstances, attempt to
transfer a content that contains characters outside of the US-ASCII
octet range (hex 00-7F)."
This seemed quite a strongly worded requirement, so we'd made the
decision that that requirement made it too complicated to handle
gracefully, and as it was so strongly worded, we'd better not ignore it.
But, if people are ignoring that requirement, it's actually interesting.
Not because people aren't following the standards, but that suggests
that 8BITMIME isn't actually that widely used...
I'd assumed that the reason we very rarely see incoming
"content-transfer-encoding: 8bit" MIME messages is because we don't
advertise that we support 8BITMIME so most senders were transcoding them
as RFC 6152 requires. But, if servers are just sending them in the 8-bit
form anyway, I'd expect to see loads of 'cte: 8bit' messages, but the
vast majority of '8 bit' messages we receive are QP encoded with a few
Base64 encoded. A few (single digit percentage) are 'cte: 8bit', mostly
spam, with some transactional messages from the same few senders.
--
Paul
Paul Smith Computer Services
support(_at_)pscs(_dot_)co(_dot_)uk - 01484 855800
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp