Как по IP определить, кто является LIR ?

Те, кто ограничивают возможность вхождения в этот класс должны быть расстреляны.

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

Нет, это моя проблема и неуважение ко всем владельцам почтовых серверов: почему из-за твоей жадности и невежества
я должен плодить очереди отложенной корреспонденции?

Ой. У тебя на этот сервер такая очередь, что ты заметишь ?

Тут на какой-то грейлистинг полмира бочку катит, так что уж говорить
о безответственных админах локалхостов…

Вот-вот. Принципиальной разницы между этими двумя вещами нет. Но за безграмотно настроенный грейлистинг давать по ухам стоит. :-)

Нет, это моя проблема и неуважение ко всем владельцам почтовых серверов

И, вообще, гораздо бОльшее неуважение - это mail from:<noreplay@bla-bla-bla>, которого нет реально. И которое сыпется с любого пых-пых-сайта почти, в том числе с правительственных, всяких коммерческих и т.п.

Ой. У тебя на этот сервер такая очередь, что ты заметишь ?

А вдруг он оттуда сто тыщь мульёнов спамов ко мне засунет, а добренькие хомячки в ответ вежливые письма от своих антивирусов (ещё то неуважение)? :)

бОльшее неуважение - это mail from:<noreplay@bla-bla-bla>, которого нет реально.

А чего он тебе сделал? Реджект на него не отправишь? Так дабл не прилетит на <> — раз, проверять доступность ящика до DATA — два.

проверять доступность ящика до DATA — два.

Ага. А потом мне говорят «а до Гугля доходит, значит это у вас косяк».

Ага. А потом мне говорят «а до Гугля доходит, значит это у вас косяк».

А, так ты проверяешь mail from при получении, долбясь в ответ? Убивать. Грейлистинг по левой нагрузке — детские игрушки по сравнению. Особенно если он настроен на отправляющей стороне. Или на обеих. :)

Я имел в виду, проверять доступность своего ящика до data, а не чужого.

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

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

твой ботнет

чо за безосновательный наезд? но в общем-то я свою проблему решил примерно как в вашем следующем письме про 465 порт. будем считать, что это такой квест дл япроверки квалификации, а кто не прошёл - пусть остаются в песочнице.;-)

и да, SPF на свой домен прову давать - это 5! бггг, вроде бы серьёзный человек, так казалось.

даже слушать не хотят про частные случаи.:(

А это о тебе забота: зачем нужен ящик на сервере, который не заботится о доступе по SSL и на альтернативных портах? :)

чо за безосновательный наезд?

Не твой конкретно, а на компьютере подписчика в общем случае. Их там хоть пруд пруди. Причем когда ему говоришь «по данным нашей IPS у тебя троян», он обижается, поэтому существенно проще просто блокировать: затронуто оказывается существенно меньше 1% клиентов. А уж физиков, желающих ptr, — хорошо если один на десять тысяч.

и да, SPF на свой домен прову давать - это 5!

А MX на свой домен? Тем более на адрес которым ты никак не распоряжаешься, и который в любой момент перестанет быть на твоем интерфейсе. Я знаю провайдеров, например, которые приостанавливают услугу статического IP по недостатку средств на счете, а адрес освобождают. После оплаты у тебя /другой/ «статический» IP.

А, так ты проверяешь mail from при получении, долбясь в ответ?

Конечно.

Убивать.

лесом.

детские игрушки по сравнению.

Не жадничай на железе и не используй PIII на серверах.

Я имел в виду, проверять доступность своего ящика до data, а не чужого.

Это любой нормальный сервер делает по-умолчанию. Но есть ещё всякие sieve и прочие автоответы.

+100500 уроды. ведь моджно просто обрывать на DATA по 4xx

ведь моджно просто обрывать на DATA по 4xx

Обрывать DATA с 4xx на несуществующий ящик? Это говно ещё неделю будет у всех в очередях бултыхаться?

Для проверки существует VRFY. Без всякой DATA.

