deravej header_checks v postfixu

[Vladimír Solnický]

19. 6. 2003 napsal(a) pavel.vrany na ogi.cz na téma ,deravej header_checks v...:

> V postfix-1.1.11 pouzivam v body_checks mimojine radku:
> /^[^\t\x20]*((file)?)name=(.*)\.(exe|bat)"("?)[\t\x20]*$/ REJECT Invalid attachment.
>
> stejne tak u postfixu2 mi vybouchlo v mime_header_checks
> /name=[^>]*\.(exe|bat)/ REJECT
>
> (zkratil jsem to, koncovek je tam vice, doc je povolen)
>
> Presto mi pres to prosel email s nasledujici prilohou:
>
> Content-Type: audio/x-midi;
>         name=Besídka.doc.exe

Nevím, zda to byl Váš důvod, ale:

Je malo pravdepodobne, ze tam bylo Besídka.doc.exe, spíše tam asi bylo
"Besídka.doc.exe" nebo dokonce =?ISO-8859-2? .... a to je problém regexpů.

Protože:

1) neřeší kodovani B (Base64) -- tam by musely dekodovat cely nazev, aby
vubec prisly na to, jaka je pripona.

2) neresi kodovani Q -- tam by se to dalo resir reg. výrazem, ale je treba
pocitat s tim, ze tecka muze a nemusi byt kodovana, a kazde pismenko
nemusi byt kodovano nebo muze byt a navic velka a mala pismena maji jine
kody, ovsem pro spusteni ve Win je velikost zanedbavana, takze vyraz se
pekne nafoukne a zpomali, kdyz ma pokryt vsechny kombinace

3) vetsina vyrazu dle mne nepokryva ani uvozovky, ktere jsou temer povinne
(tj. jen mohou byt ve specialnich pripadech vynechany)

4) toto kodovani je blbe (prectet si RFC 2045-9); ovsem jelikoz ho cilove
produkty pouzivaji, je treba ho resit. Ale melo by se hlidat i to,ktere je
spravne ...

5) Pokud tam opravdu nejaky visual basic dal dlouhé í a nikdo to cestou
neodmítl, je možné, že nemáte nastavené locales na serveru a í tedy není
součástí slova ... (ale já osobně bych misto locles radeji nastavil
postfix tak, ze nekorektní hlavicky obsahujici osmibitove znaky odmitne,
protoze tam nemaji co delat (vizte RFC) a bezne programy se daji nastavit
korektne, a tak zabil dve mouchy jednou ranou).

Zaver:

1) pouzit neco na ,,aplikacni`` urovni, protoze jen tam se to da udelat
dobre (tj. modul, ktery dostane zpravu jako celek, ktery muze parsovat a
zpracovat a analyzovat a pak ho pripadne vrati zpet MTA). U sendmailu by
to asi byl milter, u postfixu asi bude existovat neco podobneho.

2) na urovni MTA to budou vzdy jen hacky, ktere zdaleka nebudou
stoprocentni. Mohou se pouzit jako jedna z vrstev a snizit tak
pravdepodobnost pruniku neceho noveho, ale neni mozno se na ne spolehnout,
protoze MTA nepracuji s vnitrni strukturou zpravy a bez toho se to neda
udelat dobre. Samozrejme, jelikoz mnoho viru uziva velmi jednoduche
sekvence, tak to mnohe zachyti, ale staci jeden autor, ktery si precte RFC
a zamysli se nad nim, a je po legraci ...

S pozdravem

V. S.
-- 
Mgr. Vladimír Solnický, sys. administrace IT,
Vegacom, a. s., Šenovská 434, 182 03 Praha 8-Ďáblice, CZ,
telefón +420 266005154, MT +420 603855154, telefax +420 266005560.
Píši pouze za sebe, ne za Vegacom / Speaking for myself only ...