Можно либо сделать 5 аналогичных фильтров со своим доменом в каждом, либо в поле RCPTTO тоже использовать файл-список.

pavlad пишет: Потому вполне логично на мой взгляд была-бы и обратная цепочка — если в правиле фильтра указана переменная типа {LocalDomain}

Конструкция {...} — это просто подставновка, имеет один результат на выходе, а не условие сравнения. Т.е. "сравнить с 5ю разными" так не получится.

pavlad пишет: Ведь при RCPTTO сервер уже однозначно Знает — в Local или Outbond пойдет письмо. О чём и сообщает в своих логах.

Он знает об этом только на финальном этапе разворачивания алиасов и списков. А стадия RCPTTO как раз ведёт к этому финалу, и в момент выполнения правила финал еще не ясен.

pavlad пишет: когда идет речь про перетаскивание под сотню алиасов и списков рассылки с E3 на E4 — ошибиться вероятность повышается в соответственно раз.

Да, но список списков рассылок в E3 имеет вид файла-списка, в первом поле адрес списка. Этот файл годится к прямому переносу в E4 — можно вставить его имя в RCPTTO...

И еще один способ: поставить условие "локальный ли это домен" в поле "Правило". Например так:

GetDID даёт id домена, или 0 в случае, если его в списке нет, т.е. результат можно использовать как флаг TRUE/FALSE.
Или так:

GetEmailStatus ( стек: emla emlu — did uid da du islocal_flag ), и этими NIP'ами мы убираем всё кроме islocal_flag.
Или:
(эти "ExDelivery" вам известны по логам, можно более гибко определять тип адреса по ним).

GetEmailStatus делает сложные проверки адреса, в т.ч. по алиасам, учитывает email'ы, используемые в качестве логинов (т.е. локальную учетку не локального домена), админские логины из ini (которые могут отсутствовать в общем списке учеток) и прочие хитрости и исторические совместимости.