Skocz do zawartości

Wsparcie MAPI (MS365)

Polecane posty

Czy rozważane kiedykolwiek było takie wsparcie? Jest bardzo łatwe do podstawowego zaimplementowania (dodać parę okienek i pól tu i tam, a sam proces logowania się praktycznie sam robi, bo biblioteki wszystkie są dostępne od MS).

 

Głównie mowa o możliwości wykorzystania opcji "Send on behalf" w przypadku wysyłania dokumentów firmowych.

 

Aktualnie u nas jest np. skrzynka faktury@, którą podpięto do nexo. Login/hasło i cały proces wysyłania dokumentów działa tak, że niezależnie od osoby wysyłającej (w nexo), mail wychodzi z faktury@.

Od strony np. Outlooka mamy to lepiej obcykane, że każdy ma swojego maila oraz dostęp do maila faktury@ i może wysyłać w imieniu (nadal logując się swoim kontem).

 

Pewnie InsERT nie chce się uwiązywać do rozwiązań zastrzeżonych (MS), ale warto zaznaczyć, że bardzo dużo aplikacji wspiera MAPI, które jest na rynku od daaawna i ma całkiem spory zasięg na rynku.

Link to postu

W ostatnich 2-3 latach się bardzo przyzwyczailiśmy do MS365.

 

Tam wygląda to tak, że serwer hostuje "mailboxy".

 

Taki mailbox może należeć do licencjonowanego użytkownika lub być tzw. "shared mailbox".

  • W przypadku użytkowników: Mailbox jest zawsze tworzony w momencie utworzenia danego użytkownika w organizacji, a adres email tego mailboxa przyjmuje postać loginu użytkownika (adres email MS365 jest loginem do wszystkich serwisów/aplikacji związanych z tą organizacją, np. domeną @firma.com).
  • Admin może dodatkowo tworzyć te "shared mailboxy".
    • Docelowo i domyślnie są to maile, do których nie wymagana jest licencja (subskrypcja per user tak jak w przypadku użytkownika) i nie ma loginu ani hasła - raczej się do nich nie loguje bez potrzeby, tylko zarządza z poziomu konta użytkownika.
    • Do takich shared mailboxów można przydzielać pozwolenia na:
      • "Manage" - pełny dostęp do skrzynki, można robić co się zechce
      • "Send as" - zalogowany jako użytkownik, wysyłający może w polu email "From"/"Od" wpisać adres tego shared mailboxa, dzięki czemu email wypłynie właśnie z tej skrzynki (użyje credentiali użytkownika, ale wyśle tak jakby był tym shared mailboxem - wszystko się zachowa tak jakby wysłano maila z shared@firma.com, łącznie z return adresem itp.).
      • "Send on behalf" - prawie to samo co wyżej, ale poziom niżej - email nadal wypłynie z shared mailboxa, ale tym razem będzie wiadomo, że wysłał to użytkownik. Jest to odnotowane w headerze emaila jako "From: user@firma.com on behalf of shared@firma.com". Zwrotny email nadal będzie shared@. Prawie to samo co "Send as", właśnie z tą różnicą, że widać kto wysłał "on behalf".

Mamy kilka takich shared mailboxów, m.in. faktury@, zamówienia@, biuro@.

 

Teraz problem jest taki, że wszyscy używają ich przez protokół MAPI, gdzie właśnie mają pozwolenie na "Send on behalf", a logują się normalnie swoim kontem (np. Outlook, Thunderbird, czy inne które obsługują MAPI).

 

Zacząłem bawić się skrzynką w nexo, no i MAPI nie ma, więc odblokowałem IMAP w MS365 (wcześniej blokowaliśmy).

Oczywiście, IMAP wymaga logowania, a z racji na to co wspominałem wcześniej, że shared mailboxy nie mają domyślnie loginu/hasła - musiałem owe wygenerować i udostępnić mailboxa jako konto pod IMAP.

 

Konto połączyło się z nexo normalnie - wszystko działa, ale jest ono jako konto samo w sobie, a nie jako użytkownik MS, który używa shared mailboxa.

 

Teraz maile wysłane z podłączonego shared mailboxa wychodzą na podstawie credentiali tego konta, więc stracono możliwość śledzenia kto te maile wysyła (tak jak było to możliwe z MAPI na bazie "Send on behalf").

 

Zatem odblokowując IMAP dla nexo, rezygnujemy z wygody związanej z udogodnieniami MAPI po stronie serwera. Jak część teraz by używała MAPI w Outlooku a część IMAP w nexo to nie jest wesoło, bo na zmianę raz jest on behalf, a raz jako konto shared i niepotrzebnie trzeba czasem szukać i w MS365 (np. Outlooku) i w nexo kto co wysłał.

 

Myślę, że wyjaśniłem dobrze sprawę - chodzi głównie o to czy kiedykolwiek rozważano implementacje MAPI w nexo w postaci podstawowej (do celów autoryzacji kontem użytkownika, zamiast shared).

Edytowane przez Ernest Sadowski
  • Lubię to 1
Link to postu
×
×
  • Dodaj nową pozycję...