The bat ssl настройка

Обновлено: 04.07.2024

Вы можете работать с Яндекс.Почтой с помощью The Bat.

Шаг 1. Настройте ящик

Примечание. Если вы хотите, чтобы письма сохранялись некоторое время после их удаления в почтовой программе, выберите опцию Отключить автоматическое удаление писем, помеченных в IMAP как удаленные . Учтите, что они будут безвозвратно удалены из ящика сразу после перезапуска почтовой программы.

Шаг 2. Создайте пароль приложения

В разделе Пароли и авторизация выберите Включить пароли приложений . Подтвердите действие и нажмите Создать новый пароль .

Если вы включили двухфакторную аутентификацию, просто нажмите Создать пароль приложения .

Придумайте название пароля, например укажите название приложения, для которого вы создаете пароль. С этим названием пароль будет отображаться в списке. Ограничение. Созданный пароль можно увидеть только один раз. Если вы ввели его неправильно и закрыли окно, удалите текущий пароль и создайте новый.

Шаг 3. Настройте программу по протоколу IMAP

Запустите программу и настройте ее с помощью мастера установки. Электронный адрес — ваш почтовый адрес на Яндексе (например, alice.the.girl@yandex. ru );

Если у вас уже настроена учетная запись The Bat! и вы хотите добавить еще одну, откройте Ящик  → Новый почтовый ящик .

Для получения почты использовать — IMAP — Internet Mail Access Protocol v4 ;

В окне Исходящая почта укажите следующие настройки учетной записи:

Включите опцию Мой сервер SMTP требует аутентификации .

В окне Сведения об учетной записи нажмите кнопку Готово .

Синхронизируйте созданную учетную запись с сервером, чтобы получить список папок. Для этого нажмите правой кнопкой мыши на название ящика и выберите пункт Обновить дерево папок . Нажмите правой кнопкой мыши на название ящика и выберите пункт Свойства почтового ящика . Слева перейдите в меню Управление почтой . В поле справа найдите блок Использование папок IMAP в качестве стандартных . Включите опцию Отправленные и выберите из списка значение Отправленные . В том же блоке включите опцию Корзина и выберите из списка значение Удаленные . Затем перейдите к блоку Автоматически соединяться с сервером и установите значение при запуске The Bat! . Нажмите пункт Управление почтой  → Удаление и укажите в качестве папки для нормального и альтернативного удаления папку Удаленные . Также отключите опцию Использовать альтернативное удаление для старых писем и включите опцию Автоматически сжимать папки после опустошения . Нажмите пункт Параметры и включите опции Проверять при запуске The Bat! и Сжать все папки при выходе из The Bat! .

Решение проблем с The Bat!

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

«Нет соединения с сервером» «Authentication required», «Sender address rejected: Access denied» или «Send auth command first» «Sender address rejected: not owned by auth user» «Login failure or POP3 disabled» «Message rejected under suspicion of SPAM» «Bad address mailbox syntax»

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

Авторизоваться получилось, ошибки нет Авторизоваться получилось, но ошибка всё еще есть Авторизоваться не получилось

Значит, проблема была в том, что вы не приняли условия пользовательского соглашения сервисов Яндекса. Они принимаются автоматически, когда вы впервые авторизуетесь на Яндекс.Почте.

Если вы состоите в организации и проблема воспроизводится во всех ящиках домена, нужно для каждого из них авторизоваться на Яндекс.Почте. Сделать это централизованно не получится, потому что каждый пользователь Почты должен принять условия самостоятельно.

Убедитесь, что в настройках почтовой программы вы точно указали\\n следующие параметры серверов:

Подробнее о том, как проверить настройки серверов в разных почтовых\\n программах, см. в разделе Шифрование передаваемых данных.

Убедитесь, что в настройках почтовой программы вы точно указали следующие параметры серверов:

Подробнее о том, как проверить настройки серверов в разных почтовых программах, см. в разделе Шифрование передаваемых данных.

Если авторизоваться не получилось, возможно, в почтовой программе вы используете неверный логин или пароль.

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

Если авторизоваться получилось и ошибки нет, значит, проблема была в том, что вы не приняли условия пользовательского соглашения сервисов Яндекса. Они принимаются автоматически, когда вы впервые авторизуетесь в веб-интерфейсе Яндекс.Почты.

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

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

Если авторизоваться получилось и ошибки нет, значит, проблема была в том, что вы не приняли условия пользовательского соглашения сервисов Яндекса. Они принимаются автоматически, когда вы впервые авторизуетесь в веб-интерфейсе Яндекс.Почты.

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

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

