Dotaz: Re:Jak posílat e-maily přes MS Exchange?

[googler]

Ahojte, prosim Vas, riesim taku zapeklitu situaciu: Firma vyuziva primarne relativne klasicky web a email hosting (IMAP / SMTP), ale niektori zamestnanci potrebuju mat synchronizovany kalendar medzi MS Outlook (Windows) a mobilnymi zariadeniami - Vcetne moznosti odosielat emaily o polozkach v kalendari priamo cez funkcie kalendara aj mimo vlastnej domeny.

Moja predstava bola / je nasledovna:

- V MS adminovi:

- vytvorim Exchange Online konta pre dotknutych zamestnancov

- V kazdom exchange konte nastavim preposielanie prijatej posty na prislusne IMAP konto

- Doménu v MS adminovi nastavim ako internal relay

- V globalnych DNS domeny:

- MX zaznamy necham odkazovat tak ako teraz, teda na hosting

- Do SPF zaznamu k aktualnemu hostingu doplnim aj Exchange server

- DMARC zaznam necham tak ako je

- Podla instrukcii v MS adminovi vytvorim dva nove CNAME DKIM zaznamy s tym, ze ponecham aj povodny

Vysledkom tychto nastaveni by malo byt to, ze odosielanie by fungovalo z hostingu aj z Exchange kont a to bez toho, aby zabludili do SPAMu, prave vdaka DKIM a SPF.

Ked sme spravcu hostingu (jedna sa o mensi, neverejny hosting) poziadali o pridanie DKIM zaznamov, bolo nam dorazne odporucane, aby sme to nerobili lebo DKIM zaznamy su viazane na celu domenu ako taku a museli by sme zmenit aj MX zaznamy na MS cize by cela firma musela emaily migrovat do MS.

Chcem sa spytat: Bol moj predpoklad od zaciatku zly a je standard, ze DKIM zaznamy su viazane na celu domenu a nie je mozne vytvorit viacero DKIM zaznamov, aby niektore smerovali na MS a ine na hosting a teda aj vo vseobecnosti plati tvrdenie spravcu hostingu alebo je to nejake jeho specifikum pricom na inom beznom standardnom hostingu by to fungovalo presne za ucelom toho, aby bolo mozne emaily odosielat z dvoch roznych serverov?

Dakujem

Odpovědi

[Ignotus]

DKIM záznamy "nesmerujú" na rôzne MX servery, ale sú v nich uložené verejné kľúče. V rámci jednej domény ich môže existovať niekoľko, ale určite sa vyhni duplicitným záznamom. Najlepšie by bolo použiť nejaký identifikátor pre ich rozlíšenie, napríklad:

default._domainkey.example.com

calendar._domainkey.example.com

Upozorňujem, že kvôli prípadnej rotácii kľúčov je lepšie zvoliť nejaký rozumnejší identifikátor, ale to závisí od možnosti kalendárového servera: calendar202608._domainkey.example.com

Overovanie funguje tak, že odosielajúci server pred odoslaním podpíše správu svojím privátnym kľúčom. Súčasťou podpisu je aj informácia, ktorý kľúč pritom použil (zjednodušene povedané). Prijímajúci server si daný RR vyhľadá v DNS a overí, či podpis sedí.

MX záznamy slúžia ako informácia pre ostatné servery, kam posielať poštu pre konkrétnu doménu, nemôžem ale vylúčiť príliš kreatívny výklad zo strany administrátorov toho-ktorého MX.

SPF samozrejme musí obsahovať aj záznam pre kalendárový server, ale toho si si zjavne vedomý :)

K detailom ohľadne nastavenia v MS adminovi sa vyjadriť nedokážem, dúfam že pomôže aspoň toto.

[googler]

takze je moj predpoklad spravny a za beznych okolnosti v "normalnom" hostingu je mozne odosielat postu z viacerych serverov bez problemov s tym, ze MX zaznam by odkazoval iba na jeden z nich a to ten, ktory ma za ulohu zaroven aj prijimat postu. Za normalnych okolnosti by to teda malo fungovat korektne bez toho, aby posta padala do SPAMu alebo boli nejake ine problemy. Chapem to spravne?

