Re: [exim] exim attachment handling

paul spandler wrote:
> I have a question regarding Exim (as a relay,) and the handling of
> attachments. First though, some background:
>
*snip*

> The vendor of the new appliance has not been particularly helpful so
> far. The finger has been pointed at Exim as the cause of the problem
> and their support staff clearly stated that uuencoded attachments are
> not supported.

*snip*

uuencoding has a looong history, has almost certainly been overshadowed
by base-64 encoding for many years as far as 'volume' of messages, but
remains a valid encoding and a valid mime type. At least, so long as
correctly done and correctly labeled.

Exim is doing precisely what an(y) MTA is supposed to do - NOT
whimsically altering the headers, message or attachment content, or
encoding of valid smtp message traffic.

Not so the 'appliance'.

So....

IF the upstream idiot-box no longer 'supports' transport of uuencoding
or any other widely-used structure, (MUA's have no problem with it...)

AND you are duty-bound to continue using such broken gear,

THEN the only thing you can ask of Exim is to block uuencoding at an
earlier stage, hopefully encouraging whomever is using the MUA or
executable that creates it to switch away from it.

Exim can be taught to do that.

But it should not be.

Far better to fix the problem (the idiot-box), not the symptom.
EG: Disconnect it and carry it to the recycling bin.

JFWIW, it is hard to imagine anything the idiot-box can do that Exim
could not do as well or better without it.

Not to put too fine a point on it, but it isn't just the idiot-box.

*Everything* you described in your initial Tinker-to-Evers-to-Chance
post can be done within a single Exim instance, with considerably less
grief, fewer bits of hardware, and no license-cost issues.

Your appliance-maker *fears* that sort of competance. As well they
should, given that they have their collective head deeply into rectal
defilade.

Bill