Если авторизоваться получилось и ошибки нет, значит, проблема была в том, что вы не приняли условия пользовательского соглашения сервисов Яндекса. Они принимаются автоматически, когда вы впервые авторизуетесь в веб-интерфейсе Яндекс.Почты.

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

Проверьте ваш компьютер на вирусы с помощью бесплатных антивирусных программ: CureIt! от Dr.Web и Virus Removal Tool от «Лаборатории Касперского».

The Bat: сервер не предоставил корневой сертификат

В целом привязать ошибку к конкретной ситуации нельзя, однако ее значение абсолютно понятно: The Bat! не имеет необходимого SSL-сертификата на момент получения почты с защищенного сервера.

Основной причиной неполадки является то, что мейлер от Ritlabs использует собственное хранилище сертификатов, в то время как подавляющее большинство других программ довольствуется расширяемой базой данных Windows.

Способ 1: сброс хранилища сертификатов

Файлы хранилища сертификатов The Bat! в Windows

Находим путь к почтовому каталогу The Bat!

По умолчанию месторасположение каталога с данными мейлера таково:

Другой вариант устранения неисправности заключается в переходе на систему шифрования от Microsoft. При смене криптопровайдера мы автоматически переводим The Bat! на использование системного хранилище сертификатов и тем самым исключаем конфликты баз данных.

Меняем криптопровайдера в программе The Bat! для Windows

Закрыть

Мы рады, что смогли помочь Вам в решении проблемы.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Закрыть

Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.

Опишу здесь только то что связано с настройками SSL на сервере и на клиенте.

Содержание

Настройка сервера

Создание сертификата сервера

Сразу скажу, что реализация данной части - дело тяжелое. Потому что будет очень много рутинной возни, если делать все по правилам.

Первым делом нам понадобится доверенный сертификат - Certificate Authority (далее CA), чтобы иметь возможность подписывать и проверять клиентские сертификаты. Если все делать по правилам, то такой сертификат нужно создать, а затем подписать его у одного из корневых доверенных центров сертификации. Но это стоит денег. Если ваша организация заинтересована, ска жем, в развитии своего представительства в Internet, то именно это и стоит сделать. Но если вы всего лишь небольшая фирма, которая нуждается всего-навсего в почтовом сервере, то можно обойтись самоподписанным доверенным сертификатом.

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

Запускаем скрипт make_ca.sh. Какое-то время он будет возиться с генерацией секретного ключа длиной в 4096 бит, на слабой машине это займет время. можете уменьшить длину ключа до 1024 или 2048 бит, если очень не терпится все поскорее попробовать. В итоге мы получим два файла в каталоге /etc/ssl/ca:
ca.crt - это наш самоподписанным доверенный сертификат, и
ca.key - его секретный ключ.

Создание клиентских сертификатов

Теперь нам необходим скрипт для создания клиентских сертификатов:

Создаем скрипт для создания клиентских сертификатов: /etc/ssl/make_cleint_cert.sh

Прежде чем запускать этот скрипт, создадим файл конфигурации для подписывания запросов на сертификацию: /etc/ssl/ca.config

Скрипт make_ca.sh будет использоваться крайне редко - для первого создания нашего СА, и для генерации нового по истечению срока действия текущего СА. Однако, опцией -days мы устанавливаем срок действия сертификата аж на 10 лет, так что часто это делать не придется, разве что в случае компрометации сертификата (тьфу-тьфу-тьфу!).

Скрипт make_cleint_cert.sh будет использоваться нами гораздо чаще, чем хотелось бы - если все делать по правилам. То есть, мы должны выдать уникальный сертификат каждому сотруднику, имеющему почтовый ящик на нашем сервере. Причем выдать его на не слишком дли тельный срок, в идеале - месяца на 3, но во всяком случае не больше, чем на год. А по прошествии этого срока выдать всем новые сертификаты. Прибавьте к этому увольняемых и нанимаемых сотрудников. в общем, если у вас много народу - этим лучше заниматься специальной группе security officer's. Зато при этом у вас будет полноценный шифрованный канал с авторизацией и аутентификацией пользователей.

Но можно поступить и проще. Создать всего лишь один клиентский сертификат, не на персону, а на всю контору, и использовать его. И можно еще дополнительно облегчить себе жизнь, за дав ему срок действия, равный сроку действия СА. Лет эдак на 20. Все это, естественно, будет делаться в ущерб безопасности, так как ни о какой аутентификации пользователей речи не идет, да и в случае кражи сертификата вы можете очень нескоро узнать об этом. Но шифрование у вас все равно останется. Какой вариант выбрать - решайте сами.

