Алексей Черемисин

1) не делать свой почтовый сервер
2) хорошо подумать, и не делать свой почтовый сервер
3) если все равно хочется сделать, но еще раз подумать, и не делать почтовый сервер.
Ну и нужно настроить:
- записи MX, SPF, DKIM
- настроить подписи DKIM
- установить SMTP-вервер (opensmtpd например),
- установить POP и/или IMAP серверы
- настроить TLS на всем этом с сертификатами
- очень желательно настроить антиспам типа spamassist
А также по просьбе старого друга и авторитетного администратора крупных почтовых (и не только) сервисов Alexey Dmitriev

Просьба добавить в свой правильный список - настройку записи DMARC и PTR - для полноты картины.

Без этого тоже никуда никто не едет.
И еще раз крепко подумать, нужна ли Вам эта головная боль и разбирательства, "почему меня все блокируют"...
Один из выходов, хостить почту у провайдеров почты, а себе забирать архивы раз в день...

PS, И да, если уж речь зашла о настройках, Всякие PTR, SPF, MX, DKIM, DMARC и прочие вещи я не всегда знаю сам как автоматизировать. В основном ручками все собираю по привычке и правлю конфиги. А в больших инсталляциях еще и разношу на несколько серверов.
И все равно, почта требует практически еженедельного (если не ежедневного, в больших инсталляциях) присмотра и ухода, чистки очередей, разгрузки сервисов, борьбы со спамом и прочей хренью.

PPS. Лет 25 назад доставляло мне удовольствие, забирать отдавать почту по UUCP по модемному коннекту на организацию в 100 человек :)
Теперь нет никакого удовольствия. Это все равно что содержать ftp-сервер. Старый протокол, старые технологии, куча говна и палок.

Ну и коли пошла такая пьянка, некоторые корпоративные почтовики оборудуют всякими фильтрами:
- первое письмо не проходит, и его нужно ставить в отдельную очередь на минут 20-30 для повторного ответа - не выдержал таймаут - БАН
- первое письмо просто валится в спам - повторная отправка - БАН
- нельзя отправлять почту более 10 ресипиентам - БАН
- пигн-понг короткими сообщениями - иначе БАН

Ну и прочие чудеса эквилибристики почтовых администраторов.

я немного не понял рекурсии: в функции check_time вызываем сами себя? Кажется (покопавшись в мозгах своих), так делать не очень хорошо.
И вместо asyncio.ensure_future(check_time()) пишем loop.ensure_future(check_time())
Сделайте еще одну функцию, которая будет запускать в бесконечном цикле последовательно check_time и asyncio.sleep

import asyncio
from datetime import datetime

async def check_time():
    utc = datetime.now()
    print(utc)

async def checker(timeout):
    while(True):
        await asyncio.sleep(timeout)
        await check_time()

loop = asyncio.get_event_loop()
task = loop.create_task(checker(60))
loop.run_forever()

ЗЫю пришлось открыть редактор... блин...

- если провода идут по воздуху, то нужно обязательно его землить и кабель брать с землей! Типа FTP. Иначе на нем скапливается статика, особенно в сухую погоду. А уж про грозу и говорить не хочу. И для наружной укладки.

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

- второй роутер не нужен
На кабеле есть маркировка метража, так что нужно точно знать, что не более 100 метров

- я бы ушел на оптику, купил бы два трансмиттера и кусок оконцованного оптического кабеля, и закрыл бы проблему навсегда! Кстати, будет даже дешевле, чем FTP.

PS. Кстати, только что заказал для проекта два медиаконвертера TP-Link FL-311A-2 и TP-Link FL-311B-2, плюс оптический патчкорд на 120 метров SC/UPC-SC/UPC, SM 9/125, 120 м, LSZH.
Все вместе: 5400 рублей!

Идея как их отмечать на стороне еластика: иметь в документе поле например USERID_VIEW и добавлять в него ID пользователей которые отметили этот документ, ну и в поиске игнорировать доки которые содержат ID пользователя в USERID_VIEW .

Идея не очень хорошая. Потому что ...

Будет ли еластик держать в поле список 100K+ значений?

Нет, не будет.

Предложить можно следующее:
- держать список просмотренных пользователем документов отдельно от эластика, в отдельной базе (можно использовать какое нибудь KV-хранилище или просто SQL-базу)
- просмотренные документы дополнительно фильтровать программно по этому списку
- если просмотренных документов мало, то вставлять их в запрос на исключение
- или держать короткий список просмотренных документов, например 100-200 позиций, или формировать его, например по дате, и вставлять в запрос

Если загрузка по EFI, то проблем особых быть не должно.
Загрузитесь с Live CD и через GParted подвигайте разделы.
То лучше переставить систему через clonezilla например.

Установите gstreamer и используйте биндинги к яве https://github.com/gstreamer-java/gst1-java-core

Лучше всего для данной задачи подходят базы данных, основанные на алгоритмах класса r-tree/r-tree+. Например postgis для постгреса или elasticsearch.

Используйте set и операцию дизьюнкции ^
Примеры в ответе здесь https://stackoverflow.com/questions/32815640/how-t...
Или здесь https://www.google.com/amp/s/www.geeksforgeeks.org...

Самый простой способ - установить реверсивный прокси. И уже в нем настроить политики отдачи и перенаправления. Это есть и в nginx (см. upstream), и в haproxy (см. use_backend и acl), и в новомодном caddyserver (см. reverse_proxy).
Если нужно проксировать не только http/https, то я бы посмотрел на haproxy внимательней.

Пробрасывать порт нужно 27017, а не 5000!

....
     ports:
        - '27017:27017'
....

PS. И не надо картинки постить. Копируйте текст в теги code, это так просто. Из картинок его не выдрать, а набирать - лень! Я вот поэтому вообще отвечать не хотел...

Подключаетесь к ящику через imap, качаете содержимое, потом разбираете получившееся.
Imaplib и email.parse вам в помошники на питоне.

....
                return int(result.get("money",0))

Все просто
1) На каждый офис по маршрутизатору. (Я бы брал программный на линуксе. Просто комп или сервер с нужным количеством интерфейсов, с с установленным линуксом. Но это я)
2) В каждом офисе своя выделенная и замаскараденная сеть - другими словами, никто никуда не ходит, только интернет.
3) Каждый офис наводит VPN/VLAN/VxLAN с центральным, и по необходимости с нужными соседями
4) На маршрутизаторах разрешаем, какие ресурсы будут доступны внутри центра и филиалов
5) Все доступные ресурсы убираем в зоны DMZ

Во первых, подозреваю, что никому не нужно ходить из офисов непосредственно на компы.
Во вторых, извне все должно быть прикрыто, даже от офиса, ибо нефиг по компам шастать.
В третьих, общие ресурсы тоже не должны быть совместно с компами, ибо иногда их ломают...
В четвертых, тут много всякого, от броадкаста, до dhcp, авторизации и разделения...

Ах, да, есть коммутаторы L3, которые могут не только VLAN, но и VxLAN, и MPLS, и маршрутизацию.
Такие ставьте в центр сети, и рулите маршрутами, доступом и прочим...