[Ignotus]

takze je moj predpoklad spravny a za beznych okolnosti v "normalnom" hostingu je mozne odosielat postu z viacerych serverov bez problemov s tym, ze MX zaznam by odkazoval iba na jeden z nich a to ten, ktory ma za ulohu zaroven aj prijimat postu.

Áno, s týmto naozaj nie je žiaden problém - máš skrátka viacero TXT záznamov v DNS, "normálny" MX podpisuje jedným kľúčom, kalendárový druhým. Len sa vyhni duplicite v názve, tam to bude spôsobovať problémy - ak by obidva servery používali kľúč s identickým názvom a rôznym obsahom, bude sa to správať nepredvídateľne.

Prípadne ak má prevádzkovateľ konkrétny príklad, akým spôsobom to blbne, napíš to sem.

Za normalnych okolnosti by to teda malo fungovat korektne bez toho, aby posta padala do SPAMu alebo boli nejake ine problemy. Chapem to spravne?

No, teoreticky - ak to do SPAMu nepadá ešte kvôli niečomu inému ...

[googler]

Takze v pripade bezneho hostingu je jednoducho blbost to stanovisko, ktore dal spravca "svojskeho" hostingu, ze to, ze by sa do DNS domeny pridali CNAME DKIM zaznamy Microsoftu, tak sa musia zmenit aj MX zaznamy na Microsoft a bla bla bla... Inak tie DKIM zaznamy sposobia problem. Proste taketo spravanie by bolo specifikum toho konkretneho hostingu a na vacsine standardnych "profi" hostingov by takto nastavene DKIM a MX zaznamy nesposobili takyto problem?

[Ignotus]

taketo spravanie by bolo specifikum toho konkretneho hostingu a na vacsine standardnych "profi" hostingov by takto nastavene DKIM a MX zaznamy nesposobili takyto problem?

Netrúfam si určiť hranicu medzi "profi" a "neprofi" hostingom, každopádne pridať DKIM záznam (či už ako TXT alebo CNAME) nie je problém. Vlastne to ani nemá čo rozbiť, keď dodržíš to čo som písal vyššie (nesmú sa zhodovať selektory, to je tá časť pred _domainkey) - prijímajúci server si zo správy "vytiahne", ktorý podpis bol použitý a až následne správu overí cez DNS (zjednodušujem to, ale v tejto chvíli riešim operácie a ich poradie, nie detailný popis overovania). Do zóny si tých záznamov môžeš vygenerovať "milión".

[googler]

Este doplnim: Prevadzkovatel este nema priklad akym sposobom to blbne pretoze my sme zatial "neprelomili" jeho dorazne odporucanie, aby sme DKIM nepridavali lebo to sposobi problemy a ani to pretlacat asi nebudeme lebo to nie je uplne standardny profi poskytovatel a skor to vidim tak ze ani on sam tomu uplne nerozumie a boji sa toho. Po tomto jeho upozorneni sa obavam toho, ze aj keby to nahodou takto mohlo fungovat aj na jeho hostingu, obavam sa, ze by to mohol sabotovat, aby potom nevyzeral ako... Ta firma, ktora ten hosting vyuziva totiz nema pristup k editacii dns, vsetko to riesi poziadavkami na cloveka z toho hostingu, ktory to interne realizuje. Mne islo skor o to, aby som si tu overil ci mne unika nieco podstatne alebo skor bude "problem" na strane toho konkretneho hostingu a nie vseobecne.

[Ignotus]

skor to vidim tak ze ani on sam tomu uplne nerozumie a boji sa toho. Po tomto jeho upozorneni sa obavam toho, ze aj keby to nahodou takto mohlo fungovat aj na jeho hostingu, obavam sa, ze by to mohol sabotovat, aby potom nevyzeral ako...

Ak mám byť úprimný - nikto z nás nepadol učený z neba. Nemôžem hovoriť za všetkých, ale na otázku "nie som si istý, či tomu rozumiem dobre" snáď nikto rozumný nebude reagovať štýlom "ty si ...".

