Ну бывает, попробую расписать на примере.

Первый заход: приходит хост, пытается слать письмо. rcpt_verify его пропускает, доходит до data_verify, там rspamd говорит - "данные левые, а сделай-ка ты greylist". Теперь у нас есть ip-отправителя, адрес отправителя из конверта, и получатели все скопом. Последнее плохо ложится в базу, а ещё в exim'е нет лёгкого способа разлепить обратно получателей на этом этапе. Ну хорошо, допустим отправили 4XX, хост ушёл, письмо не принято.

Второй заход: приходит хост, пытается слать письмо. rcpt_verify опять его пропускает, потому что "почему бы и нет, мне никто не сказал что его надо грейлистить". Доходит до rspamd, тот опять говорит - "данные левые, а сделай-ка ты greylist". Теперь нам опять нужно разлепить получателей, угадать с тем, что мы выбрали в прошлый раз, и пнуть milter с greylisting'ом, чтоб тот проверил, пускать ли его дальше.

Недостатки такого костыля:

* письмо при каждой попытке доставки проходит через антиспам, хотя могло быть остановлено раньше и значительно дешевле по ресурсам. А раньше остановить его при данной схеме не получится, потому что почтовик не может на этапе rcpt_verify магическим образом угадать, что на data_verify его загрейлистят. Ни при первой, ни при последующих попытках доставки.
* кастомный механизм "разлепить получателей" на эксимовском конфиге - это практически write-only. В результате образуется "незаменимый гуру", который после получасовой медитации возможно сможет вспомнить как оно работает.
* как альтернатива предыдущему пункту - брать получателя "как есть", мириться с медленной работой базы грейлистинга, т.к. юзеры любят ставить в копию по 5-10-15 человек.
* необходимость во внешнем мильтере грейлистинга и настройка их связки со rspamd. Конфиг становится "хрупким", и см выше про "гуру".

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

// надеюсь понятно расписал