Задача стоит следующая: Приходит большое число писем (две-три сотни тысяч в сутки), эти письма надо обработать следующим образом: Для каждого письма проверить его валидность (неким внешним процессом по данным из заголовка письма),
если письмо невалидное, то удалить с почтового сервера, если письмо валидное, то передать его на обработку еще одному внешнему процессу, дождаться  оповещения об успешном начале обработки и удалить с почтового сервера.
Письмо должны быть гарантировано обработаны и не должны теряться в случае ошибок, сбоев питания, и прочих обстоятельств на обрабатывающей стороне.
Как сделано сейчас: Используется протокол POP3, программа подключается к почтовому серверу, забирает порцию писем (скажем, 100) не удаляя их с сервера, для каждого письма из порции получает UIDL, отключается от сервера. Дальше письма этой порции обрабатываются, когда наступает момент удаления письма, программа подключается к почтовому серверу, перебирает письма, сравнивая UIDL-ы, найдя нужный, удаляет письмо с сервера).
После обработки порции писем, программа пытается получить следующую порцию, если ее нет, то засыпает на какое-то время, и дальше все сначала.
Надежность этого решения устраивает, не устраивает скорость при большом количестве писем в ящике.

Собственно вопрос в чем - есть ли какие-то готовые проверенные решения по обработке приличных объемов почты, возможно, использование другого протокола, и т.д.
Мне необходимо обеспечить а) скорость б) надежность.
Ну все это в режиме 24/7

Буду рад пинкам в нужном направлении.

>Игорь Шевченко ©   (22.03.16 11:12) [0]

на самом почтовом сервере есть какие инструменты по валидации?

есть возможность работать с базой данных почтового сервера?

Почему нельзя сделать так, чтобы программа, которая забирает порцию писем с сервера надежно сохраняла их у себя до обработки и сразу удаляла с сервера?

virex(home) ©   (22.03.16 11:28) [1]

Нет. Интересует решение для клиентской части. Работа с базой данных почтового сервера - это IMAP имеется в виду или что ?

DayGaykin ©   (22.03.16 11:32) [2]

Это одно из решений, которые делать не хочется, но возможно, придется, если не найдется менее затратных. Сохраняло где ? В базе данных ? Сложно и затратно. Файловой системы нету.

>Для каждого письма проверить его валидность
Идет ли речь про отсеивание/частичное отсеивание спама?

>Игорь Шевченко ©   (22.03.16 11:33) [3]

вдруг бд хранится в sql-подобной бд
клиент бы запускал запросы/процедуры к бд по валидации и удалению ненужных писем, почти мгновенно
тут конечно нужна серверная часть доступа к бд, можно нацепить шифрование

Empleado ©   (22.03.16 11:53) [5]


> Идет ли речь про отсеивание/частичное отсеивание спама?


Не совсем. Спам отсеивает почтовый сервер. Здесь именно валидность писем с прикладной точки зрения. В среднем валидных писем 95%

> Надежность этого решения устраивает, не устраивает скорость

Если процент "спама" весьма высок, то не лучше ли на первом этапе (валидации) загружать не всё письмо, а только его заголовок (в MS OUTLOOK есть такая возможность). Обработать заголовки, отметить плохие для удаления, а хорошие для загрузки.  На втором этапе уже удалять "спам", загружать "проверенные" письма полностью и передавать их в обработку.
В итоге, если спама много, загружать придётся намного меньше писем, что повысит скорость. Заголовки загружаются практически мгновенно.

Труп Васи Доброго ©   (22.03.16 12:04) [8]


> В среднем валидных писем 95%

Игорь,
а не проще/быстрее сразу просить у сервера все UIDL,
а потом в один проход удалять все старое и брать все новое?

Sha ©   (22.03.16 13:05) [10]

Привет, Саша!
Не понял, можно подробнее :) Письма, они же поступают регулярно, а не так, что они лежат в ящике, ждут, пока их обработают, а потом до следующего дня. Я обозначил общий объем, а темпы поступления я, увы, обозначить не могу.

Первое, что приходит в голову.
Клиент ведет 4 списка UIDL:
- успешно обработанные - их надо удалить в ближайшем сеансе,
- переданные на обработку - надо дождаться результата,
- не прошедшие валидацию - их надо удалить в ближайшем сеансе,
- новые, еще не считанные с сервера - их надо считать ближайшем сеансе.
Клиент в непрерывном цикле делает следующее:
- соединяется с сервером, начиная новый сеанс,
- одним запросом получает все имеющиеся у него UIDL,
- сравнивает их со своим списком и считывает, если надо, очередную порцию новых сообщений,
- сравнивает их со своим списком и удаляет невалидное и обработанное,
- закрывает соединение.

Я так понимаю надёжность имеющегося подхода устраивает. Не устраивает скорость.
Проводился ли анализ на каком именно этапе происходит задержка в описанном сценарии? если проблема с POP3 - то может какой-то мэйл-сервер поддерживает какие-то плагины, для которых есть более шустрые протоколы.

Выше имелось в виду, что
"сравнивает их" = "сравнивает полученные UIDL"

> KSergey

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

У нас Женька (jack128) писал небольшой сервис на шарпе по обработки такого кол-ва заявок (багрепорты от клиентов отсылаемых нам - объем примерно такой-же).
Его вариант работает именно так как ты и говоришь 24/7 без сбоев и задержек + сортировка писем по каталогам багтрекера и отсев спама.
Вроде бы у него даже все конфигурируется.
Щас его позову, может что подскажет

Надо на ассемблере все переписать. Быстрее будет :)

KSergey ©   (22.03.16 13:51) [13]

Да, проводился анализ. Узкое место при удалении писем с сервера при наличии в ящике большего количества писем. В pop3 можно удалять письма по их номеру в сессии, а не по UIDL, поэтому при удалении приходится перебирать все письма и сравнивать UIDL

Sha ©   (22.03.16 13:49) [12]

Я примерно понял, что ты хочешь сказать, но хотелось бы для начала услышать, может, какие-то механизмы есть уже готовые. Я попробовал IMAP, но у меня сразу возникли проблемы со скоростью даже на этапе выборки писем. Читаю порцию, запоминаю UID-ы писем, потом удаляю по UID-у.
Почему мне не хочется хранить все в памяти и обрабатывать помногу - если произойдет сбой, мне кажется, я могу потерять всю хранящуюся у меня информацию. И да, забыл добавить, повторно отправлять на обработку валидные письма нежелательно.