Логика создания правил почтовых фильтров для Exim в cPanel
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.08.24 21:35
Оценка:
У меня домен на 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" явно неподходящие по адресу получателя, а дальше уже заниматься более тонкими проверками на разные варианты спамов/фишингов.
Re: Логика создания правил почтовых фильтров для Exim в cPanel
От: m2user  
Дата: 15.08.24 22:59
Оценка: +1
ЕМ>У меня домен на shared-хостинге под линуксом, почтовым сервером там Exim, управление — через cPanel. Когда-то давно настроил там несколько глобальных правил фильтрации почты, в том числе правило отвергания сообщения, если в To: стоит адрес не моего домена (спамеры любят так слать). Правило сделано через Does not match и Fail with message. Все работало, как задумано, а сегодня обнаружил, что сообщение о предстоящем закрытии учеток на Verifone/2Checkout/Avangate рассылалось их автором самому себе, а все адресаты стояли в CC, и фильтр его благополучно отверг с "no such mailbox".

у меня был такой же фильтр и давал false positive при форвардинге (когда в настройках почты настроена пересылка на другой адрес).
И если я правильно понимаю, в теории в заголовках (To, CC, BCC и пр.) вообще может не быть адресата. Адресат определяется командой "RCPT TO" SMTP серверу.
Т.е. вероятность ложного срабатывания остается.
Re[2]: Логика создания правил почтовых фильтров для Exim в cPanel
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 16.08.24 08:59
Оценка:
Здравствуйте, m2user, Вы писали:

M>в теории в заголовках (To, CC, BCC и пр.) вообще может не быть адресата. Адресат определяется командой "RCPT TO" SMTP серверу.


Насколько я знаю, все серверы добавляют его к заголовку в "Envelope-To". Вот только проверяет ли это поле Exim? Когда cPanel выполняет свой тест, в нем видно только %h_to и $h_cc.
Re[2]: Логика создания правил почтовых фильтров для Exim в cPanel
От: akasoft Россия  
Дата: 21.08.24 13:48
Оценка:
Здравствуйте, m2user, Вы писали:

M>И если я правильно понимаю, в теории в заголовках (To, CC, BCC и пр.) вообще может не быть адресата. Адресат определяется командой "RCPT TO" SMTP серверу.

Что, RFC прямо-таки разрешает опускать To-Cc-Bcc-etc?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[3]: Логика создания правил почтовых фильтров для Exim в cPanel
От: m2user  
Дата: 21.08.24 15:07
Оценка:
A>Что, RFC прямо-таки разрешает опускать To-Cc-Bcc-etc?

Не уверен насчёт RFC, но даже если эти заголовки присутствуют, то их содержимое может совсем не совпадать с "RCPT TO", а значит фильтр сработает некорректно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.