CityCat4

mail.example.com на 2.2.2.2 - так TB может быть будет даже автоматом конфигурацию находить. И посмотреть лог на почтовике - приходит ли запрос авторизации от TB. Лог можно сделать поподробнее, может там проявится ошибка.

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

Кроилово ведет к попадалову.

Поднять свой почтовый сервер. И уже на нем развернуть любую систему фильтрации по любым признакам. Я использую черные списки spamhaus, spamcop, dnsbl плюс greylisting. Правда наличие greylisting заметно осложняет отношения с mail.ru и некотрыми другими "особо умными" почтовиками, которые клали вооооот такой болт на почтовые стандарты...

Такого сервиса нет. И видимо уже никогда не будет.

И вот почему.

Когда еще не было спама, все вели себя честно, соблюдали RFC и получив в ответ User unknown, Вы могли с уверенностью сказать - такого юзера нет. Сейчас, когда методы защиты от спама становятся все изощренней, а методы спамеров соответственно тоже не стоят на месте - нет никакой гарантии, что User unknown означает что ящика не существует - он запросто может существовать и активно использоваться - но Ваше письмо не прошло по неким критериям, и чтобы Вы отвязались - получаете User unknown.
Ровно точно так же прием письма сервером совершенно не означает, что письмо прочитано пользователем. Оно может быть доставлено боту, оно может погибнуть в антиспам-фильтре, оно может быть тупо сброшено в /dev/null - без какого-либо уведомления. Пользователь мог давно уволиться, а почта перенаправляться другому или даже просто в помойку.
Елинственный способ - это получить обратную связь от адресата. Пусть кликает на ссылку - если не кликнул в течение какого-то интервала времени - значит аля улю.
В нынешних условиях почта не может являться бизнес-инструментом - слишком много факторов, не зависящих от текущего момента, чтобы письмо не дошло.

Никогда не использовал сторонние серваки под корпоративную почту - даже не потому что кто-то там мне будет указывать, а потому что не нравится мне, когда содержимое почты находится "где-то там" и этот "где-то там" может с ней сделать все что придет в голову. Только собственный сервак. На количество рыл, куда больше чем 40 - от сотни. На самом деле настройка сервака делается один раз, потом ящики просто сами заводятся, а если сбацать скрипт автонастройки TB - то и настройка почты будет сама по себе.

Только бэкап нужно сразу продумать.

Зиллион. Zimbra, SoGo, Horde, Roundcube - на вкус как говорится и цвет...

А зачем его искать? SASL стоит? Тогда это логин и пароль локальных юзеров (или доменных - в зависимости от NSS). Если SASL нет, тогда логин и пароль на SMTP не нужны.

Ээээ...куда перенаправлять-то? На локальный ящик? На другой произвольный адрес?

Если тот, кто купил данную компанию, не имеет намерения предоставлять услуг дальше, он просто выключит сервера :) особенно если это бесплатный почтовик, где вообще никто никому ничем не обязан.

1. Нет.
2. Нет.

Ничего не мешает при регистрации написать вместо имени и фамилии "Дед Мороз". Пока еще бесплатные почтовики и соцсети не обязали делать регистрацию по паспорту :) Но все к этому идет.

Что видно сотрудникам mail.ru и разработчикам приложений - знают только сотрудники mail.ru и разработчики приложений. И это удивительным образом может отличаться от того, что они декларируют о том, что знают...

Если Вас хоть сколько-нибудь заботит безопасность - считайте, что знают всЁ.

Ешкин кот, ошибка написана английским по белому - need full-qualified hostname, то есть полностью определенное имя хоста.

MX-записи к данной задаче не имеют ровно никакого отношения. MX-запись задает адрес сервера, принимающего почту для данного домена. Приоритет же здесь - число, которое задает порядок просмотра серверов, если их несколько. Если есть записи

nichego.net. IN MX 10 test1
            IN MX 20 test2
test1    IN A 1.2.3.4
test2    IN A 1.3.4.5

то при отправке письма на test@nichego.net Ваш сервер сначала попробует соединиться с test1.nichego.net, если же test1 не примет соединение, тогда обратится к test2.nichego.net. Если test1.nichego.net работает, то к test2.nichego.net обращения не будет. Такая конструкция обычно используется для резервирования почты

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