Vlákno názorů k článku Trhem proti spamu! od V.M. - V Return-Path má být věrohodná zpáteční adresa. A...

V Return-Path má být věrohodná zpáteční adresa. A teď je otázka, co tam jaký SMTP-mailer dá, když se ony všechny tři hodnoty liší.
Ale vidím, že Vy byste nenašvindlovali cizí e-mail ani jako začínající spamer z gymnázia!
Já jsem to tušil, proč se nemám podepisovat. Původně jsem si totiž myslel, že opravdu chcete rešit problém spamů.

To je sice všechno hezké, co tady plkáme, ale já říkám, že dokud lze získat seznam potenciálních příjemců spamu a vygenerovat automaticky v krátkém čase x mailů z jakékoli adresy(pro sammera není problém se někde zaregistrovat a něco málo zaplatit!), kterou pak vezme čert(tak se dnes děje), tak je to všechno jalové přemítání!

Jste si jist, pane kolego, ze jste to opravdu dobre uvazil ? Jaky je vlastne smysl toho parametru ve vami navrhovanem svete ? K cemu je dobre, aby se tentyz udaj v ramci session predaval dvakrat (a kontrolovalo se, ze totozne) ?

Popravde receno, zda se, ze doslo z vasi strany k nejakemu omylu nebo zasadnimu nepochopeni systemu predavani posty. Krome te drobnosti, ze do "Return-path" se nedava udaj z HELO, coz verim, ze jste ani tvrdit nechtel a jde o nejaky preklep, mam dojem, ze jste uplne zapomel, ze dopis cestou muze prochazet nekolika MTA, ze jeden MTA muze rozesilat - a to zcela regulerne - postu libovolneho mnozstvi uzivatelu s libovolnymi adresami, ze jeden a tentyz uzivatel muze svoji postu posilat pres vice ruznych MTA ...

Jak budou ve vasem svete reseny tyto situace ? Nebo navrhujete vsechny tyto situace "zakazat" ?

Popravde receno, velmi dobre chapu co rikate. Ale jednak opravdu nechapu, k cemu je to cele dobre a jednak je nejasne, jak chcete zaridit, aby sla dorucit vubec nejaka posta - alespon ta, ktera SPAMem neni ...

> S některými lidmi je to opravdu těžké.

To mate pravdu :-)

> Vždyť přesně tak to SMTP-programy dělají a píší do hlaviček!
> Pouze odmítají takovéto nesrovnalosti jen málokde.

Coze? On nektery SMTP server vubec LZE nakonfigurovat tak, aby session stylu:

HELO smtp.provider.cz
MAIL FROM: <uzivatel@firma.cz>
RCPT TO: <uzivatel@tento.pocitac>

odmitl??? (A vyzadoval: HELO odesilaci_smtp.firma.cz?)

A ktery SMTP server jde nakonfigurovat, aby pri odesilani z adresy uzivatel@firmaa.cz daval HELO smtp.firmaa.cz a pri uvedeni uzivatel@firmab.cz daval HELO smtp.firmab.cz? (Za predpokladu, ze je odchozim SMTP serverem pro obe firmy.)

Nebo si mozna nerozumime, cemu se rika overeni... Ale proste overeni, jestli je server dostupny pod jmenem uvedenym HELO rozhodne nestaci. Ja mel namysli, ze se domena v HELO a v MAIL FROM musi shodovat.

Nerikam, ze soucasny princip je dobry. Ale ten zde popsany vyzaduje, aby provozovatel SMTP serveru vedel o vsech domenach, ktere se pres nej maji posilat.

S některými lidmi je to opravdu těžké.
Vždyť přesně tak to SMTP-programy dělají a píší do hlaviček!
Pouze odmítají takovéto nesrovnalosti jen málokde.
A Váš princip "současné" struktury SMTP je právě to, co je proti duchu původní představy. Právě proto, že to e-mailoví provideři takto nikde nekontrolují, máme spamy, červy, politické dopisy atd.

> První SMTP-server, na který přijde dopis, ...

Aha, takze kdyz si udela spammer vlastni SMTP server, tak bude z obliga, protoze to bude kontrolovat ten prvni, tedy on sam :-)))

Musi to kontrolovat KAZDY SMTP server v ceste. Vpodstate jedina alespon trochu funkcni varianta Vaseho reseni je, ze by SMTP server musel udat nejake jmeno v domene odesilatele a prijimaci server by si overil, ze se to jmeno resolvuje na IP protistrany.

Ovsem timto silne omezuje moznosti SMTP struktury, tak jak jsou dnes. Dnes se mohu klidne pripojit dialupem a odeslat pres SMTP sveho poskytovatele dopis z abcd@firma.cz a poskytovatel nemusi nic konfigurovat. V tomto systemu by to nebylo mozne.

Nehlede na to, ze to vubec neresi problem posilani spamu z vyhackovanych pocitacu.

První SMTP-server, na který přijde dopis, by měl kontrolovat, zda v prvním příkazu "HELO doménové,jméno" je uvedena totéž, co pak v MAIL FROM a posléze v dopise ve From:
(Připustit by se mohly jen výjimky zadané nějak správcem.)
A současně SMTP-server vytváří položku Return-Path, kam dává doménové jméno právě z HELO. A při odlišnosti těchto údajů nemusí poštu přejímat už další SMTP-servery (prostě proto, že tomu tak být nemá).
Chce-li někdo posílat poštu, tak sám se musí postarat, že mu vše bude souhlasit, (Vždyt přece pro příspěvky do e-mailových diskusních skupin to tak je už dlouho!)

Hmm, zrovna AOL podporuje SPF (http://spf.pobox.com/) -- snadno si to ověřite v DNS, takže bych ho mezi spamery neřadil.

A jak si presne to overovani predstavujete.

Obecne nemuze SMTP server A rici, zda server B muze nebo nemuze posilat mail s uvedenou adresou.

Ono by úplně stačilo, kdyby SMTP-servery kontrolovaly údaj za HELO (resp. EHLO) nebo existující Return-Path: v e-mailové hlavičce s údaji ve From:
On by si to každý spamer rozmyslel, kdyby na jeho skutečnou e-mailovou adresu začali lidé spam vracet (případně mu k tomu ještě nějaký přidali).
Tato kontrola přece není nic proti ničemu - naopak by takto měly dopisy vypadat. Konec konců listservery to již léta kontrolují (nebo o tom alespon píší varováni).
Ovšem některé známé "spamové firmy" jako AOL.COM a HOTMAIL.COM to bud vše povolují schválně anebo se jejich správci naučili číst internetový e-mail zatím jen Outlookem.

Docela by se mí líbila certifikace SMTP serveru. Za SMTP by stala konkrétní osoba, v případě potřeby dohledatelná. Server na straně příjemce by dle certifikátu poznal o koho jde a poštu z necertifikovaného zdroje by prostě nepřijal. Všichni kdo by to s odesíláním pošty myslelí vážně by si, dle mého názoru, certifikaci radí pořídili. Současný stav, kdy si SMTP server muže udělat kdokoliv kdekoliv mi připadá jako hlavní problém.
Sice je to zase jen ta „poklička na hrnci“, ale připadá mi to průchodnější než placení pošty, nebo nějaké výpočty při odesílaní jako navrhoval Gates.

Nebo možná by jsme si mohli taky všichni nechat zvětšit penisy. Když je budeme mít po kolena, tak typická nabídka o zvětšení o 2-4" pozbude smysl ;o)