SMTP аутентификация [Руководство]

(последняя редакция: 2014-08-23 – страница существует с 2003)

Примечание: Эта информация будет обновляться, несмотря на предстоящий s/qmail релиз, который поддерживает проверку подлинности SMTP по умолчанию.

Введение

Запрос комментариев

Последствия  процедуры ESMTP

Система аутентификации

Аутентификация и безопасность транспортного уровня  (TLS)

Имена пользователей и области

Итоги и заключения

Поправки к Qmail

Патчи и программы

Установка qmail для SMTP аутентификации

Введение

SMTP аутентификация - это схема, которая была введена в 1999 году Дж. Майерсом из Netscape Communications и, наконец, выпущена как RFC 2554 ("Extension Service SMTP для проверки подлинности"). Отчасти основана на Расширениях SMTP, как определено в RFC 1869. Большинство современных реализаций SMTP поддерживает аутентификацию SMTP, в то время как Qmail 1.03  - нет (без патча). С другой стороны, существует много пользовательских почтовых агентов (MUAs) , включающих в себя клиента SMTP – с доступом к  SMTP аутентификации (например, Outlook, Eudora, Netscape, Mozilla, The Bat! ....).

SMTP аутентификация объявляется серверером аутентификации SMTP, требует клиента для проверки подлинности, в то время как, в конце концов, обе стороны должны взаимно принимать и поддерживать выбранную процедуру аутентификации. Первоначально изобретены в качестве протокола Host-to-Host, с SMTP аутентификацией, пользователь должен идентифицировать себя и после успешной аутентификации, предоставляется прием / передача его / ее писем.

RFC 2554 прямо не указывает, какие преимущества / плюсы пользователь SMTP аутентифицировал, за исключением выбора опционально " слоя безопасности " для последующих взаимодействий протокола. Тем не менее, в общем смысле, прошедшему проверку подлинности пользователю разрешена передача электронной почты не только к целевой системе (SMTP-сервер), а вообще везде. В Qmail терминологии, это эквивалентно 'relayclient'.

SMTP аутентификация взяла несколько идей от Simple Authentication и Security Layer (SASL), и не вписывается в схему SMTP, как будет описано далее в этом документе.

Запрос комментариев

Для того, чтобы понять SMTP аутентификацию, нужно работать через несколько RFC, которые, на первый вигляд не связаны. С другой стороны, самая последняя SMTP RFC 5321 и ее предшественница RFC 2821 (Джона Кленсина) теперь по крайней мере упоминает существование расширений SMTP и - по той же причине - требует команду 'EHLO', начинающую SMTP транзакцию. Даже после всех этих лет, это действительно будет время для более когерентных SMTP RFC; смотрите также комментарии Дэна Бернштейна о "Klensin RFC". (Е) SMTP не такой сложный протокол, и можно покрыть хотя бы основы в одном документе - удалив устаревшие команды, как VRFY и EXPN.

  • RFC 1869 определяет расширение протокола (ESMTP) для диалога SMTP, для того, чтобы указать расширенные возможности SMTP-сервером и / или передавать дополнительную информацию протокола SMTP, необходимую клиенту SMTP. Серверы SMTP, поддерживающие ESMTP, должны использовать ключевое слово 'EHLO' в SMTP приветствии.

Клиент SMTP может использовать только те расширения, которые предлагает сервер. По построению, сервер может послать предлагаемые расширения как ESMTP verb  куда угодно в диалоговом окне SMTP или как часть «MAIL FROM: '' или 'RCPT TO: ' команды.
Обычно используется 'MAIL FROM: <foobar@example.com> SIZE=1512'. В этом примере, 'SIZE' - это ключевое слово ESMTP, '1512' - это значение ESMTP и весь термин 'SIZE=1512' - параметр ESMTP (RFC 1870 "  Расширение службы SMTP для декларации размера сообщений ").

RFC 1869 реализует две различные схемы для продвижения значения ESMTP:

§  как ESMTP команда, использует"SIZE xxxxx",

§  где 'MAIL FROM: <foobar@example.com> SIZE=1512' команда, ключевое слово ESMTP соединены знаком равенства "=".

Каждое ключевое слово  ESMTP должно быть зарегистрировано в IANA.

  • В этой области, RFC 2554 описывает SMTP аутентификацию с определенным ключевым словом ESMTP 'AUTH'. 
    В текстовых отрывках и образцах RFC 2554, ESMTP Auth значит 'CRAM-MD5', 'DIGEST-MD5', и  упоминается 'PLAIN' (которые соответствуют определенным методам аутентификации или механизмам), но не предоставляется никакое посылание.
  • Тем не менее, хорошее объяснение SASL 'PLAIN' механизма предоставляется в RFC 4616. Здесь, в частности, вводятся термины authorization-id и authentication-id.
  • Попытка найти смысл указанных выше механизмов ESMTP AUTH в RFC 2222 "Простой уровень аутентификации и безопасности (SASL)" не удается. В этом RFC (также опубликовано Джоном Майерсом), изложен только общий механизм SASL и как зарегистрировать новое " имя механизма аутентификации". Тем не менее, определены механизмы SASL "KERBEROS_V4 ',' GSSAPI" и "SKEY".
  • Для успеха, нужно найти RFC 1731 "IMAP4 Механизмы аутентификации " и RFC 2195 "IMAP / POP авторизированное расширение для простого запроса/ ответа".
  • Здесь приведены некоторые практические образцы для проверки подлинности на основе протокола POP3 и IMAP4. Те RFC тоже созданы Джоном Майерсом. RFC 2060 "INTERNET MESSAGE ACCESS PROTOCOL - версия 4rev1" (Джон Майерс) рассказывает о команде IMAP4 'LOGIN' Очень жаль; это не имеет ничего общего с методом "AUTH LOGIN" в ESMTP.
  • То, что  актуальные ESMTP Auth значения де/кодированы, соответствует схеме BASE64, которая была впервые описана в RFC 1113  «Повышение конфиденциальности для Internet информации по электронной почте: Часть I - Шифрование сообщений и процедуры аутентификации"; хотя и не явно объявлено как BASE64 здесь (но позже применено это название).
  • RFC 2045 "Мультицелевые интернет почтовые расширения (MIME) Часть первая: Формат органов интернет-сообщений" дает одинаковую схему в BASE64 "алфавите" в разделе 6.8.
  • Если в дополнение используется механизм аутентификации ответа/запроса, нужно ознакомиться с так называемой HMAC процедурой с RFC 2104 "HMAC: Введённые хэширования для проверки подлинности сообщения" и в дополнение в соответствии с RFC 1321 с "MD5 сообщение -Digest Алгоритм "в качестве схемы де/шифрования.
  • До недавнего времени не было общего понимания, как можно перенести информацию аутентификации SMTP в заголовок электронной почты. С RFC 3848, однако, существует, по крайней мере минимальная схема, в том числе конкретной клавиши ESMTPA , в которую включены "Received:" строка заголовка в случае с пройденной проверку SMTP сессией.
  • Настроив MTA, таким образом, они будут принимать только SMTP заверенные сообщения на специальный порт -  изложено в RFC 4409  (и обновлено в RFC 6409), который определяет Mail SUBMISSION порт 587.
  • Совсем недавно, П. Семборский от Google и А. Мельников из ISODE (ничего себе, они все еще существуют) обновили SMTP AUTH RFC Майера: RFC 4945. По сути, там не так много новой информации в этом документе RFC по сравнению с RFC 2554, однако, перехватывает вместе с SMTP аутентификации Transport Layer Security (TLS), как определено в RFC 3207.

