Добрый день,подскажите, существует какое-либо решение для массового сбора почты с удалённых IMAP/POP-ящиков с возможностью транспорта собранной почты через lmtp в юзерские mailbox'ы уже на моём сервере?
Сбор почты будет проводится по значительному множеству удалённых ящиков для большого числа почтовый пользователей на моём сервере.
Настройки для доступа к удалённым IMAP/POP-ящикам будут храниться в БД.Насколько для этого подходит fetchmail и есть ли более подходящие варианты*?
(*) С уклоном на многопоточность\многопроцессность сбора, высокую производительность и массовость.
помимо getmail есть какие-то альтернативи?
>помимо getmail есть какие-то альтернативи?
понимаете, то что вы задумали по своей сути ненормально. ну не строят так почтовые системы, обычно держат fetchmail ради нескольких удалённых почтовых ящиков, поэтому никакого готового решения для случаев типа вашего по-моему просто не существует.
>понимаете, то что вы задумали по своей сути ненормально. ну не строят
>так почтовые системы, обычно держат fetchmail ради нескольких удалённых почтовых ящиков,
>поэтому никакого готового решения для случаев типа вашего по-моему просто не
>существует.А кто истинну в последней инстанции скажет - как строить почтовые системы?
Будет 1 000 или 10 000 аккаунтов. Будет тот или иной сборщик почты.
Таковы требования.fetchmail сможет собрать почту с 1 000 - 10 000 удалённых IMAP/POP-серверов?
P.S. у yandex.ru/mail.ru/gmail.com тоже "ненормально" построенная почтовая система, коли она умеет сбор почты?
>[оверквотинг удален]
>
>А кто истинну в последней инстанции скажет - как строить почтовые системы?
>
>
>Будет 1 000 или 10 000 аккаунтов. Будет тот или иной сборщик
>почты.
>Таковы требования.
>
>fetchmail сможет собрать почту с 1 000 - 10 000 удалённых IMAP/POP-серверов?
>видимо я вас совершенно не понял. переформулируйте задачу более детально.
>
>P.S. у yandex.ru/mail.ru/gmail.com тоже "ненормально" построенная почтовая система, коли она умеет сбор
>почты?что вы подразумеваете под сбором почты? как вы себе представляете как работают вышеуказанные системы?
>видимо я вас совершенно не понял. переформулируйте задачу более детально.Есть массовый почтовый сервис. Основной доступ пользователей происходит через web-интерфейс.
Через тот же web-интерфейс пользователь может сделать разные настройки, в т.ч. и настройки сбора почты (указать сервер, протокол, логин и пароль...).
Сбор почты с удалённых ящиков происходит периодически (каждые N-минут).>что вы подразумеваете под сбором почты? как вы себе представляете как работают
>вышеуказанные системы?Что подразумеваю - см. выше.
А как работает - очевидно, что по протоколам IMAP4/POP3, примерно так, как это делает fetchmail, но в многопоточном режиме, доставка собранной почты в ящики пользователей происходит через lmtp или прямым созданием файлов (в правельных местах, с правельными "свойствами"; maildir).Или я что-то не понимаю? :-)
>[оверквотинг удален]
>>что вы подразумеваете под сбором почты? как вы себе представляете как работают
>>вышеуказанные системы?
>
>Что подразумеваю - см. выше.
>А как работает - очевидно, что по протоколам IMAP4/POP3, примерно так, как
>это делает fetchmail, но в многопоточном режиме, доставка собранной почты в
>ящики пользователей происходит через lmtp или прямым созданием файлов (в правельных
>местах, с правельными "свойствами"; maildir).
>
>Или я что-то не понимаю? :-)ну вот мы друг-друга поняли. вы вот куда смотрите:
сбор почты c конкретного ящика многопоточным не может быть (нудно гундим про pop3|imap4 протоколы), это как многопоточная аутентификация :)
выводы:
без разницы какой сборщик использовать (у меня вообще свой на perl написан)
нужен хороший канал, особенно для пряников тиражирующих в почту ролики ётубе ;)
нужен быстрый вменяемый мта которому всё это скормить, я давно выбрал exim, но тут выбор за вами.итоги: скорость обработки левых ящиков прямопропорциональна ширине канала.
p.s. начните что-то делать, если что, я вам помогу, если не пропаду с кегой пивка ;)
>ну вот мы друг-друга поняли. вы вот куда смотрите:
>сбор почты c конкретного ящика многопоточным не может быть (нудно гундим про
>pop3|imap4 протоколы), это как многопоточная аутентификация :)Да. Это известно. Но про многопоточность я говорил в свете одновременного сбора с множества удалённых imap/pop-ящиков.
Т.е. если имеем 1000 юзеров, которые хотят собирать почту, то искомая утилита не должна делать это последовательно, по 1-му ящику раз за разом, правильное поведение - N конкурирующих потоков\процессов сбора, по N-процессов раз за разом (ну или по мере освобождения процессов в пуле от предыдущего сбора).А на счёт IMAP4 - никто не мешает собирать почту в несколько потоков по IMAP.
>выводы:
>без разницы какой сборщик использовать (у меня вообще свой на perl написан)Вывод не совсем верный: см. объяснение выше на счёт N-конкурирующих процессов. А в случае многопроцессной\многоядерной системы, ваш подход упирается в мощность процессора\ядра, на котором работает ваш скрипт.
>
>нужен хороший канал, особенно для пряников тиражирующих в почту ролики ётубе ;)канал хороший.
>
>нужен быстрый вменяемый мта которому всё это скормить, я давно выбрал exim,
>но тут выбор за вами.
>postfix тоже не слаб.
В сторону exim тоже смотрю.>итоги: скорость обработки левых ящиков прямопропорциональна ширине канала.
>+ пропорциональна возможность распараллеливания задачи на несколько субпроцессов.
>p.s. начните что-то делать, если что, я вам помогу, если не пропаду
>с кегой пивка ;)Ж)
>помимо getmail есть какие-то альтернативи?Смотрите CommuniGate
>>помимо getmail есть какие-то альтернативи?
>
>Смотрите CommuniGateА денег на него вы дадите? :)
>>>помимо getmail есть какие-то альтернативи?
>>
>>Смотрите CommuniGate
>
>А денег на него вы дадите? :)Как видно по топику действительно подходящих вариантов нету :( .