paul spandler wrote: > 2008/10/29 W B Hacker <[EMAIL PROTECTED]>: >> 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 -- ## List details at http://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/