[googler]

Ano samozrejme, osobne by som tiez nemal nic proti nemu, ak by sa ukazalo, ze sa mylil a cele to normalne funguje,nemal by som voci nemu ziadnu negativnu emociu (ved sam som tu dokazom, ze vsetci sa ucia). Na druhu stranu, uz som v zivote zazil aj takych ludi, ktori o nejakom rieseni tvrdili, ze fungovat nebude a fungovat bude len to ich a ked sa ukazal opak, tak sa to snazilivsetkymi moznymi sposobmi znegovat pretoze to vnimali tak, ze by pred klientom / sefom, vyzerali hlupo v porovnani "s konkurenciou" a podobnych situacii som zazil viac, hlavne v pripade IT freelancerov

[X]

.. DKIM zaznamy su viazane na celu domenu ako taku a museli by sme zmenit aj MX zaznamy..

Rekl bych, ze na hostingu nemaji pravdu. Odesilajici server MX zaznam mit nemusi a Je uplne normalni, ze se posta odesila, nebo prijima z nekolika ruznych serveru.

[googler]

Tiez si myslim presne to iste, len som to chcel mat potvrdene, idealne od niekoho kto sa v tom pohybuje

[Max]

Každá doména může mít kolik DKIMů chceš. V rámci podpisu se předává název selectoru, takže můžeš mít jednu doménu na jednom hostingu, kde máš DKIM definovaný v dns pomocí selectoru třeba "mail", pak posíláš maily třeba z webu, kde také podepisuješ emaily, ale jiný systém, jiné řešení, jiný privátní klíč pro dkim, takže i jiný dkim klíč, tj. pak si nastavíš pro toto posílání selector třeba mail2 atd. Syntaxe je [selector]._domainkey.[your-domain.com]

Každopádně všechny podobné workaroundy vedou k tomu, že se něco posere a čím je to složitější, tím hůře se pak něco řeší a navíc je tam ten průšvih, že prostě někteří budou omylem odesílat věci z O365, takže budou mít rozhozenou odeslanou poštu a objeví se další jakoby problémy.

Přeposílání z O365 mailboxu franta@domena.tld -> mailhosting franta@domena.tld nebude fungovat, protože O365 tu doménu má u sebe, takže nic ho netlačí jinam. Musel by se asi nastavit hybrid jako se to dělá u Exchange<->O365, aspoń jednosměrný, protože správci mailhostingu toto řešit nebudou. I ten hybridní exchange používá aliasy s vlastní doménou na interní komunikaci/přeposílání mezi servery a další věci.

Když groupware, tak celá firma. Řešení je nemálo, nemusí to být hned Office365. Můžeš použít třeba Google workspace, V on prem Kerioconnect (má addon do outlooku na plnou integraci), IeWarp (má addon do outlooku na plnou integraci) nebo IceWarp cloud. Řešeních je hodně. Jinak lze i řešit sync caldav kalendáře s Outlookem, viz: Outlook CalDav Synchronizer.

Každopádně co si budem, Outlook je MS a nejkompatibilnější je MS cloud. Navíc jejich nový Outlook není zpětně kompatibilní, takže pokud máte, nebo uvažujete o přechodu, je možné, že 3rd řešení budou mít problémy.
Zdar Max

[googler]

"Každopádně všechny podobné workaroundy vedou k tomu, že se něco posere a čím je to složitější, tím hůře se pak něco řeší a navíc je tam ten průšvih, že prostě někteří budou omylem odesílat věci z O365, takže budou mít rozhozenou odeslanou poštu a objeví se další jakoby problémy."

