Re: [exim] caution to those blocking files by extension

Peter Velan wrote:
> am 2006-11-04 14:37 schrieb John Hall:
>> On 11/4/06, Peter Velan <pv0001@???> wrote:
>>
>>>>> Will windoze execute a file that ends in dot-space-space-space-exe ?
>>>>> dosent the os see this as NOT ending in .exe
>>>> I think that windows will happily exec the file, but I don't have a
>>>> machine to test on.
>>> You are right - WindowsXP with shell cmd.exe:
>>>
>>> C:\>"xxx. exe" --- will "happily" be executed.
>> Except your average user is not going to extract the file from the zip
>> file and then launch a command prompt in order to run it.
>
> There was no mention of a .zip in the original posting ;-) But, you are
> right with:
>
>> If you
>> simply double-click the file, Windows does not appear to be willing to
>> execute it.
>
> The real danger ist an old, unpatched client which opens an attachment
> without users intervention. Wasn't there some problems with .lnk or .pif
> or something else in the past? What kind of mechanism was involved in
> these cases? I'm sure it was not the "shell" named "Windows Explorer"
> with its doubleclicking technique.
>
> Greetings,
> Peter
>

ISTR it had to do with the client being led to try to open an attachment because
it was interpreted as something that was to be displayed, or masqueraded as
something needed by a displayed part.

The process of opening then allowed the WinCrobe to act with the authority of
the logged-in user of the MUA - all too often an 'Administrator' equivalent.

Note that this persists with embedding calls to off-box files and 'images'
(which may not be...) in html malware - not as obvious as 'clickable' links.

Blocking or converting html is painful 'coz so many folks who compose in it are
not even aware they are doing so, let alone being willing to work in text instead.

NB: We've just started adding html-block as a 'recipient choice', as well as
(still in test) checking for a user's choice of *permitted* attachments (short
list!) rather than *prohibited* attachments (far too long of a list).

- Where the user's choice for attachment filename can be a proprietary code
agreed with regular correspondents - who must, of course rename the file before
attaching.

Fairly low-nuisance between/among, for example branch offices & HQ.

Otherwise, sort of TMDA'ish for 'new' arrivals. TANSTAAFL.

But it is cheap and cheerful and seems to make more sense than trying to OCR
arriving .gif's.

:-(

Bill