незарегистрированный sender id что это значит

ИД отправителя

Применяется к: Exchange Server 2013 г.

Агент sender ID — это агент по борьбе со спамом, доступный в Microsoft Exchange Server 2013 г. Агент sender ID полагается на заглавную статью RECEIVED SMTP и запрос в службу DNS системы отправки, чтобы определить, какие действия, если таковые есть, принять входящий сигнал.

Sender ID предназначен для борьбы с выдающей себя за отправитель и домен, практика, которая часто называется спуфинг. Поддельное сообщение — это почтовое сообщение, адрес отправителя которого был изменен таким образом, чтобы он выглядел, как если бы сообщение исходило от отправителя, отличного от фактического отправителя.

Поддельные почтовые ящики обычно содержат адрес From: адрес, который, как сообщается, должен быть из определенной организации. В прошлом было относительно легко подменить адрес From: в сеансе SMTP, например в загонах MAIL FROM: и в данных сообщений RFC 2822, таких как From: «Masato Kawai» masato@contoso.com, так как загоны не были проверены.

Использование кода отправителя для противодействия спуфингу

ID отправщика затрудняет подмену. Когда вы включаете ИД отправитель, каждое сообщение содержит статус sender ID в метаданных сообщения. При получении сообщения электронной почты Exchange сервер запрашивает DNS-сервер отправителей, чтобы убедиться, что IP-адрес, с которого было получено сообщение, уполномочен отправлять сообщения для домена, указанного в загонах сообщений. IP-адрес авторизованного сервера-отправителя известен как адрес PRA.

Администраторы домена публикуют записи политик отправитель (SPF) на своих DNS-серверах. Записи SPF определяют авторизованные исходящие серверы электронной почты. Если запись SPF настроена на DNS-сервере отправщика, Exchange сервер сравнирует запись SPF и определяет, разрешен ли IP-адрес, с которого было получено сообщение, отправлять электронную почту от имени домена, указанного в сообщении. Дополнительные сведения о том, что содержит запись SPF и как создать запись SPF, см. в документе Sender ID.

На Exchange сервер обновляет метаданные сообщения со статусом Отправитель на основе записи SPF. После обновления Exchange сервер метаданных сообщений доставка сообщений будет проходить так же, как обычно.

Значения состояния кода отправителя

Процесс оценки ID отправитель создает состояние отправитель ID для сообщения. Для оценки уровня доверия к нежелательной почте (SCL) для сообщения используется статус отправитель. Этот статус можно установить к одному из следующих значений:

Pass. И IP-адрес, и предполагаемый ответственный адрес (PRA) прошли проверку проверки ID отправитель.

Нейтральные. Опубликованные ID-данные отправитель явно неубедительны.

Soft fail: IP-адрес для PRA может быть в запрещенной комплекте.

Fail: IP-адрес не разрешен; В входящий почтовый ящик не обнаружено pra или домена отправки не существует.

Нет. В DNS отправитель не существует опубликованных данных SPF.

TempError: произошел временный сбой DNS, например недоступный DNS-сервер.

PermError. Запись DNS недействительна, например ошибка в формате записи.

В метаданные сообщения добавляется ИД отправитель, который затем преобразуется в свойство MAPI. Фильтр нежелательной почты в Microsoft Outlook использует свойство MAPI во время генерации значения SCL.

Outlook не отображает состояние ИД отправитель и не обязательно помечают сообщение как нежелательное в определенных значениях. Outlook используется значение состояния отправитель только при вычислении значения SCL.

Помимо семи сценариев, которые создают статусы ИД отправитель, процесс оценки ИД отправитель может выявить экземпляры, в которых отсутствует IP-адрес From: IP. Если IP-адрес From: отсутствует, не может быть задат статус отправитель. Если не может быть установлено состояние отправительского ID, Exchange продолжает обработку сообщения без включив в сообщение статус sender ID. Сообщение не отбрасывается и не отклоняется. В этом сценарии не задается состояние ИД отправитель, и событие приложения регистрируется.

