>>
>
> First off, just sent you directly a test message so we can set up to do some off-list testing - hopefully come back with better info, less chatter.
>
> Because ... Optioned ON or OFF, I am having a hard time getting my arms around seeing 8BITMIME as a noteworthy problem.
>
> A) RFC permissives aside, 8BITMIME doesn't seem to be all that common in actual use. Most 'trouble' reports are stale, and I see that as improved MUA handling, not MTA changes.
>
> Exim may be odd-man out with 8BITMIME optioned OFF - but it has NOT so far become a global pariah for that behaviour.
Well, that'll be because mobile email is still a minority pursuit, users don't realise that a good proportion of their wait when sending email is actually unnecessary, and it degrades gracefully (the email still gets sent). That doesn't mean that Exim admins shouldn't be looking to improve the user experience.
It's not just a performance issue, it's a storage issue, too.
> B) I can't find much in the way of reports as to what real-world app even *creates* 8BITMIME. Or how often.
>
> I can't find a sample to test with, either.
The way to find out would be to enable 8bitmime in Exim, and log $smtp_command in the MAIL command.
>
> C) Most current MUA even if 'fed' 8 bit-anything seem to be predisposed to ass u me the worst, and wrap it as quoted-printable.
> In the MUA, not the MTA.
They'll certainly do that when an MTA fails to advertise 8bitmime.
> D) Taken as STIPULATED that QP conversion may or may not suit the recipient's MUA environment, it should still pass transparently THROUGH the bowels of both MTA, if so optioned. Spam filtering against know incidents of abuse remain separate issues.
As for the rest of this, you seem to be arguing that YOU see some benefit in not advertising 8bitmime. So don't. But please don't hold the rest of us back with virtually the only popular smtp software the doesn't support it.
> Or perhaps not.
>
> Optioning 8BITMIME OFF by default may have already saved many Exim systems from extra WinCrobe/phish grief. And with no harm.
>
> Hold THAT thought...
>
> Otherwise, when PH said that Exim was 'not a protocol converter' I take that as guidance as well as observation.
>
> IMNSHO, Exim should remain transparent AND NOT *become* a protocol converter.
>
> So long as that is the case, MTA functionality is less vulnerable AND arm's length disinterested third-party aloof positioning enhances the reputation of said MTA for NOT munging stuff.
>
> Good stuff, both.
>
> Any conversion/encoding problems are placed back onto the shoulders of the end-point correspondents - just the same as a .doc file created in MS office is not expected to be readable on a MAJMAP-1100 system.
> That was, after all, one of the aims of MIME, was it not?
>
> One has always needed more than just an undamaged file.
> One needs the tools to utilize it.
>
> Except for headers, those are not really IN the MTA. It is mere plumbing. Intelligent plumbing, yes. But nonetheless a transport, not a consumer.
>
> Other than tools to convert between and among various text encodings, and perhaps html, extra tools aren't ordinarily in the MUA, either. One detaches an attachment and onpasses to outboard editors or display tools to USE it.
>
> So - still trying to find the beef' on this issue.
>
> Where else should I look?
>
> Bill
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
