Názory k článku
SPF a Sender-ID

Alespoň pro mě by to byl docela velký problém. Jsem zvyklý odesílat emaily s mojí adresou ve FROM jenže přes různé SMTP. Doma je to SMTP na mém PC, v práci zase jiný SMTP na cestách je to zase SMTP mobilního operátora atd.. Ani jeden z těch SMTP serverů nemá bohužel nic společného s mojí doménou, protože můj hosting SMTP nenabízí.

Takže podmínka, že email se musí odesílat ze stroje v dané doméně je ZNAČNĚ omezující.

SPF ale tuto podmínku nemá - je jen na Vás, co napíšete do toho TXT záznamu pro Vaši doménu.

Stačí tam pak doplnit "include:mujISP1.cz include:mujISP2.cz include:mujISP2.cz" a je to.

Jenze pak si spammer zjisti, ze umoznujete posilat emaily pres ISP2.cz a posle falsovane emaily pres nej.

A to udela jak?

Predpokladam, ze si vybirate seriozni ISP a ti nedovoluji svuj SMTP server pouzivat komukoliv. Takze vasi adresu muze padelat pouze opravneny uzivatel toho SMTP serveru. A pokud to udela, predpokladam, ze vami vybrany ISP vam pomuze, kdyz vas jiny jeho zakaznik poskozuje ...

Vadou tohoto systemu je, ze kdyz se chystate nekam odjet (treba na pracovni skoleni, na vedeckou na konferenci), nemuzete se na odesilani mailu "tamodsud" prilsi pripravit - malokdy budete mit totiz potrebne informace. A menit DNS az "tamodsud" je sice mozne, ale vzhledem k pomerne velke setrvacnosti DNS to muze byt problem ...

Nicmene, pro nemigrujici nebo malo migrujici uzivatele to pouzitelna metoda byt muze. Jen system nesmi hypertrofovat do situace, kdy email odeslany ze systemu, ktery nekterou z techto technik nepouziva, bude prakticky automaticky povazivany za SPAM. Na druhou stranu, pokud to do tohoto stavu nedospeje, "antispamovy" ucinek bude nejisty.

Mimochodem, v jedne z diskusi se psalo, ze jednim z dulezitych motivu zavedeni nejakeho takoveho systemu je objem dat, ktery v souvislosti s prenosy SPAMu nastava. Z tohoto pohledu se nezda prilis vhodny jakykoliv system, v ramci ktereho se dopis nejprve prenese a teprve pak posuzuje podle obsahu ...

> Mimochodem, v jedne z diskusi se psalo, ze jednim z
> dulezitych motivu zavedeni nejakeho takoveho systemu je
> objem dat, ktery v souvislosti s prenosy SPAMu nastava.

Zpusobu, jak spam skodi, je nekolik:
- Zabirani datove / serverove kapacity. A to jednak spamy a jednak chybovymi hlasenimi diky nim vygenerovanymi.
- Cas uzivatelu nutny na trideni spamu/hamu (v soucasnosti asi nejvetsi polozka)
- Ztracene prilezitosti (a dalsi skody) diky false positives

> Z tohoto pohledu se nezda prilis vhodny jakykoliv system, v
> ramci ktereho se dopis nejprve prenese a teprve pak
> posuzuje podle obsahu ...

(Originalni) SPF posuzuje mail podle SMTP obalky, mail se tedy nemusi prenest.

Sice nejsem do detailu obeznamen se SFP, ale mam dojem, ze v ceste muze byt nejaky relay a netusim, jak se cilovy server dozvi, zda je cela cesta validni, bez preneseni celeho e-mailu.

V cestě nemá žádný relay co dělat - kde by se sám od sebe vzal?

Žádná cesta se v SPF neposuzuje, jen "MAIL FROM".

Napriklad tak, ze forwarduju vsechnu svoji postu na server meho ISP :-)

??? S tím přece SPF počítá, dokonce i ve vzorovém nastavení.

Navíc je to něco, co já úmyslně udělám - tak stejně úmyslně upravím ten záznam v DNS, kde by měl být problém?

Ano, to platí v případě, že své záznamy v mém DNS koordinuji s tím, co dělá provider se svými SMTP servery. Nejsem si úplně jist, že taková koordinace je v reálném možná - viz. potřeba navyšovat počet serverů na straně ISP (a vlastní provádění této činnosti).

Samozřejmě se mohu mýlit :-)

OK, pak ano, pokud ISP něco takového provede, aniž by mě informoval - což by neměl, pokud má nějakou povědomost o SPF.

Pokud bych si svým ISP nebyl jist a forwardoval přes něj maily, tak určitě nenastvím v SPF "-all", ale třeba "~all" nebo bych SPF vůbec neřešil do té doby než se to ISP naučí.

1. Já jsem si myslel, že třeba WWW-rozhraní pro čtení a posílání pošty má skoro každý solidní provider. Jsem-li tedy na cestách, posílám raději dopisy jen přes ono rozhraní.
2. Aniž je či není SPF, mohou přece antispamové programy označovat poštu jako SPAMovou přesně podle pravidel, která jsou v článku zmíněna k doméně lupa.cz. Na to nepotřebujá nic, co by se musí zavádět.
(Že budou mít někteří lidé smůlu - tak si to musí sami zařídit jinak. Např. podle 1.)