Дополнительные сведения об отображении состояния Sender ID в сообщениях см. в статье Метки защиты от спама.

Параметры кода отправителя для обработки поддельной почты и недостижимых серверов DNS

Вы также можете определить, Exchange сервер обрабатывает сообщения, идентифицированные как поддельные сообщения, и как сервер Exchange обрабатывает сообщения, когда сервер DNS не может быть достигнут. Параметры обработки Exchange почты и недоступных DNS-серверов включают следующие действия:

Печать состояния. Этот параметр является действием по умолчанию. Все входящие сообщения в организацию имеют статус sender ID, включенный в метаданные сообщения.

Отклонение. Этот параметр отклоняет сообщение и отправляет ответ на ошибку SMTP на сервер отправки. Ответ об ошибке протокола SMTP — это ответ протокола уровня 5 xx с текстом, который соответствует состоянию кода отправителя.

Удаление. Этот параметр удаляет сообщение без информирования системы отправки удаления. Фактически сервер Exchange отправляет на сервер отправки поддельные команды SMTP ОК, а затем удаляет сообщение. Так как сервер отправки предполагает, что сообщение было отправлено, он не будет повторно отправлять сообщение в одном сеансе.

Дополнительные сведения о настройке агента идентификации отправителей см. в разделе Управление кодом отправителя.

Обновление DNS, относящаяся к Интернету, для поддержки ИД отправитель

Эффективность технологии Sender ID зависит от конкретных данных службы DNS. Чем больше организаций обновляют свои DNS-серверы с помощью записи SPF, тем эффективнее идентификатор отправитель идентифицирует поддельные сообщения электронной почты.

Чтобы поддерживать инфраструктуру ИД отправитель, необходимо обновить данные DNS, стоящие перед Интернетом, создав запись SPF и развив запись SPF на общедоступных DNS-серверах. Дополнительные сведения о создании и развертывании записей SPF см. в и. о. отправитель.

Указание доменов получателей и отправителей для исключения из фильтрации кодов отправителей

Может потребоваться исключить определенные домены получателей и отправитель из фильтрации ID отправитель. Для этого необходимо указать домены получателей и отправитель с помощью команды Set-SenderIdConfig в Exchange Management Shell. Дополнительные сведения см. в дополнительных сведениях в set-SenderIdConfig.

Источник

СОДЕРЖАНИЕ

Принцип работы

Идентификатор отправителя пытается улучшить SPF: SPF не проверяет адреса заголовка (которых может быть более одного), которые указывают заявленную отправляющую сторону. Один из этих адресов заголовка обычно отображается пользователю и может использоваться для ответа на электронные письма. Эти адреса заголовков могут отличаться от адреса, который SPF пытается проверить; то есть SPF проверяет только адрес «MAIL FROM», который также называется отправителем конверта.

Однако есть много похожих полей заголовка электронной почты, которые содержат информацию об отправляющей стороне; поэтому Sender ID определяет в RFC 4407 предполагаемый ответственный адрес (PRA), а также набор эвристических правил для установления этого адреса из множества типичных заголовков в электронном письме.

Синтаксически Sender ID почти идентичен SPF, за исключением того, что v=spf1 заменен одним из:

Единственное синтаксическое отличие состоит в том, что Sender ID предлагает возможность позиционных модификаторов, не поддерживаемых в SPF. На практике до сих пор позиционный модификатор не был указан ни в одной реализации идентификатора отправителя.

На практике схема pra обычно предлагает защиту только в том случае, если электронная почта является законной, и не предлагает реальной защиты в случае спама или фишинга. Рг для большинства легитимной электронной почты будет либо знак From: заголовок поля, или, в случае списков рассылки, отправитель: поле заголовка. В случае фишинга или спама, однако, рг может быть основан на Resent- * поля заголовка, которые часто не отображается пользователю. Чтобы быть эффективным средством защиты от фишинга, MUA (почтовый пользовательский агент или почтовый клиент) необходимо будет изменить, чтобы отображать либо pra для идентификатора отправителя, либо поле заголовка Return-Path: для SPF.

