Разрешающие и запрещающие доступы суммируются по группам (т.е. у пользователя будет сумма доступов, которые у него есть на прямую и по всем группам, куда он входит, аналогично с запретами), при этом запрещающие правила приоритетней.
Во-первых, никогда не используйте пользователей в списках доступа, исключение - только их личные (домашние) папки или профили. Всегда создавайте ролевую группу, даже если там будет только один пользователь.
Во-вторых, никогда не давайте разрешения на доступ напрямую к ресурсам (например папкам) даже пользовательским (ролевым) группам. Для доступа к ресурсам обычно создаются ресурсные группы (они могут быть локальными), например для доступа к определенной категории файлов может быть создано две ресурсных группы - одна на чтение, другая на чтение и запись, ролевые группы добавляются в ресурсные группы. Это сильно упрощает управление доступом и делает его понятным.
По рекомендациям Microsoft, доступ пользователей к ресурсам организуется именно так
Пользователь -> Ролевая группа -> Ресурсная группа -> Ресурс
Это правильный ответ на вопрос, но вопрос задан неправильно.
Почта для домена не подходит для массовых рассылок, на любой почте для домена будут рейтлимиты и ограничения, она предназначена для "человеческой" переписки. Для отправки атоматических уведомлений, транзакционных, маркетинговых писем следует использовать либо специализированные сервисы (Amazon SES, MailChimp и т.п., их много) либо слать их напрямую со своего сервиса, при условии правильных настроек. Очень опасно в плане доставляемости отправлять автоматические письма с тех же серверов, с которых идет "человеческая" переписка.
Barnie Savington, понятия не имею, будут ли проблемы, потому что два интерфейса с одинаковым адресом это не самая стандартная ситуация. А что мешает задать под Linux разные адреса интерфейсам?
А вы доступность портов как проверяете? Не любой NAT поддерживает трансляцию запросов из внутренней сети во внутреннюю сеть, поэтому доступность внешних портов надо проверять снаружи.
korobey, я же написал, зачем внутренней инфраструктуре провайдера назначать белые адреса, с маршрутизаторов нет необходимости обращаться в интернет и к ним из интернета тоже нет необходимости обращаться. Это не мешает пропускать им через себя трафик до "белых" адресов.
korobey, наличие в трассировке адресов RFC1918 ничего не говорит о наличии NAT, маршрутизаторам часто назначается "серый" собственный адрес чтобы они не были доступны извне.
3proxy специально разработан для таких конфигураций.
Проблема не в том, что 3proxy что-то не умеет, а в том, что вы не настроили маршрутизацию для дополнительных IP адресов.
Что вы имеете ввиду под дескриптором, базовый адрес?
Но в любом случае не хватает исходных данных, а что у вас при этом есть? Можно получить, например, адрес какой-нибудь функции из таблицы импорта исполняемого файла, если он уже слинкован с DLL и по нему найти начало DLL в памяти.
Не могу сказать про ePochta Mailer, но Content-ID и ссылки cid: в приложениях для рассылок обычно генерируется уже при отправке, в приложении генерирующем письмо вставка изображения как правило производится каким-то другим способом, специфичным для приложения, например по имени файла или через WYSIWYG редактор. Почитайте документацию по программе, например вот эту статью.
