Никита Мелихов, для FTP через TLS в режиме ftp-прокси годится только режим "open", причем надо, чтобы клиент его правильно поддерживал (устанавливал TLS после команды open а не до).
Никита Мелихов, если у вас не работает FTP, то и через ftp-прокси не будет работать, т.к. там тот же самый FTP. Попробуйте использовать пассивный режим FTP между клиентом и прокси. Если не поможет - используйте SOCKS прокси, а не FTP.
parent выбирается случайно для каждого исходящего соединения с учетом веса при установке соединения.
Если несколько запросов к одному серверу идут через одно соединение (keep-alive), они попадают на один parent.
В 3proxy есть сервис admin с зачатками web-интерфейса (в основном для доступа к счетчикам трафика).
Информация о том, как поддержать 3proxy есть в "Помощь проекту".
Любая CRM-система регистрирут вложения. Если вам сами вложения мешаются, так удаляйте их, раз в сутки, например.
Только со временем вы поймете, что этого не требуется, и пересадите ваших сотрудников с общего ящика почты на CRM-систему.
Относительно легко можно сделать случайную ротацию для каждого запроса, см. команду parent. Ротацию раз в 5 минут можно сделать, но для этого необходимо добавить запись allow+parent для каждого 5-минутного интервала в течении суток, см. команду allow.
setrus52, если у вас могут появиться новые объекты с тем же идентификатором, что был у удаленного объекта, то повторный запрос может удалить "неправильный" объект.
Даже если нет, поведение может оказаться неожиданным: например, пользователь с телефона в машине нажал кнопочку "удалить", улетел GET_запрос на удаление, сотовая сеть пропала и заново подключилась раньше, чем прилетел ответ от сервера, запрос улетел второй раз - прилетела ошибка, что удаляемый объект отсутствует (хотя в реальности ошибок не было, он корректно удален). В случае POST запроса данные никогда не будут автоматически отправляться повторно, вы можете обработать сетевую ошибку на клиенте, например запросив статус объекта прежде чем повторить операцию.
Dorothy, вот и поставьте локальный резолвер. Мало ли что и как зарезано или зарейтлимичено на провайдерском DNS. В момент получения письма делается практически одновременно целая пачка запросов (PTR, rDNS, A по HELO, MXы отправителя и возможно получателя, A по MXам, пачка DNSBL, SPF, DMARC, DKIM). Причем часть из них дважды, потому что сначала MTA а потом спамассасин. А локальный резолвер еще и кешировать будет.
Владислав Лысков, адаптивная верстка делается, чтобы письмо нормально выглядело на мобильных клиентах, где сейчас смотрится 70% писем. Если вы отправляете маркетинговые письма по стандартам нулевых, то 70% ваших получателей видят треш и содомию.
Владислав Лысков, станное заявление, такое можно сделать только если вы вообще темой не просто не интересовались, но и старательно избегали, т.к. с нулевых в верстке поменялось примерно все. Сейчас де-факто стандарт - адаптивная верстка, хотя стандарт принят в 2014, а многие сервисы поддержали только в последние пару лет. В конце марта этого года, например, сразу несколько крупных сервисов поддержали AMP, который добавляет динамический контент и интерактивность в письма и тоже рискует стать де-факто стандартом.
При наличии >1 получателя они не записываются в Received, чтобы не раскрывать получателей скрытой копии (или подписчиков списка рассылки). Это стандартное поведение. Видимо, адрес info@ сразу раскрывается в список рассылки и в нем сразу оказывается более одного получателя, поэтому его не видно никогда.
А нет варианта завести info как обычный ящик и оттуда форвардить на командный?
