Thunderbird начиная от версии 3.1 (and 3.0 to some degree) включают в себя функционал автоконфигурации почтового аккаунта. Цель автоконфигурации в создании для пользователей более простого способа настроить соединение клиента с почтовым сервером. В большинстве случаев, пользователь лишь должен загрузить и установить приложение, ввести свое настоящее имя, почтовый адрес и пароль в настройках аккаунта и почтовый клиент полностью готов к работе для получения и отправки писем, настолько безопасной, насколько это возможно .

Способы получения настроек

Thunderbird получает настройки сервера различными способами, каждый из них предназначен для своего случая:

  • ISPDB
    ISPDB - это центральная база данных, которая в настоящий момент принадлежит коммерческой организации Mozilla Messaging, но может быть использована любым клиентом. Она содержит настройки для крупнейших почтовых провайдеров. Мы надеемся что эта база в ближайшем времени будет содержать достаточно информации для автоконфигурирования не менее половины почтовых аккаунтов пользователей.
    Эта база была добавлена из-за нашей уверенности в том, что не все почтовые провайдеры (в том числе Microsoft) сразу же добавят файлы конфигурации для Thunderbird на своих сервера.
  • Конфигурация сервера почтового провайдера
    Почтовые провайдеры  могут предоставить информацию о своих настройках для пользователей, настроив автоконфигурацию на своем сервере. <домен>, который просто возвращает статический XML с настройками, как описано ниже. При более сложных настройках, когда, например, логин не отображается в почтовом адресе XML-файл может быть также сгенерирован провайдером. В таких случаях это единственный способ получить автоматическую настройку.
  • Файл конфигурации на жестком диске
    Администраторы могут поместить файл конфигурации в установочную папку Thunderbird. Этот способ предназначен для компаний, которые устанавливают Thunderbird на компютеры своих сотрудников и хотят получить легкую настройку учетной записи без необходимости настраивать конфигурацию почтового сервера. Этот метод не стоит применять в других случаях, потому что обновлять файл конфигурации весьма трудно. Таким образом, публичным провайдерам рекомендуется использовать конфигурации сервера.
  • Подборка наугад
    В том случае, когда другими способами определить настройки не получилось, Thunderbird пытается угадать конфигурацию, пробуя распространенные имена почтовых серверов типа imap.<domain>, smtp.<domain>, mail.<domain> и так далее, и, когда сервер отвечет, проверяет поддержку SSL, STARTTLS и шифрование паролей (CRAM-MD5).
  • Ручная настройка
    Если угадать не получается, пользователь должен ввести настройки вручную. Пользователь может также изменить настройки, даже если они были получены способами описанными выше.

В openssh есть возможность ограничить доступ пользователя в подсистеме sftp. Т.е. задать ему ChrootDirectory, как в proftpd. Например в домашнюю папку (ибо нефиг лазить за её пределами). Рассмотрим, как это можно реализовать.

Для начала, создадим группу sftpusers. Ограничения будут действовать только на пользователей из этой группы (мы ведь не хотим ограничивать пользователя root?):

addgroup --system sftpusers

Далее заменим подсистему sftp в /etc/ssh/sshd_config:

-Subsystem sftp /usr/lib/openssh/sftp-server
+Subsystem sftp internal-sftp

Ну и наконец запишем ограничения в тот же файл:

Match Group sftpusers
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Не забываем перечитать конфиг:

invoke-rc.d ssh reload
Продолжаю настройку своего почтового сервера.
В этой заметке речь будет о проверке DKIM у входящих сообщений Exim.

# Добавляем в список ACL для обработки:
acl_smtp_dkim = acl_check_dkim

# ...

# Можно разместить в начале, где задаются переменные для DKIM-отправки
# Это значит, чьи подписи мы будем точно проверять
DKIM_KNOWN_SIGNERS = paypal.com : gmail.com
dkim_verify_signers = $dkim_signers : KNOWN_DKIM_SIGNERS

# ...

# Создаем сам ACL в секции "begin acl"

# ...

# DKIM check
acl_check_dkim:

        accept  hosts           = +relay_from_hosts
        accept  authenticated   = *

        # Message without sign
        accept  dkim_status     = none
                condition       = ${if eq {$acl_c_dkim_hdr}{1} {no}{yes}}
        set     acl_c_dkim_hdr  = 1
                add_header      = :at_start:X-DKIM: Exim 4.71 on $primary_hostname (no dkim signature)

        # Message with sign, begin
        warn    condition       = ${if eq {$acl_c_dkim_hdr}{1} {no}{yes}}
        set     acl_c_dkim_hdr  = 1
                add_header      = :at_start:X-DKIM: Exim 4.71 on $primary_hostname

        # Message with sign, bad signature
        deny    dkim_status     = fail
                message         = Rejected: $dkim_verify_reason
                logwrite        = X-Auth: DKIM test failed: (address=$sender_address domain=$dkim_cur_signer), signature is bad.

        # Message with sign, invalid signature
        accept  dkim_status     = invalid
                add_header      = :at_start:Authentication-Results: $primary_hostname $dkim_cur_signer ($dkim_verify_status); $dkim_verify_reason
                logwrite        = X-Auth: DKIM test passed (address=$sender_address domain=$dkim_cur_signer), but signature is invalid.

        # Message with sign, good signature
        accept  dkim_status     = pass
                add_header      = :at_start:Authentication-Results: $primary_hostname; dkim=$dkim_verify_status header.i=@$dkim_cur_signer
                logwrite        = X-Auth: DKIM test passed (address=$sender_address domain=$dkim_cur_signer), good signature.

        accept
​

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

Используется Exim4 + Dovecot2 + PostfixAdmin

1. Файл /etc/exim4/exim4.conf - ставишь такую секцию которую я привел:

begin authenticators

auth_plain:
driver = dovecot
public_name = PLAIN
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1

auth_login:
driver = dovecot
public_name = LOGIN
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth2

auth_cram_md5:
driver = dovecot
public_name = CRAM-MD5
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth3
Настраиваю сейчас EXIM+много чего ещё, в том числе CLAMAV на Ubuntu 16.04 LTS.

Добавил пользователя clamav в группу Debian-exim,
usermod -G Debian-exim clamav​

но в логе всё равно упорно получаю 
1dfRUU-0001m6-V5 malware acl condition: clamd: ClamAV returned: /var/spool/exim4/scan/1dfRUU-0001m6-V5/1dfRUU-0001m6-V5.eml: lstat() failed: Permission denied. ERROR​

Решение было найдено не быстро, только на второй день.

Иногда бывает так что, на первый взгляд, начинает без причины падать apache, или php-fpm. Никакие CoreDump в этом могут не помогать.
Часто этот процесс представляет собой связку процессов и мониторить их необходимо все, так как заранее неизвестно, каким из процессов будет отработан наш запрос. На этот случай strace умеет принимать набор pid'ов процессов, на каждый процесс свой аргумент -p.

Получаем список всех процессов по имени: 
pidof apache2​

Собираем список аргументов: 
pidof apache2 | sed 's/\([0-9]*\)/\-p \1/g'​

Вызываем strace:
strace -s 1024 -f $(pidof apache2 | sed 's/\([0-9]*\)/\-p \1/g')​