Последствия для процедуры ESMTP

В то время как SMTP аутентификация была введена исключительно как расширение сервиса, это на самом деле существенно касается протокола (Е) SMTP, который еще не полностью документирован /обсужден.

1. ESMTP аутентификация переводит SMTP от host-to-host  к протоколу user-to-hostВ результате, некоторые функции протокола, которые имеют смысл, пока два MTA общаются, должны быть уточнены или убраны, как расширение рассылки сайта (VRFY и EXPN).

2. Более тонкая, SMTP аутентификация (а также STARTTLS RFC 3207) переводит ESMTP из протокола ориентированного на транзакции протокола  и в протокол сессии и транзакции.

ESMTP статус сессии

В то время как в SMTP в основном хорошо определена только транзакция , теперь нам нужно позаботиться об ESMTP сессии:

§  A SMTP транзакция начинается от команды клиента MAIL FROM: и завершается с финалом клиента. <CRLF> команда как последняя линия LINE во время фазы DATA , признанная сервером с 250 ответным кодом.

§  ESMTP сессия начинается с команды EHLO, включает в себя STARTTLS и AUTH команды, а также любые SMTP транзакции и заканчивает с конечной QUIT командой сервера.

§  Таким образом, RFC 2821 требует от сервера ESMTP сохранить определенное статус сессии. Кроме того, статусы сессий упорядочены: статус STARTTLS  должен быть установлен перед обработкой статуса AUTH.

§  В отличие от этого, некоторые данные статусов сессий информация должны быть очищены от сервера, если клиент ESMTP выдает команду RST .

Текущий ESMTP  проект RFC 5321 Кленсина частично позаботился об этом. Очевидно, Кленсин не внимательно читал свой собственный RFC, потому что он смешивает в прилагаемом образце (взято почти неизменным с RFC 821) терминологию "транзакции" и "сессии" (Приложение D.1.).

Тем не менее, концептуальное изменение является более серьезным. Проблема здесь становится вирулентной в случае кода отклика ESMTP. Теперь ответ сервера принадлежат к транзакции, или всей сессии? Особой проблемой является код ошибки ESMTP 552:

552 Requested mail action aborted: exceeded storage allocation

552 Too much mail data (deprecated)

552 Требуемые почтовые действия прервались: превышено распределение памяти

552 Слишком много данных почты (не рекомендуется)

 

Очевидно, что первый случай mailbox  (и, следовательно, транзакция) конкретны, в то время как второй случай  - предел инструкций как обсуждается далее в документе RFC 5321:

4.5.3.1.10. Слишком много Кода получателей

RFC 821 [1] некорректно указано, где SMTP-сервер

исчерпывает свой предел для числа команд RCPT

("слишком много получателей"), имея кода отклика 552. Правильный ответ

кода для  для этого условия  - 452.

Очевидно, что текущая  схема (E) SMTP-команд, связанных с откликами, не говорит, принадлежит ли она к сессии или транзакции -  нужно больше уточнения. Давайте надеяться на RFC 10821.

Передача почты [RFC 4409]

В то время как стандартный SMTP порт 25 используется для неограниченного приема электронной почты, в частности DSL и кабельные провайдеры хотели бы установить свои MTAs для своих клиентов на другом порту и требует ESMTP аутентификацию. Согласно RFC 4409, передача почты по умолчанию - порт 587. MTA прослушивания этого порта будет требовать успешной аутентификации SMTP до принятия MAIL FROM: команды; в противном случае выдается сообщение об ошибке:

