Комментарии 42
Это был imapsync курильщика)
Вот нормальный imapsync:
#apt-get install makepasswd rcs perl-doc libio-tee-perl git libmail-imapclient-perl libdigest-md5-file-perl libterm-readkey-perl libfile-copy-recursive-perl build-essential make automake libunicode-string-perl
#git clone git://github.com/imapsync/imapsync.git
#cpan
cpan> install Unicode::String
#cd imapsync
# make install
#imapsync --help
Вот нормальный imapsync:
#apt-get install makepasswd rcs perl-doc libio-tee-perl git libmail-imapclient-perl libdigest-md5-file-perl libterm-readkey-perl libfile-copy-recursive-perl build-essential make automake libunicode-string-perl
#git clone git://github.com/imapsync/imapsync.git
#cpan
cpan> install Unicode::String
#cd imapsync
# make install
#imapsync --help
Да, я буду разворачивать отдельную ВМ под Win системой ради этой задачи, Вы меня убедили!
Редко когда почтовый сервис и без linux. Даже если Exchange, то все равно фронтендом обычно стоит что-то на linux. Поэтому я и удивился. Но вообще статья полезная, хоть imapsync уже 70 лет в интернете, не все о нем знают.
Зачем в полной Windows структуре ставить на фронтенд для Exchange что-то на Linux? Может поделитесь подобными примерами реализаций в продуктовых средах больших компаний? :)
В гомогенной windows структуре linux сервер невозможен, ибо это приведет к тому, что она перестанет быть таковой. Плюс скорее всего это увеличит стоимость обслуживания. Но в сxеме, когда Exchange будет использоваться в качестве MDA (если необходимы end сервисы, предоставляемые Exchange), а, скажем, Postfix в качестве MTA, есть свою плюсы:
1. Postfix более гибок в плане маршрутизации.
2. Postfix требует меньше ресурсов для отсечения нежелательного траффика, более устойчив к атакам. Одним словом, он прикрывает Exchange'y задницу.
1. Postfix более гибок в плане маршрутизации.
2. Postfix требует меньше ресурсов для отсечения нежелательного траффика, более устойчив к атакам. Одним словом, он прикрывает Exchange'y задницу.
В таком случае накладываются отдельные операционные затраты на linux-админа, который стоит гораздо дороже win-админа, как показала практика.
У Exchange есть роль Edge transport server'а, которая как раз выполняет подобные функции, как антиспам можно использовать тот же ORF, который ставится на сервер с Edge-ролью. Со всем этим справится тот же человек, что и поддерживает Exchange, ведь это, читай, компоненты самого Exchange (2016 в расчет не беру, т.к. там идж и хаб роли совмещены, емнип). Для Postfix придется разворачивать отдельный linux-сервер, который будет должен админить отдельный человек, специализирующийся как раз на linux (см. 1 параграф).
У Exchange есть роль Edge transport server'а, которая как раз выполняет подобные функции, как антиспам можно использовать тот же ORF, который ставится на сервер с Edge-ролью. Со всем этим справится тот же человек, что и поддерживает Exchange, ведь это, читай, компоненты самого Exchange (2016 в расчет не беру, т.к. там идж и хаб роли совмещены, емнип). Для Postfix придется разворачивать отдельный linux-сервер, который будет должен админить отдельный человек, специализирующийся как раз на linux (см. 1 параграф).
Postfix более гибок в плане маршрутизации.
Оно редко востребовано. В голову приходит только Jira, которая подменяет адрес отправителя в уведомлениях, но в этом случае MTA надо ставить прямо на неё.
Postfix требует меньше ресурсов для отсечения нежелательного траффика, более устойчив к атакам.
Не смог найти последнего RCE для Exchange, а с вирусами и спамом намного лучше справятся специализированные железки (IronPort и т.п.).
> Оно редко востребовано. В голову приходит только Jira.
По мне так маршрутизация почты это что-то сродни маршрутизации сетей. Вы можете всю жизнь сидеть на 192.168.0.0/24 и пару раз настроить vpn. Или вам повезет и вы будете решать интересные задачи. Мне попадались интересные кейсы и я ни разу не говорил, что это невозможно. Совсем. Мне кажется, что с почтовым трафиком можно сотворить, что душа пожелает, но нужен инструмент и это не Exchange. Я не гуру Exchange, знаю, что парни делают на нем интересные штуки, но трудозатраты несопоставимы.
> IronPort и т.п
Это такой черный ящик за деньги. Последний раз я видел IronPort 7 лет назад, оно собирает сигнатуры и делится ими со всеми остальными железками. И еще у них отличные маркетологи. Хорошо. Но когда на выходе ты должен получить хороший процент отсечения спама 99,9%, не должен терять реальный трафик и ты можешь это делать без платного железа, зачем оно тебе?
По мне так маршрутизация почты это что-то сродни маршрутизации сетей. Вы можете всю жизнь сидеть на 192.168.0.0/24 и пару раз настроить vpn. Или вам повезет и вы будете решать интересные задачи. Мне попадались интересные кейсы и я ни разу не говорил, что это невозможно. Совсем. Мне кажется, что с почтовым трафиком можно сотворить, что душа пожелает, но нужен инструмент и это не Exchange. Я не гуру Exchange, знаю, что парни делают на нем интересные штуки, но трудозатраты несопоставимы.
> IronPort и т.п
Это такой черный ящик за деньги. Последний раз я видел IronPort 7 лет назад, оно собирает сигнатуры и делится ими со всеми остальными железками. И еще у них отличные маркетологи. Хорошо. Но когда на выходе ты должен получить хороший процент отсечения спама 99,9%, не должен терять реальный трафик и ты можешь это делать без платного железа, зачем оно тебе?
Я не гуру Exchange, знаю, что парни делают на нем интересные штуки, но трудозатраты несопоставимы.
Exchange использует топологию из AD, что правительно и естественно в мире Windows.
По мне так маршрутизация почты это что-то сродни маршрутизации сетей.
По-моему значительно проще, нет требований по latency, а фейловер сделан на уровне приложений.
Но когда на выходе ты должен получить хороший процент отсечения спама 99,9%, не должен терять реальный трафик и ты можешь это делать без платного железа, зачем оно тебе?
В таком случае пора открывать свой почтовый сервис или идти работать в
IronPort из разряда «поставил и забыл», после несложной настройки спам просто перестаёт приходить и можно заниматься другими вещами. Ложных срабатываний значительно меньше GMail или Exchange Online, но нет нормальной интеграции с Outlook/OWA и фильтры могли бы сделать покрасивее.
> Exchange использует топологию из AD, что правительно и естественно в мире Windows.
Я не понимаю, что значит эта фраза. Exchange интегрирован в AD, AD это ldap, никто не мешает вам брать оттуда информацию для любого другого MTA. Единственный плюс Exchange это околопочтовые плюшки, когда пользователи сидят в windows экосистеме. Те МDA.
>По-моему значительно проще, нет требований по latency, а фейловер сделан на уровне приложений.
Я про полет фантазии, несколько раз натыкался на то, что было нельзя сделать в Exchange, но можно в Postfix/Exim, особенно учитывая то, то Postfix может превратиться в набор перловых скриптов ( и это его минус тоже).Вы захотите примеров, но сейчас я не смогу вспомнить, потому что редко работаю с Exchange. (Exchange тоже может кушать скрипты, но пусть этим занимаются ребята, повернутые на майкрософте, я не хочу тратить свое время на их изучение. Имхо это не очень перспективно. Но я говорил, что существуют люди, которые делают неплохие вещи с Exchange)
> В таком случае пора открывать свой почтовый сервис
99,9% мало для сервисов типа gmail (
> IronPort из разряда «поставил и забыл»
Да — черный ящик. Только не поставил и забыл, а купил и забыл. Но если хоть немного любите почтовики, то сможете сделать все сами. Это интересно.
>Ложных срабатываний значительно меньше GMail
те Cisco сделала массовый продукт лучше, чем один из самых лучших почтовых сервисов в мире? Хочу статистику… Не вериться. У гугла почтовый трафик явно больше, чем у девайсов ironport, ему и карты в руки.
P.S. На самом деле хочу отдельное комьюнити по почте. Даже ребята, собирающие почтовые комбайны для масс, лажают в конфигах и делают костыли.
Я не понимаю, что значит эта фраза. Exchange интегрирован в AD, AD это ldap, никто не мешает вам брать оттуда информацию для любого другого MTA. Единственный плюс Exchange это околопочтовые плюшки, когда пользователи сидят в windows экосистеме. Те МDA.
>По-моему значительно проще, нет требований по latency, а фейловер сделан на уровне приложений.
Я про полет фантазии, несколько раз натыкался на то, что было нельзя сделать в Exchange, но можно в Postfix/Exim, особенно учитывая то, то Postfix может превратиться в набор перловых скриптов ( и это его минус тоже).Вы захотите примеров, но сейчас я не смогу вспомнить, потому что редко работаю с Exchange. (Exchange тоже может кушать скрипты, но пусть этим занимаются ребята, повернутые на майкрософте, я не хочу тратить свое время на их изучение. Имхо это не очень перспективно. Но я говорил, что существуют люди, которые делают неплохие вещи с Exchange)
> В таком случае пора открывать свой почтовый сервис
99,9% мало для сервисов типа gmail (
> IronPort из разряда «поставил и забыл»
Да — черный ящик. Только не поставил и забыл, а купил и забыл. Но если хоть немного любите почтовики, то сможете сделать все сами. Это интересно.
>Ложных срабатываний значительно меньше GMail
те Cisco сделала массовый продукт лучше, чем один из самых лучших почтовых сервисов в мире? Хочу статистику… Не вериться. У гугла почтовый трафик явно больше, чем у девайсов ironport, ему и карты в руки.
P.S. На самом деле хочу отдельное комьюнити по почте. Даже ребята, собирающие почтовые комбайны для масс, лажают в конфигах и делают костыли.
Я про полет фантазии, несколько раз натыкался на то, что было нельзя сделать в Exchange, но можно в Postfix/Exim
Примеры для них тоже сойдут и за обратными далеко ходить не надо: у конкурентов нет ничего похожего на DAG.
Но если хоть немного любите почтовики, то сможете сделать все сами.
Почтовик — это инструмент, его не надо любить, надо эффективно решать поставленные задачи. Для своего антиспама негде взять аналитику, которая срезает 90% спамеров ещё на этапе подключения.
У гугла почтовый трафик явно больше, чем у девайсов ironport, ему и карты в руки.
Гуглу и MS не очень интересен наш рынок, а Cisco мониторит половину интернета.
Имхо это не очень перспективно.
Каждому своё, я не вижу перспективы в своём сервере с Postfix при наличии ПДД или Mail.ru для бизнеса.
На самом деле хочу отдельное комьюнити по почте.
Оно будет немногочисленным, что-то вроде этого.
>у конкурентов нет ничего похожего на DAG.
И вы опять путаете mta и mda, DAG не занимается маршрутизацией почты, Postifx не занимается организацией ее хранения и раздачей. И кто такие конкуренты Exchange? У майкрософта там свой атмосфера. Просто не надо путать теплое с мягким. HA баз данных нет? HA storage нет? Да этих реализаций существует огромное количество. Вам просто надо в голове разделить сервисы Exchange на реальные сервисы и рассматривать их не как одно целое, а как комплекс.
> негде взять аналитику, которая срезает 90% спамеров ещё на этапе подключения.
На этапе подключения я вам срежу 98-99 % без всякой аналитики( и даже без блэклистов, которыми балуется ironport) Вот вам и пробел в знаниях при использовании черных ящиков «подключил и забыл» 90 процентов это 90 писем из 100, это вообще ниочем.
> Гуглу и MS не очень интересен наш рынок, а Cisco мониторит половину интернета.
Cisco не мониторит почтовый трафик половины интернета.
Не очень понятно деление на наш и не наш рынок в плане срезки спама. Сигнатуры могут отличаться, почтовый трафик у гугла все равно больше. Погрешности минимальны.
>Каждому своё, я не вижу перспективы в своём сервере с Postfix при наличии ПДД или Mail.ru для бизнеса.
В нынешних реалиях держать корпоративную почту(сервера) у российских компаний тоже самое, что отдавать ее конкурентам или любым другим заинтересованным лицам в погонах.
В профессиональном же плане это вас не развивает, наоборот. Или же направление именно вашей деятельности вообще совсем другое, тогда не стоит вам заниматься сервисами, которые связанны с внутрикорпоративной информацией или безопасностью.
И нет никакого такого сервера с Postfix. Есть сервис Postfix. Почтовая же система — это кластер из множества различных сервисов.
И вы опять путаете mta и mda, DAG не занимается маршрутизацией почты, Postifx не занимается организацией ее хранения и раздачей. И кто такие конкуренты Exchange? У майкрософта там свой атмосфера. Просто не надо путать теплое с мягким. HA баз данных нет? HA storage нет? Да этих реализаций существует огромное количество. Вам просто надо в голове разделить сервисы Exchange на реальные сервисы и рассматривать их не как одно целое, а как комплекс.
> негде взять аналитику, которая срезает 90% спамеров ещё на этапе подключения.
На этапе подключения я вам срежу 98-99 % без всякой аналитики( и даже без блэклистов, которыми балуется ironport) Вот вам и пробел в знаниях при использовании черных ящиков «подключил и забыл» 90 процентов это 90 писем из 100, это вообще ниочем.
> Гуглу и MS не очень интересен наш рынок, а Cisco мониторит половину интернета.
Cisco не мониторит почтовый трафик половины интернета.
Не очень понятно деление на наш и не наш рынок в плане срезки спама. Сигнатуры могут отличаться, почтовый трафик у гугла все равно больше. Погрешности минимальны.
>Каждому своё, я не вижу перспективы в своём сервере с Postfix при наличии ПДД или Mail.ru для бизнеса.
В нынешних реалиях держать корпоративную почту(сервера) у российских компаний тоже самое, что отдавать ее конкурентам или любым другим заинтересованным лицам в погонах.
В профессиональном же плане это вас не развивает, наоборот. Или же направление именно вашей деятельности вообще совсем другое, тогда не стоит вам заниматься сервисами, которые связанны с внутрикорпоративной информацией или безопасностью.
И нет никакого такого сервера с Postfix. Есть сервис Postfix. Почтовая же система — это кластер из множества различных сервисов.
И вы опять путаете mta и mda
Какой смысл их рассматривать отдельно? Отдельно MTA нужен только сервисам рассылок и Яндекса с их хайлоадом, а компании внедряют интегрированное решение.
HA баз данных нет? HA storage нет? Да этих реализаций существует огромное количество.
Консистентные на уровне приложений, с lagged copy, защитой очереди и минимальным оверхедом?
90 процентов это 90 писем из 100, это вообще ниочем.
Я немного перепутал проценты:
На этапе подключения я вам срежу 98-99 % без всякой аналитики( и даже без блэклистов, которыми балуется ironport)
Поделитесь секретом, только без грейлистинга — это зло похлеще RBL.
Cisco не мониторит почтовый трафик половины интернета.
Выше привёл ссылку на это.
В нынешних реалиях держать корпоративную почту(сервера) у российских компаний тоже самое, что отдавать ее конкурентам или любым другим заинтересованным лицам в погонах.
Какие риски у турагенства, кафе или стоматологической клиники? Это не Ростелеком чтобы в онайне сливать всё в ФСБ, да и силовики пока не голодают для продажи секретов первому встречному.
В профессиональном же плане это вас не развивает, наоборот.
Компания покупает решение задачи и в этом очень помогают продукты Cisco, Microsoft и других. Даже Google купил Postini для борьбы со спамом в GMail.
P.S. Вспомнил про один фатальный недостаток Exchange — управление группами с внешними получателями сделано чудовищно, хотя с учётом его интеграции в AD другое решение будет выглядит костылём.
> Какой смысл их рассматривать отдельно?
Чтобы не путать их и не ставить DAG в пример, когда речь идет об MTA.
> Поделитесь секретом, только без грейлистинга — это зло похлеще RBL.
Да, грейлистами. Только я считаю, что зло это RBL, так как из-за RBL вы можете потерять честный трафик, а из-за грейлиста нет. ( те тоже можете, но это должен быть совсем криво настроенный сервер не соблюдающий RFC)
> Какие риски у турагенства, кафе или стоматологической клиники?
Согласен, мелким компаниям можно не тратить деньги на почтовые сервера.
Чтобы не путать их и не ставить DAG в пример, когда речь идет об MTA.
> Поделитесь секретом, только без грейлистинга — это зло похлеще RBL.
Да, грейлистами. Только я считаю, что зло это RBL, так как из-за RBL вы можете потерять честный трафик, а из-за грейлиста нет. ( те тоже можете, но это должен быть совсем криво настроенный сервер не соблюдающий RFC)
> Какие риски у турагенства, кафе или стоматологической клиники?
Согласен, мелким компаниям можно не тратить деньги на почтовые сервера.
— Это как раз ни разу не проблема.
Перегонял с помощью ImapSync почту из exim/dovecot в Exchange 2013. Удобно, что можно сначала в фоне перегнать основной объём, а потом перед переходом уже инкрементно быстро «догнать».
Специально развернул для тестирования виртуалки на Centos и Ubuntu для ImapSync. Результат — глюк на глюке с кодировками. Примерно 5% писем — в треш. Постоянные вылеты по ошибке. Потом собрал, как и автор ImapSync из исходников на Windows.
Итого:
1) Из терабайта почты только примерно 100 Mb не перенеслось на автомате.
2) Скорость оказалась выше примерно в полтора раза. Конфигурации виртуалок были одинаковые. Выполнялось под Win 8.1 Pro x64.
Минусы: пришлось подбирать версию Perl, с которой собралось без ошибок.
Вот эта связка оказалась самой удачной:
Here is a [MSWin32] system (Windows NT 6.2 Build 9200 amd64)
With perl 5.16.3 Mail::IMAPClient 3.35
$Id: imapsync,v 1.637
Строка в «родном» батнике использовалась следующая:
@imapsync --host1 10.100.100.1 --user1 %%G --password1 %%H --port1 143 --authmech1 LOGIN --host2 mail.MyDomain.ru --user2 %%I --password2 %%J --port2 993 --ssl2 --maxsize 50000000 --maxlinelength 9900 --regexflag «s/\\Flagged//g» --disarmreadreceipts --addheader --no-modules_version --showpasswords
Перегонял с помощью ImapSync почту из exim/dovecot в Exchange 2013. Удобно, что можно сначала в фоне перегнать основной объём, а потом перед переходом уже инкрементно быстро «догнать».
Специально развернул для тестирования виртуалки на Centos и Ubuntu для ImapSync. Результат — глюк на глюке с кодировками. Примерно 5% писем — в треш. Постоянные вылеты по ошибке. Потом собрал, как и автор ImapSync из исходников на Windows.
Итого:
1) Из терабайта почты только примерно 100 Mb не перенеслось на автомате.
2) Скорость оказалась выше примерно в полтора раза. Конфигурации виртуалок были одинаковые. Выполнялось под Win 8.1 Pro x64.
Минусы: пришлось подбирать версию Perl, с которой собралось без ошибок.
Вот эта связка оказалась самой удачной:
Here is a [MSWin32] system (Windows NT 6.2 Build 9200 amd64)
With perl 5.16.3 Mail::IMAPClient 3.35
$Id: imapsync,v 1.637
Строка в «родном» батнике использовалась следующая:
@imapsync --host1 10.100.100.1 --user1 %%G --password1 %%H --port1 143 --authmech1 LOGIN --host2 mail.MyDomain.ru --user2 %%I --password2 %%J --port2 993 --ssl2 --maxsize 50000000 --maxlinelength 9900 --regexflag «s/\\Flagged//g» --disarmreadreceipts --addheader --no-modules_version --showpasswords
А есть инструменты для бэкапа почты по IMAP на компьютер с Win?
Нормальный imapsync это
docker pull skempken/imapsync
:)
docker pull skempken/imapsync
:)
> Вот нормальный imapsync:
> make install
рутом, ага.
Нормальный imapsync: sudo dnf install imapsync; man imapsync.
PS. а так да — автор забыл вставить тег «Windows»
> make install
рутом, ага.
Нормальный imapsync: sudo dnf install imapsync; man imapsync.
PS. а так да — автор забыл вставить тег «Windows»
Добавил тег
под пользователем у вас не хватит прав, чтобы записать в /usr/bin/
install: cannot create regular file '/usr/bin/imapsync': Permission denied
И я удивлен, что у Федоры он есть в репозитарии. В debian/ubuntu/centos его нет.
install: cannot create regular file '/usr/bin/imapsync': Permission denied
И я удивлен, что у Федоры он есть в репозитарии. В debian/ubuntu/centos его нет.
> под пользователем у вас не хватит прав, чтобы записать в /usr/bin/
man sudo
> И я удивлен, что у Федоры он есть в репозитарии. В debian/ubuntu/centos его нет.
Повод стать мейнтейнером деба :-)
man sudo
> И я удивлен, что у Федоры он есть в репозитарии. В debian/ubuntu/centos его нет.
Повод стать мейнтейнером деба :-)
> man sudo
Как-то даже неудобно писать о том, что технически разницы между # make install и $sudo make install нет. Те ваш изначальный комментарий противоречит самому себе.
Это уже похоже на троллинг. Я заканчиваю беседу.
Как-то даже неудобно писать о том, что технически разницы между # make install и $sudo make install нет. Те ваш изначальный комментарий противоречит самому себе.
Это уже похоже на троллинг. Я заканчиваю беседу.
> Как-то даже неудобно писать о том, что технически разницы между # make install и $sudo make install нет.
Технически разница есть (man sudoers), но Вы правы — это была шутка.
Естественно ни «make install» рутом ни «sudo make install» пользователем нельзя делать ни в коем случае.
Надо ставить из пакетов.
Технически разница есть (man sudoers), но Вы правы — это была шутка.
Естественно ни «make install» рутом ни «sudo make install» пользователем нельзя делать ни в коем случае.
Надо ставить из пакетов.
> Технически разница есть (man sudoers)
нет. Или объяснитесь.
> ни в коем случае.
А что вы делаете, когда пакета нет? Машете рукой, типа да не очень-то и хотелось, пойду лучше пива выпью ) Или собираете пакет сами?
P.S. Мы понимаем, что самостоятельная сборка приводит к усложнению апдейта системы. Просто вы настолько же категоричны, насколько неправы.
нет. Или объяснитесь.
> ни в коем случае.
А что вы делаете, когда пакета нет? Машете рукой, типа да не очень-то и хотелось, пойду лучше пива выпью ) Или собираете пакет сами?
P.S. Мы понимаем, что самостоятельная сборка приводит к усложнению апдейта системы. Просто вы настолько же категоричны, насколько неправы.
>> Технически разница есть (man sudoers)
> нет. Или объяснитесь.
В /etc/sudoers можно накрутить всякоразно ограничений для sudo. За запрет на «rm -rf /» не скажу, но что можно запускать, а что нельзя — накрутить можно.
> > ни в коем случае.
> А что вы делаете, когда пакета нет? Машете рукой, типа да не очень-то и хотелось, пойду лучше пива выпью ) Или собираете пакет сами?
Вы не поверите, но именно собираю пакет. Это не слишком сложно, зато на порядок безопаснее. Особенно если использовать чужие машины (типа OpenSuse Build Service или Fedora koji).
Куда сложнее искать каждый раз, не завалялось ли у кого нечаянно «rm -rf /» (или его аналог) в make install. Случаи были. Просто из-за неаккуратности девелов.
> нет. Или объяснитесь.
В /etc/sudoers можно накрутить всякоразно ограничений для sudo. За запрет на «rm -rf /» не скажу, но что можно запускать, а что нельзя — накрутить можно.
> > ни в коем случае.
> А что вы делаете, когда пакета нет? Машете рукой, типа да не очень-то и хотелось, пойду лучше пива выпью ) Или собираете пакет сами?
Вы не поверите, но именно собираю пакет. Это не слишком сложно, зато на порядок безопаснее. Особенно если использовать чужие машины (типа OpenSuse Build Service или Fedora koji).
Куда сложнее искать каждый раз, не завалялось ли у кого нечаянно «rm -rf /» (или его аналог) в make install. Случаи были. Просто из-за неаккуратности девелов.
Может надо собрать пакет, а не делать make install?
> Как-то даже неудобно писать о том, что технически разницы между # make install и $sudo make install нет
при:
1. /etc/groups: wheel: ..., Вы
2. /etc/sudoers: %wheel ALL=(ALL) NOPASSWD: ALL
скорее всего нет.
при:
1. /etc/groups: wheel: ..., Вы
2. /etc/sudoers: %wheel ALL=(ALL) NOPASSWD: ALL
скорее всего нет.
Для аналогичной цели использовал Larch (https://github.com/rgrove/larch):
$ gem install larch
$ larch --from imaps://mail.example.com --to imaps://imap.gmail.com --all --exclude Spam Trash Drafts "[Gmail]/*"
$ gem install larch
$ larch --from imaps://mail.example.com --to imaps://imap.gmail.com --all --exclude Spam Trash Drafts "[Gmail]/*"
Он, к сожалению, больше не поддерживается
Кстати под виндой не собирается.
Installing package 'Unicode-String'…
Error installing package 'Unicode-String': Read a PPD for 'Unicode-String', but
it is not intended for this build of Perl (MSWin32-x86-multi-thread-64int-5.24)
Собирается. Нужно использовать соответствующую версию perl.
или взять готовую версию у автора https://imapsync.lamiral.info/dist2/
Обновил статью, уточнил какие версии стоит использовать, чтоб избежать ошибок компиляции.
А кто подскажет по миграции, пытаюсь мигрировать из Exchange 2010 в Gmail, но не могу победить вложенные папки — в Exchange у меня, например, Inbox и пара папок Test1 и Test2 внутри. А на gmail они переезжают как две равноправные папки-лэйблы INBOX/Test1 и INBOX/Test2.
А хотелось бы как _InBox и внутри Test1 и Test2 и так далее.
А хотелось бы как _InBox и внутри Test1 и Test2 и так далее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IMAPSync. Перенос почты между серверами