Re: [exim] Exim 5.x

Ian Eiloart wrote:
>
> On 19 May 2011, at 19:05, W B Hacker wrote:
>
>> Ian Eiloart wrote:
>>>
>> *snip*

*snip* again

>>
>> If nothing has reverted, I read that as a U Cambridge server having
>> accepted 8BITMIME with a 250-Ok many years and versions ago.
>
> Yes, but it was advertising 8bitmime, so you'd expect it not to
> complain:
>
> 250-xoanon.csi.cam.ac.uk Hello i [193.193.193.107] 250-SIZE 20971520
> 250-8BITMIME 250-EXPN 250-PIPELINING 250-STARTTLS 250 HELP mail
> from:<> size=5000 body=8bitmime 250 OK
>

See below...

> Without 8BITMIME advertised, this happens:
>
> 250-ppsw-50.csi.cam.ac.uk Hello chip.uscs.susx.ac.uk [139.184.14.86]
> 250-SIZE 104857600 250-PIPELINING 250 HELP mail from:<> size=5000
> body=8bitmime 501<> size=5000 body=8bitmime: malformed address:
> size=5000 body=8bitmime may not follow<>
>
> You get the same result if you provide a return path.

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.


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.

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.

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.

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