none
AntiSpam - Проверка отправителя в E2k7 RRS feed

  • Вопрос

  • Включены все фильтры кроме SenderID(ввиду малой поддержки многими доменами)
    Спама приходит порядка 20-30 писем в день.
    Практически все эти письма высланы с несуществующих адресов. Например: benjamin.nash@anu.edu.au, 3dbrian@powertech.com.au
    Знаю что есть фильтры, позволяющие проверять адрес отправителя на существование(Не ip отправителя, как SenderID, а именно email отправителя).
    Есть ли такой для E2k7 ??
    • Перемещено Hengzhe Li 18 марта 2012 г. 5:39 forum merge (От:Exchange Server 2007)
    18 августа 2008 г. 11:55

Ответы

Все ответы

  • Очевидно речь идет о callback verification

    Штатного нет

    18 августа 2008 г. 14:47
  •  AMDf написано:
    Включены все фильтры кроме SenderID(ввиду малой поддержки многими доменами)
    Спама приходит порядка 20-30 писем в день.
    Практически все эти письма высланы с несуществующих адресов. Например: benjamin.nash@anu.edu.au, 3dbrian@powertech.com.au
    Знаю что есть фильтры, позволяющие проверять адрес отправителя на существование(Не ip отправителя, как SenderID, а именно email отправителя).
    Есть ли такой для E2k7 ??

     

    А как вы себе представляете проверку отправителя на существование? Ведь если такая проверка проходит на каком-нить сервере SMTP, то по сути это является спамерской атакой с проверкой существующих ардесов в арганизации.

     

    Самое правильное - использовать RBL, задержку в приеме сообщений (Gray List), проверку разрешения домена отправителя в реальный IP адрес MX записи сервера отправителя и интелектуальный рейтинговый движок аниспам фильтра.

    19 августа 2008 г. 8:45
  • А как вы себе представляете проверку отправителя на существование? Ведь если такая проверка проходит на каком-нить сервере SMTP, то по сути это является спамерской атакой с проверкой существующих ардесов в арганизации.
    В exim эта функция называется Sender Verify Callout.

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

    Это НЕ является по сути спамерской атакой так как это встречная проверка и она проверяет валидность того отправителя который пытается послать письмо.

    19 августа 2008 г. 9:10
  • Это кстати очень действенный способ борьбы со спамом, так как большинство адресов - поддельные.
    Неплохо бы было его внести в штатный список фильтров каким нибудь очередным RollUp'oм )))
    19 августа 2008 г. 11:45
  • Вам каждая нормальная система даст "250 2.1.5 Recipient OK" (по причине описанной мною выше) и не скажет, что пользователя не существует. Так что вы такой проверкой ничего не достигнете.

    19 августа 2008 г. 11:48
  • Нормальная система должна выдать
    "550 5.1.1 User unknown"
    19 августа 2008 г. 12:37
  • Вот в таком случае возможна спамерская атака, когда по подготовленному заранее шаблону (имя_фамилия@домен) вычисляются существующие п/я в вашей почтовой системы Smile

    Засветите свои почтовые ящики - будете получать спам!

    19 августа 2008 г. 13:41
  • А как же работает тогда Recipient Filtering в Exchange?
    Как раз и выдает ошибку, если почтового ящика нет. А то NDR-ы будут со страшной силой накапливатся на несуществующие адреса спамеров.
    20 августа 2008 г. 12:24
  • Как работатет Recipient Filtering... ну уж точно не отправляет ни куда запросы для проверки существования п/я в другом домене. А вот в чем отличие Sender и Recipient Filtering понимаю на уровне интуиции  

     

    NDR не будут накапливаться если письмо будет опознано как спам в результате работы: RBL, проверке разрешения домена отправителя в реальный IP адрес MX записи сервера отправителя и интелектуального рейтингового движка аниспам фильтра. А вот если вы каждый раз будете обращаться за проверкой атпровителя на спамерский сервер и там, поверте мне, эта проверка пройдет - получите как раз спам + много NDR! 

    22 августа 2008 г. 8:28

  • Я тут писал про недостатки CallBack верификации.
    Скажем так, я ее у себя никогда использовать не буду, слишком много хлопот.

    Про проверку получателей я писал тут

    "Это НЕ является по сути спамерской атакой так как это встречная проверка и она проверяет валидность того отправителя который пытается послать письмо."
    +1
    Отличие этой проверки от SMTP отправки всего лишь в наличие DATA. Письмо реально не отправляется, поэтому нельзя говорить, об отправке спама. Это всего лишь незаконченная SMTP сессия, что вполне может быть согласно RFC.


    "Sender и Recipient Filtering понимаю на уровне интуиции " что это значит?


    "проверке разрешения домена отправителя в реальный IP адрес MX записи сервера отправителя " не допускаете мысли, что почтовый сервер может только отправлять почту, но не принимать ее?

    "А вот если вы каждый раз будете обращаться за проверкой атпровителя на спамерский сервер и там, поверте мне, эта проверка пройдет - получите как раз спам + много NDR! "
    Это возможно, если спам сервер работает, как релей. Но спамеры могут и не знать, за какой домен отвечает этот релей и в качестве отправителя ставить всякую ерунду, тогда call back не пройдет.
    25 августа 2008 г. 12:49
    Модератор
  •  Pavel Nagaev написано:

    "Sender и Recipient Filtering понимаю на уровне интуиции " что это значит?

    Что значит? Ну до недавнего времени ни как не мог разобраться в отличиях листов запрета одного и второго фильтра - тупил) 

     

     Pavel Nagaev написано:

    "проверке разрешения домена отправителя в реальный IP адрес MX записи сервера отправителя " не допускаете мысли, что почтовый сервер может только отправлять почту, но не принимать ее?

    Допускаю, и что из этого? Мы с вами, кажется, говорим о случае когда сервер получателя принимает почту... или я что-то пропустил? Дело тут в другом - Exchange 2007 этого не делает.

     

     Pavel Nagaev написано:

    "А вот если вы каждый раз будете обращаться за проверкой атпровителя на спамерский сервер и там, поверте мне, эта проверка пройдет - получите как раз спам + много NDR! "
    Это возможно, если спам сервер работает, как релей. Но спамеры могут и не знать, за какой домен отвечает этот релей и в качестве отправителя ставить всякую ерунду, тогда call back не пройдет.

    Что я видимо совсем понятно выразился. Имел в виду следующее: сервер получателя обращается для проверки на сервер "подставного" отправителя, проверка проходит и в результате вы почти наверняка получите спам (если IMF не отфильтрует). И второй вариант: сервер получателя обращается для проверки на сервер "спамерского" отправителя, проверка проходит и в результате вы почти опять наверняка получите спам (если IMF не отфильтрует) и засветите свой почтовый адрес.

     

    От себя хочу заметить следующее: бороться с очередью NDR можно и уменьшением количества повторов отправки и интервалами между ними.

    28 августа 2008 г. 8:09
  • Бороться с очередями NDR нужно путем включения проверки получателей в AD.

     

    "уменьшением количества повторов отправки и интервалами между ними." - это лишнее.

     

     

    Допускаю, и что из этого? Мы с вами, кажется, говорим о случае когда сервер получателя принимает почту... или я что-то пропустил? Дело тут в другом - Exchange 2007 этого не делает.

     

    Я хотел сказать, что проверять наличие MX записи для входящего сервера не правильно, т.к. отправляющий сервер может заниматься только отправкой. Примером могут служить пулы SMTP серверов в больших системах.

    Это относится не к Exchange, а к теории борьбы со спамом.

     

     

    28 августа 2008 г. 9:09
    Модератор