Конечно.

“Be strict in what you send, but generous in what you receive” — только поэтому интернет ещё работает со всем зоопарком реализаций.

Но есть ещё всякие sieve и прочие автоответы.

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

и на скольких серваках он ещё не отключен?;-) ладно, уговорил, можно и 5xx давать

и на скольких серваках он ещё не отключен?;-)

Вот у кого VRFY не отключен, у тех и проверяй mail from ;)

> Но есть ещё всякие sieve и прочие автоответы.

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

Мне кажется, сейчас ты не очень понял, что я имею ввиду.

не угадал - ведь я даже bounce не смогу им отправить назад. что явно нарушение RFC.

ведь я даже bounce не смогу им отправить назад.

Во-первых, отправить можешь, но не примут. А баунсов на баунс не бывает.

Во-вторых, именно поэтому и надо проверять возможность доставки во время входящей smtp сессии, чтобы не приходилось баунсами швыряться.

Мне кажется, сейчас ты не очень понял, что я имею ввиду.

Я вижу, что мы говорим о разных вещах, вернее читаем друг друга в разном контексте.

MX ДОЛЖЕН в любой момент времени ответить на запрос и однозначно либо принять, либо отвергнуть письмо. Для этого можно описать несколько MX, хоть один ОБЯЗАН ответил.

Не ответит - позже перешлют письмо, поваляется в очереди. Так вроде любой MTA работает.

А в чём заключается проблема топикстартера? Бери любой халявный днс хостинг и вбивай там какие хочешь записи.

надо проверять возможность доставки

а я с AS о чём?
я тут же и проверяю этт noreply и получаю «ПНХ» причём иногда и с занесением в GL или даже BL.:(
AS правильно сказал -уроды!

а я с AS о чём?

а) Откуда у тебя баунс берется? б) В чем ты видишь проблему отправить баунс на несуществующий ящик?

Не ответит - позже перешлют письмо, поваляется в очереди.

Почему ради нежелания одного недоадмина обеспечить бесперебойность работы своего MX весь мир должен тратить ресурсы на очереди к нему?

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

И ptr тоже? Ага, бери.

Почему ради нежелания одного недоадмина обеспечить бесперебойность работы своего MX весь мир должен тратить ресурсы на очереди к нему?

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

И ptr тоже? Ага, бери.

Почитал, оказывается неправильно понимал эту штуку, спасибо.

Потому что так работает протокол SMTP.

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

Тебе будет приятно, если /твой/ сервер будет вынужден держать большие очереди? Но ты этого не боишься: «большинство ведет себя вежливо, значит мне проблемы не грозят, поэтому я могу на всех положить». Это путь к деградации.

Особо нежелающие всегда могут настроить свои MTA нужным образом

Каким? Плевать на rfc? Смотри выше.

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

Пойми ещё одно: главное правило в сети — «веди себя с другими максимально корректно, прощай другим ошибки». Поэтому нельзя допускать невоспитанных и необразованных хомячков.

вернее читаем друг друга в разном контексте.

Возможно...

а) Откуда у тебя баунс берется ?

Его умный клиент всякими sieve может сформировать. А вот проверку по имеющимся фильтрам сделать сложнее, чем просто доступность ящика проверить. По крайней мере, я не знаю, как это у Cyrus-IMAP реализавать.

Кроме того, нормальный callback не особенно и нагружает. Во-первых, должно быть кэширование, во-вторых, если речь о потоке спама, лимиты на ошибки от сервера отправителя с временной блокировкой.

Его умный клиент всякими sieve может сформировать.

А почему MUA его формирует не на Reply-To, а на envelop from? А если в envelop from существующий адрес, а в Reply-To: noreply@list, и sieve отправляет баунс как и положено на noreply@list, тебе легче?

Но даже если ты принял письмо от несуществующего адреса, в чем для тебя проблема попытаться доставить обратно этот редчайший баунс? Будет 5xx в smtp сессии, и всё. Да своими колбеками ты таких 5xx существенно больше генерируешь, не говоря уже про никому не нужные RCPT TO …/nQUIT.