Вопросы стандартизации

С SPF списки рассылки продолжают работать как есть. Серверы пересылки, желающие поддерживать SPF, должны изменять только SMTP MAIL FROM и RCPT TO, но не почту. Эта концепция не нова: в исходном RFC 821 серверы пересылки SMTP всегда добавляли свое имя хоста к обратному пути в MAIL FROM.

Патенты

Источник

Что такое Sender ID

Распространение спама может привести к блокировке почтового ящика. При этом необязательно вы сами будете распространять нежелательные письма. самостоятельно. Спамеры «встраиваются» в чужую почту и используют её адрес или другие данные для своих рассылок.

Чтобы бороться со спамом, используются разные технологии, и Sender ID — одна из них.

Sender ID позволяет определять отправителя электронного письма, не допуская подделки обратного адреса.

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

Пример фишинга. Письмо пришло не от официального Instagram компании, а от поддельного почтового ящика

Как работает Sender ID

Технология Sender ID создана на основе двух других технологий — Caller ID и SPF (Sender Policy Framework — подпись с информацией о серверах, которые могут отправлять почту с вашего домена).

Called ID работает так: провайдер, который пропускает через себя почтовый трафик, должен маркировать каждое письмо IP-адресом, с которого оно было отправлено. Сервер получателя должен проверить эту маркировку по своей базе данных и, если IP не внесён в чёрный список, то письмо проходит. В противном случае — помещается в папку «Спам».

Sender ID в свою очередь определяет отправителя, а потом сопоставляет IP его письма с IP домена, в котором находится его почтовый адрес. Если IP совпадают, то письмо проходит, если нет, то блокируется.

Преимущества и недостатки Sender ID

Преимущества

Sender ID помогает бороться со спамом. Он отслеживает почтовые адреса отправителя и препятствует распространению нежелательных писем.

Недостатки

Чтобы технология работала, необходимо, чтобы Sender ID поддерживали почтовые сервера, с которых приходят письма. Ведь письма, которые пришли с серверов без Sender ID, автоматически попадают в спам.

Еще один минус — спамеры, у которых есть собственные почтовые серверы, могут внедрить в них SPF или Sender ID. Тогда на рассылку Sender ID никак не повлияет: письма не попадут в папку «Спам». Конечно, могут сработать и другие спам-фильтры, однако Sender ID будет бесполезен.

Подведём итог

Sender ID препятствует распространению спама, фишинговых атак. В итоге пользователи почты в безопасности: они не откроют поддельные письма от хакеров, не перейдут по ссылке и не скачают на свой компьютер вирус или вредоносную программу.

Однако Sender ID работает, если его используют большое количество почтовых серверов. В противном случае, если письмо пришло с почты, которая не использует Sender ID, оно будет заблокировано. Однако многие почтовые серверы, например, Яндекс, используют Sender ID.

Узнавайте об обновлениях блога Email Soldiers первым

Спасибо!

Осталось подтвердить подписку — кликнуть по кнопке в письме, которое мы вам отправили.

Следите за обновлениями в соцсетях или получайте их от нашего телеграм-бота

Источник

Проблема с Sender ID

Документы, описывающие SPF-Classic (v=spf1) и Sender ID (spf2.0) находятся на рассмотрении в rfc-editor.org, однако документ Sender ID имеет некоторые противоречия с интерпретацией предыдущих стандартов, включая v=spf1.

В связи с этим, сегодня была подана апелляция в соответствующую инстанцию об удалении трёх букв и одного знака препинания из спецификации spf2.0.

Эта апелляция станет восьмой апелляцией в истории соотв. инстанции IESG.

Re: Проблема с Sender ID

P.S. В данном контексте слово из трёх букв не является матерным.

