forum.lissyara.su

По логике здравого смысла - если при выполнении "delay=хх" в ACL если "спамер" разорвал соединение - exim должен выполнить acl_smtp_notquit и завершить процесс.
Однако процесс "висит" и полностью отрабатывает не только задержку, а также и все ACLы после! И только затем вызывает acl_smtp_notquid.
Как-то это ненормально... В документации не нашел ничего чтобы изменить это поведение... Кто нибудь с этим боролся? Или это.. у меня пананойя?

Не очень понятно что ты хотел сказать.

Понял так:
1. Подсоединился спамер.
2. Вводит команды xxxx, rcpt to: ТЕБЕ_НА_ЯЩИК
3. Срабатывает задержка, к примеру на 10 секунд.
4. Спамер не дожидается и отключается.
5. Exim выполняет задержку и после задержки ждёт команд от спамера, которого нет.
6. Exim выясняет что команд нет и закрывает сессию.

1-4 yes
5. Exim выполняет задержку (а соединения уже давно нет),
выполняет ВСЕ ACLы, в том числе если прописано то делает запросы в базу (а соединения-то уже давно нет)
6. Exim выясняет что соединения нет, записывает лог (connection lost) и закрывает сессию

dvs писал(а):5. выполняет ВСЕ ACLы

Не все, а только тот блок в котором происходит задержка. Скорее всего весь блок acl_smtp_rcpt, т.к. команда rcpt to была получена и должна быть обработана до какого-либо действия : accept. deny, drop, defer и т.п.

Вобщем еxim должен принять решение на введённую команду (rcpt to?). delay - это не принятие решение, а отсрочка и следовательно выполняется весь блок.

разумеется блок acl_smtp_rcpt
И что, это нормально?
Соединения-то уже нет. Зачем мучать базу данных, что-то еще проверять... Больше всего непонятно зачем ждать.

Соединения-то уже нет. Зачем мучать базу данных

Ну exim может и без базы работать.. :-)

Ничего плохого в этом я не нахожу..

тоже не вижу плохого.
скорей всего фича - может что-то было так проще реализовать.
а наличие-отсутствие конекта определяться может, например, лишь между АКЛ - так даже проще...