Владимир Дубровин

Можно, если хотя бы на одном из ноутбуков прямое подключение к Internet с реальным IP-адресом или через маршрутизатор, позволяющий публикацию FTP-серверов с реальным IP-адресом на маршрутизаторе.

TCP защищает от случайных повреждений, для этого к пакету добавляется 32-битная чексума. Вероятность повреждения пакета вообще не очень высока, т.к. чексумы есть еще и на канальном уровне, случайное повреждение такое, что сойдется чексума исключительно маловероятно. Но чексума защищает не от всех повреждений данных и точно не защищает от умышленных. Например если в каждом октете занулять какой-либо бит, то чексума сойдется. Дальше все зависит от ваших потребностей. Но добавлять свою чексуму большого смысла точно нет, если вы хотите более надежно защищать данные - защищайте их криптографически. Вы можете это делать пустив свой протокол поверх SSL/TLS, совсем не обязательно городить защиту внутри протокола.

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

Юникод-кодировки UTF-8 и UTF-16 обе содержат в том числе и символы иврита.

bind не лазит в текстовые файлы в процессе работы, это было бы слишком медленно, все записи из файлов зон считываются при загрузке зоны и заносятся в кэш. После изменения зоны достаточно сказать
rndc reload имя_зоны

Если вы регулярно производите операции надо зоной, удобней всего сделать пару скриптов (добавить запись/убрать запись), которые буду производить изменения в зоне, инкрементить serial и делать rndc reload для зоны.

Храните Folder+UID и хэш от заголовков сообщения. В заголовках помимо Message-ID есть еще и идентификаторы очередей, поэтому вероятность, что совпадут заголовки целиком практически отсутствует.
Если письмо переносится в другую папку и меняется Folder+UID - берите хэш от заголовков, и ишите нет ли письма с другим Folder+UID с таким же хэшем, если есть, то считайте дублем.

Пропавшие Folder+UID помечайте как удаленные и убивайте по завершении сеанса.

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

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

Вам надо договариваться с хостером, чтобы они включили ваш блок в свои анонсы и настроили его роутинг на ваш сервер.

biz.mail.ru, как уже посоветовали

второй способ - в ящике на mail.ru подключить сбор почты с info@domen.ru, тогда в интерфейсе mail.ru можно использовать info@domen.ru для отправки.

третий способ - просто залогиниться в интерфейсе mail.ru ящиком info@domen.ru, тогда mail.ru будет работать как веб-интерфейс к данному ящику. Можно переключаться между разными ящиками или залогинить разные ящики в разных вкладках.

Письма отправленные через SMTP не хранятся сервером. GMail в данном случае является не правилом, а исключением.
В почтовых приложениях (Thunderbird и т.п.) использующих IMAP само почтовое приложение сохраняет копию письма в отправленных.

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

Это возможно в двух случаях:
1. Доступна передача зоны (что является ошибкой конфигурации)
2. Для домена настроен DNSSEC
в остальных случаях только брутфорс, т.е. угадывать имена подбором.