Sender ID implementations SHOULD interpret the version prefix «v=spf1» as equivalent to «spf2.0/mfrom,pra», provided no record starting with «spf2.0» exists.

Sender ID implementations SHOULD interpret the version prefix «v=spf1» as equivalent to «spf2.0/mfrom», provided no record starting with «spf2.0» exists.

Читателю предлагается найти четыре отличия.

Re: Проблема с Sender ID

>Читателю предлагается найти четыре отличия.
Ты такие задание diff_у давай, не напрягай честнОй народ.

Re: Проблема с Sender ID

diff показывет построчные изменения.

Re: Проблема с Sender ID

Отличие одно, но в 4 байта 😉

Re: Проблема с Sender ID

Неправда. Четыре отличия, каждое по одному байту!
😉

Re: Проблема с Sender ID

> diff показывет построчные изменения.

Re: Проблема с Sender ID

У меня стойкое ощущение, что автор новости курил что-то забористое, причем на пару с тем, кто эту новость пропустил. Давайте еще такие новости постить: «в текущей разрабатываемой версии mono, файле foo.c на 149 строчке был удален лишний пробел. Это уже 253 ревизия файла foo.c».

Даже если в новости и содержится какой-то смысл, важность его неплохо бы пояснить в ней же. А если практического смысла для заглавной страницы lorа нет, то нефиг такое пропускать. ИМО.

Re: Проблема с Sender ID

А какие MTA поддерживают Sender ID?

Re: Проблема с Sender ID

Re: Проблема с Sender ID

SPF слишком малоэффективен, пока его не начнут использовать все, все его не начнут использовать потомучто пока он слишком малоэффективен.

К тому же при больших потоках почты эта бяка неимоверно снижает производительность почтовой системы. В лучшем случае народ пропишет один раз spf записи для своих доменов и позабует про них, а проверять по spf вообще мало кто будет. Ну рзве что пальцастые админы мелких почтовиков, где они не увидят потери производительности, или конторы типа AOL, которым это будет повод содрать денег с юзеров.

При текущей реализации оно имхо больше проблем порождает чем решений.

Re: Проблема с Sender ID

мы это уже обсуждали. все его начнут использовать тогда когда MSN, AOL и ещё пара крупных контор (навроде Google) будет игнорировать правило «

Re: Проблема с Sender ID

> мы это уже обсуждали. все его начнут использовать тогда когда MSN, AOL и ещё пара крупных контор (навроде Google) будет игнорировать правило «

А они этого делать не станут, поа 95% (от общающихся с ними) у себя записи не пропишет, а они не пропишут. Вот и получается замкнутый круг.

Re: Проблема с Sender ID

