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 как обычный ящик и оттуда форвардить на командный?
Разрешающие и запрещающие доступы суммируются по группам (т.е. у пользователя будет сумма доступов, которые у него есть на прямую и по всем группам, куда он входит, аналогично с запретами), при этом запрещающие правила приоритетней.
Во-первых, никогда не используйте пользователей в списках доступа, исключение - только их личные (домашние) папки или профили. Всегда создавайте ролевую группу, даже если там будет только один пользователь.
Во-вторых, никогда не давайте разрешения на доступ напрямую к ресурсам (например папкам) даже пользовательским (ролевым) группам. Для доступа к ресурсам обычно создаются ресурсные группы (они могут быть локальными), например для доступа к определенной категории файлов может быть создано две ресурсных группы - одна на чтение, другая на чтение и запись, ролевые группы добавляются в ресурсные группы. Это сильно упрощает управление доступом и делает его понятным.
По рекомендациям Microsoft, доступ пользователей к ресурсам организуется именно так
Пользователь -> Ролевая группа -> Ресурсная группа -> Ресурс
Это правильный ответ на вопрос, но вопрос задан неправильно.
Почта для домена не подходит для массовых рассылок, на любой почте для домена будут рейтлимиты и ограничения, она предназначена для "человеческой" переписки. Для отправки атоматических уведомлений, транзакционных, маркетинговых писем следует использовать либо специализированные сервисы (Amazon SES, MailChimp и т.п., их много) либо слать их напрямую со своего сервиса, при условии правильных настроек. Очень опасно в плане доставляемости отправлять автоматические письма с тех же серверов, с которых идет "человеческая" переписка.
Даже если нет, поведение может оказаться неожиданным: например, пользователь с телефона в машине нажал кнопочку "удалить", улетел GET_запрос на удаление, сотовая сеть пропала и заново подключилась раньше, чем прилетел ответ от сервера, запрос улетел второй раз - прилетела ошибка, что удаляемый объект отсутствует (хотя в реальности ошибок не было, он корректно удален). В случае POST запроса данные никогда не будут автоматически отправляться повторно, вы можете обработать сетевую ошибку на клиенте, например запросив статус объекта прежде чем повторить операцию.