classic.ISPforum.cz

Dobry den, mam dotaz.

Resim jeden problem u zakaznika.

Zakaznik ma hotel kde ma nejake bezdratove pripojeni pomoci mikrtoika. Ma udelano na tom hotelu, ze se muzou pripojovat lidi bezdratove a zadarmo.
Problem je ten ze zakaznici nemuzou odesilat maily, protoze provider ma svuj smtp server. Takze aby mohli poslat mail museli by si nastavit jeho smtp server.
Jenze nektery nevi co a jak.

Jde to nejak nastavit tak, ze ikdyz maji nastaveny smtp npr. seznamu to nejak smerovalo na smtp toho providera?

Priklad. ja sem zakaznik, mam outlook kde mam nastaveny smtp smtp.seznam.cz port 25 . Ted mail neodeslu, protoze bych si to musel zmenit na smtp.neco.net. nevim jak to zmenit takze neodeslu nic.

Jesli jde na Mk nastavit vse co prijde na port 25 slo na smtp providera.

Zkousel jsem nastavit ve firewall nat nastavit chain dstnat protokol tcp port 25 action dst-nat to adress ip smtp providera port 25

to nefunguje.

Dekuji moc za radu jak to vyresit

vlastním DNS...

vyzaduje tam ten ISP nejakej login pro smtp ?

reset píše:vyzaduje tam ten ISP nejakej login pro smtp ?

A taky bude problem, pokud ti klienti se neautentizovanemu SMTP budou snazit cpat nejaka hesla.

pokud to nejde redirectem , tak asi jedine postavit vlastni smtp a poustet to pres toho pred tebou.
Nebo idealne pres jiny externi smtp server

soooc píše:

reset píše:vyzaduje tam ten ISP nejakej login pro smtp ?

A taky bude problem, pokud ti klienti se neautentizovanemu SMTP budou snazit cpat nejaka hesla.

Vhodnou konfigurací postfix+sasl (na nějakém linuxu) funguje smtp bez autorizace i s libovolnou autorizací (právě pro přesměrování je to ideální, protože to odešle email i z libovolného pošťáka, kde má uživatel nastavenou autorizaci - lze to nakonfigurovat tak, že SMTP prostě zkousne libovolnou autorizaci a klientovi se hlásí, že podporuje autorizaci - nutné pro Outlook 2007+ s autorizací na smtp a možná i jiné pošťáky), takže při použití vlastního smtp to není problém.

marvel píše:

soooc píše:

reset píše:vyzaduje tam ten ISP nejakej login pro smtp ?

A taky bude problem, pokud ti klienti se neautentizovanemu SMTP budou snazit cpat nejaka hesla.

Vhodnou konfigurací postfix+sasl (na nějakém linuxu) funguje smtp bez autorizace i s libovolnou autorizací (právě pro přesměrování je to ideální, protože to odešle email i z libovolného pošťáka, kde má uživatel nastavenou autorizaci - lze to nakonfigurovat tak, že SMTP prostě zkousne libovolnou autorizaci a klientovi se hlásí, že podporuje autorizaci - nutné pro Outlook 2007+ s autorizací na smtp a možná i jiné pošťáky), takže při použití vlastního smtp to není problém.

Ano, nerikam, ze to je nemozne, jen upozornuju, ze je treba i zde hledat

soooc píše:

marvel píše:

soooc píše:A taky bude problem, pokud ti klienti se neautentizovanemu SMTP budou snazit cpat nejaka hesla.

Vhodnou konfigurací postfix+sasl (na nějakém linuxu) funguje smtp bez autorizace i s libovolnou autorizací (právě pro přesměrování je to ideální, protože to odešle email i z libovolného pošťáka, kde má uživatel nastavenou autorizaci - lze to nakonfigurovat tak, že SMTP prostě zkousne libovolnou autorizaci a klientovi se hlásí, že podporuje autorizaci - nutné pro Outlook 2007+ s autorizací na smtp a možná i jiné pošťáky), takže při použití vlastního smtp to není problém.

Ano, nerikam, ze to je nemozne, jen upozornuju, ze je treba i zde hledat