Nezlobte se, ale nevidim duvod, proc bych mel pouzivat nejake WWW rozhrani pro cteni posty (kdyz mame nativni rozhrani). A pokud jsem pripojen nekde pres dial-up, rozhodne zadne WWW rozhrani pro cteni posty pouzivat nebudu.

To jste tak 5 let za Čínou. - Asi zřejmě vůbec netušíte, co současné WWW-nadstavby dělají (navíc).
(A dokonce je to jedna z nejjednodušších ochran proti virům v dopisech, používáte-li jiného WWW-klienta než MSIE!)
P.S.
Samozřejmě jsou i jiné "gateway-e" pro čtení pošty než WWW-nadstavby. Ovšen to byste musel chtít o problému začít uvažovat, než hned odmítnout (VŽDY!), co pořádně neznáte.

WWW rozhrani je mozna vhodne pro to, abyste vyridil par soukromych dopisu, nebo, v nouzi nejvetsi, vyridil i tu a tam nejaky ten dopis pracovni. Pro vyrizovani nekolika desitek dopisu denne uz al eprilis vhodne neni - tedy, pokud na nej nejste zvykly a plne vam nevyhovuje. A me zadne takove prilis nevyhovuje (a jelikoz jsem sam sobe poskytovatelem postovni schranky, nejsem omezovan v tom, co bych nasadil).

WWW rozhrani vam tedy muze slouzit jako nouzova nahrazka. Ja ale mam na mysli "kocujici uzivatele", kteri proste postu z nahodnych mist vyrizuji vice-mene regulerne. A to proste proto, ze ja mezi takove uzivatele patrim. Ani ted nejsem ani ve sve kancelari v praci, ani doma ...

Nemohu s Vámi souhlasit především proto, že k WWW-rozhraní zpřístupňujícímu poštu se daleko snáze dají udělat nadstavby pomocí WWW-agenta - než k jinému protokolu. (Včetně nároků na nutné znalosti.)

To, ze se neco udela snaze neznamena, ze to existuje nebo je duvod se domnivat, ze by to nejaky ISP v dohledne dobe vyvinul. Predstava, jak vetsina ISP vyviji - nebo i jen implementuje ci instaluje - nekolik ruznych WWW rozhrani, ktera se snazi poskytnout sluzby podobne tomu-kteremu MUA, ktery pouzivaji jeho zakaznici, mi nepripada prilis realna ...

Tak ja jakozto "WWW-agent" k tomu mam teda docela odpor... a to vcetne ActiveX balastu nad Exchange, coz je asi nejkomfortnejsi "WWW pristup", ktery v soucasne dobe na svete existuje...

1. Je to značně komplikované, nikdy nevím odkud budu chtít odeslat email se svým FROM.

2. Málokdo se asi může jednoduše hrabat v záznamech o své doméně, většinou mám doménu u nějakého hostingu.

Na to existuje několik odpovědí

1. přestanete používat SMTP správným způsobem, jakým jej užíváte (nebližší server) a budete vždy posílat maily přes jeden server po autentizaci
2. SPF vůbec nebudete využívat nebo povolíte odesílat celému světu
3. tyto problémy vyřečí další návrhy, které umožní odeslat mail po "zaplacení" trochy výpočetního času, autorizaci odeslání digitálním podpisem a podobně
4. poskytovatelé dns hostingu zprovozní systémy, které umožní snadnou editaci a zveřejňování záznamů (webová rozhraní)

pridavam moznosti
5) zblaznite se a v cele v bohnicich nebude pocitac
6) vyse**** se na nejake maily uplne
7) zahajite globalni termonuklearni valku, zbytek lidi shromazdite na jednom miste a nebudete potrebovat mail..

V clanku se o tom asi explicitne nehovori, ale k cemu je to +ptr? Vzdyt PTR zaznam si pro svoji IP adresu muzu udelat jaky chci. To by se musel jeste delat dopredny (A) lookup pro vsechny PTR zaznamy, ktere se najdou, a ve vysledne mnozine adres by musela ta adresa SMTP klienta byt (takhle to dela TCP wrapper, treba).

-Yenya

Podle RFC se ten A lookup dela.

No, třeba to donutí poskytovatele připojení přestat nutit lidem jejich SMTP. Všichni bezdráťáci kteří u mě mají signál přeprodávají nextru a nutili by mě tedy používat smtp.nextra.cz, což já nechci. Používat mnou v rámci hostingu zaplacený SMTP neumí nebo nechtějí povolit. Takže půlka sídliště jede přes jejich SMTP a já můžu mít problémy, pokud někdo z nich bude spamovat. Takže jedu přes blbý GPRS, který mi to kupodivu povolí.

Ja bych rekl, ze je to ochrana proti tomu, kdyz nekdo chytne cerva, ktery rozesila spamy...

