v8: Ошибка при отправке почты ("SMTP error code 500, 5.3.3 Unrecognized command) [Почти решено] #680836

Уже была тема При отправке почты на некоторые адреса появляется сообщение об ошибке "SMTP error code 500, 5.3.3 Unrecognized command" Столкнулся с такой же проблемой. Платформа 8.2.18.109. На 16 платформе такого не было. Кто-нибудь сталкивался?

при чем тут 1с?

Потому что отправка производится средствами платформы. Объект ИнтернетПочта.

[Кто-нибудь сталкивался?] мало информации, нужен как минимум лог со стороны почтовика

Нашел причину. Кому интересно, проблема в том, что в теле сообщения содержится строка, где содержится только точка. До пользователя доходит сообщение с текстом до этой точки. Например, сообщение: абв где жзи . клм Пользователь получит: абв где жзи Как мне потом сообщил знающий человек - "точка" для сервера это команда отправки сообщения. А ошибка появляется потому что сообщение уже отправлено "точкой", а 1С пытается его отправить своей командой "Послать". Сервер просто не понимает чего от него хотят.

Гм. А если сообщение из нескольких предложений? И как их разделять? Почему Thunderbird нормально шлёт с точками?

В строке должна быть только точка. Если в строке есть что-то еще кроме точки, то ошибки не будет. Почтовые клиенты как-то обходят это.

Спасибо.

+ Это описано в RFC 2821 The mail data is terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the end of mail data indication.

а в логах мне отказали сказали, если включат логирование, то все ляжет

то все ляжет Правильнее "лягут". И не все, а только сисадмины

ну тут как бы программировать надо :)

1с то при чем все-таки? или ей в платформу должны были все РФЦ зашить?

1С тут не при чем оказался. 1С шлет серверу команду DATA, а в ней текст сообщения.

Для того, чтобы отправка писем не зависело от содержания и применяют например base64 кодирование. Если бы исходный текст, содержащий пустые строчки с точкой был предварительно base64 закодирован, то при передаче в протокол уже бы не попали лишние управляющие последовательности

Но тогда на другом конце его надо раскодировать. Получатель (пользователь) не будет же самостоятельно это делать. Или это как-то автоматически разруливается? Мне как раз предстоит решить эту проблему сообщений с точками.

Ну это как раз в РФЦ и прописано, так называемое MIME-кодирование. Каждый компонент письма имеет заголовок, где в том числе и указывается примененное кодирование, соответственно клиент читает этот заголовок и применяет соответствующее раскодирование. Не знаю как это реализовано в 1С ИнтернетПочта, давно не пользую.

Понял. Спасибо.

Странно. На ИТС нанписано Протокол SMTP позволяет посылать только текстовые данные, при этом отводя на каждый октет (символ) только 7 или 8 бит. Все текстовые данные сообщения посылаются в Unicode (16 бит на символ), поэтому необходимо предварительное конвертирование в UTF-8. UTF-8 кодирует один символ текста от одного до четырех байт по 8 бит каждый. Но UTF-8 строка является бинарными данными, а для почтовых протоколов это не приемлемо. Таким образом, полученная UTF-8 строка еще дополнительно кодируется (не путать с шифрованием) по методу base64. А вот что в исходнике письма: Content-Type: text/plain;    charset="utf-8" Content-Transfer-Encoding: 8bit

Короче, не стал париться. Сделал отправку в HTML. Но интересно было бы узнать православное решение.

Не знаю, какое решение является православным, сам уже давно не пользуюсь встроенными в 1С объектами. Принятую почту "раскодирую" с помощью CDO, исходящую почту формирую вручну по стандарту, это не так сложно. Просто в свое время жестоко обломался в ИнтернетПочта, осадочек остался

У меня немного другой подход к разработке. По максимуму использую объекты платформы. Ибо кроссплатформенность и вообще. Спасибо, что навел на мысль.

Флаг в руки. Я тоже не от любви к искусству убежал на CDO. Долго жрал кактусы, но теперь плюнул на это дело. Мне кажется 1С распыляется в данном случае: всякие там интернет почты, географические схемы и пр. фигня. Лучше бы просто сделали встроенную поддержку .NET и/или Java. Тогда бы кому нужно все эти системные штучки приделывали сами, появились бы разные библиотечки (ну там готовые обработки). А то они же сами не верят в свои поделки. В БП для ЭДО используется отнють не ИнтернетСоединение, а специальная ВК, лежащая в архиве (по крайней мере в 2.0 так было вроде).