none
Запрет отправки от анонимного пользователя. RRS feed

  • Вопрос

  • Господа, помогите советом.

    Настроил соединитель отправки для получения почты из Интернет.

    имя incoming 

    fqdn mail.myfirm.org

    local ip: 192.168.0.x 25

    remote ip: 0.0.0.0 - 255.255.255.255

    проверка подлинности TLS

    Группы разрешений Анонимные пользователи

    Все отлично, почту получаю, только вот авторизации на СМТП нету и я могу подключиться к Этому коннектору извне для отправки писем анонимно.

    тоесть могу вообще указать адрес отправителя 123@123.ru и отправить письма внутрь домена :( от этого имени. Наружу письма не уходят от анонима -   550 5.7.1 Unable to relay.

    Дык вот подскажите как сделать так что бы и письма приходили из вне и для отправки обязательно авторизоваццо надо было.....

    Remove-ADPermsission "ReceiveConnector-Name" -user "NT AUTHORITY\Anonymous Logon"  -extendedrights
    "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"

    не помогает. :( просто исчезает галочка в настройках коннектора Группы разрешений Анонимные пользователи. письма из вне продолжают приходить при этом, но и отправка от анонима внутрь домена через этот коннектор тоже продолжает работать. :((( если снять галочку Анонимные пользователи самому, почта из инета перестает приходить - возвращаются ответы 530 5.7.1 Client was not authenticated, что естесственно нормально и тогда нужна авторизация для отправки, но почта то из вне не приходит :(((. тоесть где включить авторизацию только для отправки через этот коннектор.

    хелп ми плиз гуру!



    • Изменено Lordnn1 3 сентября 2012 г. 18:33
    3 сентября 2012 г. 18:30

Ответы

  • Например вот так:

    1й:

    New-ReceiveConnector -Name Receive_From_Inet -Usage Internet -Bindings 0.0.0.0:25 -Server server_name
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Inet' | Remove-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights 'ms-Exch-SMTP-Accept-Authoritative-Domain-Sender'


    2й:

    New-ReceiveConnector -Name Receive_From_Local -Usage Client -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.1-192.168.0.254 -Server server_name
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Local' | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights 'ms-Exch-SMTP-Accept-Any-Recipient'
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Local' | Set-ReceiveConnector -AuthMechanism 'Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer' -PermissionGroups 'ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partners'

    • Помечено в качестве ответа Lordnn1 7 сентября 2012 г. 5:35
    4 сентября 2012 г. 11:16
    Отвечающий
  • Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

    • Помечено в качестве ответа Lordnn1 7 сентября 2012 г. 5:35
    5 сентября 2012 г. 11:33

Все ответы

  • Я думаю это нереально. Чтобы принимать почту из Интернета, вам в любом случае придется включать анонимного пользователя. Аутентифицировать другие сервера вам просто не где.

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

    3 сентября 2012 г. 19:07
    Отвечающий
  • Добрый день, Максим.

    И как тогда орагнизована авторизация на мейл.ру например? понятно что там не эксчейндж.... ну дык чтоэто за почтовик который авторизовать на смтп не может? эй микрософт, я люто разачарован....

    4 сентября 2012 г. 3:32
  • И как тогда орагнизована авторизация на мейл.ру например?

    На сколько я вас понял о "мейл.ру", вы говорите об авторизации клиентской части?

    На Exchange для этих целей используется клиентский коннектор "Client Servername". Подробнее здесь.

    4 сентября 2012 г. 4:12
  • если я Вас правильно понял Роман, необходимо обязательно устанавливать edge transport server?
    4 сентября 2012 г. 4:15
  • Дык вот подскажите как сделать так что бы и письма приходили из вне и для отправки обязательно авторизоваццо надо было.....
    т.е. что б внешние клиенты могли подключаться к вашему серверу и отправляли/принимали почту?? по поп3??
    4 сентября 2012 г. 4:40
  • если я Вас правильно понял Роман, необходимо обязательно устанавливать edge transport server?

    Нет, не обязательно.

    Опишите пожалуйста более подробно, для чего вам нужно авторизованное smtp-соединение, какие клиенты будут авторизоваться (внешние/внутренние). Пока не понятна ваша цель, сложно предложить решение

    4 сентября 2012 г. 4:53
  • Роман, 25 порт смотрит наружу  (SAT правило на маршрутнике) как и должно быть. тоесть любой клиент может отправить письмо через мой смтп сервис не важно куда внутрь или наружу. со входящими письмами все понятно - там и должны быть разрешены анонимные подключения чтобы пользователи из вне могли присылать мне почту. НО анонимный же пользователь может сделать рассылку через этот смтп. наружу такие письма не уходят сервер грит Unable to relay потому, что как я думаю, соединитель отправки привязан на работу только с текущим же сервером, но во внутрь домена анаонимный пользователь может прислать письмо от любого имени. тоесть я настраиваю клиент почты "зе бат!" на компе за пределами организации. вписываю ему смтп mail.mycorp.org и могу с этими настройками от любого имени отправлять почту внутрь домена. что собственно и подразумевает анонимная авторизация в настройках коннектора получения (коннектор отправки то не задействуется). если бы задействовался коннектор отправки, то анонимный пользователь настроеный таким образом получил бы ответ Unable to relay как в случае с попыткой отправки на внешние адреса через этот смтп. вот у меня в голове и не укладывается - неужели нет механизмов решающих эту проблему? едж транспорт решает?

    может быть я не верно понимаю механизмы работы ексчейнджа 2010?


    • Изменено Lordnn1 4 сентября 2012 г. 5:21
    4 сентября 2012 г. 5:11
  • авторизоваццо для получения не нужно у меня поп3 вообще закрыт.

    необходимо авторизоваццо для отправки через этот коннектор, но если включить авторизацию на нем то и почта приходить не будует.

    взаимоисключающие настройки. и запраетить отправку анонимно нельзя и отключить анонимное получение нельзя.


    4 сентября 2012 г. 5:18
  • авторизоваццо для отправки должны внешние клиенты. но если так включить авторизацию письма из вне перестают ходить. так как сервер авторизацию просит. что собссна естесственно в этой ситуации.
    4 сентября 2012 г. 5:19
  • Да, я думаю у вас возникла небольшая путаница.

    По-умолчанию, поставив галку "Anonymous Users" на принимающий коннектор, вы тем самым разрешаете прохождение почты независимо от того, какой будет указан отправитель (разрешение ms-Exch-SMTP-Accept-Any-Sender).

    Но, чтобы какой-нибудь анонимус мог отправить письмо куда-то наружу, используя ваш почтовый сервер, у вас должно быть разрешено на этом коннекторе прием любого получателя (разрешение ms-Exch-SMTP-Accept-Any-Recipient). Это разрешение по умолчанию не дается.

    Другими словами, прием почты от любого отправителя разрешен по умолчанию (если транспорт настроен на работу с интернетом), а отправка любому отправителю (вне вашей организации) - запрещена. Т.е. транспорт увидит, что получатель находится не в его организации, и, т.к. нету у анонимуса ms-Exch-SMTP-Accept-Any-Recipient, то письмо будет отклонено.

    4 сентября 2012 г. 5:57
    Отвечающий
  • у вас получился опен релей внутри сети. в принципе нормально. не уверен, возможно вкладка "проверка подлинности" из настроек ресив конектора вам поможет.
    4 сентября 2012 г. 6:17
  • Спасибо что пояснили, с отправкой на внешние адреса теперь понятно. я конечно же прочитаю статью understandibg reciev connectors и постараюсь все понять :), 

    подскажите, пожалуйста, возможно ли убрать разрешение на отправку от анонимуса внутрь домена. тогда моя пробмлема будет решена.

    времени не хватает на чтение и понимание, а проблема висит... обещаю, сегодня вечером проштудирую труд что б больше глупых вопросов не задвать :)

    4 сентября 2012 г. 6:23
  • Нет. Распишу для наглядности все варианты:

      • Анонимус отсылает из интернета письмо в вашу организацию - по-умолчанию - разрешено. если запретить прием писем из интернета от анонимуса, то к вам вообще перестанут ходить письма от других компаний.
      • Анонимус отсылает из вашей организации в вашу же организацию - по-умолчанию - разрешено. запретить можно, создав дополнительный коннектор и указав в нем локальные IP адрес
      • Анонимус отсылает из интернета письмо в интернет, но используя ваш почтовый сервер - по-умолчанию запрещено.
      • Анонимус отсылает из вашей организации в интернет - по-умолчанию - запрещено, но можно разрешить (только через shell).
    4 сентября 2012 г. 6:37
    Отвечающий
  • Анонимус отсылает из вашей организации в вашу же организацию - по-умолчанию - разрешено. запретить можно, создав дополнительный коннектор и указав в нем локальные IP адрес

    вот вот так и сделано.

    Первый коннектор с именем incoming с анонимной авторизацией со всеми ип адресами

    второй коннектор с именем outgoing с авторизацией серве exchange и только внутренними адресами 192.168.x.x

    но анонимус все еще может отправлять письма внутрь организации :(





    • Изменено Lordnn1 4 сентября 2012 г. 7:13
    4 сентября 2012 г. 6:45
  • но анонимус все еще может отправлять письма внутрь организации :(

    Может отправлять внутрь организации именно из самой организации (например сканер или МФУ какие-нибудь)?

    Приведите, пожалуйста, что выведет команда:

    Get-ReceiveConnector | Get-ADPermission | where {$_.User -like '*anonymous*'} | ft deny,extendedrights,accessrights -AutoSize



    4 сентября 2012 г. 6:58
    Отвечающий
  • Комманду маленько поправил поскольку КД русский

    4 сентября 2012 г. 7:19
  • Для уточнения, еще раз выполните вот эти команды:

    Get-ReceiveConnector "EX\Incoming" | Get-ADPermission | where {$_.User -like '*аноним*'} | ft deny,extendedrights,accessrights -AutoSize
    Get-ReceiveConnector "EX\Outgoing" | Get-ADPermission | where {$_.User -like '*аноним*'} | ft deny,extendedrights,accessrights -AutoSize

    4 сентября 2012 г. 7:31
    Отвечающий
  • Поставьте для коннектора EX\Outgoing следующие механизмы аутентификации и перезапустите службу MSExchangeTransport:


    4 сентября 2012 г. 7:48
    Отвечающий
  • спасибо за наводку, может быть я опять не верно понимаю механизмы работы. но в этом коннекторе явно указано что принимать почту можно только с 192.168.0.x

    В организации необходима возможность отправки от имени другого пользователя наружу с использованием сторонних смтп клиентов, специфика работы такая :)

    если я поставлю эти галки подобная возможность работать перестанет.

    Угу проверил. перестала работать возможность.

    4 сентября 2012 г. 8:35
  • какую то путаницу навели. есть exchange обслуживающий какие то почтовые домены, например domain.ru. он должен принимать почту от других почтовых серверов и от клиентов с адресами этого же домена. это совсем разные и независимые задачи.
    для первого случая (сервера) создается стандартный коннектор с анонимным доступом, с запретом релея и с запретом отправлять от имени авторитативного (то есть нашего domain.ru) домена
    для второго (клиенты) создается коннектор с стребованием аутентификации, разрешением отправлять от имени своего домена и с разрешением отправлять на любые адреса (релей)

    4 сентября 2012 г. 9:23
  • Воооооот. красивейший ответ. командлеты не напишите ну или через ГУИ?
    4 сентября 2012 г. 10:15
  • Например вот так:

    1й:

    New-ReceiveConnector -Name Receive_From_Inet -Usage Internet -Bindings 0.0.0.0:25 -Server server_name
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Inet' | Remove-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights 'ms-Exch-SMTP-Accept-Authoritative-Domain-Sender'


    2й:

    New-ReceiveConnector -Name Receive_From_Local -Usage Client -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.1-192.168.0.254 -Server server_name
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Local' | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights 'ms-Exch-SMTP-Accept-Any-Recipient'
    Get-ReceiveConnector -Identity 'server_name\Receive_From_Local' | Set-ReceiveConnector -AuthMechanism 'Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer' -PermissionGroups 'ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partners'

    • Помечено в качестве ответа Lordnn1 7 сентября 2012 г. 5:35
    4 сентября 2012 г. 11:16
    Отвечающий
  • ок. Спасибо вам всем большое... сейчас все пойдут домой а я буду эксперементировать...

    по результатам отпишу.

    4 сентября 2012 г. 11:20
  • еще Get-ReceiveConnector | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon”
    проследи чтобы на первом не было ms-exch-smtp-accept-authoritative-domain-sender, а на втором было )

    4 сентября 2012 г. 14:36
  • значиццо добавил коннекторы согласно командлетам

    результаты. 

    1) снутри наружу все уходит

    2) снаружи внутрь все ходит

    3) отправка от имени друго пользователя изнутри наружу перестала работать, при чем письмо просто остается в папке исходящие и просто висит там. ошибок сервер не возвращает

    4) отправка от имени друго пользователя изнутри внутрь работает

    5) анонимный юзер снаружи попрежнему не может отправить письмо через эти коннекторы наружу 550 5.7.1 Unable to relay

    6) Анонимный юзер попрежнему может прикинуццо любым юзером и отправить письмо снаружи внутрь

    ни чего не поменялось за исключением 3 пункта. с моими коннекторами все работало

    текущие коннекторы отличаются по правам с моими коннекторами, что естественно :)

    и в заключение аноним со своими правами как просили

    Господа, пишу в 22-41, простите сегодня уже нету сил,как обещал, штудировать труд о понимании рисив коннекторов. но понимаю што пропускать незя такой текст. 

    • Изменено Lordnn1 4 сентября 2012 г. 16:42
    4 сентября 2012 г. 16:40
  • Я окончательно запутался, что в итоге вам нужно получить :)

    Давайте пройдемся прям по вашим пунктам:

      • "снутри наружу все уходит" - тут все правильно
      • "снаружи внутрь все ходит" - тут все правильно
      • этот пункт пока отложим. тут почему-то транспорт не хочет забирать письмо из ящика - это совсем другой вопрос. к коннекторам отношения не имеет. Этот отправитель попадает в 192.168.0.1-192.168.0.254?
      • "отправка от имени друго пользователя изнутри внутрь работает" - это необходимо или надо, чтобы это было запрещено?
      • "анонимный юзер снаружи попрежнему не может отправить письмо через эти коннекторы наружу" - необходимо, чтобы он мог отправлять?
      • этот пункт так и должен быть. проверять, "прикидывается" отправитель кем-то или нет, должен антиспам (по умолчанию на транспортном сервере выключен).

    И еще, выполните вот эту команду и проверьте потом пункт 3 (незабудьте перезапустить службу транспорта):

    Set-ReceiveConnector -PermissionGroups 'AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers' -Identity 'server_name\Receive_From_Local'
    

    5 сентября 2012 г. 5:58
    Отвечающий
  • И снова здравствуйте!

    • "снутри наружу все уходит" - тут все правильно -ок
    • "снаружи внутрь все ходит" - тут все правильно -ок
    • этот пункт пока отложим. тут почему-то транспорт не хочет забирать письмо из ящика - это совсем другой вопрос. к коннекторам отношения не имеет. Этот отправитель попадает в 192.168.0.1-192.168.0.254? - это ниже
    • "отправка от имени друго пользователя изнутри внутрь работает" -  - тут тоже все ок
    • "анонимный юзер снаружи попрежнему не может отправить письмо через эти коннекторы наружу"  - тут тоже все ок. спам разводить по сети не будем я думаю :)))
    • этот пункт так и должен быть. проверять, "прикидывается" отправитель кем-то или нет, должен антиспам (по умолчанию на транспортном сервере выключен). - антиспам на транспортном сервере включен. настройки антиспама тож ене верные получается

    С 3 пунктом помогает выставление галочки внешняя аутетификация после этого я могу отправить письма от имени другого пользователя изнутри наружу. Да эти отправители попадают во внутренюю сеть.


    • Изменено Lordnn1 5 сентября 2012 г. 9:02
    5 сентября 2012 г. 9:01
  • последний пункт тоже работает как надо, главное чтобы анонимный внешний пользователь не мог прикинуться юзером твоего домена, судя по выводу прав так оно и есть. а если он прикитывается чужим доменом то тут только проверка на уровне антиспама.

    по третьему: что требуется реализовать? аутентификацию при отправке внутренними пользователями домена или возможность отправлять вообще от любых адресов и доменов?

    5 сентября 2012 г. 9:30
    • последний пункт тоже работает как надо, главное чтобы анонимный внешний пользователь не мог прикинуться юзером твоего домена, судя по выводу прав так оно и есть

       да действительно можно прикинуццо пользователем домена. чужим существующим доменом не пробовал. чужим несуществуюшим пробовал - тоже можно.

    по 3 

    есть юзер с обычным почтовым ящиком.

    есть программа 1с (мать ее) в которую тоже почта ходить должна. для 1с заведен еще один отдельный ящик под каждого юзверя. 

    тоесть на каждого пользователя 2 не зависимых ящика

    при отправке писем на основной ящик пользователя с помощью правил транспорта я дублирую поток на ящик 1с для этого пользователя.

    но при отправке из 1с нужно штобы светился основной ящик пользователя. 

    выставляем разрешение на "отправить как" меняем поле "От" внутри 1с,  и все работает.

    тоесть пользователи которые отправляю письма от другого имени могут быть только внутри сети.

    вот примерно так.

    5 сентября 2012 г. 9:55
  • как поправить права для того что бы аноним с внешки не смог прикинуццо юзером домена?

    ну это наверно последний вапрос. точнее в самом начале надо было просто его задать.

    5 сентября 2012 г. 9:56
  • Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

    • Помечено в качестве ответа Lordnn1 7 сентября 2012 г. 5:35
    5 сентября 2012 г. 11:33
  • ок. попробую... по результатам отпишусь
    5 сентября 2012 г. 15:05
  • Да, господа, все работает отлично. 

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

    но в оутглюке 10 видно, что юзер 123@123.ru отправил письмо от имени admin@mycorp.ru примерно так.

    Теперь дело за настройкой антиспама? 

    Вы крутые гуру хочу быть таким же, все еще учу "Understanding receive connectors" :) почти все понятно...

    5 сентября 2012 г. 16:55
  • Всем спасибо. Разбираюсь с антиспамом.

    Статью прочитал. все понятно :)

    7 сентября 2012 г. 5:36
  • для меня тоже стало проблемой. но я опишу проще на примере вот смотрите пример правильно работающего почтаря при попытке отправить анонимно:

    220 mail.mydomain.ru Microsoft ESMTP MAIL Service ready at Thu, 18 Oct 2012 14:0
    4:21 +0700
    ehlo
    250-mail.mydomain.ru Hello [ххх.хх.ххх.ххх]
    250-SIZE 31457280
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-X-ANONYMOUSTLS
    250-AUTH
    250-X-EXPS NTLM
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250-XEXCH50
    250 XSHADOW
    mail from:test@mydomain.ru
    250 2.1.0 Sender OK
    rcpt to:test@mydomain.ru
    250 2.1.5 Recipient OK
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    subject:HAHAHA
    HAHAHA
    .
    450 4.4.3 Sender ID check is temporarily unavailable

    тут как видно отказано в таких махинациях, а у меня же см. ниже:

    220 mail.mydomain.ru Microsoft ESMTP MAIL Service ready at Thu, 18 Oct 2012 10:54:40
    +0400
    ehlo
    250-mail.mydomain.ru Hello [ххх.ххх.ххх.ххх]
    250-SIZE 10485760
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-X-ANONYMOUSTLS
    250-AUTH
    250-X-EXPS NTLM
    250-8BITMIME
    250-BINARYMIME
    250-XEXCH50
    250 XSHADOW
    mail from:test@mydomain.ru
    250 2.1.0 Sender OK
    rcpt to:test@mydomain.ru
    250 2.1.5 Recipient OK
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    subject:HAHAHA
    HAHAHA
    .
    250-Transmission in progress. Stay tuned
    250 2.6.0 <bf490448-e159-4b4a-94d7-1f2a02f9f94a@EDGE***.ru> [InternalId=38] Que
    ued mail for delivery

    а вот так мне ну совсем не надо.

    ВОПРОС: как сделать так чтобы такого не было? По поводу скрипта скажу сразу он не работает а именно:

    Get-ReceiveConnector “my connector” | Get-ADPermission -user “NT AUTHORITY\Анонимный вход” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

    обратите внимания ОС у меня русскоязычная может с этим связано? т.к. я ввожу “NT AUTHORITY\Анонимный вход”

    попробовал выполнить данный командлет на EDGE сервере в итоге при попытке отправить письмо выдается следующее:

    250 2.1.5 Recipient OK
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    subject:GAFD
    dafaf
    .
    250-Transmission in progress. Stay tuned
    250 Message accepted for delivery

    p.s. схема у меня такая: Excnahge 2010SP2+Forefront for Excnahge2010, отдельный EDGE-сервер.

    • Изменено rimanya 26 октября 2012 г. 10:12
    26 октября 2012 г. 9:06
  • 1. Возможно EMS консоль не принимает ввод Cyrillic, надо переключить настройки шрифтов в консоли.

    2. Вам ничего не мешает найти это соединитель и выставить руками права. ADSIEDIT СN = Configuration -> CN = Services -> CN = Microsoft Exchange -> CN = "Название организации" -> CN = Administrative Groups -> CN = Exchange Administrative Group -> CN = Routing Groups -> CN = группы маршрутизации Exchange -> CN = Connections -> CN = "Receive Connector" 


    MCITP. Знание - не уменьшает нашей глупости.

    26 октября 2012 г. 9:48
    Модератор
  • принимает как выяснилось. Просто задался вопросом где эту команду вводить? на EDGE или Хабтранспорте почтовика. Когда вводил на EDGE он принял команду:

    [PS] C:\>Get-ReceiveConnector "Default internal receive connector EDGE" | Get-ADPermission -user "NT AUTHORITY\Анонимный
     вход" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

    Подтверждение
    Вы действительно хотите выполнить это действие?
    Удаление разрешения Active Directory "EDGE\Default internal receive connector EDGE" для пользователя "NT
    AUTHORITY\АНОНИМНЫЙ ВХОД" с правами доступа "'ExtendedRight'".
    [Y] Да - Y  [A] Да для всех - A  [N] Нет - N  [L] Нет для всех - L  [S] Приостановить - S  [?] Справка
    (значением по умолчанию является "Y"):y


    итогом было то что при попытке отправить письмо текст уже был другим:

    mail from:test@mydomain.ru
    250 2.1.0 Sender OK
    rcpt to:test@mydomain.ru
    250 2.1.5 Recipient OK
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    subject:dadada
    dadada
    .
    250-Transmission in progress. Stay tuned
    250 Message accepted for delivery

    и письмо уже не доходит до адресата test@mydomain.ru

    но это все же думаю не то что я хотел хотелось бы

    450 4.4.3 Sender ID check is temporarily unavailable

    • Изменено rimanya 26 октября 2012 г. 10:29
    26 октября 2012 г. 10:27
  • Где вводить? Все равно, так как настройки и права хранятся в AD.

    MCITP. Знание - не уменьшает нашей глупости.

    26 октября 2012 г. 10:43
    Модератор
  • хорошо зашел как вы порекомендовали, какие права (галочки)там нужно выставить для анонимного входа?
    26 октября 2012 г. 11:05
  • Receive Connector Permissions

    Receive connectors process incoming sessions to the server. The session may be established by an authenticated sender or by an anonymous sender. If a session is authenticated successfully, the SIDs in the session access token are updated. Table 4 lists the permissions that can be granted to a session connecting to a Receive connector.

    Table 4   Receive connector permissions

    Permission Display name Description

    ms-Exch-SMTP-Submit

    Submit Messages to Server

    The session must be granted this permission or it won't be able to submit messages to this Receive connector. If a session doesn't have this permission, the MAIL FROM command will fail.

    ms-Exch-SMTP-Accept-Any-Recipient

    Submit Messages to any Recipient

    This permission allows the session to relay messages through this connector. If this permission isn't granted, only messages addressed to recipients in accepted domains are accepted by this connector.

    ms-Exch-SMTP-Accept-Any-Sender

    Accept any Sender

    This permission allows the session to bypass the sender address spoofing check.

    ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

    Accept Authoritative Domain Sender

    This permission allows the session to bypass a check that prevents inbound messages from e-mail addresses in authoritative domains.

    ms-Exch-SMTP-Accept-Authentication-Flag

    Accept Authentication Flag

    This permission allows Exchange servers that are running earlier versions of Exchange Server to submit messages from internal senders. Exchange 2010 servers recognize the message as internal.

    ms-Exch-Accept-Headers-Routing

    Accept Routing Headers

    This permission allows the session to submit a message that has all received headers intact. If this permission isn't granted, the server strips all received headers.

    ms-Exch-Accept-Headers-Organization

    Accept Organization Headers

    This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with “X-MS-Exchange-Organization-“. If this permission isn't granted, the receiving server strips all organization headers.

    ms-Exch-Accept-Headers-Forest

    Accept Forest Headers

    This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with “X-MS-Exchange-Forest-“. If this permission isn't granted, the receiving server strips all forest headers.

    ms-Exch-Accept-Exch50

    Accept Exch50

    This permission allows the session to submit a message that contains the XEXCH50 command. This command is required for interoperability with Exchange 2000 Server and Exchange 2003. The XEXCH50 command provides data, such as the spam confidence level (SCL) for the message.

    ms-Exch-Bypass-Message-Size-Limit

    Bypass Message Size Limit

    This permission allows the session to submit a message that exceeds the message size restriction configured for the connector.

    Ms-Exch-Bypass-Anti-Spam

    Bypass Anti-Spam

    This permission allows the session to bypass anti-spam filters.


    MCITP. Знание - не уменьшает нашей глупости.

    26 октября 2012 г. 11:16
    Модератор
  • попробую отпишусь
    • Изменено rimanya 26 октября 2012 г. 12:49
    26 октября 2012 г. 12:45
  • Создайте коннектор и настраивайте на нем права. Настроите проверите работу, а потом внесете изменения в промышленную среду или работающий с подключениями коннектор. Чтобы потом воплей не было, что не работает. 

    Еще вот здесь.

    Configuration, Services, Microsoft Exchange, Administrative Groups, Exchange Administrative Group (FYDIBOHF23SPDLT), Servers, <Server Name>, Protocols and finally SMTP Receive Connectors.


    MCITP. Знание - не уменьшает нашей глупости.


    26 октября 2012 г. 12:51
    Модератор
  • Прошу прощения, уточнение: "Создайте коннектор и настраивайте на нем права"

    имелось ввиду на почтовом сервере коннектор отправки или не EDGE-сервере?

    27 октября 2012 г. 7:55
  • выполнил на EDGE сервере команду снятия возможности отправки письма от имени моего домена на адреса моего домена:

    Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

    все вроде как отработало, и ранее выстваленная галочка в соеденителе получания в группе разрешений "анонимные пользователи" снялась. Но вот при попытке отправить письмо на внешний ящик на гугле в котором стоит полная пересылка писем на мой корпоративный ящик, письмо возвращается с ошибкой и до корпоративного ящика не доходит, но в ящик гугл оно попадает.

    Technical details of permanent failure:
    Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Anonymous client does not have permissions to send as this sender (state 17).

    11 ноября 2012 г. 14:31
  • все так и должно быть насколько я знаю.
    11 ноября 2012 г. 16:14
  • Как же так? У меня появился корпоративный ящик и я сделал пересылку с гугля на мой ящик и теперь когда приходит письмо на гугль, я его не получаю, а в ящике гугля письмо+письмо с отчетом об ошибке пересылки. Это не есть то что нужно. А то что нужно я писал выше "450 4.4.3 Sender ID check is temporarily unavailable" при попытке отправки письма от имени моего домена на адреса моего домена. Прошу проконсультировать.
    11 ноября 2012 г. 20:22
  • а гугл от имени твоего корпоративного ящика пытается отправить?

    12 ноября 2012 г. 12:05
  • нет, там просто стоит пересылка всех писем на мой ящик. Причем чудеса. Вот сейчас поставил галочку в соеденителе получания в группе разрешений "анонимные пользователи" и снова запустил скрипт и ошибка пропала, т.е. переадресация идет без ошибок с гугла. Я так понимаю она происходит когда я где-то что-то меняю, вот только что пока не зафиксировал.
    12 ноября 2012 г. 16:49
  • эту галочку в консоли лучше совсем не трогать, особенно если что то делали через PS, так как она снимает и назначает стандартный набор разрешений для анонимуса, и если например убрать одно разрешение, как в нашем случае, то галочка пропадет, но это не означает что пропадут все остальные положенные ему разрешения. некоторые по неопытности и незнанию могут зайти в консоль "поиграться", увидят что галка не стоит, поставят и снимут обратно, и само собой все "поедет" )

    12 ноября 2012 г. 18:21
  • это понятно что отсутствие галочки это не значит что все права сняты. Но вот что я заметил, в общем при создании дополнительно ящиков, права слетают видимо и письма которые до создания ящиков с гугля нормально пересылались, после создания ящика с ошибками и не доходят, и как же теперь все корректно расставить, хоть новый коннектор создавай. Все это я выполнял на пограничном EDGE-сервере.
    12 ноября 2012 г. 18:33
  • У меня в ADSI почему-то не отображается соединитель отправки тот что на сервере EDGE см. вложения. Коннектор отправки тот что на самом Exhange сервере отображается в Protocols and finally SMTP Receive Connectors. Получается у меня в AD нет данных о соединителе отправки? как мне сделать так чтобы как я и писал выше при попытке отправить анонимно снаружи письмо от любого (даже несуществующего) домена или моего домена на адрес из моего домена письмо отбрасывалось?

    12 июня 2013 г. 18:55
  • как тебе удалось победить проблему "тока анонимный пользователь все еще может отправлять письма внутрь домена от любого имени включая имена пользователей домена..." я бьюсь уже с этим очень долго, :((
    12 июня 2013 г. 19:16
  • это задача для EDGE сервера 

    http://technet.microsoft.com/en-us/library/hh945224(v=exchg.141).aspx

    В самом Эксчейндже такой вещи не настроишь.

    Я сам до сих пор без EDGE сижу... :( пока нормально.

    >>

    Да, господа, все работает отлично. 

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

    но в оутглюке 10 видно, что юзер 123@123.ru отправил письмо от имени admin@mycorp.ru примерно так.

    !!!Теперь дело за настройкой антиспама? !!!

    13 июня 2013 г. 4:23
  • У меня включен фильтр по ID отправителя, но как показала практика он не работает!!! Как видно из лога абсолютно грязного письма (несмотря на то что было переадресовано с моего ящика на майле)

    Authentication-Results: mxs.mail.ru; spf=permerror (mx137.mail.ru: error in processing during lookup of domain of justclick.ru: Could not find a valid SPF record) smtp.mailfrom=sender@justclick.ru smtp.helo=mta-02-makeevent.justclick.ru;
         dkim=pass header.i=justclick.ru
    Received-SPF: None (EDGE.mydomain.ru: valery@make-event.ru does not designate
     permitted sender hosts)

    т.е. вроде как бы должен отбросить письмо, но нет оно в папке входящие :((


    • Изменено rimanya 14 июня 2013 г. 11:13
    14 июня 2013 г. 11:12
  • цитата

    "ID отправителя работает путем проверки того, на самом ли деле каждое сообщение e-mail имеет происхождение на домене интернета, с которого оно было послано. Это делается путем сверки адреса сервера, отправившего сообщение, с зарегистрированным списком серверов, которые владельцы доменов авторизировали на отправку сообщений.

    Если у вас нет никакого опыта работы с ID отправителя, то они могут быть немного сложными для понимания, поэтому позвольте мне объяснить принцип их работы.

    Организация может публиковать запись Sender Policy Framework (SPF) на публичном DNS сервере(ах), содержащем их домен. Опубликованная SPF запись содержит список IP адресов, которым разрешено отправлять сообщения для определенного домена. Если конкретная организация опубликовала SPF запись, и кто-то в этой организации отправляет сообщение получателю за пределами Edge Transport сервера в другой организации, сервер Edge Transport будет осматривать SPF запись, чтобы убедиться в том, что SMTP сервер, отправляющий сообщение, наличествует в списке."

    


    • Изменено Lordnn1 17 июня 2013 г. 8:21
    17 июня 2013 г. 8:21
  • Уважаемые гуру, подскажите куда копать. Хоть Edge и нет в наличии, но вопросом живо интересуюсь.

    Спасибо!

    17 июня 2013 г. 8:22
  • поясните в чем конкретно проблема то?

    17 июня 2013 г. 9:18
  • Да проблем то у меня нету.

    у комрада rimanya есть проблема двумя постами выше. 

    у меня проблемы были в свое время по топику, он и был создан. Проблема была решена частично. Релэи для анонимного пользователя были запрещены у меня, но собссна от анонимного пользователя внутрб домена с подменой домена и пользователя все также можно отправлять (решение за EDGE транспортом если я все правильно понял).

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


    • Изменено Lordnn1 17 июня 2013 г. 9:29
    17 июня 2013 г. 9:24
  • подделку домена запрещает командлет что я писал выше. или вы что то другое имеете ввиду?
    edge в принципе необязателен, почти все задачи решаются на hub

    17 июня 2013 г. 9:32
  • Что то у меня прошлый раз не заработало... ни как не могу вспомнить чтоже. В любом случае подниму этуже тему еще раз когда проблема появится.

    Спасибо Дмитрию еще раз!

    • Изменено Lordnn1 17 июня 2013 г. 9:50
    17 июня 2013 г. 9:50
  • Здравствуйте! решил ли кто-то проблему с запретом ? У меня так же как и у автора проблема в том что кто угодно может отправлять письма с корпоративного адреса корпоративным сотрудникам без авторизации. Как запретить это в exchange 2013 не понятно. https://ittun.wordpress.com/2013/08/07/exchange-2013-настройка-соеденителей-получения/  Есть такая статья, но после всех шагов всё равно кто угодно может отправлять сообщения корпоративным сотрудникам

    Подскажите пожалуйста что нужно сделать? 

    29 марта 2016 г. 14:30
  • Я смог запретить отправлять от моего домена мне же  только включив фильтр на Edge - Sender Filtering, и вписал туда свой внешний домен.

    И теперь когда пытаюсь отправить телнетом и вбиваю свой домен внешний, выдает сообщение Sender Denied.

    15 апреля 2016 г. 8:15
  • Алексей, добрый день!

    Мы порешали эту проблему с помощью ORF. извините что долго отвечал :)

    21 апреля 2016 г. 9:43
  • Добрый день! Почитав форум где Вы пишите что у Вас все заработало но опять же цетирую: 

    Да, господа, все работает отлично. 

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

    Запутался что то я заработало или нет, меня интересует именно чтобы из интернета анонимные пользователи не могли отправлять от имени внутреннего домена > внутренним пользователям домена письма

    24 января 2018 г. 10:46
  • Добрый! Это задача которая должна быть повешена на антиспам модуль.
    8 февраля 2018 г. 9:35