>> или если после helo/ehlo мы не используем указанных команд
>> ничего с этим делать не нужно, это долбежка, можем
>> заносить эти ip в blacklist на уровне firewall или sendmail
> А есть способ автоматически заносить в blacklist на уровне sendmail, теже
> STARTTLS=server, relay=abts-mum-static-160.102.169.122.airtelbroadband.in [122.169.102.160]
> (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-GCM-SHA384,
> bits=256/256
> ruleset=check_relay, arg1=[141.98.11.95], arg2=141.98.11.95, relay=srv-141-98-11-95.serveroffer.net
> [141.98.11.95] (may be forged), reject=421 4.3.2 Connection rate limit exceeded.чем вам starttls не угодил? эта ж технология...
Средствами sendmail - нет. Искать milter решения для sendmail или писать свои.
>>> И если можно по поводу отключения, ответа для сообщений не известному ящику
>>> как поставить или просто где копать в этом направлении?
>> и этого лучше не делать: кто-то простукивает наши email адреса и делает
>> это с поддельных email, Вы собираетесь отправлять уведомления на
>> несуществующие email?!
> Здесь есть проблема, и она в том что они шлют тонны писем
> типа от почтового адреса для атаки, а сервер на них отвечает,
> тем самым отправляет тонны писем с ошибкой на этот адрес.
блокируйте на уровне firewall и access в sendmail.
Ну или прикручивать к sendmail amavis и прочую байду, искать живые
milter фильтры для sendmail...
По RFC, MTA обязан уведомить обратную сторону о том что user-unknown,
письмо попадет в очередь и sendmail будет пытаться его отправить
в течении: Timeout.queuereturn=5d
потом умрет и фик с ним. Можно сделать multiqueue и оперировать с ними
ps. Те, настроить и бросить MTA и host на котором он крутится - опасно,
можно поиметь кучу проблем: взлом, спам и тд и тп. Посему регулярный
просмотр логов - или парсинг с уведомлением, в том числе и очередей.
