I to mate pravdu (i kdyz ten vir - asi bych se hadal ;-) Trochu me nadzvednul clovek, ktery se verejne chlubi ve svem clanku jak ignorantsky prispiva k vetsi zatezi mailserveru (vzdyt odesilatel se falsuje u vetsiny vice rozsirenych exemplaru uz nejaky patek).
Treba tady berou penize podle "poctu komentaru" ;-)))
Zkuste si ty hlavicky vetsiny vice rozsirenych exemplaru projit - vetsinou obsahuji krome doplneneho from s nesmyslem i druhe s adresou. Tento cerv dusledne tvori hlavicku beze stop, u tech predchozich chybela prave ta duslednost, takze informace o odesilateli tam byla a dokonce spravna, k ni se pridalo dalsi from, ktere vam vetsinou zobrazi mailovy klient (to prvni - podle RFC tam preci zadne dalsi neni).
No, tak to by som chcel vidiet, ako toto niekto na svojom serveri povoli. Zmienovany post.cz by musel podporovat relaying, pretoze ten Karlik urcite nie je v tej istej domene (pripojeny zrejme cez dialup u svojho ISP). Takze prenho je mailserver jeho ISP jedina moznost ako poslat mail.
A relaying na mailserveroch je no-no, ak nie je osetreny nejakou autentikaciou (co asi free mail ako post.cz robit nebude). Cize toto nie je riesenie.
Pokud se SMTP server rozhodne, ze je mail nedorucitelny, tak by prece mel poslat odesilateli chybovou zpravu (jestli je ten duvod, ze dana adresa neexistuje, uzivatel ma plny mailbox, anebo ze zprava obsahuje vir, na tom prece nezalezi).
Jen se ty zpravy nesmi posilat na hlavicku From: z mailu, ale na obalkove From (bez dvojtecky; nebo tez Return-Path).
Nahodou jsem ;-)
Mam uz za sebou par vetsich implementaci mailserveru a denne resim problemy s nimi. Takze jsem ponekud alergicky, kdyz me rika 'kamarade' nekdo, kdo by klidne zakaznikovi upravil mail.
Jsou 2 moznosti, jak reagovat na mail s virem.
1) nechat byt
2) vratit chybu
Jakakoliv jina akce je neeticka a porusuje to rfc.
Ostatne i z technickeho hlediska je to dost problematicka zalezitost.
Jak to vlastne udelat, kdyz odstranim prilohu? Beze slova? Nebo kam umistim informaci o teto akci? Do tela zpravy? A co kdyz klient nezobrazi tuhle zpravu, ale jeji html variantu? Takze do html? To je uz asi dost zajimava vec, hrabat do kodu html. Musim se starat o spoustu veci, chyb klientu, resit ruzne nestandartni rozsireni apod.
Takze bych rek, ze je to uplnej nesmysl, neco ze zpravy odstranovat. Diky takovejm blbostem hodne casto resim to, ze vola zakaznik: "kolega se mi uz 3 dny snazi poslat nejaky soubor a ja to nejak nemuzu precist".
A mimochodem, v kuzi spravce mailserveru? Vetsina administratoru na tohle kasle. Tak co, prisel zakaznikovi vir, nemuze si stezovat, za to nemuzu, ma se chranit. Neprisel mu mail? To je problem, protoze si zrejme bude stezovat.
Takze si, 'kamarade', nech kecy a napred si zjisti, jak to u provideru chodi.
To jsou jen reci. Jedine podstatne je, zda pres mailserver tecou viry nebo ne. Nas mailserver ma seznam pripon, ktere povazuje za nebezpecne a misto jejich odeslani pouze vygeneruje zpravu (pro obe strany), ze mail s temito priponami proste nedorucuje. A dost. Chapu to tak, ze kdyz na postu prijedu s balikem, co zcela zretelne tika, tak i postak, co ma jen pul mozku me s nim vyhodi. Muj "postak" sice nema ani tu pulku, ale na tohle jeste staci. A to varovani? Jak uz rekl nekdo jiny: je fuk proc mail nejde dorucit, ale ze to nejde se rici musi.
No a v tom je ten vtip - tenhle virus ma na onu adresu nastaveny i from v obalce (tj. vsechny from v mailu jsou zmeneny na nespravnou adresu), return-path... Jedina identifikace je vetsinou jmeno pocitace, z nejz pochazi (coz je treba M) a jeho IP adresu (obcas z rozsahu lokalnich adres, obcas adresy pouzivane providery na dial-up linkach, atd...). Tj. odpoved nema mailserver kam poslat. Je smutne, ze nektere SMTP servery povoli posilat maily s jakoukoliv from hlavickou bez nejmensich problemu - pak to funguje takto divoce...
Pravda - ten virus taky na RFC moc nehledi, ale tady to byl asi zamer...