Office 365 (Exchange Online) i wysyłanie maili z tego samego username w obydwu domenach

Exchange Online, jak to Exchange w ogólności może być irytujący. Tego, że tak oczywista sprawa, jak posiadanie dwóch domen i chęć wysłania maili używając tego samego użytkownika, ale różnych domen może być utrudnione - to się nie spodziewałem. Przykład konkretny i wcale nie tajny - dwa maile [email protected] i [email protected] hostowane na Office 365.

Office 365 dość dobrze obsługuje kilka domen podpiętych do jednej organizacji - domyślnie ustawia każdemu użytkownikowi alias w każdej dostępnej domenie (na przykład [email protected] i [email protected]) i pozwala administratorom na ręczne ustawienie dowolnego aliasu w obrębie wszystkich domen (na przykład dodatkowo [email protected], ale już [email protected]).

Rozwiązanie pierwsze - EmailAddressPolicyEnabled #

Teoretycznie, jeśli użytkownik Exchange’a posiada kilka aliasów, na które poczta przychodząca trafia do jego skrzynki, to powinien też móc wysyłać z nich maile. Nic bardziej mylnego. Stoi za tym domyślna polityka EmailAddressPolicy.

W webowym centrum administracyjnym powinna być gdzieś tutaj, ale nie zawsze będzie widoczna.

Odkąd Microsoft stworzył PowerShella, część zadań administracyjnych da się wykonać tylko z PowerShella - także w hostowanym przez Microsoft Exchange Online. Wyłączenie domyślnej polityki może brzmieć groźnie, ale jeśli tyczy się to administratorów Office 365 (najczęściej nas samych) to raczej wiedzą co robią 😉

Problem polega na tym, że Knowledge Base Microsoftu zaleca w opisanej powyżej sytuacji użycie cmldetu Set-Mailbox z przełącznikiem -EmailAddressPolicyEnabled:$false ( https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailbox?view=exchange-ps). Poza koniecznością odpalenia tego na Windowsie - żaden problem - prawda?

Odpowiedź na powyższy błąd znajdziemy w pierwszym akapicie dokumentacji tego cmldetu:

This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings may be exclusive to one environment or the other.

https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailbox?view=exchange-ps

Istota problemu #

Krótkie uzupełnienie co takiego robi domyślna polityka adresów e-mail: kiedy wysyłamy maila, sprawdza, czy mamy uprawnienia do wysyłania z adresu podanego w polu From. Jeśli nie mamy - podmieni adres From na nasz bazowy adres. Niestety polityka ta sprawdza tylko identity, czyli odpowiednik userPrincipalName, nie zaś aliasy. Także posiadając alias - nie mamy uprawnień do wysyłania z niego maili.

To assign a different SMTP address as the primary SMTP address for a recipient, you must disable the option to automatically update an email address based on the email address policy applied to the recipient.

https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj156614(v=exchg.150)?redirectedfrom=MSDN

Rozwiązanie drugie - Shared Mailbox #

Inne źródła od razu wskazywały konieczność założenia skrzynki współdzielonej (Shared Mailbox) o takim adresie, jak alias, z którego chcemy wysyłać maile. Następnie należałoby ustawić sobie uprawnienia do tej skrzynki współdzielonej i przekierowanie maili na nią wpadających na podstawowe konto.

Zatem do dzieła:

Problem drugi - automatyczne aliasy #

To jednak moment, kiedy w naszym przypadku dostaniemy taki oto przemiły błąd:

The proxy address "SMTP:[email protected]" is already being used by the proxy addresses or LegacyExchangeDN. Please choose another proxy address.

Czy to oznacza, że trzeba jedynie usunąć sobie proxy address, czyli alias z konta Exchange i po kłopocie? Otóż nie.

Problem polega na tym, że kiedy posiadamy kilka domen to Exchange z automatu doda nam alias w każdej domenie - nawet dla skrzynek współdzielonych. Czyli ta świeżo tworzona skrzynka poza adresem [email protected] dostanie alias… [email protected]

Obejście na szczęście jest dość proste - należy stworzyć Shared Mailbox z adresem o innej nazwie (tutaj: not_daniel), a następnie podmienić jej alias w domenie dsinf.net na właściwy [email protected], drugi zaś ( [email protected]) można usunąć.

Zakończenie implementacji od strony użytkownika #

Skoro mamy gotową skrzynkę współdzieloną użytkownik musi ją jeszcze podpiąć do swojej własnej. Jak to zrobić pokażę na przykładzie Outlook Web App (OWA).

Testowanie #

Aby potwierdzić, że wszystko działa, jak należy, sprawdzimy, czy możemy wysłać maile z nowego aliasu poprawnie oraz, czy możemy je odebrać. Najłatwiej wykorzystać darmowe usługi online do testowania maili - ja użyłem 10minutemail.com do testu poczty wychodzącej oraz ismyemailworking.com do testu maili przychodzących.

Podsumowanie #

Exchange jest nietrywialny, a w wersji Online - tym bardziej. Na szczęście da się obejść pewne problemy i cieszyć się wysyłaniem maili z aliasów w innych domenach.

Na zakończenie - taki oto maili wpada na główną skrzynkę odbiorczą, informując, iż skrzynka współdzielona właśnie zaczęła forwardowanie wszystkich maili - na tę główną 😉