Re: [exim] exim attachment handling

paul spandler wrote:
> 2008/10/29 W B Hacker <wbh@???>:
>> 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.
>
> This is exactly the sort of response I had hoped to receive. The
> vendor's suggestion seemed contrary to my understanding of what any
> MTA would do (irrespective of the flavour.) I have a conference call
> with their second-line staff shortly. Their current stance is:
>
> <snip>
>
>>From the message headers i saw that the message passes EXIM 4.5.1 server
> which uses UUENCODE as default attachment format.

Merely evidence of htier ignorance.

The only time an MTA has to do with selection of a 'default attachment
format', would be iif/as/hwne it generated a DSN wherein the blocked
message is returned as an attachment.

Even So - the older uuencode should be the most 'universal' of formats,
just in case a really old correspondent cannot shift gears to base-64.

>
> We are not able to resolve the issue using <insert appliance here>
> since messages is
> received by <insert appliance here> already corrupted.
>

AR: <the above>

Should be amended to read:

> We are not able to resolve the issue using <insert appliance here>
> since <insert appliance here>
> was designed without reference to the smtp process or standards.

> If possible bypassing the EXIM server will be the best solution fore
> this issue.
>
> </snip>
>
> ...so it seems they are content that Exim receives the email and then
> mangles it before squirting it to the upstream appliance.
>

Sheer ignorance. Cubed.

>> 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.
>
> Agreed - we're not doing that. Our internal relaying function is
> simple, clearly defined and proven. Fortunately, the appliance is not
> within my remit...
>
> Thanks
>
> Paul
>

Seems to me that all that the solution required is a clean alternative
uplink to get the mail out, and a note to the effect:

'Please advise when you have replaced <insert appliance *somewhere*>
with something standards complaint.'

Optionally quote applicable IETF RFC's ....

Good luck with it!

Bill