Ещё заметь, твой callback неэффективен с моими серверами, например: я всегда и на любые mail from и rcpt to возвращаю 250, а посылаю лесом только в ответ на data.

если речь о потоке спама

Если речь идет о потоке спама с левых адресов, то ты сам выглядишь для всего мира как спаммер. Зато радостно примешь гору мусора от поддельных реальных адресов, походя завалив кого-то левыми коннектами.

проблему отправить баунс на несуществующий

потому что его не примут, кэп.

потому что его не примут, кэп.

И в чем тут для тебя проблема?

А почему MUA его формирует не на Reply-To, а на envelop from?

Потому, что там одно и то же.

Будет 5xx в smtp сессии, и всё.

Если бы. Гораздо чаще то, что определяется, как MX для этого мусора, попросту не является smtp-сервером.

Ещё заметь, твой callback неэффективен с моими серверами,

Зато с другими эффективен.

я всегда и на любые mail from и rcpt to возвращаю 250, а посылаю лесом только в ответ на data.

Ну вот, кстати, принятием комплекса мер по оценке принимаемого письма до DATA, можно заметно снизить нагрузку и поотвечать на callback, который гораздо менее прожорлив.

Если речь идет о потоке спама с левых адресов, то ты сам выглядишь для всего мира как спаммер.

Это смотря как подходить к оценке спама.

походя завалив кого-то левыми коннектами.

Ещё раз читаем про ограничения/лимиты.

Потому, что там одно и то же.

Там может быть одно и то же, часто Reply-To: соответствует From:, а не mail from, иногда все три различны.

то, что определяется, как MX для этого мусора, попросту не является smtp-сервером

У нас ситуация, когда ты получил письмо, кладешь его в локал, а твой клиент с помощью sieve сформировал баунс (это у тебя discard так отрабатывается?). Так?

Ну вот, кстати, принятием комплекса мер по оценке принимаемого письма до DATA, можно заметно снизить нагрузку

Я проверяю и отправителя и получателя, и если что-то не устраивает, в ответ на команду DATA отвечаю 4xx или 5xx вместо 354, не принимая тело письма. В результате те, кто не хочет ничего доставлять, а просто мимо проходил, не могут отличить валидный адрес от несуществующего.

поотвечать на callback

Пройдите вдоль, уважаемый. Лесом.

Быть подверженному directory harvest? Зачем из best practice вынесен VRFY, чтобы того же самого добивались добавлением единственной строчки mail from: <> перед пачкой rcpt to вместо пачки vrfy?

Это смотря как подходить к оценке спама.

От тебя валит а) волна попыток доставить почту на несуществующие ящики, б) ты напрягаешь своими «прими письмо … ой, я передумала». Естественно, ты спамер.

Ещё раз читаем про ограничения/лимиты.

Чтобы убедиться, что тысяча разных незакешированных адресов валидны, ты сделаешь тысячу сессий.

в ответ на команду DATA отвечаю 4xx или 5xx

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

Пройдите вдоль, уважаемый. Лесом.

Я вижу, мы друг-друга понимаем всё больше. :-)

Чтобы убедиться, что тысяча разных незакешированных адресов валидны, ты сделаешь тысячу сессий.

И что ? Эта тысяча совершенно незаметна на общем фоне. Если же ты имеешь ввиду одиночный источкик, то «Ещё раз читаем про ограничения/лимиты»

Зачем из best practice вынесен VRFY, чтобы того же самого добивались добавлением единственной
строчки mail from: <> перед пачкой rcpt to вместо пачки vrfy?

забыл добавить. VRFY - гораздо более производительный способ. посредством rcpt to много не насобираешь.

+100500 я отключил vrfy ещё когда сендмылом пользовался.

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

Зато с другими эффективен.

у меня срубает до 90% спама (уже после BL), остаются копейки.