У меня домен на shared-хостинге под линуксом, почтовым сервером там Exim, управление — через cPanel. Когда-то давно настроил там несколько глобальных правил фильтрации почты, в том числе правило отвергания сообщения, если в To: стоит адрес не моего домена (спамеры любят так слать). Правило сделано через Does not match и Fail with message. Все работало, как задумано, а сегодня обнаружил, что сообщение о предстоящем закрытии учеток на Verifone/2Checkout/Avangate рассылалось их автором самому себе, а все адресаты стояли в CC, и фильтр его благополучно отверг с "no such mailbox".
Поставил вместо "To" "Any Recipient", но при проверке обнаружил, что так cPanel генерирует для Exim правило, объединяющее результаты проверок для "To" и "CC" по ИЛИ. Для проверок "matches regex" результат получается предсказуемый и логичный, а у меня "does not match", поэтому результат получается истинным, когда
любой адресат
не соответствует выражению.
Мне это кажется неправильным, поскольку смысл фразы "any recipient does not match" скорее означает "ни один адресат не подходит".
Сперва хотел написать в их поддержку, потом подумал — вдруг кому-то все-таки может пригодиться имеющаяся логика.
Кто-нибудь может представить себе ситуацию, когда имеет смысл проверять и "To", и "CC", и выполнять какие-то определенные действия, если
любой из них
не соответствует правилу (is not equal, does not ...)?
Или мне таки правильно кажется, что разумно было бы объединять проверки с отрицательными условиями не по "или", а по "и"?
Можно, конечно, изменить смысл правила на "Any recipient matches regex", чтобы
пропускать сообщения, когда любой из адресатов подходит, но это не так удобно, поскольку логично именно отвергать с диагностикой "No such mailbox" явно неподходящие по адресу получателя, а дальше уже заниматься более тонкими проверками на разные варианты спамов/фишингов.
Здравствуйте, m2user, Вы писали:
M>И если я правильно понимаю, в теории в заголовках (To, CC, BCC и пр.) вообще может не быть адресата. Адресат определяется командой "RCPT TO" SMTP серверу.
Что, RFC прямо-таки разрешает опускать To-Cc-Bcc-etc?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>