Что такое коды состояния аутентификации электронной почты. Какие новые коды вводит RFC 7372. Как используются коды для DKIM, SPF и обратной проверки DNS. Какие преимущества дают эти коды.
Что такое коды состояния аутентификации электронной почты
Коды состояния аутентификации электронной почты — это специальные расширенные коды, которые позволяют почтовым серверам сообщать клиентам о причинах отклонения или задержки сообщений, связанных с проблемами аутентификации. Эти коды были введены в RFC 7372 в 2014 году для улучшения диагностики проблем с доставкой электронной почты.
Основные причины для введения таких кодов:
- Существующие коды состояния не позволяли точно указать причину отказа, связанную с аутентификацией
- Новые коды дают более подробную информацию клиентам о проблемах с DKIM, SPF и обратной проверкой DNS
- Это позволяет лучше диагностировать и устранять проблемы с доставкой писем
Новые коды состояния в RFC 7372
RFC 7372 вводит следующие новые расширенные коды состояния:
- X.7.20 — Проходящая подпись DKIM не найдена
- X.7.21 — Подходящая подпись DKIM не найдена
- X.7.22 — Не найдено действительной подписи DKIM, соответствующей автору
- X.7.23 — Проверка SPF не удалась
- X.7.24 — Ошибка проверки SPF
- X.7.25 — Обратная проверка DNS не удалась
- X.7.26 — Многократные проверки подлинности не пройдены
Коды для DKIM аутентификации
DKIM (DomainKeys Identified Mail) — это метод аутентификации электронной почты, который позволяет проверить подлинность отправителя письма. RFC 7372 вводит три новых кода состояния для DKIM:
- X.7.20 — возвращается, когда в сообщении нет ни одной проходящей DKIM подписи
- X.7.21 — возвращается, когда есть проходящие подписи, но ни одна не является приемлемой по локальным требованиям
- X.7.22 — возвращается, когда нет приемлемой подписи, соответствующей адресу отправителя в поле From
Эти коды позволяют более точно указать причину отказа, связанную с DKIM аутентификацией. Например, код X.7.22 говорит о том, что подпись есть, но она не соответствует отправителю, что может указывать на подделку письма.
Коды для SPF проверки
SPF (Sender Policy Framework) — это метод проверки того, что IP-адрес отправителя письма авторизован для отправки почты от имени указанного домена. RFC 7372 вводит два кода для SPF:
- X.7.23 — возвращается при неудачной проверке SPF, противоречащей локальной политике
- X.7.24 — возвращается при ошибке в процессе проверки SPF
Эти коды позволяют отличить случаи, когда SPF проверка явно не прошла, от случаев, когда произошла ошибка при проверке. Это помогает диагностировать проблемы с настройкой SPF записей.
Код для обратной проверки DNS
Обратная проверка DNS — это метод проверки соответствия IP-адреса отправителя его доменному имени. RFC 7372 вводит код:
- X.7.25 — возвращается, когда обратная проверка DNS не удалась
Этот код позволяет явно указать на проблему с обратной DNS-записью для IP-адреса отправителя. Это может помочь администраторам обнаружить и исправить неправильные настройки DNS.
Код для множественных ошибок аутентификации
RFC 7372 также вводит общий код для случаев, когда не прошло несколько проверок аутентификации:
- X.7.26 — возвращается, когда не удалось пройти более одной проверки аутентификации
Этот код рекомендуется использовать вместо указания только первой неудачной проверки, так как он дает более полную картину проблем с аутентификацией.
Преимущества использования новых кодов состояния
Введение новых кодов состояния аутентификации в RFC 7372 дает ряд преимуществ:
- Более точная диагностика проблем с доставкой писем
- Возможность автоматизировать обработку ошибок аутентификации
- Улучшение совместимости между различными почтовыми системами
- Помощь администраторам в настройке и отладке механизмов аутентификации
- Повышение безопасности электронной почты за счет лучшего выявления поддельных писем
Применение кодов состояния на практике
На практике новые коды состояния аутентификации могут применяться следующим образом:
- Почтовые серверы возвращают эти коды при отклонении или задержке писем
- Почтовые клиенты используют коды для информирования пользователей о причинах проблем с отправкой
- Системы мониторинга анализируют коды для выявления проблем с настройкой DKIM, SPF, DNS
- Списки рассылки используют коды для очистки базы подписчиков от недействительных адресов
Важно отметить, что использование этих кодов необязательно. Операторы могут продолжать использовать общие коды ошибок, если не хотят раскрывать детали своей политики аутентификации.
Ограничения и проблемы использования новых кодов
При использовании новых кодов состояния аутентификации следует учитывать некоторые ограничения и потенциальные проблемы:
- Протокол SMTP позволяет вернуть только один расширенный код состояния за один обмен
- Отказ может быть вызван несколькими причинами, не только проблемами аутентификации
- Использование кодов раскрывает детали локальной политики аутентификации, что может быть нежелательно
- Не все почтовые системы могут корректно обрабатывать новые коды
Поэтому при внедрении этих кодов нужно тщательно продумать политику их использования и возможные последствия.
Заключение
Введение новых кодов состояния аутентификации в RFC 7372 стало важным шагом в развитии стандартов электронной почты. Эти коды позволяют более точно диагностировать проблемы с доставкой писем, связанные с DKIM, SPF и обратной проверкой DNS. Их использование помогает повысить безопасность и надежность систем электронной почты.
Однако внедрение этих кодов требует взвешенного подхода с учетом возможных ограничений и проблем. В целом, новые коды состояния аутентификации являются полезным инструментом для администраторов и разработчиков почтовых систем, позволяющим улучшить обработку ошибок и диагностику проблем с доставкой электронной почты.
Проволока канатная ГОСТ 7372-79 — Северсталь-метиз
Возможность производства проволоки без покрытия
|
Диаметр,мм |
Маркировочная группа, Н/мм2 (кгс/мм2) |
||||
|
1370 (140) |
1770 (180) |
1960 (200) |
2160 (220) |
||
|
0,20-0,30 |
— |
— |
+ |
+ |
+ |
|
0,31-0,65 |
— |
+ |
+ |
+ |
+ |
|
0,70-3,00 |
+ |
+ |
+ |
+ |
+ |
|
3,01-3,50 |
+ |
+ |
+ |
+ |
— |
|
3,51-4,00 |
+ |
+ |
+ |
— |
— |
|
4,01-5,00 |
+ |
+ |
— |
— |
— |
Возможность производства оцинкованной проволоки группы «С» и «Ж»
|
Диаметр, мм |
Маркировочная группа, Н/мм2 (кгс/мм2) |
||||
|
1370 (140) |
1570 (160) |
1770 (180) |
1960 (200) |
2160 (220) |
|
|
0,20-0,30 |
— |
— |
+ |
+ |
+ |
|
0,31-0,65 |
— |
+ |
+ |
+ |
+ |
|
0,70-2,20 |
+ |
+ |
+ |
+ |
+ |
|
2,21-3,50 |
+ |
+ |
+ |
+ |
— |
|
3,51-4,00 |
+ |
+ |
+ |
— |
— |
|
4,01-5,00 |
+ |
+ |
— |
— |
— |
Геометрические параметры проволоки
|
Диаметр проволоки, мм |
Проволока без покрытия |
Оцинкованная проволока |
|
Группы С и Ж |
||
|
0,20-0,38 |
±0. 01 |
+0.02 -0.01 |
|
0.40-0.75 |
+0.02 -0.01 |
+0.03 -0.01 |
|
0.80-1,50 |
±0.02 |
+0.04 -0.01 |
|
1.60-2.30 |
±0.03 |
+0.05 -0.01 |
|
2,40-3.60 |
+0.06 -0.01 |
|
|
3.80-5.00 |
±0.04 |
+0.07 -0.01 |
Поверхностная плотность цинка
|
Диаметр проволоки, мм |
Поверхностная плотность цинка, г/м2, не менее, для групп |
|
|
С |
Ж |
|
|
0,20-0,24 |
15 |
20 |
|
Свыше 0,24-0,32 |
20 |
25 |
|
Свыше 0,32-0,38 |
||
|
Свыше 0,38-0,45 |
30 |
40 |
|
Свыше 0,45-0,55 |
35 |
|
|
Свыше 0,55-0,65 |
40 |
50 |
|
Свыше 0,65-0,75 |
60 |
|
|
Свыше 0,75-0,95 |
50 |
70 |
|
Свыше 0,95-1,15 |
60 |
80 |
|
Свыше 1,15-1,40 |
90 |
|
|
Свыше 1,40-1,80 |
70 |
100 |
|
Свыше 1,80-2,40 |
80 |
110 |
|
Свыше 2,40-3,00 |
90 |
125 |
|
Свыше 3,00-3,80 |
100 |
135 |
|
Свыше 3,80-4,40 |
110 |
150 |
|
Свыше 4,40-5,00 |
165 |
|
Тепловое реле перегрузки РТН-7372 200-320А TDM SQ0712-0026
Похоже JavaScript оключен в вашем браузере.
Вам необходимо включить поддержку JavaScript в браузере или воспользоваться другим браузером.
- Избранное
- Сравнить
Поделиться
Артикул: 004.030.136
Производитель: ТДМ
Тепловое реле РТН-7372 с диапазоном уставок тока 200…320А применяется для защиты электродвигателей от:
− перегрузки;
− ассиметрии и обрыва фаз;
− превышения длительности пуска;
− заклинивания ротора.
Тепловое реле постоянно контролирует ток, потребляемый электродвигателем. Когда значение тока превышает уставку, вспомогательные контакты теплового реле изменяют своё положение, вызывая остановку электродвигателя.
7171.00₽
- Описание
- Номенклатура
- Документация
Технические характеристики
| Диапазон регулировки тока уставки | 200–320 А |
| Номинальное напряжение катушек управления | 660 В |
| Количество и вид контактов | 1з+1р |
| Способ монтажа | Винтовое соединение |
| Типы контакторов, используемых с реле | КТН-5330 |
| Код по каталогу изготовителя | SQ0712-0026 |
Размеры
Конструкция
- Пломбирование прозрачной крышки, защищающей диск регулировки уставки, исключает несанкционированный доступ к регулировкам рабочих значений тока уставки.
- Процесс повторного включения может происходить в двух режимах: ручном и автоматическом.
- О текущем состоянии размыкающих и замыкающих контактов информирует индикатор на передней панели.
- Наличие кнопки «Тест» позволяет проверить работоспособность реле до его подключения в силовую цепь.
- Возможность принудительной остановки контактора.
Номенклатура электротепловых реле РТН
| Наименование | Артикул | Диапазон установок реле, А | Рекомендуемый контактор |
|---|---|---|---|
| РТН-5370 63-90А | SQ0712-0020 | 63-90 | KTH 5115 |
| РТН-5371 90-120А | SQ0712-0021 | 90-120 | KTH 5116 |
| РТН-5372 110-135А | SQ0712-0022 | 110-135 | KTH 5150 |
| РТН-5374 135-160А | SQ0712-0020 | 135-160 | KTH 5185 |
| РТН-5376 150-180А | SQ0712-0024 | 150-180 | KTH 5225 |
| РТН-6378 160-250А | SQ0712-0025 | 160-250 | KTH 5265 |
| РТН-7372 200-320А | SQ0712-0026 | 200-320 | KTH 5330 |
| РТН-7374 250-400А | SQ0712-0027 | 250-400 | KTH 6400 |
| РТН-8370 320-500А | SQ0712-0028 | 320-500 | KTH 6500 |
| РТН-8373 400-630А | SQ0712-0029 | 400-630 | KTH 7630 |
Вспомогательные элементы и аксессуары для SQ0712-0026
Аналогичные товары или товары на замену SQ0712-0026
Низковольтное оборудование ТДМ | |
Электротепловые реле серии РТН ТДМ |
jpg»>Двухдиапазонная точка доступа Ruckus ZoneFlex 7372, 901-7372-US00
Нет в наличии, но мы можем сотворить чудо!
Свяжитесь с намиОбеспечение высокопроизводительных мобильных сетей с двухдиапазонным доступом среднего радиуса действия
Чувствительные к задержкам IP-телефония и видео предъявляют повышенные требования к беспроводной локальной сети (WLAN), особенно в местах с высокой плотностью бизнеса.
Двухдиапазонные точки доступа (AP) Ruckus Wireless ZoneFlex™ 7372 среднего радиуса действия 802.11n 2×2:2 помогают сетевым операторам поддерживать превосходную производительность с лучшей в своем классе емкостью и поддержкой самых сложных современных приложений.
Двухдиапазонные точки доступа ZoneFlex 7372 обеспечивают надежный доступ в средах с высокой плотностью. Запатентованные компанией Ruckus адаптивные антенные решетки BeamFlex+™ и технология формирования луча передачи (TxBF) обеспечивают увеличение пропускной способности и повышение производительности до 4 раз. Эти двухпотоковые точки доступа обеспечивают самую надежную связь и лучшее соотношение цены и качества в сложных, постоянно меняющихся радиочастотных средах.
Ruckus 7372 Особенности:
- Улучшение отношения сигнал-помеха плюс шум (SINR) до 4 дБ и подавление помех до 15 дБ по сравнению с другими точками доступа
- Одновременная поддержка 2,4 ГГц и 5 ГГц
- Поддержка до до 500 одновременных клиентов
- Поддержка пространственного мультиплексирования
- Теоретическая пропускная способность 300 Мбит/с на радиостанцию
- Технология антенны BeamFlex+ адаптируется к местоположению клиента и полярности радиочастотного сигнала
- Одновременное прослушивание во всех поляризациях
- Идеальное решение для VoIP и IPTV HD-качества с поддержкой изохронной многоадресной потоковой передачи IP-видео и 4 очередей на клиентскую станцию
- Smart Mesh Networking повышает гибкость, снижает затраты
- Двухпоточный MIMO 2×2:2
- Новый выбор каналов
- Автоматическое подавление помех
- 27 BSSID поддерживают дифференцированные услуги с QoS и безопасностью
- Поддерживает WEP, WPA-PSK (AES), 802. 1X
- Zero-IT и динамический PSK
- Captive-портал и гостевые учетные записи
- Поддерживает RADIUS и Active Directory блоки питания, поэтому вам понадобится инжектор POE, дополнительный блок питания или коммутатор POE.
- WM #:
- 112512170
- Тип товара:
- Точка доступа (AP)
- Наружное использование:
- №
- Максимальная пропускная способность (Мбит/с):
- 100+ Мбит/с
RFC 7372: Коды состояния аутентификации по электронной почте
RFC 7372: коды состояния аутентификации по электронной почте [Домашняя страница RFC] [ТЕКСТ|PDF|HTML] [Отслеживание] [ПИС] [Информационная страница]ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Инженерная рабочая группа Интернета (IETF) М.
Кучерави
Запрос комментариев: 7372 Сентябрь 2014 г.
Обновлений: 7208
Категория: Трек стандартов
ISSN: 2070-1721
Коды состояния аутентификации по электронной почте
Абстрактный
Этот документ регистрирует кодовые точки, чтобы разрешить коды состояния быть
возвращается почтовому клиенту, чтобы указать, что сообщение
отклонено или отложено именно из-за аутентификации по электронной почте
неудачи.
Этот документ обновляет RFC 7208, поскольку некоторые кодовые точки
зарегистрированные заменяют те, которые рекомендованы для использования в этом документе.
Статус этого меморандума
Это документ для отслеживания стандартов Интернета.
Этот документ является продуктом Инженерной группы Интернета.
(IETF). Он представляет собой консенсус сообщества IETF. Оно имеет
получил общественное мнение и был одобрен для публикации
Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 5741.
Информация о текущем статусе этого документа, любых опечатках,
и как предоставить отзыв о нем можно получить на
http://www.rfc-editor.org/info/rfc7372.
Уведомление об авторских правах
Copyright (c) 2014 IETF Trust и лица, указанные в качестве
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
внимательно, так как они описывают ваши права и ограничения в отношении
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить текст упрощенной лицензии BSD, как описано в Разделе 4.e
Доверительные юридические положения и предоставляются без гарантии, поскольку
описан в Упрощенной лицензии BSD.
Kucherawy Standards Track [Страница 1] RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г.
Оглавление
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Ключевые слова. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Новые расширенные коды состояния. . . . . . . . . . . . . . . . . . 3
3.1. Коды ошибок DKIM. . . . . . . . . . . . . . . . . . . 3
3.2. Коды неисправности SPF. . . . . . . . . . . . . . . . . . . . 4
3.3. Обратный код ошибки DNS. . . . . . . . . . . . . . . . 5
3.4. Код множественных ошибок аутентификации. . . . . . . . . . 5
4. Общие соображения. . . . . . . . . . . . . . . . . . . 5
5. Вопросы безопасности. . . . . . . . . . . . . . . . . . . 6
6. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 6
7. Нормативные ссылки. . . . . . . . . . . . . . . . . . . . 7
Приложение А. Благодарности. . . . . . . . . . . . . . . . . . 8
1. Введение
[RFC3463] представил коды состояния расширенной почтовой системы, а [RFC5248]
создал для них реестр IANA.
[RFC6376] и [RFC7208] представили, соответственно, DomainKeys.
Идентифицированная почта (DKIM) и Sender Policy Framework (SPF), два
протоколы для проведения аутентификации сообщений. Еще один распространенный
приемочный тест электронной почты — это обратная проверка системы доменных имен (DNS)
на IP-адресе почтового клиента, как описано в Разделе 3
[RFC7001].
Текущий набор расширенных кодов состояния не включает код
для указания того, что сообщение отклонено или отложено из-за
причины местной политики, связанные с любым из этих механизмов. Это
потенциально полезная информация для агентов, которым нужно больше, чем
рудиментарная обработка информации о причине, по которой сообщение было
отклонено при получении. В этом документе представлены расширенные коды состояния
для сообщения об этих случаях клиентам.
Раздел 3.2 обновляет [RFC7208] по мере необходимости новых расширенных кодов состояния.
этой спецификации регистрируются и рекомендуются к использованию.
2. Ключевые слова
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
«СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
«НЕОБЯЗАТЕЛЬНО» в этом документе следует интерпретировать, как описано в
[RFC2119].
Kucherawy Standards Track [Страница 2] RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г. 3. Новые расширенные коды состояния Новые расширенные коды состояния определены в следующем подразделы. 3.1. Коды ошибок DKIM В приведенных ниже определениях кодовых точек следующие определения: использовал: прохождение: Подпись считается проходящей, если базовая проверка DKIM алгоритм, определенный в [RFC6376], работает успешно. приемлемо: Подпись является «приемлемой», если она удовлетворяет всем местным требованиям. определенные требования (если таковые имеются) в дополнение к прохождению основных Алгоритм проверки DKIM (например, некоторые поля заголовка включены в подписанный контент, без частичных подписей и т. д.). Код: X.7.20 Образец текста: Проходящая подпись DKIM не найдена Связанный базовый код состояния: 550 Описание: этот код состояния возвращается, когда сообщение не содержал ни одного проходящего DKIM подписи. (Это нарушает
рекомендация Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
Код: X.7.21
Образец текста: Подходящая подпись DKIM не найдена
Связанный базовый код состояния: 550
Описание: этот код состояния возвращается, когда сообщение
содержит одну или несколько проходных DKIM-подписей,
но ни один не приемлем. (Это нарушает
рекомендация Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
Трек стандартов Kucherawy [Страница 3] RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г. Код: X.7.22 Образец текста: не найдено действительной подписи DKIM, соответствующей автору Связанный базовый код состояния: 550 Описание: этот код состояния возвращается, когда сообщение содержит один или несколько проходящих DKIM подписи, но ни одна из них не является приемлемой, потому что ни у кого нет идентификатора (ов) который совпадает с адресом(ами) автора, найденным в поле заголовка From. Это особый
случай X.7.21. (Это нарушает совет
Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
3.2. Коды отказа SPF
Код: X.7.23
Образец текста: проверка SPF не удалась
Связанный базовый код состояния: 550
Описание: этот код состояния возвращается, когда сообщение
завершили проверку SPF, которая произвела
"неудачный" результат, противоречащий местной политике
требования. Используется вместо 5.7.1, т.к.
описано в Разделе 8.4 RFC 7208.
Ссылка: [RFC7372]; [RFC7208]
Автор: М. Кучерави
Контроллер изменений: IESG
Код: X.7.24
Образец текста: ошибка проверки SPF
Связанный основной код состояния: 451/550
Описание: Этот код состояния возвращается при оценке
SPF относительно пришедшего сообщения
привело к ошибке. Используется вместо
4.4.3 или 5.5.2, как описано в разделах
8.6 и 8.7 RFC 7208.
Ссылка: [RFC7372]; [RFC7208]
Автор: М. Кучерави
Контроллер изменений: IESG
Трек стандартов Kucherawy [Страница 4] RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г. 3.3. Обратный код ошибки DNS Код: X.7.25 Образец текста: обратная проверка DNS не удалась Связанный базовый код состояния: 550 Описание: этот код состояния возвращается, когда SMTP IP-адрес клиента не прошел обратный DNS проверочная проверка, противоречащая локальной политике требования. Ссылка: [RFC7372]; Раздел 3 [RFC7001] Автор: М. Кучерави Контроллер изменений: IESG 3.4. Код множественных ошибок аутентификации Код: X.7.26 Образец текста: Многократные проверки подлинности не пройдены Связанный базовый код состояния: 550 Описание: этот код состояния возвращается, когда сообщение не удалось проверить подлинность более одного сообщения проверить, вопреки требованиям местной политики.
Конкретные механизмы, которые вышли из строя, не
указано.
Ссылка: [RFC7372]
Автор: М. Кучерави
Контроллер изменений: IESG
4. Общие соображения
По характеру простого протокола передачи почты (SMTP) только один
расширенный код состояния может быть возвращен для данного обмена между
клиент и сервер. Однако оператор может решить отложить или
отклонить сообщение по множеству причин. Клиенты, получающие эти
коды должны учитывать, что отказ, отраженный одним из этих
коды состояния могут не отражать единственную причину или наиболее важную
причина непринятия сообщения или команды.
Важно отметить, что раздел 6.1 [RFC6376] не рекомендует
специальная обработка сообщений без действительной подписи DKIM. Там
некоторые операторы игнорируют этот совет, некоторые из них поступают так
насколько требуется действующая подпись домена автора (т. е. одна
соответствие домену(ам) в поле заголовка From), чтобы принять
сообщение. Более того, некоторые зарождающиеся технологии, основанные на SPF и
DKIM зависит от такой аутентификации. Эта работа не поддерживает
конфигурации, которые нарушают рекомендации DKIM, а скорее
признает, что они существуют, и просто стремится обеспечить
улучшенная совместимость с такими операторами.
Трек стандартов Kucherawy [Страница 5] RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г. Конкретным вариантом использования этих кодов является программное обеспечение для списка рассылки, которое обрабатывает отказы, чтобы удалить из набора подписчиков те адреса, которые больше не действительны. В таком случае необходимо отличать ошибки аутентификации от признаков того, что адрес получателя больше недействителен. Если принимающий сервер выполняет несколько проверок аутентификации и более чем один из них выходит из строя, что требует отказа от сообщение, серверу SMTP СЛЕДУЕТ использовать код, указывающий на несколько методы отказали, а не сообщали только о первом неудачном.
Может случиться так, что один метод всегда будет неудачным; таким образом,
возврат конкретного кода этого метода не является информацией, полезной для
отправляющий агент.
Проверка обратного IP-DNS описана в разделе 3 [RFC7001].
Любые технологии проверки подлинности сообщений или применения политик
разрабатываемые в будущем должны также включать регистрацию собственных
расширенные коды состояния, так что этот вид конкретной отчетности
доступны операторам, которые хотят их использовать.
5. Вопросы безопасности
Использование этих кодов раскрывает локальную политику в отношении электронной почты.
аутентификации, которая может быть полезной информацией для субъектов, пытающихся
для доставки нежелательной почты. Следует отметить, что нет
конкретное обязательство использовать эти коды; если оператор не желает
раскрыть этот аспект локальной политики, он может продолжать использовать общий
код результата, такой как 5.7.7, 5.7.1 или даже 5.7.0.
6. Соображения IANA
Регистрация новых расширенных кодов состояния, для добавления к
Подреестр перечислимых кодов состояния расширенного состояния SMTP
Реестр кодов можно найти в Разделе 3.
Трек стандартов Kucherawy [Страница 6]
RFC 7372 Коды статуса аутентификации по электронной почте Сентябрь 2014 г. 7. Нормативные ссылки [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания Уровни требований», BCP 14, RFC 2119, март 1997 г. [RFC3463] Водрей, Г., «Коды состояния расширенной почтовой системы», RFC 3463, январь 2003 г. [RFC5248] Хансен, Т. и Дж. Кленсин, «Реестр для SMTP Enhanced Коды состояния почтовой системы», BCP 138, RFC 5248, июнь 2008 г. [RFC6376] Крокер Д., Хансен Т. и М. Кучерави, «DomainKeys Идентифицированные почтовые (DKIM) подписи", STD 76, RFC 6376, Сентябрь 2011. [RFC7001] Kucherawy, M., "Поле заголовка сообщения для указания Состояние аутентификации сообщения», RFC 7001, сентябрь 2013 г. [RFC7208] Киттерман, С., "Структура политики отправителей (SPF) для Разрешение на использование доменов в электронной почте, версия 1", RFC 7208, апрель 2014 г.
1X
Кучерави
Запрос комментариев: 7372 Сентябрь 2014 г.
Обновлений: 7208
Категория: Трек стандартов
ISSN: 2070-1721
Коды состояния аутентификации по электронной почте
Абстрактный
Этот документ регистрирует кодовые точки, чтобы разрешить коды состояния быть
возвращается почтовому клиенту, чтобы указать, что сообщение
отклонено или отложено именно из-за аутентификации по электронной почте
неудачи.
Этот документ обновляет RFC 7208, поскольку некоторые кодовые точки
зарегистрированные заменяют те, которые рекомендованы для использования в этом документе.
Статус этого меморандума
Это документ для отслеживания стандартов Интернета.
Этот документ является продуктом Инженерной группы Интернета.
(IETF). Он представляет собой консенсус сообщества IETF. Оно имеет
получил общественное мнение и был одобрен для публикации
Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 5741.
Информация о текущем статусе этого документа, любых опечатках,
и как предоставить отзыв о нем можно получить на
http://www.rfc-editor.org/info/rfc7372.
Уведомление об авторских правах
Copyright (c) 2014 IETF Trust и лица, указанные в качестве
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
внимательно, так как они описывают ваши права и ограничения в отношении
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить текст упрощенной лицензии BSD, как описано в Разделе 4.e
Доверительные юридические положения и предоставляются без гарантии, поскольку
описан в Упрощенной лицензии BSD.
Kucherawy Standards Track [Страница 1] 
Оглавление
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Ключевые слова. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Новые расширенные коды состояния. . . . . . . . . . . . . . . . . . 3
3.1. Коды ошибок DKIM. . . . . . . . . . . . . . . . . . . 3
3.2. Коды неисправности SPF. . . . . . . . . . . . . . . . . . . . 4
3.3. Обратный код ошибки DNS. . . . . . . . . . . . . . . . 5
3.4. Код множественных ошибок аутентификации. . . . . . . . . . 5
4. Общие соображения. . . . . . . . . . . . . . . . . . . 5
5. Вопросы безопасности. . . . . . . . . . . . . . . . . . . 6
6. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 6
7. Нормативные ссылки. . . . . . . . . . . . . . . . . . . . 7
Приложение А. Благодарности. . . . . . . . . . . . . . . . . . 8
1. Введение
[RFC3463] представил коды состояния расширенной почтовой системы, а [RFC5248]
создал для них реестр IANA.
[RFC6376] и [RFC7208] представили, соответственно, DomainKeys.
Идентифицированная почта (DKIM) и Sender Policy Framework (SPF), два
протоколы для проведения аутентификации сообщений. Еще один распространенный
приемочный тест электронной почты — это обратная проверка системы доменных имен (DNS)
на IP-адресе почтового клиента, как описано в Разделе 3
[RFC7001].
Текущий набор расширенных кодов состояния не включает код
для указания того, что сообщение отклонено или отложено из-за
причины местной политики, связанные с любым из этих механизмов. Это
потенциально полезная информация для агентов, которым нужно больше, чем
рудиментарная обработка информации о причине, по которой сообщение было
отклонено при получении. В этом документе представлены расширенные коды состояния
для сообщения об этих случаях клиентам.
Раздел 3.2 обновляет [RFC7208] по мере необходимости новых расширенных кодов состояния.
этой спецификации регистрируются и рекомендуются к использованию.
2. Ключевые слова
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
«СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
«НЕОБЯЗАТЕЛЬНО» в этом документе следует интерпретировать, как описано в
[RFC2119].
Kucherawy Standards Track [Страница 2] 
(Это нарушает
рекомендация Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
Код: X.7.21
Образец текста: Подходящая подпись DKIM не найдена
Связанный базовый код состояния: 550
Описание: этот код состояния возвращается, когда сообщение
содержит одну или несколько проходных DKIM-подписей,
но ни один не приемлем. (Это нарушает
рекомендация Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
Трек стандартов Kucherawy [Страница 3] 
Это особый
случай X.7.21. (Это нарушает совет
Раздела 6.1 RFC 6376.)
Ссылка: [RFC7372]; [RFC6376]
Автор: М. Кучерави
Контроллер изменений: IESG
3.2. Коды отказа SPF
Код: X.7.23
Образец текста: проверка SPF не удалась
Связанный базовый код состояния: 550
Описание: этот код состояния возвращается, когда сообщение
завершили проверку SPF, которая произвела
"неудачный" результат, противоречащий местной политике
требования. Используется вместо 5.7.1, т.к.
описано в Разделе 8.4 RFC 7208.
Ссылка: [RFC7372]; [RFC7208]
Автор: М. Кучерави
Контроллер изменений: IESG
Код: X.7.24
Образец текста: ошибка проверки SPF
Связанный основной код состояния: 451/550
Описание: Этот код состояния возвращается при оценке
SPF относительно пришедшего сообщения
привело к ошибке.
Используется вместо
4.4.3 или 5.5.2, как описано в разделах
8.6 и 8.7 RFC 7208.
Ссылка: [RFC7372]; [RFC7208]
Автор: М. Кучерави
Контроллер изменений: IESG
Трек стандартов Kucherawy [Страница 4] 
Конкретные механизмы, которые вышли из строя, не
указано.
Ссылка: [RFC7372]
Автор: М. Кучерави
Контроллер изменений: IESG
4. Общие соображения
По характеру простого протокола передачи почты (SMTP) только один
расширенный код состояния может быть возвращен для данного обмена между
клиент и сервер. Однако оператор может решить отложить или
отклонить сообщение по множеству причин. Клиенты, получающие эти
коды должны учитывать, что отказ, отраженный одним из этих
коды состояния могут не отражать единственную причину или наиболее важную
причина непринятия сообщения или команды.
Важно отметить, что раздел 6.1 [RFC6376] не рекомендует
специальная обработка сообщений без действительной подписи DKIM. Там
некоторые операторы игнорируют этот совет, некоторые из них поступают так
насколько требуется действующая подпись домена автора (т. е. одна
соответствие домену(ам) в поле заголовка From), чтобы принять
сообщение.
Более того, некоторые зарождающиеся технологии, основанные на SPF и
DKIM зависит от такой аутентификации. Эта работа не поддерживает
конфигурации, которые нарушают рекомендации DKIM, а скорее
признает, что они существуют, и просто стремится обеспечить
улучшенная совместимость с такими операторами.
Трек стандартов Kucherawy [Страница 5] 
Может случиться так, что один метод всегда будет неудачным; таким образом,
возврат конкретного кода этого метода не является информацией, полезной для
отправляющий агент.
Проверка обратного IP-DNS описана в разделе 3 [RFC7001].
Любые технологии проверки подлинности сообщений или применения политик
разрабатываемые в будущем должны также включать регистрацию собственных
расширенные коды состояния, так что этот вид конкретной отчетности
доступны операторам, которые хотят их использовать.
5. Вопросы безопасности
Использование этих кодов раскрывает локальную политику в отношении электронной почты.
аутентификации, которая может быть полезной информацией для субъектов, пытающихся
для доставки нежелательной почты. Следует отметить, что нет
конкретное обязательство использовать эти коды; если оператор не желает
раскрыть этот аспект локальной политики, он может продолжать использовать общий
код результата, такой как 5.7.7, 5.7.1 или даже 5.7.0.
6. Соображения IANA
Регистрация новых расширенных кодов состояния, для добавления к
Подреестр перечислимых кодов состояния расширенного состояния SMTP
Реестр кодов можно найти в Разделе 3.
Трек стандартов Kucherawy [Страница 6] 
