Пожалуйста, потерпите меня, так как я не опытный администратор
У меня есть почтовый сервер linux, который работал пару лет, и теперь внезапно какой-то пользователь не может отправлять электронные письма. Они сразу получают ответ от «Системного администратора»:
501 5.5.4 error bad notify parameter syntax
Это происходит только для этого пользователя и только на его компьютере. Он отлично работает в Thunderbird, но не в Outlook 2013. Другие пользователи могут использовать Outlook 2013 без проблем.
Я смотрел журнал, и вот что он говорит, когда этот пользователь пытается отправить электронное письмо
replacing command "RCPT TO: <myemail@gmail.com> NOTIFY=SUCCESS,FAILURE,DELAY" with "RCPT TO: <myemail@gmail.com> NOTIFY=SUCCESS,FAILURE,DELAY NOTIFY=NEVER"
Я проверил все правила Outlook, которые могут включать добавление заголовков, отключение антивирусного сканера электронной почты, повторное добавление учетной записи и т. Д.
Я читал и, похоже, NOTIFY = NEVER нельзя смешивать с другими командами NOTIFY.
у меня есть smtpd_command_filter настроить как это
/^(RCPT\s+TO:<.*>.*)\s+NOTIFY=\S+(.*)/ $1 NOTIFY=NEVER$2
/^(RCPT\s+TO:.*)/ $1 NOTIFY=NEVER
Я плохо разбираюсь в регулярных выражениях, но предполагаю, что он неправильно разбирает исходную команду и добавляет NOTIFY = NEVER в конец вместо того, чтобы заменять его.
Тем временем я закомментировал это, что отправляет уведомление «ваше сообщение успешно доставлено» обратно отправителю. Я замолчал, добавив
smtpd_discard_ehlo_keywords = silent-discard, dsn
в main.cf
Мои новые настройки в порядке или мне нужно исправить исходную проблему, которая, как я предполагаю, заключается в регулярном выражении? Любые идеи?
Я читал и, похоже, NOTIFY = NEVER нельзя смешивать с другими командами NOTIFY.
Для справки, он определен в RFC 1891 Раздел 5.1
Команда RCPT, выдаваемая клиентом, может содержать необязательное ключевое слово esmtp «NOTIFY», чтобы указать условия, при которых сервер SMTP должен генерировать DSN для этого получателя. Если используется ключевое слово NOTIFY esmtp, оно ДОЛЖНО иметь связанное значение esmtp, отформатированное в соответствии со следующими правилами с использованием ABNF из RFC 822:
notify-esmtp-value = "NEVER" / 1#notify-list-element notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"Ноты:
а. В параметре NOTIFY МОГУТ появиться несколько элементов списка-уведомлений, разделенных запятыми; однако ключевое слово NEVER ДОЛЖНО появляться само по себе.
б. Любое из ключевых слов НИКОГДА, УСПЕХ, ОТКАЗ или ЗАДЕРЖКА может быть написано в любой комбинации заглавных и строчных букв.
Это ваше регулярное выражение (похоже, скопировано из эта страница)
/^(RCPT\s+TO:<.*>.*)\s+NOTIFY=\S+(.*)/ $1 NOTIFY=NEVER$2
/^(RCPT\s+TO:.*)/ $1 NOTIFY=NEVER
Это командная строка RCPT из Outlook 2013
RCPT TO: <myemail@gmail.com> NOTIFY=SUCCESS,FAILURE,DELAY
Вышеупомянутая строка будет соответствовать второй строке. Зачем? Потому что между TO: и <myemail@gmail.com>, там пробел. Ваша первая строка регулярного выражения не содержит пробелов между TO: и '<'.
Для пробела между ':' и '<' проблема, вот что RFC 5321 говорит
Поскольку это был частый источник ошибок, стоит отметить, что пробелы не допускаются ни с одной стороны двоеточия, следующего за FROM в команде MAIL или TO в команде RCPT. Синтаксис точно такой, как указано выше.
Так вот почему проблема возникает локально. Выглядит как перспективы все еще добавляют пространство между после RCPT TO: таким образом нарушение спецификации RFC.
Решение Regex:
Измените первую строку регулярного выражения, чтобы она стала такой
/^(RCPT\s+TO:\s*<.*>.*)\s+NOTIFY=\S+(.*)/ $1 NOTIFY=NEVER$2
добавление \ s * будет соответствовать строке, у которой есть ноль или более пробелов после RCPT TO:
Для объяснения того, как работает регулярное выражение, посетите эта страница.