Názory k článku
Google přijímá poštu po IPv6, vyžaduje ale reverzní záznam
-
A proč by zrovna existence reverzního záznamu měla být předpokladem toho, že nejde o spam? Co když někdo jen chce mít ve své síti pořádek a přiřadí reverzní i AAAA záznam všem svým uživatelům (mezi kterými se samozřejmě mohou vyskytovat lidé s postiženým OS odesílající nevědomky spam)? Přijde mi to jako poměrně irelevantní informace a taková kontrola bude velice často a) nefunkční nebo b) naopak neopodstatněná buzerace.
To už by bylo lepší udělat nějakou obdobu SPF/DKIM/ADSP – správce sítě by definoval, zda z té sítě lze posílat e-maily přes port 25:
a) ano
b) ne
c) jen s klientským certifikátem od určité CA
+ případné výjimky pro konkrétní adresy. -
j (neregistrovaný)
Protoze pri jeho neexistenci jde o spam zcela urcite. Spammer totiz jaksi nedisponuje prostredky, jak si reverz na cizim stroji zaridit. A ano, jiste je mozne, ze nektery provider prideluje reverz vsem klientskym strojum. Ale vzhledem k realnemu stavu internetu je jeho neexistence velmi dobrou indikaci.
-
j (neregistrovaný)
Viz nekde kolem, jen na tom skonci 3/4 pokusu o doruceni mailu. Samo, neni to jediny pravidlo ... ale vysledkem je, ze z nejakych 5-10k spamu/den (dorucenych a zpracovanych filtrama) jsou doslova jednotky kusu.
Kdokoli totiz chce realne mailserver provozovat, tak nema zadny problem s tim, ten reverz mit.
-
conyx (neregistrovaný)
Tak to asi neznáte velké společnosti a jejich podporu. Když jsem chtěl po UPC nastavit reverzní DNS záznam (IPv4), protože jsem se nemohl připojit na školní SSH server, trvalo to asi měsíc. Než jsem se prokousal přes ty cvičené opice které odpovídají "podle tabulek", aniž by tušili co po nich vlastně chci, trvalo to 14 dní. Když jsem se konečně dostal k někomu, kdo mi porozuměl, trvalo další 2 týdny, než to skutečně nastavili.
Nejhorší na tom bylo, že UPC nepoužívá žádný ticket system, takže jsem ten problém musel vysvětlovat pořád dokola. -
j (neregistrovaný)
Neexistence reverzu zcela vypovida o schopnosti spravce si najit spravneho pripojovatele jeho mailserveru. Na vsech mailserverech co adminuju odmitam prijimat maily nejen s neexistujicim reverzem, ale i s reverzem, ktery vede jinam, nez odkud se snazi byt mail dorucen (= kontrolola tam a zpet). Samo jak na IPv6 tak na IPv4.
A (kupodivu) jen na tomto pravidle skonci pres 90% spamu. Samo, nedoruci se jiste maily jistych neschopnych odesilatelu ... ale vidim to zhruba tak, ze kdyz si nekdo neumi na auto nasadit kola, tak se mu taky po silnici moc dobre jezdit nebude.
-
Ondřej CaletkaZlatý podporovatelNeexistence reverzu zcela vypovida o schopnosti spravce si najit spravneho pripojovatele jeho mailserveru.
…píše člověk z IPv6 tunelu bez reverzního záznamu :P
Ono to bohužel není tak jednoduché, zvlášť v současné době rozvoje IPv6, kdy třeba v ČR si jako domácnost můžete vybrat z jednoho ISP, co má nativní IPv6 a to k vám ještě musí vést telefonní dráty. A provozování vlastního mailserveru v domácnosti je legitimní, zvlášť na broadbandové přípojce.
Spousta domácích přípojek má vygenerovaný reverzní záznam pro IPv4, ale pokud má IPv6 bez něj, Google od nich zapnutím IPv6 najednou začal odmítat poštu, kterou do té doby přijímal.
-
mc (neregistrovaný)
No nevím jak na IPv6, ale na IPv4 rozhodně není dobré nemít reverzní záznam pro vše (pokud se nepletu je to i doporučeno v nějakém RFC). Některé služby na které se pracovní stanice připojuje totiž reverzní záznam z různých důvodů hledají a pokud není, tak práce s takovou službou může rychlostně drhnout.
-
Ondřej CaletkaZlatý podporovatel
Tak se divit můžeš začít :)
# dig -x 2a00:1028:83c8:14**::1
; <<>> DiG 9.9.3-P2 <<>> -x 2a00:1028:83c8:14**::1 ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45481
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.*.*.4.1.8.c.3.8.8.2.0.1.0.0.a.2.ip6.arpa. IN NS;; AUTHORITY SECTION:
8.2.0.1.0.0.a.2.ip6.arpa. 7200 IN SOA dns.iol.cz. hostmaster.iol.cz. 2013040701 43200 2160 1209600 7200;; Query time: 1478 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: So zář 21 10:47:06 CEST 2013
;; MSG SIZE rcvd: 158 -
j (neregistrovaný)
Vime caletka, s pulkou mozku se asi zije blbe, kdyby totiz tam byla i ta druha, tak by caletka mozna aspon tusil, ze IPv6 ma neco jako privacy extension, a ze jaksi klient neni server.
Plkat jeste k tomu o nejakych telefonnich dratech, a domacnostech, muze leda chorej mozej.
Ja samozrejme mam i vlastni mailserver, samozrejme vcetne naleziteho reverzu.
-
Ondřej CaletkaZlatý podporovatel
Víme, j, urážky si nechají od cesty. Faktem je že mají tunel od HE a vytahují se, že mají reverz. To umí každý.
Až budou mít domácí přípojku s nativním IPv6 (o tom se totiž v blogpostu píše) a povede se jim přemluvit ISP, aby jim nadelegoval reverzní záznamy, pak nechť j referuje, jak je to snadné a jak jsou všichni hloupí. Do té doby nechť si j nechá svoje plky.
-
j (neregistrovaný)
Vime caletka, kdyz je nekdo retardovanej, a netusi, ze rec je o serverech, ktere si jaksi 90% lidi neprovozuje na domaci pripojce ... a kde jaksi fuknci reverz je vubec predpokladem, abych se s dodavatelem vubec o necem bavil ...
A mimochodem, muj ISP nema problem mi nastavit zcela libovolny reverz i na IPv4 ... staci kdyz mu zavolam/poslu SMS/... (tech 4ek mam par, takze resit delagaci prefixu by byl jaksi decenti overkill)
Vazne by me zajimalo, kolik tak lidi si na sve domaci pripojce provozuje vlastni mailserver ... promile to nebude co? Hmm ...
-
Filip JirsákStříbrný podporovatelZprávička je o tom, že Google vyžaduje reverzní záznam od klientů. To, že dnes lidé neprovozují servery na domácích přípojkách je vinou NATu, až se tohohle omezení zbavíme, bude každý mít přirozeně doma spoustu serverů. Pokud váš ISP nastaví svým klientům libovolný reverz pro IPv6, brzo mu dojde místo na disku (teda pokud pro to bude mít nějaký rozumný automatizovaný postup, ne že mu bude nutné kvůli každému záznamu volat).
-
Pokud ty e-maily odmítneš (místo abys je zahodil nebo hodil do spamu), tak se to ještě dá pochopit – odesílatel se hned dozví o problému (chce to odpovědět správnou chybovou zprávou), má šanci to předat správci svého serveru a ten může zařídit nápravu. Během krátké doby (hodiny, den) to může být vyřešené, případně se alespoň najde způsob jak to obejít (posílat dočasně poštu přes jiný server). Nejhorší je, když se zprávy ztrácí a ty nevíš, jestli je adresát dostal nebo zmizely někde cestou.
-
j (neregistrovaný)
Srv maily samo se zcela korektni spravou odmitne prijmout, ve 100% pripadu plati, ze protistrana vubec netusi (tyka se tech jednotlivosti, kdy to vubec nekdo resi).
Pro zajimavost (posledni mesic na mailserveru serveru jedne firmy):
700x IPv6 s reverzem
29 000x IPv4 s reverzem
92 000x bez reverzu (tohle skonci hlaskou 450 4.7.1 Client host rejected: cannot find your hostname)=> 3/4 provozu konci jen na tomhle jedinym pravidle. A jsou to taky 3/4 usetrenyho provozu, protoze se ty maily neprenasej + samo zatizeni CPU, kdyby to mel resit az nekde dal.
-
j (neregistrovaný)
Firma ktera si neumi zaridit funkcni mail bude mit nejspis presne stejny problem s tim, zaridit si placeni faktur. Nehlede na to, ze dotycna firma po mailu stejne zadne objednavky neprijima. Od toho jaksi provozuje bud shop na webu ... nebo edi pro ty vetsi.
Jinak je jiste extremne efektivni probirat 5 - 10 000 spamu denne, jestli v nich probuh neni nejaka zakazka ...
-
ppp (neregistrovaný)
Srv maily samo se zcela korektni spravou odmitne prijmout, ve 100% pripadu plati, ze protistrana vubec netusi (tyka se tech jednotlivosti, kdy to vubec nekdo resi).
Říkáte, že vámi zmíněný server někdo zcela korektně spravuje, a proto maily od klientů bez reverzního záznamu odmítá?
Ve vyjádření googlu se ale píše o jiné situaci (a o tom je také následující diskuse): mail w.ill b.e m.arked a.s spam or p.ossibly r.ejected. Tedy že mail je označen jako spam (a spadne tak adresátovi do složky spam, kde ho často mezi skutečným spamem nenajde).(Do angličtiny vloženy tečky kvůli debilnímu spam filtru v této diskusi, který odmítá "zakázaná slova" (aniž řekne, která to jsou). (Za komunismu vás také zavřeli za zakázaná slova, aniž vám ovšem někdo předem řekl, co je zakázáno. :-))) ))
-
H0axZlatý podporovatelTak po ipv4 vyžaduje reverz také a také to není všude samozřejmost. Kromě toho by rád ještě správné SPF a HELO SPF a DKIM a pak ještě přiřazuje cca 50% náhody jestli mail laskavě doručí nebo hodí do spamu. Mám vps, které má všechny potřebné údaje správně. Jedna doména pořízená dříve se na google doručuje, druhá doména, nová, leze do spamu. Všechny údaje jsou tam schodné, posílám ze stejného klienta blablabla a prostě spam. Nechápu firmy, že na to klidně přejdou s celou firemní korespondencí. No, alespoň si maj amíci co číst.
-
U e-mailu taky asi nebudeš nic garantovat – může ti shořet server a nebo se admin uklepne a vymaže frontu místo jedné zprávy… to jsou prostě havarijní situace, které můžou nastat. Ale já mluvím o standardním nastavení procesů, o tom, jak naplánuješ, aby to fungovalo – a tady si myslím, že by měl být kladen důraz na spolehlivost: jakmile přijmu e-mail a řeknu, že jsem ho zařadil do fronty pod určitým ID, tak bych ho měl doručit. Přijímat ho nemusím – když mám vážné podezření, že jde o spam, můžu ho odmítnout ještě v rámci SMTP relace a je to fér, odesílatel se dozví o problému hned a ví, na čem je. Pokud už jsem e-mail přijal, měl bych ho doručit do schránky adresáta. Když to automatické filtry vyhodnotí jako spam, tak mohou e-mail označit a ten se pak na základě pravidel (které má uživatel pod kontrolou a ví o nich) může přesunout do složky spam – ale to by měl brát uživatel jen jako pomůcku ve smyslu „stačí když se na to kouknu později“ a ne jako „můžu to klidně všechno smazat nebo to nechat vyhnít“. Hnusí se mi přístup lidí, kteří se vymlouvají na anti-spamové filtry, tvrdí, že něco poslali, i když to neposlali a že se mám podívat do spamu, nebo na druhé straně, že jim nic nepřišlo a že „to asi sežral anti-spam“ nebo „se to někde ztratilo cestou“.
-
Souhlasím, to je velká chyba, které se dopustili návrháři IMAPu. Existuje rozšíření pro Thunderbird, které místo posílání pošty přes SMTP prostě uloží odesílaný mail do správné složky. Pokud si vlastní server tak nastavíš, pak není problém tu poštu odeslat. Ovšem je to velmi nestandardní řešení, i když mě osobně by se líbilo, kdyby bylo všude.
-
No právě. Ale není k tomu důvod. Dřív se pošta četla přímo na serveru v terminálu, takže stačil jen SMTP pro posílání pošty mezi servery. Pak se ale objevily počítače, které nebyly k síti trvale připojené a bylo potřeba vymyslet něco nového. A vymyslela se jen půlka, druhá půlka zůstala.
Takže když se konfiguruje e-mailový klient, musí se konfigurovat dvě samostatné a naprosto nezávislé služby. Přitom řešení máme před sebou. Nikde jinde to tak nefunguje: můj Jabber klient umí jedním kanálem zprávy posílat i přijímat, na telefonování mi taky stačí jeden operátor a jedna SIM.
POP3 je něco jiného, ten neumí s poštou na serveru pracovat, je to jen jednosměrný kanál. IMAP umí klidně mail na server nahrát. Ale servery ho už neumí odeslat.
-
Ivan (neregistrovaný)
IMAP umoznuje aby se server s klientem dohodli na bambilionu ruznych rozsireni vcetne takovych veci jako je vyhledavani a trideni. Odesilani posty by uz mohla byt jen tresnicka na dortu. Rozhodne by to usnadnilo zivot lidem, kteri se pripojuji notebookem do ruznych siti a nemaji moznost pouzivat autentizovane SMTP.
Bohuzel ani DHCP neumoznuje poslat SMTP server jako option.
Nakonec vsichno skonci u web-mailu a problem bude vyresen.
-
Např. u DNS používání místních serverů chápu, je to dobrá distribuovaná databáze.
Ale používat místní SMTP server podle toho, kde zrovna jsem? To považuji za přežitek – chci posílat poštu přes svůj server, kde mám účet, znám otisk jeho TLS certifikátu, můžu mu věřit… Místní SMTP servery by měly smysl leda kdyby všichni šifrovali a podepisovali – pak bych např. při návštěvě v nějaké instituci mohl poslat e-mail přes jejich server a on by se doručil rovnou v místě, aniž by musel jít přes půl světa.
-
H0axZlatý podporovatel
Místní smtp je krávovina od počátku. Nehodlam cpát svý maily nějakýmu troubelovi u kterýho visim na wifi a má "takysíť". Nehledě na to, že cíl by můj mail nevzal protože spf. Kromě toho jsou takový servery věčně na BL a dobře jim tak. Imap odesílání by lidem rozhodně nic neulehčilo. Máš smtp blokovaný v síti, abys neodesílal spam? No tak se blokne i imap a ani tu blbou poštu nestáhneš :-D. Kromě toho můžeš mít jinej smtp a jinej imap/pop server, třeba kvůli balancingu. Není snad pravidlo, že děláme soft, kterej umí jednu věc a dělá jí dobře? Smtp a imap se jaksi rozcházejí ve funkci, pro kterou jsou určeny. Microsoft má exchange, má tam padesát funkcí v jednom a ani jedna nefunguje. Borcí jsou to.
-
Ondřej CaletkaZlatý podporovatel
Ano, proto radši budeme konfigurovat v klientovi dva nezávislé protokoly a dvě nezávislé autentizace kvůli jedné službě. A aby toho nebylo málo, tak až budeme posílat megabajt fotek přes GPRS, počkáme si nejdřív minutu než se pomocí SMTP předají k odeslání a pak další minutu, než se IMAPem uloží do složky Sent. Tomu teda říkám systémové řešení…
-
Cohen (neregistrovaný)
Osobně jsem toho názoru, že shazovat někoho kvůli vlastní neschopnosti podívat se na problém s nadhledem, je řekněme hloupé. Víceméně prezentujete názor, že kritizovat funkčnost čehokoliv existujícího, je nesmysl. Jen si Vás dovolím upozornit na jednoduchou věc - z logického hlediska je naopak nesmyslný systém, kdy jeden mail odesílám 2x, poprvé přes SMTP protokol k doručení a podruhé ho přes IMAP ukládám do cílové složky.
Těžko bychom na internetu hledali něco, co je tak svázáno svou minulostí, jako je mail. A to samozřejmě v negativním slova smyslu. IMAP je toho zářným příkladem. Je to nesmírně komplexní protokol s obrovskou variablitou, takže je v podstatě každá implementace úplně jiná. Interoperabilita IMAP serverů je noční můrou provozovatelů veřejných mailových služeb.
Co se týče MAPI protokolu, vůbec se MS nedivím, že šli vlastní cestou.
-
j (neregistrovaný)
Jeste by bylo fajn, kdyby ta jejich vlastni cesta fungovala aspon s jejich vlastnima vytvorama ... Takovy detail ... pridam uzivatele do AD, a v utlouku ho nekdo vidi hned ... nekdo trebas az za 14 dnu. To potesi ... reseni? Nejspis zadny.
A takovych veci je hafo. Kdyz si zapnu ten "hnusnej a blbej" imap, tak mam na disku par kB dat. Kdyz si zapnu utlouka s tim uzasnym M$ protokolem, tak mam na disku 5GB ... to potesi, specialne u stanic, ktery by z principu mohly bejt bezdiskovy ...
-
Cohen (neregistrovaný)
Pokud si vzpomínám, generuje Exchange dva typy globálních adresních listů, jeden pro online použití, druhý pro offline. Generování každého listu lze nastavit s různou frekvencí. To, který list se použije, je záležitost klienta a aktuálního stavu připojení k serveru. Neříkám, že s tím nejsou problémy, ani se nechci MS nijak zastávat za chyby v implementaci. Jen bych chtěl poukázat na to, že IMAP tuto schopnost nemá.
S porovnáním velikostí se mýlíte, aktuální verze klientů pro oba protokoly běžně poskytují možnost konfigurace stahování položek pro offline použití. A to obvykle na úrovni hlavičky/celé zprávy.
Každopádně bych se tu nerad dostal do role obhájce cesty MS, k tomu mám dost daleko. Jestli jsem si ale dovolil moc kritikou "hnusného a blbého" IMAPu, tak se poníženě omlouvám ;-)
-
Falesnej Lael (neregistrovaný)
Kdyz si neumis pri instalaci Outlooku odskrtnout "cache mode", tak se Ti holt vsechno stahuje na lokal. Za blbost se plati. V tomto pripade 5-ti GB diskoveho prostoru :-).
BTW, stejne se chova i IMAP. Muzes si to nechavat na serveru, nebo stahovat lokalne. Zalezi na tom, zda-li to potrebujes nebo nepotrebujes mit k dispozici offline.
-
j (neregistrovaný)
Zeby to bylo tim, ze mail je navrzen ponekud jinak, nez se aktualne pouziva? On je totiz navrzen presne stejne, jako ... dramaticka pauza .... POSTA.
=> nekde mam svoji prijimaci schranku, do ktere mi postacka vhodi to, co je adresovano me. Ale kdyz chci neco poslat, muzu to vhodit do ... velke prekvapko ... LIBOVOLNE odesilaci schranky.
Jaksi se totiz predpoklada, ze nebudu svuj mail odesilat pres nejaky svuj mailserver na druhym konci planety, ale ze ho poslu pres ten, ktere provozuje ten, ke komu sem zrovna pripojen. A je to tak prave proto, ze se predpoklada, ze spojeni nemusi existovat stale.
-
Cohen (neregistrovaný)
To asi nikdo nerozporuje, jen netuším, co jste tím historickým vhledem chtěl říci.
Kdyby byl kdysi web navržen stejně, jako v klasickém světě fungují časopisy a noviny, asi by to taky nebylo úplně ideální. A posmívání se někomu, kdo by to následně kritizoval, by bylo asi tak stejně oduševnělé, jako Váš příspěvek.
-
Pali (neregistrovaný)
Asi by sa zislo dat do pozornosti tento draft.
IMAP SUBMIT Extension
https://tools.ietf.org/html/draft-kundrat-imap-submit-02 -
Souhlas, bylo by fajn mít jeden protokol pro spojení: e-mailový klient → jeho poštovní server, přes který by se posílalo i přijímalo. A jiný protokol pro spojení jeden server → druhý server. Ale to je celkem jedno – pokud posíláš přes svůj server, tak se máš prokazovat jménem a heslem a server pak nemusí zajímat tvoje IP adresa a reverzní záznamy. A kromě toho je tu RFC 6409 – Message Submission for Mail – a port 587, který je vyhrazený pro tyto účely. Port 25 by pak zůstal čistě pro doručování z jednoho serveru na druhý.
-
Ondřej CaletkaZlatý podporovatel
I u vlastního serveru, na který odesílám pomocí submission mě rozčiluje, že stejná zpráva se posílá dvakrát. A pak mě taky štve kreativita některých lidí, kteří poštu s firemní adresou odesílatele posílají přes svého lokálního ISP a diví se, že není občas spolehlivě doručena.
Přitom aspoň jedna serverová implementace existuje:
http://www.courier-mta.org/imap/INSTALL.html#imapsend
Je škoda, že nedostála nějaké širší implementaci, podle mě je to to správné systémové řešení, jak vzdáleně obsluhovat e-mailovou schránku (což je účel, ke kterému IMAP slouží). Odesílání pošty je přece základní obsluhou takové schránky.
-
dustin (neregistrovaný)
Jo, outbox courieru jsme roky používali ke spokojenosti obchodníků kteří nemuseli řešit SMTP server. Stávající dovecot to sám o sobě neumí (i když obezlička typu http://www.dovecot.org/list/dovecot/2007-April/021457.html není složitá).
Vyřešili jsme to smtp autorizací a maily se posílají přes firemní SMTP server i zvenku. Samozřejmě se může stát, že má síť zablokovaný port 25 ven.
-
Ondřej CaletkaZlatý podporovatel
Samozřejmě se může stát, že má síť zablokovaný port 25 ven.
Právě proto je přesně pro tyto účely normalizována služba Submission, port 587, který by blokován být neměl, resp. jeho blokování nemá pro správce sítě takový význam jako blokování odchozího portu 25. Třeba v Postfixu stačí submission jen odkomentovat v
master.cf. Vedlejším efektem je, že na portu 25 je pak možné zcela zakázat autentizovaný přístup, což trochu překazí plány hádačům hesel. Samotného mě překvapilo, kolik jich chodí hádat hesla na port 25 a jak málo naopak jich zkouší heslo na 587. -
Filip JirsákStříbrný podporovatel
Doufal jsem, že s IPv6 „povinnost“ reverzních záznamů skončí, případně že se přestanou používat úplně. Při tom počtu IPv6 adres stejně nezbývá nic jiného, než aby je vlastník příslušného bloku všem vygeneroval automaticky z IPv6 adresy. K čemu tedy takový záznam bude, když tam bude akorát jinak zapsaná IPv6 adresa?
-
Ondřej CaletkaZlatý podporovatel
Navíc je musí generovat v reálném čase. Nikdo nemá tak velký disk, aby se na něj vešel zónový soubor se všemi možnými záznamy byť jen jediné /64 reverzní zóny.
-
Filip JirsákStříbrný podporovatel
To bych vůbec neřešil, že ho to nepotěší, akorát dostane ochutnat své vlastní medicíny. Na blbý dotaz blbá odpověď, platí to i pro DNS :-)
-
j (neregistrovaný)
Jirsak jirsak, kdybyste si spolecne s caletkou to RFC aspon precetli, ze ...
Reverz se predpoklada pro SERVERY, pripadne pro IPcka, ktera jsou uvedena v DNS (=maji jmeno), v pripade stanic je pak treba dobre mit reverz na IPcku vygenerovanem z MAC adresy (pokud na nej zaroven ukazuje nejaky jmeno) protoze prave a JEN na TETO adrese, lze(realne) provozovat server. Reverz se naopak nepredpoklada u IPcek, generovanych nahodne a vyuzivanych pouze pro odchozi provoz.
V RFC je kuprikladu napsano, ze stanice pouzivajici privacy extension muze stejne nahodne (trebas na zaklade te nahodne IP) generovat PTR zaznam. Muze ... ale nemusi.
-
Filip JirsákStříbrný podporovatel
No jo, jenže Google vyžaduje reverzní záznam pro klienty. Navíc s rozšiřováním IPv6 se bude doufám server (= bude tam nějaká služba čekající na spojení) stávat pomalu z každého zařízení. Takže počet zařízení používaných pouze pro odchozí provoz se bude blížit nule, a ty reverzy stejně nepůjde řešit jinak, než automatickým generováním pro libovolný dotaz. A nebo se někdo chytne za nos, reverzní záznam nebude nikdo vyžadovat a v praxi je budou mít jen směrovače, u kterých to ještě dává nějaký smysl.
-
SB (neregistrovaný)
„...protoze prave a JEN na TETO adrese, lze(realne) provozovat server.“
Asi tomu moc nerozumím, ale vždycky jsem si myslel, že adresa IP je jednoznačným a DOSTAČUJÍCÍM určením zařízení v síti, na kterém si můžu pustit jakýkoliv server, co mě napadne, a systém DNS až jako nepovinná nadstavba nad tím (už z důvodu bezpečnostních problémů). Dle výše uvedené diskuse je třeba mít záznam v DNS, jinak se se mnou nebudou jiné servery bavit. 1. mi to přijde jako porušení síťové neutrality (některé servery jsou si rovnější), 2. v případě řešení spamu jako „security by obscurity“. Uniká mi něco? -
Ondřej CaletkaZlatý podporovatel
Už dnes něco takového je možné, přinejmenším pomocí PowerDNS a jeho rozmanitých backend pluginů. Ale samozřejmě je potřeba on-line podepisování, což třeba Knot bude mít zanedlouho.
On-line podepisování není žádné zlo, v podstatě všechny ostatní šifrované služby tak fungují (aspoň TLS a SSH). Výhodou DNSSECu je, že je ho možné provozovat i v režimu off-line podepisování. Ale pokud nejste zrovna správce TLD s klíči v HSM a s HSM v trezoru, prakticky si off-line podpisováním bezpečnost moc nezlepšíte.
-
benghi (neregistrovaný)
1. Podpora IPv6 v rámci provozovatelů smtp serverů je žalostná. Stav jsem zkoumal na začátku roku 2012 a prakticky neexistoval větší freemail, který by IPv6 na úrovni smtp podporoval. Bohužel. V oblasti placených e-mailových služeb to bylo podobné. Testy jsem od té doby neopakoval, nevidím doteď náznaky toho, že by se situace nějak zásadně změnila.
2. Vzhledem k 1 lze nasazení IPv6 na gmailu považovat svým způsobem za referenční.
3. Reverzní záznamy nemá spousta IPv4 adres. O tom jsem se bohužel přesvědčil na vlastní kůži, za což vděčím panu j a jeho stupidnímu trolování. Ano, nedělá to jen na rootu, dělá to všude. Je psychopat, baví ho ponižovat lidi, což je vzhledem k jeho "nevirtuální" pozici ve společnosti pochopitelné. Nechápu jeho přístup, je vysoce inteligentní člověk, schopný psycholog by mu dokázal pomoci.
4. Přirovnání smtp k poštovní schránce je trefné. Skutečně to tak bylo míněno, ale tahle možnost umřela kvůli spammerům, čili takhle se to už nikdy používat nebude. Pamatuju doby kdy to šlo, ale skončily definitivně kolem roku 2006, občasná neprůchodnost přes spamfiltry je mezi námi u tohoto řešení déle jak 10 let.
5. MAPI není jediný protokol, který umí přijímat i odesílat. Dalším je WL2K, což je dost specifická záležitost. SMTP je pekelná a zaostalá věc, když to porovnám s FBBvB2, jenže je jediná nad tcp/ip. Možná by to chtělo vyvinout něco nového. Od základu.
6. IMAP send nemá a nepotřebuje. Pouze spravuje složky a jejich obsah na dálku. Použití nad něčím jiným než lokální sítí nikdo nečekal. Spíše je otázka, zda má klient komunikovat s smtp serverem. To je imho pitomost. Imap je v tomhle ohledu noveloidní, s jeho pomocí nacpete mail do složky "k odeslání" kde si jej chytne smtp server, začlení do vlastní odesílací fronty a přesune jej do složky "odeslané". Implementace vypadá jinak. To ovšem není problém protokolu, ale jeho implementace.
7. Adresní prostor IPv6 je obrovský a razíme teorii, že bude z větší části nevyužitý. Používání reverzního záznamu má ty části odlišit. Je to porušení síťové neutrality a imho je to navíc blbej nápad, který bude google muset časem přehodnotit.
ČLÁNKY DO MAILU