RFC2476 definuje port 587 jako MSA (Message Submission Agent), pres ktery by se mela odesilat posta z beznych klientu a port 25 (MTA) by zustal pouze na komunikaci mezi SMTP servery. Je fakt, ze se to moc neuchytilo, ale je taky fakt, ze presne tohle to resi, protoze tenhle port vetsinou blokovany nebyva. Takze jen je to zase o tom, co je kdo ochotny udelat pro to, abyse spammerum ztizilo spamovani.

Pokud vsichni budou krcit rameny a rikat: "Ja nechci nic menit, ale nechci aby mi chodily spamy", tak se asi moc daleko nedostanem.

O.

Obavam se, ze je na vas, abyste si nastavil z jakeho SMTP serveru bude vase posta odesilana - v tomto pripade proste pridate "smtp.nextra.cz". Je to daleko rpavdepodobnejsi vyvoj nez to, ze ISP zmeni nejake navyky.

Jinak ale - neni povinnost pouzivat SMTP u ISP, pokud si to neprejete - a vase vzajemna smlouva s nim to umoznuje. No a jestli se vam jejich podminky nelibi - zvolte jineho ISP ...

Mozete v sucasnosti verit vobec nejakemu SMTP serveru, ze vam poskytuje platne "mail from"? Nie.

SPF je tu na to, aby vam toto umoznil. SPF zaznam v nejakej domene specifikuje, ktorym SMTP serverom ohladom danej domeny verit mozete. Zvysok autentizacia je uz samozrejme na spravcovi dotycneho SMTP servera alebo serverov, co je u providerov zalezitostou nastavenia SMTP servera - ak sa prihlasite, potvrdi vasu adresu, inac nie.

Ak budete niekde na druhom konci sveta, tak ci tak sa musite prihlasit na server vasho ISP cez POP3/IMAP za ucelom citania posty, tak preco by vam malo vadit prihlasenie sa na SMTP server vasho ISP za ucelom posielania posty?

Ne, verit skutecne nemuzete. Neni take duvod verit - nikdo nerika, ze to FROM platne je, nebo ze to kdokoliv zarucuje. Na zaruceni autenticity odesilatele nejakeho dopisu al euz mechanismy existuji - ano, mluvim o elektronickem podpisu. Nevidim celkem duvod, proc zavadet dalsi mechanismus resici prakticky tentyz problem, kdyz uz jeden existuje. A jestli nevyhovuje - mela by nejprve, pravdepodobne, nastat diskuse proc vlastne nevyhoduje a jake jine vlastnosit pozadujeme - aby zase nevzniklo neco, co se takrka zase nebude pouzivat ...

Elektronicky podpis je z tohoto hladiska kanon na vrabce. Nie je ho mozne uplatnit na SMTP leveli. A vyzaduje o dost viac CPU casu na oboch stranach.

Ano, existuju pokusy o zavedenie el. podpisu na SMTP urovni, avsak SPF a podobne techniky poskytuju jednoduchsie riesenie, ktore ma sice nejake nevyhody ale je zarovnen jednoduche: miesto podpisovania mailu odosielatelom a jeho posielania zhocikade je maily poslany iba z niekolkych miest, ktore su v DNS uvedene ako doveryhodne a interna autentizacia/autorizacia je ponechana na tieto miesta.

Pokial hovorime o SPF, existuje uz pokial viem niekolko jeho implementacii, takze si myslim ze ma ovela vacsiu sancu sa naozaj uplatnit ako komplikovane riesenia typu SenderID

Ano, SPF je evolucia, kym podpisovanie mailov je revolucia. Otazka je, ci je Internet na tuto revoluciu pripraveny, a ja si myslim ze odpoved znie NIE.

Presne tohle jsme uz resili u DomainKeys... Ano, osobni elektronicky podpis je kanon na vrabce. DomainKeys i SPF se proste jednou zavedou (u SPF dokonce staci jen pridat radek do DNS), kdezto u klicu je problem s vhodnym klientskym SW a musi se o to porad nekdo starat (prichazeji/odchazeji zamestnanci), zatimco SPF se meni jen kdyz provadim nejake vyznamnejsi zmeny v siti.

To uz tu jednou bylo a jedeme dokola, takze jen velice strucne. Elektronicky podpis musite take jednou zavest. A klice muzete vydavat na sto let, budete-li chtit. Nevim, kolik klientskych softwaru tuto technilogii nepodporuje - z tech, co vitam ve svem okoli kazdy - takze i tento argument je, zrejme, umely. Nastaveni v souvislosti s prichody a odchody zamestnancu musite delat tak jako tak - preci jim nenechavate pristup na firemni servery a do firemnich schranek. Pridat do CRL jedno seriove cislo neni slozitejsi ukon nez pridat jeden zaznam do DNS. Takze i tohle je prast jako uhod.

Snaha zavest podobny system na trochu jine cile a motivace nez zajistit autenticitu uzivatelu - ve skutecnosti jde o to donutit uzivatele aby museli odesilat postu pres centralne kontrovatelny bod. Tohle skutecne elektronicky podpis neresi - ten dava drziteli certifikatu moznost zabranit mi uzivat jim vydany podpis - ale nedava mu jakoukoliv kontrolu nad obsahem dopisu. A to je prostor pro SPF ...