Как приложения SaaS / Mult-Tenancy реализуют уведомления по электронной почте (отправка и получение)?

Question

Учитывая мультитенантное приложение, Как поставщики реализуют почтовые уведомления с точки зрения настройки учетной записи электронной почты и перспективы программирования:

Отправка электронных писем может исходить из общей учетной записи: например, notifications@VendorName.com или noreply@VendorName.com, это кажется разумным, учитывая, что в содержимом электронной почты могут содержаться адреса ответов и адреса.

Получение электронных писем: Как приложение получит электронную почту, например; генерировать билеты поддержки или назначать комментарии в электронном письме к проекту / задаче. Я видел идентификаторы в теме и некоторые ответы на адреса, содержащие имя учетной записи, например: notifications@AccountName.VendorName.com

Я понимаю, что можно программно подключиться к серверу pop3 и получать электронные письма и искать идентификаторы с темой, но есть ли способ настроить и получать электронную почту на одну учетную запись pop3 от нескольких суб -адреса адресов электронной почты (не уверен в терминологии), например: noreply@AccountName1.VendorName.com или noreply@AccountName2.VendorName.com и проверьте имя учетной записи по адресу? (аналогично проверке поддоменов по URL)

Какие-либо практики, опыт, комментарии или предложения?

(не уверен, что это актуально, но используется C # asp.net-mvc, службы и т. Д.)

Answer 1

Мы (по адресу muHive ) являемся продуктом для управления входящей электронной почтой / социальными беседами. Если вы смотрите на обработку входящих сообщений электронной почты или разговоров в социальных сетях от клиентов, у нас есть впечатляющий набор инструментов.

Для наших собственных исходящих потребностей самый простой способ - использовать API отправки электронной почты. Не беспокойтесь об отправке SMTP самостоятельно. Мы используем Amazon SES , а также попробовали Sendgrid , что дало нам дополнительные преимущества, такие как статус доставки и анализ электронной почты.

Существует два способа обработки нескольких учетных записей для перехвата всех адресов электронной почты. Если ваша целевая система может различать разных клиентов и назначать задачи нужным представителям на основе содержимого / отправителя, попросите всех ваших клиентов отправить электронное письмо по адресу support@company.com.

Как вы правильно сказали, вы также можете создать *accountName_support@company.com* адреса электронной почты и использовать разные учетные записи в любом решении CRM / Support, используемом для управления этими электронными письмами.

Другой подход заключается в том, чтобы ваши клиенты отправляли вам электронное письмо по адресу support@company.com, и вы используете систему, основанную на правилах (например, muHive), для пересылки этих писем соответствующим руководителям учетных записей на основе клиента / аккаунт, который отправил почту.

Answer 2

Для отправки уведомлений по электронной почте мы отправляем уведомление на адрес, связанный с каждой учетной записью, и просто отправляем его с нашего домена на этот адрес. Наш адрес отправителя отслеживается, и ответы попадают в рабочую очередь CSR.

Для входящих писем мы используем FogBugz (от создателей Stack Overflow) для отслеживания дел. Это принимает новые случаи по электронной почте (например, Case@mycompany.com). Билеты автоматически создаются из электронной почты. Моя единственная жалоба заключается в том, что клиент должен проверить неясную ссылку на обновления дел (без веб-портала «Мои дела», но, возможно, это появится в следующей версии FogBugz).

У нас есть настраиваемое поле в FogBugz, чтобы указать клиенту, от которого поступил билет. Теоретически мы могли бы написать плагин для FogBugz, который автоматически назначал бы это, используя домен отправителей, но я думаю, что CSR еще не жаловались достаточно громко: