Владислав Лысков, станное заявление, такое можно сделать только если вы вообще темой не просто не интересовались, но и старательно избегали, т.к. с нулевых в верстке поменялось примерно все. Сейчас де-факто стандарт - адаптивная верстка, хотя стандарт принят в 2014, а многие сервисы поддержали только в последние пару лет. В конце марта этого года, например, сразу несколько крупных сервисов поддержали AMP, который добавляет динамический контент и интерактивность в письма и тоже рискует стать де-факто стандартом.
При наличии >1 получателя они не записываются в Received, чтобы не раскрывать получателей скрытой копии (или подписчиков списка рассылки). Это стандартное поведение. Видимо, адрес info@ сразу раскрывается в список рассылки и в нем сразу оказывается более одного получателя, поэтому его не видно никогда.
А нет варианта завести info как обычный ящик и оттуда форвардить на командный?
Разрешающие и запрещающие доступы суммируются по группам (т.е. у пользователя будет сумма доступов, которые у него есть на прямую и по всем группам, куда он входит, аналогично с запретами), при этом запрещающие правила приоритетней.
Во-первых, никогда не используйте пользователей в списках доступа, исключение - только их личные (домашние) папки или профили. Всегда создавайте ролевую группу, даже если там будет только один пользователь.
Во-вторых, никогда не давайте разрешения на доступ напрямую к ресурсам (например папкам) даже пользовательским (ролевым) группам. Для доступа к ресурсам обычно создаются ресурсные группы (они могут быть локальными), например для доступа к определенной категории файлов может быть создано две ресурсных группы - одна на чтение, другая на чтение и запись, ролевые группы добавляются в ресурсные группы. Это сильно упрощает управление доступом и делает его понятным.
По рекомендациям Microsoft, доступ пользователей к ресурсам организуется именно так
Пользователь -> Ролевая группа -> Ресурсная группа -> Ресурс
Это правильный ответ на вопрос, но вопрос задан неправильно.
Почта для домена не подходит для массовых рассылок, на любой почте для домена будут рейтлимиты и ограничения, она предназначена для "человеческой" переписки. Для отправки атоматических уведомлений, транзакционных, маркетинговых писем следует использовать либо специализированные сервисы (Amazon SES, MailChimp и т.п., их много) либо слать их напрямую со своего сервиса, при условии правильных настроек. Очень опасно в плане доставляемости отправлять автоматические письма с тех же серверов, с которых идет "человеческая" переписка.
Barnie Savington, понятия не имею, будут ли проблемы, потому что два интерфейса с одинаковым адресом это не самая стандартная ситуация. А что мешает задать под Linux разные адреса интерфейсам?
А вы доступность портов как проверяете? Не любой NAT поддерживает трансляцию запросов из внутренней сети во внутреннюю сеть, поэтому доступность внешних портов надо проверять снаружи.
korobey, я же написал, зачем внутренней инфраструктуре провайдера назначать белые адреса, с маршрутизаторов нет необходимости обращаться в интернет и к ним из интернета тоже нет необходимости обращаться. Это не мешает пропускать им через себя трафик до "белых" адресов.