530 Authorization required (#5.7.1)

Помимо этого поведения, MTA список ESMTP на порт подачи требуется только для реализации (предложения) подмножества ESMTP-команд. Это эффективно отделяет задачи (Е) SMTP-сервера, чтобы принять

§   (E)SMTP transactions from unprivileged hosts -- or --

§  ESMTP sessions only from privileged users.

Аутентификация системы

Вроде бы ясно, что SMTP аутентификация зависит от разрозненных механизмов / способов / процедур, разбросанных в широком диапазоне RFC. Теперь, мы идем дальше и обсудить рамки аутентификации SMTP и понять, что все еще сложнее.

Сервер извещений

Мы взяли пример с RFC 2554. "S:" показывает SMTP сервер и "C:" SMTP клиент.

S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.

Вот, RFC 2554 использует несколько значений для ключевого слова AUTH как команду ESMTP, которая разрешена RFC 1869, однако нарушает разбор нескольких клиентских реализаций ESMTP. Одна работа вокруг, чтобы добавить искусственно "=" (знак равенства) между AUTH ключевым словом и значением, например AUTH=LOGIN.

AUTH механизмы

Есть три механизма аутентификации, широко используемых для аутентификации SMTP. В документации, идущей с qmail-smtp-auth-patch Кшиштофа Дабровски, предоставляется обзор ГНД и их AUTH механизмов (который я обновил):

 Клиент

Версия

Логин

Plain

CRAM-MD5

 Eudora

 4.x, 5.x, 6.x,7.x

 x

 

 x

 The Bat !

 1.39

 x

 

 x

 Thunderbird

 1.5

 x

 

 x

 Outlook Express

 4

 x

 

 

 Outlook Express

 5

 x

 

 

 Outlook

 2000

 x

 

 

 Netscape

 4.x

 x

 x

 

 Netscape

 4.0x

 x

 

 

 Pegasus Mail

 4.1x

 x

 

 x

 Mulberry

 4.x

 

 x

 x

SMTP Auth особенности серверных предыдущих ГНД

Примечание: Эта таблица уже историческая. Большинство ГНД сегодня (Mail.app от Apple, Opera почтовый клиент ...) поддерживают любой метод.

AUTH LOGIN

Наиболее распространенный 'AUTH LOGIN' механизм выглядит так

S: 220 esmtp.example.com ESMTP
C: ehlo client.example.com
S: 250-esmtp.example.com
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE 255555555
S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: auth login
S: 334 VXNlcm5hbWU6
C: avlsdkfj
S: 334 UGFzc3dvcmQ6
C: lkajsdfvlj
S: 535 authentication failed (#5.7.1)

Из всех предлагаемых механизмов проверки подлинности ESMTP, клиент выбирает 'auth login'. Затем ESMTP сервер выдает '334 VXNlcm5hbWU6' , где 'VXNlcm5hbWU6'  - это закодированная строка Base64 'Username:'. Клиент предоставляет закодированное Base64 имя пользователя и сервер отвечает с запросом 'Password:' ('334 UGFzc3dvcmQ6'). В приведенном выше примере, дается случайный ввод и сервер, наконец, отвергает запрос на аутентификацию.

Тем не менее, существует другая, RFC совместимая версия этого поведения, когда клиент изначально посылает идентификатор пользователя  userid  уже методом AUTH LOGIN :

C: AUTH LOGIN ZHVtbXk=
S: 334 UGFzc3dvcmQ6
C: Z2VoZWlt

AUTH PLAIN

Согласно документации IANA, PLAIN аутентификации определяется в RFC 2245 "Анонимный SASL механизм". Тем не менее, более полезное объяснение аутентификации PLAIN можно найти в RFC 2595 "Использование TLS с IMAP, POP3 и ACAP" (глава 6):

"Механизм состоит из одного сообщения от клиента к серверу. Клиент посылает авторизацию личности (идентично Войти как), после которой US-ASCII нулевой символ, и аутентификацию личности (личность, чей пароль будет использоваться) с последующим US-ASCII нулевым символом, а затем открытый текст пароля. Клиент может оставить авторизацию личности пустой, чтобы указать, что это то же самое, что и аутентификация личности."

Иными словами, правильная форма значения AUTH PLAIN – это - 'authorization-id\0authentication-id\0passwd' где '\0'  - это нулевой байт.

Некоторые ESMTP AUTH PLAIN реализации не полностью следуют этой процедуре. Мы видим, что в протоколе с помощью Netscape 4.8 MUA подключения к модифицированному Qmail 1.03 сделать PLAIN аутентификации:

C: ehlo client.example.com
S: 220-esmtp.example.com
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 ok, go ahead (#2.0.0)
C: RCPT TO:<....>

В этом примере, имя пользователя было "тест" и пароль 'testpass'. Здесь клиент Netscape немедленно передает информацию аутентификации на сервер (в том числе разрешения, удостоверяющего искусственную личность 'Test'), не дожидаясь, пока сервер объявить свои SMTP AUTH возможности.

Еще процедура возможна для клиентов, предоставивших  строку аутентификации после AUTH PLAIN:

C: AUTH PLAIN
S: 334
C: dGVzdAB0ZXN0AHRlc3RwYXNz

 

Authorization-ID и Authentication-ID

В указанных выше образцах, мы использовали термины идентификатор пользователя userid  и имя пользователя usermame  в качестве синонима (и пренебрегли кодировкой полностью).

Тем не менее, внутри AUTH PLAIN  идентификация клиента подразделяется на идентификатор авторизации authoriziation-id  и идентификатор аутентификации authentication-id , обычно идентификатор пользователя с последующим паролем. Строгого правила об использовании authorization-id нет. В частности, просто установка authorization-id=authentiation-id , конечно, действует, но в лучшем случае включает некоторую избыточность.

Для целей проверки подлинности SMTP, не ясно, что является целью authorization-id  и какую политику использовать для SMTP-сервера, несмотря на предоставленное (или потенциально отсутствует) здесь значение. Что касается клиента SMTP, может быть полезно authorization-id = <return-path. Тем не менее, некоторые SMTP-сервера используют ошибочно authorization-id для целей аутентификации и не применяют значение authentication-id. Таким образом, по соображениям совместимости и отсутствия стандартизации, представляется целесообразным использовать оба значения, заполненные с одинаковым содержанием userid.

AUTH CRAM-MD5

В то время как для AUTH PLAIN и LOGIN передаются четкие имена пользователя и пароль, дела идут значительно более безопасно с CRAM-MD5 механизмом аутентификации. Как уже упоминалось в его названии, CRAM-MD5 сочетает в себе механизм / ответ на запрос, чтобы обмениваться информацией и (криптографическим) Message Digest 5 алгоритмом для хэширования важной информации.

Я использую пример, основанный на публикации Маркуса Штумпфа в список рассылки Qmail.Типичный SMTP AUTH CRAM-MD5 диалог начинается вот так:

S: 220 popmail.space.net ESMTP
C: ehlo client.example.com
S: 250-popmail.space.net
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE 0
S: 250 AUTH CRAM-MD5
C: auth cram-md5
S: 334 PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+
C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

В отличие от AUTH LOGIN, ответ сервера – это единоразовый BASE64 закодированный  вызов. Вызов 'PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+' переводится на'<24609.1047914046@popmail.Space.Net>'. Ведущие и ведомые кронштейны ('<', '>') являются обязательными, также и часть вызова, которая обеспечивает хост после, '@'. '24609.1047914046' случайная строка, как правило, построена из 'pid' и CURRENT_TIMESTAMP, чтобы вызов был уникальным.

Ответ клиента включает в себя как username  так и digest. В то время как имя пользователя передается в виде открытого текста (но, конечно, в кодировке Base64), задача сервера используется клиентом для создания 'digest' от вызова и пароля (который обычно называют "секрет" или "общий секрет" в данном контексте), и гласит:

tim b913a602c7eda7a495b4e6e7334d3890

"Общий секрет" после username  с дополнительным пространством вычисляется с использованием следующего MD5 алгоритма хэширования:

digest = MD5(('secret' XOR opad), MD5(('secret' XOR ipad), challenge))

Если и SMTP-сервер и клиент "делят" тот же вызов и секрет, пользователь может быть успешно аутентифицирован с помощью передаваемых и Base 64, закодированных "Имя пользователя" и "digest".

Передача пароля (секрет) теперь заменяется digest. Несмотря на то, что digest рассчитывается с помощью вызова и секрета, что само по себе отправляется в открытом виде, это (в нашем текущем понимании) практически невозможно реконструировать секрет; за исключением атаки по словарю:

  1. Секрет очень эффективно скремблирован вызовов и
  2. мы используем лавинный эффект хэш-функции.

AUTH параметр как часть 'MAIL FROM:' команды

По RFC 2554, информацию об аутентификации может дополнительно предоставить в качестве параметра ESMTP AUTH с одним значением в "'MAIL FROM:' команде. Параметр ESMTP AUTH должен быть использован следующим образом:

C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK

Здесь значение AUTH должно быть закодирован внутри " xtext" как описано в RFC 1891 "служба расширения SMTP для уведомления о состоянии доставки". RFC 2554  рассматривает использование дополнительного параметра AUTH в 'MAIL FROM:'  команде в контексте «доверенной среды для общения аутентификации отдельных сообщений". Это на самом деле требует распространения информации AUTH к другому MTA (Агент передачи почты; например, по шлюзу электронной почты.) в качестве параметра AUTH при трансляции сообщения любому серверу, который поддерживает расширение AUTH. В случае, если проверка подлинности слабая, сервер должен установить 'AUTH=<>' в качестве параметра к 'MAIL FROM:' команде.

Я не в курсе, о том, что любая реализация MUA использует последнюю схему, однако, некоторые MTA (например. Postfix) поддерживают его.

Qmail 1.03, т в особенности qmail-smtpd не имеет никакого понимания каких-либо параметров в 'MAIL FROM:' команде; ему не хватает квалифицированной поддержки ESMTP в этом отношении. Это имеет место в дополнение для ESMTP SIZE '' объявления (RFC1870), который был частично восстановлен расширением Криса Харриса SIZE .
Мой текущий патч SMTP-аутентификации для qmail-smtpd вводит полный и расширяемый параметр 'MAIL FROM:' и обрабатывает предоставленный параметр AUTH как $TCPREMOTEINFO.

Статус аутентификации

Как указано, RFC 2554 позволяет два различных применения расширения ESMTP AUTH:

  1. AUTH обменный параметр, как части диалога SMTP (как показано выше).
  2. AUTH как ESMTP параметр в 'MAIL FROM:' комманде.

Очевидно, это оказывает существенное влияние на состояние самой аутентификации. Первый подход фактически эквивалентен с SMTP сессией аутентификации, в то время как вторая - эффективно аутентификация, предоставленного 'MAIL FROM:' отправителя и служит «информационными» данными. К сожалению, RFC 2554 не дает никаких намеков, что действительно означает статус «проверено". Существует общее мнение, что авторизованный пользователь имеет право для неограниченной ретрансляции.

В случае, когда идентификационная информация передается как расширение к  'MAIL FROM:'  команде, можно относить это эквивалентно с наличием дополнительного  'tcpremoteinfo'- как правило, полученного с помощью протокола 'ident'.

Когда аутентификация прервана

Клиент может отменить запрос на проверку подлинности, отправляя просто '*' на сервер. Сервер должен отклонить процедуру AUTH и ответить на ошибку протокола SMTP '501'. Тем не менее, сервер должен кэшировать метод аутентификации для того, чтобы сохранить статус.

Аутентификация кода возврата

Сервер может принять или отклонить запрос AUTH от клиента одним из следующих кодов в соответствии с RFC 4954:

Код

Значение

От
qmail-smtpd

Заслуга 
qmail-remote

235

Аутентификация пройдена

да

да

334

Текстовая часть, содержащая [BASE64] закодированную строку

да

да

432

необходим переход паролем

нет

>= 0.75

454

Временный сбой аутентификации

да

н/д

500

Линия обмена аутентификации слишком длинная

нет

н/д

501

Искаженный входной аутентиф. / Синтаксическая ошибка

да

н/д

503

AUTH команда не допускается в течение почтовой транзакции

да

н/д

504

Непризнанный тип аутентификации

да

н/д

530

Необходима аутентификация

режим передачи

н/д

534

Механизм аутентификации очень слабый

нет

нет

535

Учетные данные недействительны

да

да

538

Необходимо шифрование для запрошенного механизма аутентификации

нет

нет

SMTP аутентификация Reply-Codes и их реализация в моем qmail-authentication

После неудачного ESMTP запроса (начиная с кода 5x), сервер должен сбросить свой статус и клиент может либо предоставить правильную информацию, или может выбрать другой механизм аутентификации, или может войти с не аутентифицированным статусом.

Уведомления о нескольких аутентификациях

SMTP-сервер может предложить несколько типов аутентификации клиенту:

S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN

Как должен развернуться SMTP-сервер и зависит ли клиент от этой информации?

  • Сервер ESMTP может выдать клиенту упорядоченный список типов Auth.
  • Рассмотрим ситуацию, где вы торговец на рынке : Вы предлагаете своим клиентам яблоки, бананы и персики. Вы можете покомандовать с покупателем, что ему выбрать? Очевидно: нет.
  • Это исключительно обязанность заказчика, клиента ESMTP соответственно, выбрать тип идентификации, он может развернуть и предпочитает.
  • По аналогии, не имеет никакого смысла объявлять конкретный механизм идентификации (как сервер SMTP), а затем говорить клиенту: «Ах, нет, этот метод заключается слабый"

Короче говоря: клиент ESMTP выбирает механизм идентификации, подходящтй для него – соответствующий объявлениям сервера. Это обязательство SMTP-сервера для поддерживать объявленный метод идентификации и иметь соответствующие данные аутентификации в наличии.

Распространение аутентификации

В общем, SMTP аутентификация позволяет одноинтервальную MTA аутентификацию пользователя. Интересно обсудить распространение подлинности. Давайте сначала определим, о чем мы говорим:

Как правило, пользователь получает электронные письма с помощью POP3 или IMAP4 протоколов. Для отправки, полезным подходом заключается в том, что пользователь - электронной инициатор - устанавливает клиента электронной почты (то есть Outlook.) для проверки подлинности SMTP и впервые подключается к Основному-MTA. Здесь хранится идентификатор пользователя и пароль; которые, как правило, такие же, как те, что используются для учетной записи POP3 / IMAP4. В этом случае, Основной-MTA действует как SMTP- ретрансляция. Теперь у нас есть пользователь MTA аутентификации.

Может быть, необходимо подчинить Аутентификацию SMTP для получателя MTA или дополнительный внутренний SMTP-Gateway, который подключается к Интернету. Таким образом, мы говорим о User-to-Principal-MTA-to-MTA  трафике с требованием аутентифицированной цепи связи.

Для чего это может быть хорошо? Мы видели, что SMTP аутентификация служит в основном для обеспечения неограниченной ретрансляции. С End-to-End  аутентификацией Конец-в-конец,  можно достичь две дополнительные цели:

  1. Может быть гарантирована подлинность самого (содержание почты) сообщения,
  2. Может быть обеспечена уникальность и подлинность инициатора электронной почты (предоставленный Mail From: <Return-Path>).

Последнее требование важно для первой, так как оно позволяет отказаться от писем с поддельными / фальсифицированными "Return-Path" адресами.

Для того, чтобы сохранить цепочку аутентификации для MUA пользователя, не только идентификатор пользователя и пароль должны быть распространы, а кроме того, "Return-Path" адрес. В этом отношении, Mail From: <Return-Path> выступает в качестве информации авторизации.

Как ни странно, эта концепция уже вводилась для схемы аутентификации AUTH PLAIN (как описано выше), а затем была упрощена. К сожалению, на сегодня для Аутентификации SMTP, распространение подлинности не возможноа без изменения стандарта.
Сегодня мы видим огромную активность требования аутентификации в почтовом трафике, для того, чтобы снизить нагрузку на спам. Как указано, гарантированная аутентификация для электронных писем слишком слаба, чтобы уменьшить спам; Кроме того, должна быть включена квалифицированная информация авторизации.

Информация о подлинности в электронной почте "Received:" заголовок [RFC 3848]

Одна - на самом деле недостаточная - попытка в этом направлении – это добавить информацию аутентификации в заголовке электронной почты, который требуется RFC 3848.  Стандартные патчи аутентификации SMTP для qmail-smtpd  включают проверку подлинности пользователя, эквивалентную tcpremoteinfo  в  заголовке Received:

Received: from xdsl-81-173-228-159.netcologne.de (HELO mail.fehnet.net) (erwin@fehcom.net@81.173.228.159) 
by hamburg134 with SMTP; 23 Jan 2005 11:53:28 -0000

Хоть эта информация erwin@fehcom.net@81.173.228.159 довольно точная, но не хватает знаний о процессе. RFC 3848 требует другого обозначения, которое включено в мои последние патчи аутентификации SMTP для qmail:

Received: from xdsl-81-173-228-159.netcologne.de (HELO mail.fehnet.net) (erwin@fehcom.net@81.173.228.159) 
by hamburg134 with ESMTPA; 23 Jan 2005 13:32:13 -0000

Ключевое слово ESMTPA  обозначает "ESMTP аутентификацию" и, таким образом представленная информация может быть четко интерпретирована. Тем не менее, качество этой информации не может быть гарантировано, если она не происходит из последнего принимающего хоста.

Некоторые Anti-Spam программы, как SpamAssassin начинают использовать эту информацию, включая ее в расчет спам-веса сообщения. Как отметил Дари C. В. О'Ши (Комитет Apache SpamAssassin) " Целевое расширение границы", которое имеет дело с интерпретацией в заголовке электронной почты, работает  сверху вниз, для того, чтобы проверить целостность представленной информации.

Так как любой из заголовков сообщений электронной почты может быть легко подделан, дополнительные проверки для каждого соединения SMTP должны быть облегчены, чтобы свести к минимуму любую потенциальную подделку. Таким образом, основная проблема остается, чтобы получить доверенную информацию из не-доверенной среды.

Аутентификация и протокол Transport Layer Security [RFC 4954]

RFC 4945 очень строгий об использовании незащищенной идентификатора пользователей / пароля в диалоговом окне SMTP Auth:

Если реализация поддерживает механизмы SASL, которые подвержены пассивным подслушивающим атакам (например, [PLAIN]), то реализация должна поддерживать по крайней мере одну конфигурацию, где эти механизмы SASL не рекламируются или используются без наличия внешнего слоя безопасности, такого как [TLS].

По существу, это ТРЕБУЕТ от любого клиента и сервера ESMTP:

  • Поддерживать по крайней мере CRAM-MD5, DIGEST-MD5, или любой другой C/R способ аутентификации через незашифрованные линии.

§  Разрешить AUTH PLAIN и/или AUTH LOGIN только совместно с SMTPS/STARTTLS.

Далее:

Если SMTP-клиент готов использовать SASL PLAIN через TLS для проверки подлинности на SMTP-сервер, клиент проверяет сертификат сервера в соответствии с правилами [X509]. Если сервер не предоставил сертификат, или если проверка сертификата не удается, клиент НЕ ДОЛЖЕН пытаться аутентифицироваться с использованием механизма SASL PLAIN.

После успешных [TLS] переговоров, клиент должен проверить свое понимание сервера хоста против подлинности сервера, как представлено в сообщении сертификата сервера, для того, чтобы предотвратить человек-в-середине атаки. Если не удается, клиент НЕ ДОЛЖЕН пытаться аутентифицироваться  с использованием механизма SASL PLAIN. Соответствие осуществляется в соответствии со следующими правилами:

  • Клиент должен использовать имя прокси-сервера, как раньше, чтобы открыть соединение в качестве значения для сравнения с именем сервера, как и любой форме сервера хоста, полученной из незащищенного удаленного источника (например, небезопасный поиск DNS). CNAME канонизация не выполняется.
  • Если присутствует расширение AltName типа dNSName в сертификате,  оно должно использоваться в качестве источника идентичности сервера.

Смотрите RFC 4945: 14. Дополнительные требования при использовании SASL PLAIN через TLS

На самом деле, я не имею ни малейшего понятия, почему это очень строгая рекомендация (которая требует проверки подлинности сервера с помощью DNS) является составной частью настоящего стандарта и не выражается / ссылается на  другое место.

Как ни странно, RFC не удается четко определить, что является "именем хоста" сервера и, как определить этот "безопасный удаленный источник» (никогда не слышали об MX записях?).

Имена пользователей и области действия

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

§   POP3 сервера, в дополнение к

§   IMAP4 серверу, также через

§  Интерфейс Webmail.

Возможно, почтовый ящик является частью виртуального домена в ведении Intersevens Vpopmail или vmailmgr Брюса Гюнтера . Помимо qmail-pop3d POP3 сервера Дэна Бернштейна, как правило, либо Binc или Dovecot используется для доступа IMAP4.

Все эти продукты имеют разное понимание, где хранить имена пользователей / пароли и как их использовать, как мы увидим.

Имена пользователей

Если мы говорим о «имени пользователя» для аутентификации SMTP, мы, как правило, имеем в виду типичного пользователя как «Алиса» или «Боб». По RFC 821 «местная часть» адреса электронной почты - это имя RFC821Mailbox , как это предусмотрено в стандартной схеме LDAP.

Для электронной почты 'alice@example.com' просто локальная часть "Алиса" является именем пользователя, используемое для аутентификации.

С точки зрения безопасности это очень опасно, когда:

  1. Адреса электронной почты являются открытыми. Если локальная часть адреса электронной почты используется в качестве информации аутентификации, это можно рассматривать как существенная утечка данных.
  2. Для целей аутентификации, кроме 'имени пользователя' и 'Пароля', мы могли бы проверить также предоставленный адрес электронной почты, что повышает энтропию идентификации строки; смотрите, например, 'Auth PLAIN'.

Кроме того, "имя пользователя" может быть сложным. Вместо простого имени, могут быть использованы пробелы и другие символы, в зависимости от реализации. Мои последние SMTP патчи для аутентификации Qmail позволяют имена с пробелами, как "Угадай, кто.

Области действия

В то время как локальная часть адреса электронной почты соответствует  "почтовому ящику", часть домена часто считается областью влияния (эта формулировка взята из протокола RADIUS ).

В общем, для домена 'example.com' пользователь 'Bob' может существовать. Для другого домена "foo.bar" то же самое имя пользователя может быть приемлемым. Аутентификация работает, если мы обеспечим в дополнение  "область действия", как различать информацию. В этом случае пользователь не обеспечивает его «область действия», а войдя в систему, сервер должен искусственно добавить свои известные " области действия " (=домены), как намек для того, чтобы позволить успешную аутентификацию.

База данных пользователей

Существует очень мало общего понимания, куда поместить базу данных пользователя для проверки подлинности SMTP и как ее построить.

  • SMTP аутентификация не устанавливает ограничения на имя пользователя или на пароль.
  • Для того чтобы разобрать Unix /etc/passwd  или теневой файл паролей, у него должен быть корень. Реализация Дэна Бернштейна qmail-pop3d с этим справляется. Дополнительная программа qmail-popup (под управлением корня) выполняет checkpassword, который - с успешно проверкой подлинности пользователя - вызывает qmail-pop3d.
  • Другое внедрение базы данных пользователей SASL в  - /etc . в flat файл. Кшиштофа Домбровского cmd5checkpw  , который даже не предусматривает никакого механизма безопасности для защиты его содержания (имя пользователя / пароль), за исключением основных средств Unix инструментов.
  • В многопользовательской среде домена может быть необходимо включить имя домена в имя пользователя SMTP Auth; но не все MUAs поддерживают его. Как правило, имя пользователя аутентификации SMTP обеспечивается MUA к SMTP-серверу без суффикса домена.
  •  Qmail позволяет создать базу данных для быстрого поиска с помощью qmail-users механизма. Там нет понимания, как улучшить этот механизм, чтобы позволить SMTP аутентификации определяться пользователями.

Помимо этих деталей, база данных пользователей SMTP Auth  может быть "местной" базой данных (Oracle, MySQL, Postgres) или может быть "дистанционно" доступна с помощью LDAP поиска через "централизованную" базу данных.

Тем не менее, основной задачей является обеспечить единую базу данных пользователь /пароль для электронной почты:

·         Должно ли Имя пользователя для аутентификации SMTP совпадать с учетной записью электронной почты (то есть, имя почтового ящика)?

·         Что насчет возможного суффикса домена (Vpopmail vpasswd  требует этого)?

·         Должна ли аутентификация SMTP "секрет" быть такой же, как POP3 / IMAP4 пароль?

·          Как бороться с обстоятельствами, в которых сервер SMTP отличается от хоста wrt. POP3 / IMAP4 сервера?

Формат сохраненного пароля

Есть несколько способов использования пароля для аутентификации.

  • Самый простой способ просто передать пароль для целей аутентификации. Конечно, это самый опасный способ и только полезный по зашифрованным каналам, как TLS соединения.
  • Для того чтобы справиться с этим, вместо пароля используется checksum. Например, хэш, вычисленный как MD5 или SHA-1, хранится в этом формате в базе данных и используется для проверки подлинности вместо самого пароля. Несмотря на доступных таблиц радуги, в частности, общий MD5 хеш не является надежным выбором для защиты пароля.
  • Таким образом, используется алгоритм CRAM-MD5, который обеспечивает скремблированное и с вызовом одноразовое хэш-значение информации аутентификации в качестве хэш-суммы.

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

Резюме и Заключение

Влияние на ESMTP протокол

Подводим итоги:

  • По конструкции, RFC 2554 не соответствует RFC 821,
  • При изменении (E)SMTP от транзакции к сессии ориентированного протокола,
  •  не позволяет распространение  аутентификации,
  •  использует две противоречивые схемы аутентификации SMTP и не определяет, что значит Аутентификация SMTP (для сервера и для клиента)
  •  использует несколько ESMTP AUTH объявлений значений при использовании как глагола ESMTP,
  • с двумя различными презентациями, в зависимости от того, предлагалось как SMTP глагол или как расширение к "MAIL FROM:" команде (с и без обязательной "=" между ключевым ESMTP и значением);
  • включает в себя два различных метода, как раз/зашифрованного значения ESMTP для AUTH (7 бит ASCII против "xtext").

Чем хороша ESMTP аутентификация?

Основной причиной является позволить неограниченную ретрансляцию сообщений электронной почты для определенных пользователей.

SMTP аутентификация является административным инструментом для менеджера электронной почты, чтобы контролировать поведение его / ее MTA (Message Transfer Agent).

Таким образом, SMTP аутентификация дополняет / заменяет другие административные средства, позволяющие контролируемое использование системы электронной почты. Другие средства, например:

§  Основаны на отправителе: Realtime Blocking List (RBL) к примеру доступен с rblsmtpd Дена Бернштейна.

§  Основаны на пользователе/ отправителе: Расширение реле контроля Брюса Гюнтера для Qmail (POP-before-SMTP).

§  Основаны на сообщении: Tagged Message Digest Agent (TMDA).

§  Основаны на получателе: Белые списки получателей (eg. Мое расширение для ПОЛУЧАТЕЛЕЙ для Qmail).

Большинство из этих инструментов, основанных на знании IP / FQDN доменного имени peer хоста, или - как мой SPAMCONTROL патч - использовать чеки на информацию SMTP-конверта. Главным образом, проверки на конверте IP/FQDN/SMTP имеют приоритет над Аутентификацией SMTP.

Таким образом, SMTP аутентификация является дополнительным подходом, основанным на идентификации / аутентификации пользователя и особенно хорошо подходит для поддержки мобильных пользователей.

Обеспечение отправки почты, безусловно, хорошо подходит для интернет-провайдеров, чтобы управлять электронной почтой через их системы, хотя это значительно нарушает принципы нейтралитета сетевого трафика, поскольку он, как правило, будет препятствовать работе собственного SMTP-сервера, работающего на порту 25.

Реализации для Qmail

Существуют два основных понятия реализации, которые будут использоваться в сочетании с проверкой подлинности SMTP:

1.      ВнутренняяБиблиотека Cyrus SASL

2.      ВнешняяПодключаемые модули аутентификации (PAM)

Использование аутентификации Cyrus SASL делается на базе данных SASL 'sasldb'. Записи (т.е.. Пользовательская база) там модифицированы с помощью команды 'saslpasswd'. Библиотека Cyrus SASL поддерживает различные методы аутентификации, как LOGIN, CRAM-MD5 и др. В частности, на PAM можно ссылаться как на внешний метод аутентификации.

Подключаемые модули аутентификации (которые на самом деле никогда не считались RFC) являются более общей основой, где поиск пользователя осуществляется через произвольный внешний модуль - РАМ. Основная идея в том, чтобы передавать информацию аутентификации от сети (т.е.. Через qmail-smtpd) к PAM. РАМ проверяет достоверность информации аутентификации от своего имени и и выходит либо с кодом возврата "0" в случае успешной аутентификации или с '1' (или ненулевое значение еще), если аутентификация не удалась по какой-то причине.
Конечно, структура информации аутентификации должна быть взаимно согласована. В общем, у нас есть информация аутентификации типа 'login'  и типа 'challenge/response' (C/R). В случае SMTP аутентификации, то ESMTP AUTH ключевые слова, о которых сервер оповещает, и способность РАМ должны совпадать.

Checkpassword Интерфейс

В обобщении метода аутентификации PLAIN, Дэн Бернштейн определил checkpassword интерфейс, который будет использоваться, в частности, для комбинации qmail-pop3и вспомогательного PAM checkpassword.

"checkpassword обеспечивает простой, простой интерфейс для проверки пароля всех корневых приложений. Он подходит для использования в таких приложениях, как login, FT ftpd и pop3".

"checkpassword читает дескриптор 3 и концу файла и затем закрывает дескриптор 3. Там должно быть не более 512 байт данных до конца файла. Информация поставляемая на дескриптор 3 представляет собой имя login, заканчивающееся на\ 0, пароль заканчивающийся на \ 0, а timestamp заканчивающийся на \ 0, и, возможно, больше данных. Там нет других ограничений на формы логин имени, пароля и метки времени. Если пароль является недопустимым, checkpassword выходит 1. Если checkpassword злоупотребляют, он может выдать 2. Если есть временная проблема проверки пароля, checkpassword выводит 111. "

Преимущество интерфейса checkpassword  - это просто быть применимым для большинства методов аутентификации, как CRAM-MD5 и, например, механизм POP3 APOP. В случае CRAM-MD5, то строка checkpassword:

userid\0digest\0challenge\0

Хотя программа Бернштейна checkpassword  подходит только для локального поиска пользователя (с помощью /etc/passwd  или тень PASSWD) и, следовательно, требует для работы корень, его определение интерфейса широко используется, например, в Vpopmail vchkpwd.

Следует отметить, что checkpassword  вызывает другую (дочернюю-) программу, обычно qmail-pop3d. Для аутентификации SMTP это становится устаревшим, однако дочерняя программа должна быть; В противном случае проверка пользователь не будет осуществлена. Общий выбор  - это программа true  (в качестве /bin/true or /usr/bin/true), которая выходит всегда как '0'.

qmail-smtpd

По данным сайта Рассела Нельсона www.qmail.org, есть несколько патчей аутентификации SMTP, доступных для qmail-smtpd:

  • "Mrs. Brisby's" реализация может рассматриваться как отправная точка для этого развития (и поддерживает PLAIN и LOGIN),
  • сейчас в основном заменены патчем Кшиштофом Дабровски (и Эрика Джонсона) qmail-smtpd-auth-0.31  включить поддержку CRAM-MD5 с дополнительным cmd5checkpw PAM. К сожалению, хотя широко распространенный, SMTP-AUTH патч Кшиштофа Домбровского ломает интерфейс checkpassword  для CRAM-MD5. Вместо передачи последовательности
'userid\0password\0challenge\0' он использует

'userid\0challenge\0password\0'.

Еще одним препятствием является закрыть (например, 'qmail-popup') излишний файл дескриптора 2 (FD 2). Это тормозит общую регистрацию на STDERR. Кроме того, безосновательное закрытие FD 3 (предоставить информацию о AUTH к PAM) конфликтует с чтением

control/morercpthosts.cdb. Кроме того, есть некоторые проблемы декодирования BASE64.

qmail-remote

Выбор решает, когда дело касается Аутентификации SMTP для qmail-remote:

  • Первый патч создан Джейем  Соффианом  и был окончательно затронут Робертом Сандерсом.
  • Бьорн Калькбреннер (URL-адрес, упоминаюшийся на qmail.org более не существует) сделал значительные изменения (в частности, добавил преобразование BASE64 для указанного имени пользователя и пароля) в его версии qmail-smtp-auth-send-0.0.1.tar.gz. Обе версии используют параметр ESMTP AUTH, как часть 'MAIL FROM:'команды; как уже было сказано выше; хотя и с неправильным синтаксисом и адресом электронной почты вместо имени пользователя. Опять же, нет ясного понимания, что такое «статус аутентификации" и как склеить SMTP аутентификацию с (письмами, полученными) qmail-smtpd  и (отправленными) qmail-remote. Понятие введено в RFC 2554 может быть полезным для монолитных SMTP реализаций, как sendmail, но очень трудно поддерживать в тех случаях, когда участвуют несколько задач / пользователей.

Qmail патч аутентификации

Это очень неудовлетворительная ситуация для Qmail может быть устранена, используя свой комбинированный патч Qmail Authentication patch (0.8.0).

Основываясь на общем кодировании, Аутентификация, Qmail предоставляет следующие возможности:

  • qmail-smtpd: Объявление AUTH с поддерживаемыми типами PLAIN, LOGIN, и CRAM-MD5, требующих checkpassword  совместимый PAM.
  • Гибкая схема для объявления, поддержки и соблюдения подлинности ESMTP определенного типа; в том числе функции ОТПРАВКИ. 
  • qmail-remote: Основанные на отправителе типы CRAM-MD5, PLAIN и LOGIN, используя улучшенную smtproutes  и совместимую authsenders  базу данных пользователей, для того, чтобы ретранслировать SMTP.
  • Mail From: <return-path> AUTH=user анализатор / генератор поддержки xtext" представление пользователя.
  • Аутентифицированное имя пользователя входит в заголовок "Отправлено:".

Объединив аутентификации для qmail-smtpd  и qmail-remote, удаленная информация пользователя может быть сохранена в некоторой степени, если Qmail действует как реле.

Патчи и программы

qmail-authentication-0.8.3  - Общая аутентификация SMTP для qmail-smtpd и qmail-remote. Соответствует RFC 3848 и RFC 4409 (MD5: ffa18b9c5398c7a6e1658b5ba762a218).

  • Обеспечивает теперь аутентификацию CRAM-MD5 для qmail-remote.
  • Тонкая настройка SMTPAUTH объявлений для qmail-smtpd  и поддержки ОТПРАВКИ.
  • Основанная на отправителе аутентификация согласно'Mail From:' и аутентифицированный smarthost  ретрансляции для qmail-remote.
  • Исправлена ошибка (0.8.2): qmail-smtpd тайно позволяет auth даже при отключении  (tx Chris P.)
  •  Исправлена AMD64 ошибка для  MD5 (0.8.3) и несколько небольших (tx Alan P.)

qmail-smtpd-auth-0.5.10 Включает общий  'MAIL FROM:' Параметр парсер поддержку 'AUTH' и 'SIZE' рекламу ; Соответствует RFC 3848 и RFC 4409 (MD5: 8df16e5724dbd1fa9d371c7fbd167e7d).

  • Позволяет «комплексные» имена пользователей для CRAM-MD5.

qmail-smtpd-auth-0.4.3 – Обновлена и исправлена ошибка в версии Криштофа Дабровски SMTP-Auth патче (MD5:f2653126515ca3ae26ff7d016a70663b).

cmd5checkpw-0.30 – адаптированная версия Криштофа Дабровски cmd5checkpw; пользовательская база находится в /var/qmail/users/authuser.

vchkpw.c.diff – через Vpopmail's 5.3.27 vchkpw соответствует интерфейсу checkpassword  для C / R запросов.

Base64-1.3 - Base 64 конвертер для Unix (взято у  Джона Волкера).

SPAMCONTROL - позволяет дополнительно регистрацию qmail-smtpd  сессий и соответствующих параметров SMTP-авторизаций.

Дополнение

Inter7 внедрил вышеупомянутый патч vchkpw в текущую Vpopmail 5.4.x.

Большинство нынешних «больших» qmail патчей (например, Билла Шаппа в "Qmail toaster") включают мой патч аутентификации SMTP, но не netqmail.

Установка qmail-smtpd для SMTP аутентификации

Во-первых, патч Qmail 1.03 (или netqmail-1.0.6) с одним из патчей Auth, как указано выше.

Во-вторых, вам нужен PAM, чтобы позволить  аутентификацию для определенной базы данных. Для небольших сред, cmd5checkpw-0.30 будет полезным выбором, однако для больших сайтов один из следующих PAM более полезный.

checkpassword:

Без изменения фактического пользователя qmail-smtpd, как правило, работает как, CHMOD в checkpassword будет предоставлять доступ к паролям пользователя системы:

# ls -al /bin/checkpassword
-rwx------ 1 root wheel 7676 Sep 12 13:07 /bin/checkpassword
chmod u+s /bin/checkpassword
chmod go+x /bin/checkpassword
# ls -al /bin/checkpassword
-rws--x--x 1 root wheel 7676 Sep 12 13:07 /bin/checkpassword

Для того, чтобы уменьшить риски безопасности, это может быть необходимо повысить  qmail-smtpd эффективные групповые права на wheel или root и, с другой стороны, ограничить права выполнения для checkpassword  к этой группе.

checkvpw:

vmailmgr Брюса Гюнтера предоставляет checkvpw утилиту, которая может быть использована в качестве PAM для SMTP аутентификации. Здесь, виртуальные домены всегда находятся под контролем соответствующего пользователя и базы данных пользователей децентрализованы.

Для того, чтобы checkvpw  работал с qmail-smtpd, должны быть выполнены следующие шаги:

  • checkvpw - который принадлежит к корню - должен быть липким:
    -rwsr-sr-x 1 root root 58408 Feb 8 2001 /usr/bin/checkvpw
  • checkvpw требует дополнительный аргумент, чтобы справиться с пропавшей Maildir средой, как правило, maildir.
  • Для успешной аутентификации, информация о домене должна быть добавлена к Userid  и построена как адрес электронной почты  (userid@virtualdomain.com).
  • checkvpw не поддерживает CRAM-MD5 аутентификацию.

vchkpw:

Inter7's Vopmail предоставляет vckpw как PAM, которая позволяет аутентификацию через центральную базу данных.

В-третьих, вы должны установить qmail-smtpd , чтобы принимать проверку подлинности SMTP.

В настоящее время патч qmail-authentication позволяет использовать переменную среды SMTPAUTH для qmail-smtpd  следующим образом:

SMTPAUTH

Значение

""

Слева пустым, чтобы позволить типы аутентификации "PLAIN" и "LOGIN"

"+cram"

Добавить "CRAM-MD5" поддержку

"cram"

Простая (безопасная) поддержка "CRAM-MD5", никаких других типов не предложено

"!"

Осуществление SMTP Auth (типа "LOGIN" или "PLAIN")

"!cram"

Осуществление SMTP Auth типа "CRAM-MD5"

"!+cram"

Осуществление SMTP Auth типа "LOGIN", "PLAIN", или "CRAM-MD5"

"-"

Отключение SMTP Auth (для конкретного соединения)

SMTPAUTH настройки для qmail-smtpd

Примечание: Привязка qmail-smtpd  на порт 587  с SMTPAUTH='!...' просто позволяет отправку!

Вот мой qmail-smtpd  файл запуска, который позволяет аутентификацию SMTP для пользователей системы; хотя и без возможности CRAM-MD5.

  #!/bin/sh

  QMAILDUID=`id -u qmaild`

  QMAILDGID=`id -g qmaild`

  HOSTNAME=`hostname`

  export SMTPAUTH=''

  MAXCONCURRENCY=`cat /var/qmail/control/concurrencyincoming`

  exec tcpserver -vR -l $HOSTNAME -c $MAXCONCURRENCY \

       -u $QMAILDUID -g $QMAILDGID 0 smtp \

       /var/qmail/bin/qmail-smtpd /bin/checkpassword true 2>&1

 

Еще примеры показывают, как настроить файл выполнения с checkvpw Брюса Гюнтера:

  #!/bin/sh

  QMAILDUID=`id -u qmaild`

  QMAILDGID=`id -g qmaild`

  HOSTNAME=`hostname`

  export SMTPAUTH=''

  MAXCONCURRENCY=`cat /var/qmail/control/concurrencyincoming`

  exec tcpserver -vR -l $HOSTNAME -c $MAXCONCURRENCY \

       -u $QMAILDUID -g $QMAILDGID 0 smtp \

       /var/qmail/bin/qmail-smtpd /usr/bin/checkvpw true maildir 2>&1

 

Настройка qmail-remote для проверки подлинности SMTP

Есть два прецедента, как позволить qmail-remote поддерживать аутентификацию SMTP:

  1. Локальный пользователь в системе с использованием проверки подлинности:
    Поскольку не существует пользовательского интерфейса, чтобы указать userid  и uid  , и больше не доступен для qmail-remote  информация аутентификации должна быть связана с отправляющим адресом: 'Mail From: '. 
    Связывание '<Return-Path> с идентификатором аутентификации способствует control/authsenders.
  2. qmail-remote выступает в качестве реле и удаленный хост требует проверки подлинности: 
    Теперь аутентификация зависит от назначения и квалифицированный userid  и информация о пароле может быть добавлена к настройкам реле в control/smtproutes.

Внутри qmail-remote Я использую общий схему адресации, поддерживающую «комплексные» имена:

control/authsenders:
eschmidt@google.com:gmail-smtp-in.l.google.com:587|E. Schmidt|topsecretcontrol/smtproutes:
gmail.com:gmail-smtp-in.l.google.com|myaccount|mypasswd

Следует отметить, что authsenders имеют приоритет над smptroutes.

Тестирование

Как уже обсуждалось, успешная аутентификация SMTP зависит от гладкого взаимодействия трех сторон:

§  Mail User Agent (MUA) как SMTP Auth клиент и его возможности ,

§  SMTP Auth сервер для объявления настройки механизмов Auth и для сотрудничества с

§  PAM, который читает базу данных пользователей и удостоверяет пользователя.

Помимо настройки ошибок, в случае возникновения проблем необходимо определить выбранный механизм идентификации (как обсуждалось ранее) и проследить (E) SMTP сессии. recordio  Дэна Бернштейна (часть его UCSPI) может быть использована в сочетании с модифицированным run  скриптом, например, для qmail-smtpd:

  #!/bin/sh

  QMAILDUID=`id -u vpopmail`

  QMAILDGID=`id -g vpopmail`

  HOSTNAME=`hostname`

  export SMTPAUTH=''

  MAXCONCURRENCY=`cat /var/qmail/control/concurrencyincoming`

  exec tcpserver -vR -l $HOSTNAME -c $MAXCONCURRENCY \

       -u $QMAILDUID -g $QMAILDGID 0 smtp \

       /usr/local/bin/recordio sh -c '/var/qmail/bin/qmail-smtpd \

       /home/vpopmail/bin/vchkpw true 2>&1'

 

Для целей тестирования, это run  скрипт должен вызываться на переднем плане и отслеживание на TTY появляется, когда клиент SMTP подключается к серверу. Образец выше, может быть использован для отслеживания аутентификации SMTP против Vpopmail vchkpw.

Раз/шифрование BASE64:

Для того, чтобы декодировать строки BASE64, можно использовать конвертер base64 . Важно понимать, что для правильного декодирования должен быть включен задний "\0". Давайте предположим, что имя пользователя является "тест" и пароль "testpass". Для того, чтобы проверить раз/шифрование , следует действовать следующим образом:

bash-2.05b$ printf "test" | base64 -e
dGVzdA==
bash-2.05b$ printf "testpass" | base64 -e
dGVzdHBhc3M=
bash-2.05b$ printf "\0test\0testpass" | base64 -e
AHRlc3QAdGVzdHBhc3M=

Таким образом, имя пользователя " test " переводится как "dGVzdA==" и соответствующий пароль "testpass" становится "dGVzdHBhc3M=".
Для AUTH Plain, ведущий "\0" (если не предоставляется Authorize-ID ) должен быть включен, и вся строка кодирует как as "AAllc3QACWVzdHBhc3M=". Знак равенства ("=") является выравниванием характера. Во время диалога SMTP AUTH, эти строки могут быть поставлены из командной строки.

Примечание: Важно использовать printf  от bash, таким образом, никакие символы CR/LF не добавляются, что произойдет с использованием echo  вместо printf.

Работа с CRAM-MD5 вызовами /дайджестами:

При разработке поддержки CRAM-MD5 для qmail-remote, я нашел PERL скрипта PaulMakepeace к генерации HMAC дайджест очень полезный (он писал, что инструмент для Exim). Вы можете скачать немного модифицированную версию hmac_md5.pl  отсюда и вам нужно установить модуль PERL DIGEST-HMAC-1.02 с CPAN.

Благодарности:
Майкл Хольцт  указал мне на разные процедуры аутентификации для AUTH LOGIN и AUTH PLAIN. 
Исправлена ошибка, и некоторые конструктивные критики относительно нескольких объявлений Auth  были подняты Каллумом Гибсоном.

Перевод выполнен с оригинала