Исправление ошибки аутентификации на SMTP сервере
При появлении ошибки такого характера:
An error in action 99: При сохранении - SQL1:
ORA-29279: Постоянная ошибка SMTP: 535 5.7.3 Authentication unsuccessful.
ORA-06512: на "SYS.UTL_SMTP", line 54
ORA-06512: на "SYS.UTL_SMTP", line 140
ORA-06512: на "SYS.UTL_SMTP", line 219
ORA-06512: на "SHABOERP.PKG_MAIL", line 282
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 19
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 141
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 843
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 313
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 213
ORA-06512: на line 2
Ошибка аутентификации на SMTP сервере. И при этом, что бы поменять аккаунт нужно редактировать sys.utl_SMTP - под пользователем sys.
select * from un9mail_box t
Логин и пароль настраиваются в этой таблице
select utl_raw.cast_to_varchar2(utl_encode.base64_encode(utl_raw.cast_to_raw('Новый логин или пароль для mail'))) from dual
Сейчас в таблице задан почтовый акканут shabo_mail
Нет задан smtp_login.
Как проверить корректность соединения из Из Sql и тестовую отправку почты?
Надо написать анонимный PL/SQL bloc:
Можно использовать эту процедуру для теста. И после выполнения проверить наличие ошибок в логе процесса mail_server. Также нужно проверить блокировку 25 порта.
ORA-29279: Постоянная ошибка SMTP: 535 5.7.3 Authentication unsuccessful.
ORA-06512: на "SYS.UTL_SMTP", line 54
ORA-06512: на "SYS.UTL_SMTP", line 140
ORA-06512: на "SYS.UTL_SMTP", line 219
ORA-06512: на "SHABOERP.PKG_MAIL", line 282
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 19
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 141
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 843
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 313
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 213
ORA-06512: на line 2
Также нужно проверить учётную запись. БД пытается коннектиться данной учёткой на указанный в настройках сервер.
mail.uniacc.md port 25
Не находит там такой учётки и получает "ошибка SMTP: 535 5.7.3 Authentication unsuccessful."
select * from un9mail_box t
дает
0 def noreply@una.md mail.uniacc.md 25 uniacc.md c2hhYm9fbWFpbA== **************
Уже настроенный почтовый сервер mail.shabo.ua
Учётка shabo_mail - с сервера mail.shabo.ua
Учетка с mail.shabo.ua - erp.robot@mail.shabo.ua
Если mail.shabo.ua доступен с внешнки - надо настроить в un9mail_box параметры сервера и используемой там учётки (или другой тестовой).
Ошибка при пробе коннектиться:
Не выполнен commit после изменений. В таблице старые данные. Сделайте commit и попробуйте повторно. С Коммитом:
An error in action 99: При сохранении - SQL1:
ORA-29279: Постоянная ошибка SMTP: 535 5.7.3 Authentication unsuccessful.
ORA-06512: на "SYS.UTL_SMTP", line 54
ORA-06512: на "SYS.UTL_SMTP", line 140
ORA-06512: на "SYS.UTL_SMTP", line 219
ORA-06512: на "SHABOERP.PKG_MAIL", line 282
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 19
ORA-06512: на "SHABOERP.PKG_MAIL_UTL", line 141
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 843
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 313
ORA-06512: на "SHABOERP.YSHABO_PKG_DF", line 213
ORA-06512: на line 2
Это уже с новыми настройками.
Нужно быть настроить параметры подключения к серверу в другом месте. При первой попытке может выдать ошибку - либо повторите, либо перед проверкой переподключитесь к БД. Проверьте с текущими настройками.
Но это на системной схеме un4public.
На cloudbd её настраиваем мы, в случае необходимости.
Это нужно было для случая, когда с разных схем идёт рассылка разными почтовыми серверами.
На вашей рабочей БД настройка проще, т.к. используете только один почтовик - ваш.
Если пишет, что неверные данные аутентификации на своей БД:
В этом случае pkg_mail.begin_auth_session в вашей БД тоже читает данные почтового сервера через пакет mail_params.
Пакет/синоним mail_params ссылается на схему un4public. Если да, то:
select * from t_mail_servers;
В этой таблице в схеме un4public на вашем сервере проверьте/настройте параметры подключения к серверу.
А параметры авторизации (логин/пароль) в основной схеме, в таблице un9mail_box. После настройки - commit. Чтобы другие сессии увидели изменения в БД.