jj, u vlastního smtp a přesměrování klientů na něj je to dnes prakticky nutnost, protože Outlook2007+ se při odesíláním s autorizací prostě odmítne připojit na smtp server, který mu při připojení nepotvrdí, že přijímá autorizaci Nižší verze Outlooku s tím problém neměly. Nevím jak u jiných pošťáků, řešil jsem to kvůli Outlookům, ale mám dojem, že většina ostatních toto nevyžaduje.

moje SMTP hlásí toto (na telnetu) a přijme+odešle cokoliv (s i bez autorizace. pozn. v logu se v případě autorizace objeví login ):
EHLO localhost
250-xxxxxxxxxxx (adresa smtp serveru)
250-PIPELINING
250-SIZE 12582912
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

nevim co tady řešíte, normálně bych udělal co jsem psal a to že to přeložím na DNSKu, prostě smtp.seznam.cz se bude rovnat mému smtp tečka. pokud neumí někdo nastavit přihlašování s heslem tak nemá co dělat u pcčka

těžko napíšeš do dns všechny smtp servery světa.

marvel píše:jj, u vlastního smtp a přesměrování klientů na něj je to dnes prakticky nutnost, protože Outlook2007+ se při odesíláním s autorizací prostě odmítne připojit na smtp server, který mu při připojení nepotvrdí, že přijímá autorizaci Nižší verze Outlooku s tím problém neměly. Nevím jak u jiných pošťáků, řešil jsem to kvůli Outlookům, ale mám dojem, že většina ostatních toto nevyžaduje.

Informativně, jak řešíš, pokud je použito NTLM nebo GSSAPI na původním serveru? Nebo to také bereš to tak, že tito mají smůlu (je jich minorita)?
Což u firemního sektoru se občas vyskytuje místo PLAIN/LOGIN. Pro klasické LOGIN/PLAIN metody to jde odrbat jak píšeš.
A asi je to stejně zastaví na STARTTLS, protože asi těžko předložíš certifikát, který bude podepsán tak, aby to klient bez řvaní spolknul (a pak záleží na politikách, zda uživatel vůbec bude mít dovoleno dát pokračovat).
A když tu poštu pošle na tvůj server, tak je další věc, co s tím udělají případné cílové servery v návaznosti na SFP/DS a podobné. Může to v závislosti na konfiguraci takový mail přímo v tichosti zlikvidovat. Je pak sranda, když musím managorovi vysvětlovat, že těch 100 mailů, co napsal za víkend na hotelu a rezeslal lidem, bylo někde pozahazováno, protože přišly odjinud, než měly (nepřišly z smtp serveru jeho firmy, což mají deklarováno jako jediný možný zdroj mailu).
Ideální není ani jendo (ať už zkusit násilím to přesměrovat na sebe nebo ho natvrdo zaříznout a zdar).
Bohužel doporučené řešení, že přijmající SMTP server pro příjem dat od MUA má sedět na portu 587 a 25 slouží jen pro MTA-MTA přenos je hezké, ale v praxi se zatím moc neujalo (a to pomíjím, že starší Outlook verze s tím mají těžké problémy, pokud je něco jiného, než 25 nebo 465, který by vlasntě měl být dle rfc pořádku mrtvý, ale kvůli Outlookům to nejde).

okoun píše:nevim co tady řešíte, normálně bych udělal co jsem psal a to že to přeložím na DNSKu, prostě smtp.seznam.cz se bude rovnat mému smtp tečka. pokud neumí někdo nastavit přihlašování s heslem tak nemá co dělat u pcčka

a co tim docilis? ... rekl bych ze nic , bude neco to same jako redirect , jen pracnejsi , postu si ale stejne neodesles (v tomto pripade viz zadani)

Manipulovat sDNS pro tento případ je sebevražda.
Viz původní zadfání je ssi i klíčová otázka, co znamená to:

"Zkousel jsem nastavit ve firewall nat nastavit chain dstnat protokol tcp port 25 action dst-nat to adress ip smtp providera port 25"

Chtělo by to rozvést. Co to nefunguje znamená. Protože by to fungovat mělo, pokud daný ISPík nevyžaduje z vlastní sítě nějaké specifické ověření (pokud klient se nebude snažit vnutit přihlášneí vlastní, případně bazírovat na správném certifikátu pro TLS atd).

