Posílali jste v dávných dobách e-mail z příkazové řádky přímo komunikací se SMTP serverem? Stejnou metodu lze jednoduše použít, když chcete zjistit, jestli nějaká adresa na serveru existuje. Přitom ale nechcete žádný e-mail poslat.
Nejprve pomocí dig zjistíte adresu SMTP serveru a potom se s ním spojíte pomocí netcat nebo telnet na portu 25. Dále postupujete podle detailního návodu.
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.
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.
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.
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
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.
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.
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.
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.
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í.
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.
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.
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.
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
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.
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.
ČLÁNKY DO MAILU