Re: [exim] TNEF

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] TNEF
The Doctor wrote:
> On Tue, Dec 11, 2012 at 04:34:12PM +0100, Jan Ingvoldstad wrote:
>> On Tue, Dec 11, 2012 at 4:13 PM, The Doctor <doctor@???>wrote:
>>
>>>
>>> What if the client is outside the LAN??
>>>
>>
>> Uhm, there is only a problem if the client is sending "outside the LAN", so
>> those are exacty the instances where the recipient reasonably responds:
>>
>> "Hi The Doctor, I cannot read your attachment"
>>
>> and maybe helpfully add something about sending it in a different format.
>
> Tried that befreo.
>
> The lidiot said winmail.dat is 'standard'.
>
>> --
>> Jan


In a sense, it may be, given the percentage of WinLusers in the world.

But .. so is the case with any OTHER mime-type or 'attachment'.

How many types of those does smtp pass-through transparently?

Must be hundreds, if not a thousand by now.

It should no more be an MTA 'issue' than a .jpg or an .xls file.

Up to the MUA, or the recipient to save-locally and feed to 'whatever'
appropriate app to handle and present. They do not WANT it touched,
otherwise.

You'd be upset if a spreadsheet and all its formulae were converted to
plaintext without being asked, would you not? or a .doc or .sxw or xhtml
file stripped of its tags, fonts or formatting?

Not only is digging down into TNEF 'not our job' MTA standards or
policy-wise, it is just as impractical to try and make it such as it
would be to unravel and convert any OTHER mime-type OR
non-smtp-altogether transfer.

'Encapsulate' or 'gateway' it as we once had to do with uucp or X400.

Send it off to ClamAV or the like if it is a potential malware vector.

But otherwise 'MTA' applies - if it CAN fit within smtp's due bounds,
just message-TRANSFER it - intact and unaltered.

If it is PRESENTED at the point of acceptance into the 'transfer'
network without the smtp needfuls?

Malformed messages and protocol violations, and non-smtp-compliant
things that just do not 'fit' are not new - not by years and tears.

MTA have always had need to kick such things back and let the sender fix
that, and the many means to detect and action that are roads well travelled.

There is scant need to argue with the sender or receiver - and even
less to argue with each other.

Bill
--
韓家標