В какую это сторону они начнут игнорировать softfail (‘

Re: Проблема с Sender ID

Ну ведь всегда нужно с чего-нибудь начать?

Допустим, что сначала все просто опубликуют записи об SPF, это уже будет большой прогресс! После этого будет смысл включать SPF-утилиты в стандартные комплекты поставки MTA’ев, а там и глядишь, недолго и до того, как фичу будут действительно использовать по назначению.

Да и вообще, SPF пока ещё даже не был признан стандартом, а уже столько народу использует! И Яндекс, и Гугл, и AOL!

Re: Проблема с Sender ID

Ну как вы сами уже заявляли, многие записи-то прописывают, проблема в том, что далеко не все эти записи в данный момент проверяют. 😉

Re: Проблема с Sender ID

> Ну как вы сами уже заявляли, многие записи-то прописывают, проблема в том, что далеко не все эти записи в данный момент проверяют. 😉

Я вот то же прописываю. 🙂 А проверять пока смысла большого не имеет.

Re: Проблема с Sender ID

И я прописываю, насколько позволяют провайдеры, и проверял бы, да вот пока такой возможности нет (читай «провайдер не предоставляет данной опции»).

Re: Проблема с Sender ID

Народ, ставьте себе smc-milter для senmail или что-нибудь похожее для своего MTA. Простая проверка входящей почты на соответствие уже существующим правилам отправки почты (проверка обратного адреса и проч) останавливет около 90% спама безо всяких заморочек с DNS.

Re: Проблема с Sender ID

Ну и посмотрел я описание «вашего» smc-milter, так у него заморочки с DNS ещё приличнее. SPF отдыхает.

Источник

Интеграция с сервисом (API)

API позволяет рассылать сообщения через ваши проекты и сервисы по протоколам HTTP/HTTPS, SMTP и SMPP. Готовые библиотеки на разных языках программирования подключаются к вашему проекту и помогают отправлять сообщения из любого места с помощью одной команды.

SMPP протокол

Подключение

Через наш SMS-шлюз возможно отправлять сообщения по протоколу SMPP версий 3.4 и 5.0.
Для получения доступа по SMPP-протоколу необходимо включить в настройках в группе «Настройки API» соответствующую опцию и добавить IP-адреса, с которых будете выполнять подключение, на этой странице.

Адрес SMPP-сервера: smpp.smsc.ru, порт: 3700.
Для шифрованного SSL-подключения используется порт 3443.

Адрес резервного SMPP-сервера: smpp2.smsc.ru.

Пример настроек для подключения (формат kannel): group = smsc
smsc = smpp
smsc-id = smsc
host = smpp.smsc.ru
port = 3700
smsc-username =
smsc-password =

system-type = «»
interface-version = 34
source-addr-autodete ct = yes
source-addr-ton = 5
source-addr-npi = 1
dest-addr-ton = 1
dest-addr-npi = 1
validityperiod = 1440
transceiver-mode = true
receive-port = 0
enquire-link-interva l = 60
wait-ack-expire = 0
max-pending-submits = 300
throughput = 30

Максимально возможный интервал бездействия составляет 2 минуты. В течение этого времени Клиенту необходимо отправить сообщение или выполнить пустую команду ENQUIRE_LINK, иначе соединение будет разорвано из-за не активности.

Логин используется от личного кабинета, пароль должен быть создан на странице Пароли для доступа. Логин и пароль не должны быть на русском языке.
Данный раздел содержит только краткое описание SMPP-протокола. Подробности смотрите в спецификации.

Скачать спецификацию протокола SMPP v3.4 smpp34.zip (500 Кб) smpp34rus.zip (1,1 Mб).

Скорость рассылок

Пропускная способность подключения или количество отправляемых каждую секунду SMS-сообщений зависит от размера окна передачи (smpp window size). В примере настроек данный параметр называется max-pending-submits. Для массовых рассылок лучше задавать большие значения (1000-2000). Также в примере параметр throughput задает ограничение на максимальное количество SMS-сообщений в секунду.

Вместе с массовыми рассылками через одно подключение можно отправлять и срочные одиночные SMS-уведомления. Система установит максимальный приоритет таким сообщениям и отправит их раньше любых массовых рассылок без ожидания в очереди.

При массовой отправке сообщений не стоит забывать о системе контроля скорости отправки сообщений в секунду, при превышении которой происходит генерация ошибки превышения скорости (throttling). В случае получения данной ошибки Клиенту по SMPP-стандарту необходимо повторить отправку, снизив общую скорость на своей стороне. По умолчанию скорость задана 30 SMS/cек для каждого аккаунта. Для изменения максимально разрешенной скорости необходимо отправить запрос в службу поддержки сервиса.

Множественные подключения

По умолчанию сервер обрабатывает одновременно с одного логина только одно подключение для более корректной отдачи статусов, поэтому при повторном подключении ранее подключенное соединение с таким же логином будет автоматически завершаться. Если же необходимо иметь несколько одновременных подключений для повышения скорости отправки, то можно в настройках всех подключений задать следующий параметр (multi connection):
system-type = «MCON2»
или
system-type = «MCON9» Значение после MCON может быть от 1 до 9 и задает количество одновременных подключений.

Также возможны одновременные подключения с разными логинами, привязанными к одному личному кабинету и счету. Для этого необходимо создать в личном кабинете в разделе «Реселлер» дополнительные аккаунты с необходимым типом субаккаунта.

Отправка SMS-сообщения

Для отправки SMS-сообщения используйте команду SUBMIT_SM согласно спецификации.

Для использования кодировки ISO-8859-1 (ASCII) вместо GSM при подключении нужно указать:
system-type = «ISO»
В текст SMS-сообщения можно добавлять комментарии, предназначенные для просмотра отправителем истории сообщений в личном кабинете.

Команда SUBMIT_MULTI для множественной рассылки пока не реализована.

Сервер не принимает более одного одинакового запроса на отправку SMS-сообщений в течение минуты для защиты от ошибок и зацикливаний в программе на стороне Клиента для того, чтобы снизить нагрузку и не расходовать средства Клиента, а также не допустить многократной отправки сообщения одному абоненту.

Сервер также блокирует отправку более 50 сообщений одному абоненту, которые были отправлены с перерывом между сообщениями менее 30-ти секунд, для защиты от флуда и лишнего списания средств со счета Клиента, так как многие операторы не пропускают большое количество сообщений одному абоненту за короткий промежуток времени.

Комментарии в SMS-сообщениях

При отправке SMS-сообщений можно добавлять в конец текста любой комментарий, уточняющий либо дополняющий SMS-сообщение для отправителя. Данный текст не будет отправляться абонентам и влиять на стоимость SMS и доступен для просмотра и фильтрации в списке отправленных сообщений в личном кабинете.

Для добавления комментария необходимо в конце текста SMS-сообщения, предназначенного для отправки, указать специальную комбинацию «\n

\n» (перевод строки, 3 символа тильды и снова перевод строки), и после этого любой текст, который будет считаться комментарием, не будет отправлен абоненту, но отобразится в истории.

Отправка MMS-сообщения

Отправка e-mail сообщения

Отправка голосового сообщения (звонок)

Для отправки голосового сообщения используйте команду SUBMIT_SM с текстом «__CALL__: \nvoice: » (текст «__CALL__», двоеточие, пробел, текст сообщения, перевод строки, слово «voice», двоеточие, голос, используемый для озвучивания текста).

\n» (перевод строки, 3 символа тильды и снова перевод строки), после которой передать параметр param, определяющий некоторые характеристики звонка (более подробно можно посмотреть в описании).

Отправка viber-сообщения

Для отправки viber-сообщения используйте команду SUBMIT_SM с текстом «__VIBER__: » (текст «__VIBER__», двоеточие, пробел, текст сообщения).

При формировании текста сообщения можно использовать специальные макросы для создания кнопки, при нажатии на которую будет происходить открытие браузера и переход по указанной в макросе ссылке, а также прикреплять файлы. Более подробно дополнительные возможности при отправке viber-сообщений описаны в документации к http-протоколу.

Отправка soc-сообщения

Для отправки soc-сообщения, отправляемого пользователям социальных сетей «Одноклассники», «ВКонтакте» или пользователям «Mail.Ru Агент», используйте команду SUBMIT_SM с текстом «__SOC__: » (текст «__SOC__», двоеточие, пробел, текст сообщения).

Отправка HLR-запроса

Для отправки HLR-запроса используйте команду SUBMIT_SM с текстом __HLR__. Результат запроса приходит в обычном статусе (Delivery Report), который можно получить как по SMPP-подключению, так и по HTTP на свой обработчик.

Формат статуса с результатом HLR-запроса, возвращаемого по SMPP: id: stat: err: imsi: msc: mcc: mnc: cn: net: rcn: rnet:
Описание параметров:

Параметр	Значение
id	Идентификатор сообщения.
status	Статус сообщения.
err	Код ошибки, если абонент недоступен (список).
imsi	Уникальный код IMSI SIM-карты абонента.
msc	Номер сервис-центра оператора, в сети которого находится абонент.
mcc	Числовой код страны абонента.
mnc	Числовой код оператора абонента.
cn	Название страны регистрации абонента.
net	Название оператора регистрации абонента.
rcn	Название роуминговой страны абонента при нахождении в чужой сети.
rnet	Название роумингового оператора абонента при нахождении в чужой сети.

Строковые данные, например, страна и оператор, закодированы через функцию urlencode.

Проверка статуса

Получать статус доставки отправленного SMS-сообщения по SMPP-протоколу можно как в автоматическом режиме, получая от сервера ответную PDU-команду DELIVER_SM сразу после изменения статуса, так и по запросу отдельной командой QUERY_SM. Для автоматического получения статуса по SMPP-протоколу необходимо подключаться в режиме transceiver или receiver и при отправке SMS указывать флаг запроса статуса (registered_delivery). Если при отправке не указывать данный флаг, то статусы сообщений будут передаваться на HTTP-обработчик.

При автоматическом возврате статуса в команде DELIVER_SM передаются стандартные TLV-параметры receipted_message_id ( ), message_state (числовой ) и network_error_code ( ), а также дополнительные TLV-поля с кодами 0x2000 и 0x2001, содержащие информацию о стоимости и типе сообщения:

Имя (код) поля	Размер	Тип	Описание
8192 (0x2000)	Var. max 6	COctet String	Стоимость сообщения в формате «n.nnnn».
8193 (0x2001)	2	Integer	Флаг в виде 2-х байтового числа, содержащий различную информацию о сообщении. Возможны комбинации значений битов разных характеристик. Биты 0-3 (тип сообщения): 0 (по умолчанию) – SMS. 1 – Flash-SMS. 2 – Бинарное SMS. 3 – Wap-push. 4 – HLR-запрос. 5 – Ping-SMS. 6 – MMS. 7 – Звонок. 10 – Viber. Бит 5 – оплата сообщения со второго баланса. Бит 8 – признак шаблонного сообщения.

Также в команде DELIVER_SM передается текст статуса в следующем формате:
id: sub: dlvrd: submit date: done date: stat: err:
Описание параметров:

Параметр	Значение
id	Идентификатор сообщения, назначенный сервером при отправке.
sub	Количество SMS частей в отправленном сообщении.
dlvrd	Количество доставленных SMS.
submit date	Дата отправки.
done date	Дата изменения статуса.
status	Статус сообщения в виде строки (DELIVRD, EXPIRED, UNDELIV).
err	Код ошибки, если сообщение не может быть доставлено (список).

Пример результата строки статуса (Delivery Report): id:854019 sub:001 dlvrd:001 submit date:1108202241 done date:1108202241 stat:DELIVRD err:000

По умолчанию для длинных сообщений, разбиваемых на несколько SMS, сервер возвращает только один статус (DELIVER_SM) для всего склеенного сообщения и одинаковые ID в ответе SUBMIT_SM_RESP для всех SMS-частей данного сообщения. Для включения режима обработки и возврата статусов для каждой SMS-части отдельно установите следующий параметр в настройках подключения (либо в настройках личного кабинета): system-type = «SINGLE»
Если необходимо указать несколько параметров в поле system-type, то укажите их через запятую: system-type = «ISO,SINGLE»

Получение входящих сообщений

Для включения пересылки входящих SMS-сообщений по SMPP-подключению необходимо установить галочку «Передавать входящие SMS по SMPP-подключению» в настройках личного кабинета (раскрывающаяся вкладка «Настройки API») либо обратиться в службу поддержки. При этом передача входящих сообщений на обработчик Клиента должна быть отключена.

Входящие сообщения приходят в PDU-команде DELIVER_SM. Для получения необходимо подключаться к SMPP-серверу в режиме transceiver или receiver.

Коды ошибок в статусе

Возможные коды ошибок в статусе сообщений или HLR-запросов (значения ):

Источник