Назад | Перейти на главную страницу

Масштабируемость IMAP

Я создаю систему, которая позволяет участникам отправлять ей содержимое по электронной почте и мгновенно автоматически анализировать его.

я задала вопрос относительно использования настраиваемого SMTP-сервера для перехвата почты. Одна из причин этого заключается в том, что при увеличении спроса его легко масштабировать (просто установите новый почтовый сервер). Одно из предложений заключалось в использовании IMAP IDLE вместо отслеживания одного почтового ящика.

У меня вопрос, насколько это масштабируемо? Если бы у меня был один почтовый ящик с псевдонимом электронной почты с подстановочными знаками для захвата всей почты, сколько почты он мог бы обрабатывать за один раз, не останавливаясь? Если бы я пошел по пути создания отдельного почтового ящика для каждого члена, как было бы лучше всего контролировать каждого из них?

Существует своего рода стандартный протокол под названием LMTP (см. RFC 2033), который позволяет вам реализовать почтовый процессор, принимающий почту от обычного SMTP-интерфейса. Интерфейс обеспечит вам защиту и займется управлением очередью. Ваш LMTP-сервер будет получать почту и выполнять синтаксический анализ и уведомления.

Преимущество этого решения заключается в том, что вы можете вставить балансировщик нагрузки между ними и добавить столько блоков, на которых запущен ваш LMTP-слушатель, сколько вам нужно.

Я думаю, что и Sendmail, и Postfix поддерживают LMTP. Ваш любимый сервер вполне может.

Насколько я понимаю, вы собираетесь написать прослушиватель SMTP, который в зависимости от значения команды RCPT TO: будет принимать или отклонять соединение. После принятия соединения он будет анализировать данные, сопровождающие команду DATA, и результат парсера будет сигнализировать соответствующему приложению, которое будет использовать данные, верно?

Зачем вам вообще нужен физический почтовый ящик? При каждом соединении ваш слушатель порождает дочерний обработчик, который анализирует и уведомляет зарегистрированное приложение. В зависимости от вашей нагрузки вам может потребоваться или не обязательно поддерживать очередь локально (или отправить отправителю ошибку 4xx, чтобы он повторил доставку), или вам может потребоваться поддерживать очередь для каждого зарегистрированного приложения. Предполагая, что для каждого приложения имеется один почтовый ящик, вы думаете, что каждый почтовый ящик используется как отдельная очередь для каждого приложения. Использование IMAP для определения изменения почтового ящика просто означало бы, что вам нужно написать еще один прослушиватель (IMAP), который будет проверять почтовые ящики. ИМХО, это лишний перебор.

Я не пишу .NET, но вот что я бы сделал: я бы заставил каждое приложение прослушивать порт (определяемый при регистрации с помощью SMTP-прослушивателя). Затем, когда синтаксический анализатор решил, куда следует пересылать данные, дочерний обработчик должен подключиться к соответствующему порту и переслать данные приложению. В вашем случае такое решение может быть неприемлемым, особенно если требуется серьезная перезапись.

Вы можете найти полезные советы, прочитав "Руководство программиста по интернет-почте", хотя его образцы кода написаны на Visual Basic.

Вы бы очистили почту после того, как проанализируете ее? Если это так, то наличие нескольких почтовых ящиков на одном сервере, вероятно, не даст вам никакого преимущества в производительности, поскольку почтовые файлы, вероятно, все равно будут храниться на одном томе.

Какой объем входящей почты вы ожидаете от этой системы? Узким местом почти наверняка будет ваш код синтаксического анализа, а не сам почтовый сервер. Нет причин, по которым один сервер IMAP не должен обрабатывать тысячи сообщений в минуту.

NB: Мы обрабатываем заявки в службу поддержки, используя один почтовый ящик, который опрашивается каждую минуту с помощью POP3. Каждое сообщение анализируется на предмет номера учетной записи / токена поддержки и выгружается в базу данных, и оно легко обрабатывает тысячи каждый час.

Ваши самые большие проблемы, вероятно, будут связаны с предотвращением / отклонением спама и почтовыми бомбами.

Вы рассматривали возможность использования двух SMTP-серверов? Сначала выставьте стандартный smtpd (например, Postfix) в Интернет. Настройте его так, чтобы он принимал почту только на правильные адреса и т. Д. Затем пусть он передает сообщения в smtpd, который вы пишете, который не отображается извне. Вы можете положиться на экземпляр Postfix в управлении очередью, фильтрации и т. Д. Поскольку ваш демон также будет разговаривать только с доверенным экземпляром Postfix, вам не придется так сильно беспокоиться о том, что ошибка может быть использована извне. (Конечно, вам все равно следует писать параноидальный код.)

Другой (возможно, лучший) вариант - заставить Postfix доставлять сообщения в локальный процесс, который вы пишете, который передает сообщения на ваш внутренний сервер, используя более простой протокол, чем SMTP.

Любой из них должен быть довольно легко масштабируемым. Вы можете добавить дополнительные прокси-серверы, используя несколько записей MX, и дополнительные внутренние серверы с любым (в зависимости от того, как вы настроили Postfix для взаимодействия с ними) с другим набором записей MX и циклическим перебором DNS, или, возможно, с чем-то еще.