>>>> 1. В принципе, как можно выйти из создавшейся ситуации?
>>> Административно повлиять на "аутентифицированного" пользователя - не вариант?
>> Можно, но завтра появистя второй, третий и т.д. За всеми не набегаешься.
> А не надо бегать. Есть технические стандарты - благоволите соблюдать. Не согласны
> - стройте свой интернет с игрищами и блудницами.Так я понимаю, он ни чего и не нарушает.
Я заблокирую этот домен получателя и дождусь, пока cron забьём им всё дисковое пространство на диске, может быть так до них дойдёт быстрее.
>[оверквотинг удален]
>> (delivery temporarily suspended: connect to lk.mydomain.local[x.x.x.35]:25: Operation
>> timed out)
>>
>>
>>
>> user@lk.mydomain.local
>> У меня таких писем в очереди очень много и я пока не
>> понимаю, как не принимать письма для домена с несуществующей mx-записью.
> Наличие МХ записи не обязательно. В смысле, технически при отсутствии мх отправка
> может осуществляться по адресу из А записи, по ориджину домена...
Спасибо, этот момент я упустил.
> Можно просто не принимать письма от отправителей с несуществующим доменом - reject_unknown_sender_domain.
> Это правильнее всего, ибо нефиг.
У меня есть это правило в цепочке проверок, но оно не работает, домен не задан, MAIL FROM пустой.
> Ну а что в итоге-то беспокоит? Письма в очереди висят? Ну и
> бох с ними, повисят и через четверо суток самоликвидируются. Бывает, по
> несколько сотен таких висят, серверу от них плохо не делается.
За ночь набежало:
% mailq | grep MAILER-DAEMON | wc -l
1235
Напишите
> второй скрипт, который будет искать такие письма в очереди с учетом
> наличия ваших некошерных "отправителей" и грохать именно их. Ну или покрутите
> maximal_queue_lifetime, но я бы это не трогал без крайней нужды.
Скрипт-то есть, очередь очищается. Он исправляет последствия болезни, но не её причины.
Как временное решение, я вижу это блокировка домена и в дальнейшем написание дополнительный проверок через policy сервер. Хотелось конечно решение проблемы "из коробки", но видимо его нет.