Majklik píše:

marvel píše:jj, u vlastního smtp a přesměrování klientů na něj je to dnes prakticky nutnost, protože Outlook2007+ se při odesíláním s autorizací prostě odmítne připojit na smtp server, který mu při připojení nepotvrdí, že přijímá autorizaci Nižší verze Outlooku s tím problém neměly. Nevím jak u jiných pošťáků, řešil jsem to kvůli Outlookům, ale mám dojem, že většina ostatních toto nevyžaduje.

Informativně, jak řešíš, pokud je použito NTLM nebo GSSAPI na původním serveru? Nebo to také bereš to tak, že tito mají smůlu (je jich minorita)?
Což u firemního sektoru se občas vyskytuje místo PLAIN/LOGIN. Pro klasické LOGIN/PLAIN metody to jde odrbat jak píšeš.
A asi je to stejně zastaví na STARTTLS, protože asi těžko předložíš certifikát, který bude podepsán tak, aby to klient bez řvaní spolknul (a pak záleží na politikách, zda uživatel vůbec bude mít dovoleno dát pokračovat).
A když tu poštu pošle na tvůj server, tak je další věc, co s tím udělají případné cílové servery v návaznosti na SFP/DS a podobné. Může to v závislosti na konfiguraci takový mail přímo v tichosti zlikvidovat. Je pak sranda, když musím managorovi vysvětlovat, že těch 100 mailů, co napsal za víkend na hotelu a rezeslal lidem, bylo někde pozahazováno, protože přišly odjinud, než měly (nepřišly z smtp serveru jeho firmy, což mají deklarováno jako jediný možný zdroj mailu).
Ideální není ani jendo (ať už zkusit násilím to přesměrovat na sebe nebo ho natvrdo zaříznout a zdar).
Bohužel doporučené řešení, že přijmající SMTP server pro příjem dat od MUA má sedět na portu 587 a 25 slouží jen pro MTA-MTA přenos je hezké, ale v praxi se zatím moc neujalo (a to pomíjím, že starší Outlook verze s tím mají těžké problémy, pokud je něco jiného, než 25 nebo 465, který by vlasntě měl být dle rfc pořádku mrtvý, ale kvůli Outlookům to nejde).

Pokud používáš "extra" vylepšení smtp a hodně cestuješ, tak se především ve firemním segmentu předpokládá použití vpn, toto má řešit běžné případy použití smtp. S SPF jsem se náhodou setkal až nedávno, kdy jedna firma odmítala řešit emaily z domén které nemají SPF anebo kde se liší zadaná ip (jinak řečeno hrozně chytrý admin, který si něco přečetl a naklikal to do nějakého windows serveru), jinak asi nevím, kdo by SPF používal. Naopak ale vím, že drtivá většina mailových serverů používá různé black listy, a pustit (speciálně na volném hotspotu) 25 port volně téměř jistě znamená mít danou ip běhěm několika málo dnů (případně hodin) na nějakém blacklistu Nejlepší ochranou proti zablacklistovaní se mi osvědčil vlastní smtp, kde si to pohlídám. Zkoušel jsem i různé pravidla v mikrotiku (počet konekcí na 25 apod), ale výsledek nebyl nijak oslnivý, spousta toho prošlo.

Majklik píše:Manipulovat sDNS pro tento případ je sebevražda.
Viz původní zadfání je ssi i klíčová otázka, co znamená to:

"Zkousel jsem nastavit ve firewall nat nastavit chain dstnat protokol tcp port 25 action dst-nat to adress ip smtp providera port 25"

Chtělo by to rozvést. Co to nefunguje znamená. Protože by to fungovat mělo, pokud daný ISPík nevyžaduje z vlastní sítě nějaké specifické ověření (pokud klient se nebude snažit vnutit přihlášneí vlastní, případně bazírovat na správném certifikátu pro TLS atd).

Přesně tak, to by zcela jistě mělo fungovat, ale jak říkáš, kdoví, co má na svém smtp nastaveno ISP. Ještě bych překotroloval zda mají na daném hotelu správně nastavený firewall a maškarádu, resp. jestli tam není nějaká chyba/překlep.