Názory k článku
Jak z příkazové řádky ověřit adresu bez poslání e-mailu
-
Pali (neregistrovaný)
A stále to nebude fungovať. V DNSke sú akurát tak záznamy vedúce k MTA serveru, ktorý vôbec nemusí mať ani páru o tom, aké adresy cieľový SMTP server po ceste prijme či zahodí... Na bouncy sa akosi pozabudlo, že? Ako som už písal, to že gmail je výnimka ešte neznamená, že takto sa správajú všetky emailové servery.
-
slovensky expert (neregistrovaný)
Tjn, ked aj v CR sa casto blokuje pristup priamo na TCP port 25 mimo siete providera (tusim UPC?).
Radsej nehovorim o kolejnej sieti, odkial nejde pristupovat na cudzie TCP porty 25, 465 a niekedy neslo ani 587, lebo priamy pristup k cudziemu SMTP robia iba spammeri. Je odporucane pouzivat kolejne SMTP, ktore to posle v mene odosielatela, ale to dobre nefunguje so SPF a DKIM.Kapitola sama o sebe je pristup na port 53 (TCP/UDP) mimo dva urcene DNS servery providera. To tiez vyuzivaju iba zli hackeri a je treba to transparentne presmerovat k ISP alebo rovno zatrhnut.
Internet nie je to, co byval, ze vsetko fungovalo hned po nastaveni.
-
Filip JirsákStříbrný podporovatelTo, že protější strana odpoví OK na RCPT TO, ještě neznamená, že e-mail existuje. A dneska ani negativní odpověď nemusí znamenat, že adresa neexistuje – administrátoři poštovních serverů jsou velmi vynalézaví v odmítání e-mailů pod záminkou boje proti spamu.
-
Filip JirsákStříbrný podporovatel
Když ověřujete existenci e-mailové adresy, připojujete se na cílový server (tam, kde by měla existovat schránka k té adrese). Ten server samozřejmě musí pro příslušnou doménu přijímat e-maily bez přihlášení – když posíláte e-mail na user@example.com, neznáte žádné přihlašovací údaje k serveru example.com.
-
Zero (neregistrovaný)
Vidim ze tebe nepomoze ani ta transplantacia...
Tu mas par linkov na SASL:
http://asg.web.cmu.edu/sasl/
https://tools.ietf.org/html/rfc4422
http://www.postfix.org/SASL_README.html
Odporucam hlavne tento mas tam aj priklad ako prebieha autentifikacia na SMTP:
https://www.gnu.org/software/gsasl/manual/html_node/SASL-Overview.html -
Adam KaliszStříbrný podporovatelMohl byste prosim Vase nazory nejak konstruktivne podlozit? SASL je opravdu metoda autentizace. Sam telnet prihlasovani pri testovani jinych portu nepotrebuje, ale pokud sluzba nejake overeni identity, nebo login vyzaduje, tak jste i s telnetem namydleny. Nebo to chapu spatne? Kde je chyba?
-
Filip JirsákStříbrný podporovatel
Když někam posíláte e-mail, cílový server po vás nemůže chtít ověření. Představte si, že teď najdete zajímavé zboží v nějakém e-shopu, kde jste nikdy dříve nenakupoval. A budete jim chtít poslat e-mailem nějaký dotaz. Server e-shopu přeci po vás nemůže chtít žádné přihlášení – nikdy jste s ním neměl nic společného, teď posíláte první e-mail, takže nemáte žádné jméno a heslo, kterým byste se prokázal.
Jméno a heslo použijete v okamžiku, kdy nějakému serveru předáváte e-mail, aby ho vaším jménem odeslal. Protože k tomu serveru máte nějakou vazbu – je to server vašeho poskytovatele připojení nebo server, který hostuje vaši e-mailovou schránku.
-
Adam KaliszStříbrný podporovatel
Děkuji za osvětlení, jak to myslíte.
Samozřejmě, že login v takovém případě ani já, ani server přeposílající mým jménem, nebude mít. Ověření identity, což je součást autentizace, ale do jisté míry možné je na základě např. certifikátu vydaného nezávislou autoritou. Aspoň tak jsem SASL z velmi krátkého čtení pochopil. -
Filip JirsákStříbrný podporovatel
Ne, SASL se používá pouze při komunikaci mezi "hloupým klientem" (to je terminus technicus), třeba Outlookem nebo Thunderbirdem, a serverem, který pro toho hloupého klienta zprostředkovává odesílání.
Autentizace vůči cílovému serveru je také možná, ale používá se to jen pár let jako ochrana proti spamu. A není to autentizace uživatele, ale serveru - ověřuje se, že má právo odesílat e-maily z dané domény. Ověřuje se to buď přes SPF (zda daná IP adresa má právo odesílat z dané domény), nebo přes DKIM (že daný server má privátní klíč, který se kterým je spojeno právo odesílat z dané domény).
Certifikační autorita se také může použít, ale ta se nepoužívá k ověření odesílající strany, nýbrž k ověření příjemce (cílového serveru). Odesílající strana si podle certifikátu ověří, že e-mail předává správnému cílovému serveru a ne někomu, kdo se za něj jenom vydává. Je to stejný princip, jako u HTTPS, kdy si podle certifikátu ověříte, že komunikujete skutečně se serverem své banky a ne s útočníkem, který z vás chce vylákat přihlašovací údaje.
-
Adam KaliszStříbrný podporovatel
Díky za vyčerpávající objasnění situace. Kéž by takhle někdo "polopatě" přednášel.
-
Pokud se email posílá z nějakého desktopového klienta tak se to běžně připojuje k jednomu "odesílacímu" smtp serveru (věčinou vyžaduje přihlášení) ten zprávu přijme, najde cílový "příjmací" smtp server a pošle ho tam.
Protokol je ale stejný smtp, takže ten "odesílací" smtp se dá obejít a spojit se přímo z cílovým smtp a takto to funguje. -
Filip JirsákStříbrný podporovatel
Jenže tady server e-mail jenom přijímá (resp. na samotný e-mail ani nedojde). Odeslání simuluje člověk ručně telnetem nebo netcatem.
-
Ano, opravdový zástup odborníků tu je :)
Samozřejmě, pokud je na serveru graylisting, vyhodí nás s chybou, o tom žádná.
Pokud je server jen tupý forwarder, neověříme schránku, ale tak maximálně doménu, to je taky pravda.
Další věc je, že pokud je v doméně doménový koš, existenci schránky taky neověřime.
Ale s tím se musí počítat, metoda prostě není stoprocentní, lepší stejně neexistuje. Spousta mailserverů je nastavena podobnými odborníky, kteří se tu vyjadřují a ti dokáží být velmi kreativní. Server klidně může příjmat maily pro neexistující uživatele a strkat je do /dev/null, aniž by to odesílateli oznámil ("skvělá" ochrana soukromí, aby nikdo nevěděl, který adresy existují) a vymyslet se dá cokoliv.
Co se týká šifrování, sice je to mezi SMTP servery možné, ale myslím si, že si ještě nikdo nedovolí zahazovat nešifrovaná spojení, protože je prostě moc serverů, který to nepoužívají. -
BobTheBuilderStříbrný podporovatelNení to tak jednoduché, jsou experti, co SMTP/SSL (port 465) odmítnou, pokud nedůvěřují certifikační autoritě, která vystavila certifikát vašeho serveru. Takže žádný self-signed certifikát a ani certifikát vystavený vaší vlastní certifikační autoritou.
-
j (neregistrovaný)
To je jejich problem, s takovejma idiotama se nebavim. Anzto a jelikoz klic u smtp sice muze byt pouzit k autorizaci protistrany, ale to se pak uz rozhodne nebavime o verejnym mailserveru. Nehlede na to, ze kdyz uz, tak DANE. Protoze v tom pripade drzitel domeny zcela jasne deklaruje zamer, ze si nepreje, aby se nekdo bavil se serverem, kterej se podepisuje jinym nez uvedenym klicem.
BTW: Mimo jiny presne tak funguje de-mail, zcela standardni mta, ktery se autorizuje vuci ostatnim svym klicem. A tim se vytvari uzavrena mailova sit, ktera garantuje parametry dorucovani - coz ve verejny siti nelze.
Jo a BTW2: 99,9% MTA udela to, ze pokud se z libovolnyho duvodu nepovede doruceni pres ssl, dorucej to nesifrovane. I proto je naprosta kokotina jakkoli resit certifikaty - sou urceny vyhradne k vytvoreni p2p ssl kanalu. Ne k overovani.
-
Filip JirsákStříbrný podporovatel
Pokud důvěřujete každému certifikátu, je tam ten certifikát na dvě věci. Autoři SMTP TLS jaksi očekávali, že když už se něco zabezpečuje, má se to udělat pořádně. "Expert" je spíš ten, kdo takový certifikát na server nasadí - protože je to jen pseudozabezpečení, které nechrání prakticky proti ničemu (každý, kdo má reálně šanci spojení poslouchat, má reálně možnost přesměrovat ho na sebe). Zvlášť v dnešní době, kdy můžete mít certifikát od Let's Encrypt zdarma.
-
Filip JirsákStříbrný podporovatel
Nikdo vás nenutí certifikátům WoSign důvěřovat. (Teda pokud nepoužíváte Firefox.)
-
Lol Phirae (neregistrovaný)
Jistě. Nebo certifikátům od Comodo, StartComu, DigiNotar, Turktrust nebo dalších desítek snake-oil CA, které sice taky validují leda velký hovno, ale to nás přece nemůže odradit od toho, abychom jim defaultně důvěřovali, protože tak to je správné a tak to musí být. Fuj self-signed certifikáty, to by tak hrálo aby si lidi něco ověřovali přes DNS a vystavovali si to sami podle potřeby.
-
BobTheBuilderStříbrný podporovatel
To je poněkud přímočará a nepříliš spolehlivá metoda. Obvykle narazíte na 2 potíže:
1) přímé spojení na port 25 bývá pro klientské počítače blokováno (aby hacknuté počítače v síti nemohly rozesílat spamy), klienti odesílají přes port 587/STARTLS s autentizací
2) pokud toto omezení nemáte, cílový server nemusí odmítnou neexistující adresu - buď ji ani nezná (děla jen interní relay *), nebo odmítnutí odloží, aby nesloužil pro directory harvesting (tedy hledání platných loginů pro případný další hackerský útok).
*) typicky postfix+spamassasin předřazený před exchange server -
Tomas (neregistrovaný)
V zasade ti, co hovoria, ze to nemoze vobec fungovat alebo funguje len obcas maju pravdu. Graylisting a zahadzovanie neskor v local delivery faze to pokazi.
Vseobecne clanok je uplne zbytocny. Takymto sposobom clovek nezisti nic a tak ako je to opisane je to do takej miery nespolahlive, ze vysledok nie je mozne pouzit podla mna na nic.
V celej diskusii ale neodznela jedna velmi dolezita veta: pre admina je lepsie (v boji proti spamu) zahodit toho co mozno najviac este vramci smtp dialogu. V tom case je to z pohladu zdrojov najlacnejsie. Cize dost vela ludi ked moze posle na rcpt to hard error a necaka na content filtre za tym.
-
j (neregistrovaný)
Sak taky proto se rovnou strili komunikace stema mamlasama, co si ani neumi nastavit reverz v dns. 90% spamu mi skonci na tomhle jedinym pravidle(bavime se o desitkach tisic denne). Jo, jasne, koncej na tom i nektery "regulerni" maily, ale jak rikam, pokud chce nekdo jezdit na silnici, potrebuje auto co proslo technickou, pokud mi chce nekdo posilat maily, potrebuje administratora s aspon jednou mozkovou bunkou. Pokud mu to nestoji za tech 10s prace s nastavenim DNS, tak ho s naprostym klidem hodim do stoupy.
Vyhoda tohodle je, ze ho odstrelis hned, jak se pokusi navazat spojeni, takze k nejakymu zjistovani mailu se samo vubec nedostane.