Okey uz je to zaujimavejsie pretoze si prvy clovek co ma podobne stanovisko ako spravca hostingu pretoze tvrdis, ze odosielanie cez rozne servery vdaka DKIM sice v principe fungovat moze, ale skor ci neskor sa nieco posere. Mohol by si konkretizovat blizsie co by sa mohlo pokazit? Myslis, ze aj pri normalnom beznom hostingu by sa mohlo stat nieco take co pise spravca aktualneho hostingu (posta v spame, domena v blackliste, ip v blackliste...) alebo skor mas na mysli "uzivatelske" problemy (napr. to preposielanie). Viaceri mi totiz uz napisali, ze pouzitie viacero odosielacich serverov je takymto sposobom nie len mozne, ale moze byt dokonca az ziaduce. To preposielanie samotne nevidim ako problem lebo v Exchange adminovi je myslim mozne nastavit pravidlo. Nieco v zmysle "ak dane konto nemas u seba pouzi verejny mx zaznam domeny a posli to tam" alebo nieco obdobne tam myslim je. Pokial ide o nahodne odosielanie posty z Ex. konta: Ano, to mi napadlo a riesil by som to tiez pravidlom: "Vsetku odoslanu postu preposielaj aj na IMAP. Na IMAPE sice potom tato zriedkava nahodne odoslana posta bude v prijatej poste, ale to by nemal byt pre uzivatelov zasadny problem.

[Max]

Pokud chceš mít na obou stranách stejnou doménu, tak musíš mít účet vždy jen na jedné straně, prostě ten stejný mailbox nesmí existovat na obou mail serverech, protože když bude existovat na obou stranách, tak uživatel bude mít část emailů na mailhostingu a část v O365 podle toho, od koho půjde komunikace. A ty ten email nepřepošleš, protože nemůžeš přeposlat email od franta@domena.tld v O365 na franta@domena.tld na mailhostingu. Možná by šlo vytvořit pravidlo, aby kopii všech emailů posílal O365 na další server, ale pak bude mít uživatel email 2x ve dvou různých, ale vlastně stejných, účtech. Posílání/přijímání zakázat nemůžeš, protože potřebuješ posílat pozvánky a další věci, takže to také není řešení.

Pokud ti ten mailbox bude existovat vždy jen na jednom serveru, tak pochybuji, že správce hostingu ti upraví konfiguraci na míru tak, aby jakékoli neexistující adresáty na svém serveru pro tvou doménu posílal na O365, protože tím si vyslouží místo na blacklistu, jelikož sám nebude vědět, na jaké adresáty lze komunikaci přijmout a na jaké hned odmítnout. Tím si zhoršíš antispam na mailhostingu a zároveň mailhosting bude víc spamovat O365 a dostanou se u nich na blacklist. Lze to řešit recipient filtrem, kde by jsi si vedl seznam všech akceptovaných emailových adres, což je opět nutná modifikace na straně providera + musí dokázat nabídnout možnost na vlastní úpravu toho seznamu.
Celkově je myšlenka splitnutného mail řešení, které člověk nemá pod vlastní správou, dost na pytel.
Navíc teď ti někdo z vedení může i tvrdit, jak mu nebude vadit nějaká menší nekonzistence, nebo gulášek v mailech, ale to jen proto, že si to plně neuvědomuje a věz, že si to pak celkem rychle uvědomí.

Za mně je to nesmysl. Pokud vedení touží po groupware, měl by zmigrovat všechny a držet jednotné řešení. Nebo použít jinou doménu. Tj. firma má doménu @neco.cz a management chce groupware jen pro sebe, tak by měly mít všichni z managementu v O365 doménu/email @neco.eu a z cz (každý zmigrovaný by si nastavil přeposílací pravidlo) by si nechal přeposílat emaily do O365.
Zdar Max

[googler]

Aha jasne to s tymi mailboxami chapem. Ex. boxy by mali iny tvar ako imap boxy a nepotrebujem preposielat z imapu na ms ale len z ms na imap, takze nepotrebujem od spravcu hostingu individualnu configu a Exchange server by mal mat tu feature na preposielanie "von" ak dany mailbox exchange neeviduje u seba

[Max]

Pak to není problém, ale je to celkově hodně ugly. Ti uživatelé pak budou mít dva mailboxy v outlooku a ten jeden bude sloužit jen na kalendář a kontakty, stále nepůjde out of office, filtry synchronizované se serverem, delegace schránek apod.
Licence na Office řešíte krabicovky? Pokud ano, tak pak je asi nejlevnější licence, co můžeš použít, EO1 (Exchange Online Plan 1).
Zdar Max