Теперь создадим клиентский сертификат. Запустим скрипт make_cleint_cert.sh с параметрами имя_клиента e-mail клиента пароль на файл клиентского сертификата:

Сначала опять будет генерироваться ключ, затем будет создан и подписан сертификат пользователя. На экран вываливается информация о сертификате, и вот мы получили все необходимое:

Настройка почтового клиента BAT для работы с SSL сертификатом

Запускаем The Bat!. Выбираем наш почтовый ящик, идем в Свойства почтового ящика - Общие сведения. Видим там кнопочку Сертификаты, и нажимаем ее. В открывшемся окне нажимаем кнопку Импортировать. и открываем файл client_Test_User.p12. В окне Пароль PFX - Введите пароль по расшифровке данных, хранимых в client_Test_User.p12 вводим пароль на файл клиентского сертификата - q1w2e3. Вылезает окно Пароль PFX - Введите пароль для расшифровки личного ключа, хранимого client_Test_User.p12 - еще раз вводим q1w2e3. И далее при запросе Сохранить личный ключ в брелоке отвечаем Да. И видим, что в окне теперь отображаются два сертификата - наш персональный и доверенный сертификат сервера. Выбрав любой из них, и нажав кнопку Просмотреть, увидим, что This CA root certificate is not trusted because it is not in the Trusted Root CA. То есть The Bat! не желает просто так доверять нашему самоподписанному сертификату. Исправляем ситуацию, переходим на закладку Путь сертификации, выбираем наш СА, и нажимаем кнопку Добавить к доверенным. На запрос подтверждения отвечаем Да. Теперь ви дим, что наши сертификаты The Bat! считает правильными.

Теперь настроим The Bat! на от правку почты через TLS: идем Пользователь - Свойства почтового ящика - Транспорт и в списке Соединение выбираем Безопасное на стандартный порт (STARTTLS). И дальше все должно работать.

Напишем письмо нашему test user'у, отправим отправим его и посмотрим в логи:

Боже, какой ужас. надо срочно изменить детализацию логов. вместо smtpd_tls_loglevel = 3 поставим smtpd_tls_loglevel = 1. Но главное, мы увидели, что установилось защищенное соеди нение - TLS connection established from unknown[192.168.211.3]: TLSv1 with cipher RC4-SHA (128/128 bits), и наше письмо ушло под его защитой. Но это еще не все. Если мы посмотрим в исходный текст письма на стороне получателя, то увидим там:

То есть, на данный момент имеем защищенное соединение, но не имеем аутентификации.

Настройка аутентификации через TLS

Исправляемся. Добавим в /etc/postfix/main.cf строчки:

Снимем отпечаток с пользовательского сертификата:

и скопируем последовательность разделенных двоеточиями цифр из строки MD5 Finger print в файл usr/local/etc/postfix/fingerprints. После этой числовой последовательности можно (и нужно) для собственной информации и для того, чтобы отработала команда postmap дописать туда имя клиента.
Делаем:

И снова отправим письмо многострадальному ТестЮзеру. Оп-ля. Опять не то, потому что получаем:



Шаг № 4. В данном окне выберите наиболее подходящий вам протокол работы с почтой:

  • IMAP – вся почта хранится на сервере. Выберите IMAP в случае, если вы планируете работать с почтой с нескольких устройств и через веб-интерфейс.
  • POP3 – почта скачивается с почтового сервера. Выберите POP3, если работа с почтой планируется только с одного устройства.



Шаг № 6. В случае правильного ввода всех данных вы попадаете на завершающий экран процесса «Создание нового почтового ящика (Create new user account)». Вам предлагается проверить остальные свойства почтового ящика. Выберите «Да» и нажмите кнопку «Готово».


Шаг № 7. В открывшемся окне свойств почтового ящика перейдите в раздел «Транспорт». В случае, если ваш интернет провайдер блокирует какие-либо порты, во вкладке «Транспорт» вы можете использовать альтернативные.
Для подключения к почтовому серверу доступны следующие порты:

  • IMAP: шифрованное подключение SSL - 993, без шифрования - 143
  • SMTP: шифрованное подключение SSL - 465, без шифрования - 587
  • POP3: шифрованное подключение SSL - 995, без шифрования - 110

Далее нажмите кнопку «Аутентификация».


Шаг № 8. В открывшемся окне выберите «Аутентификация SMTP (RFC-2554)» и «Использовать параметры получения почты (POP3/IMAP)». Для применения изменений нажмите кнопку «ОК».

Читайте также: