8. Литература
| [ABNF] | Crocker, D. и P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, Ноябрь 1997. |
| [CRAM-MD5] | Klensin, J., Catoe, R. и P. Krumviede, «IMAP/POP AUTHorize Extension for Simple Challenge/Response», RFC 2195, Сентябрь 1997. |
| [ESMTP] | Klensin, J., Freed, N., Rose, M., Stefferud, E. и D. Crocker, «SMTP Service Extensions», RFC 1869, Ноябрь 1995. |
| [ESMTP-DSN] | Moore, K, «SMTP Service Extension for Delivery Status Notifications», RFC 1891, Январь 1996. |
| [KEYWORDS] | Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, Март 1997. |
| [SASL] | Myers, J., «Simple Authentication and Security Layer (SASL)», RFC 2222, October 1997. |
| [SUBMIT] | Gellens, R. и J. Klensin, «Message Submission», RFC 2476, Декабрь 1998. |
| [RFC821] | Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821, Август 1982. |
| [RFC822] | Crocker, D., «Standard for the Format of ARPA Internet Text Messages», STD 11, RFC 822, Август 1982. |
9. Вопросы безопасности
В этом документе затрагиваются вопросы безопасности.
Если клиент использует это расширение для создания шифрованного туннеля через открытую сеть до корпоративного сервера требуется обеспечить такую настройку клиента, чтобы почта никогда не передавалась на этот сервер без соответствующей аутентификации и шифрования. В противном случае атакующий сможет красть клиентскую почту путем захвата соединений SMTP и ложной индикации отсутствия на сервере поддержки данного расширения или генерации ложных отказов от выполнения команд AUTH.
До начала согласования SASL все протокольные транзакции выполняются в открытом виде и могут быть изменены в результате активной атаки. По этой причине клиенты и серверы должны отбрасывать любые сведения, полученные до начала согласования SASL после того, как будет завершено SASL-согласование, приводящее к использованию защищенного уровня.
Этот механизм не защищает порт TCP, поэтому при активной атаке возможно перенаправить попытки соединения с портом транслятора в порт подачи сообщений [SUBMIT]. Параметр AUTH=<> предотвращает для таких атак возможность заставить транслируемое сообщение без аутентификации конверта «подбирать» аутентификацию клиента транслятора.
Клиент подачи сообщений может требовать от пользователя аутентификации всякий раз, когда анонсируется подходящий механизм SASL. Следовательно, для сервера подачи сообщений [SUBMIT] может оказаться нежелательным анонсирование механизма SASL в тех случаях, когда использование этого механизма не дает клиенту преимуществ по сравнению с анонимной подачей сообщений.
Это расширение не предназначено для замены сквозных систем поддержки цифровых подписей или шифрования типа S/MIME или PGP. Данное расширение предназначено для решения иных задач и ниже перечислены основные отличия от сквозных (end-toend) систем:
- данное расширение в общем случае полезно только на защищенных территориях;
- это расширение защищает «конверт» сообщения в целом, а не только тело сообщения;
- расширение аутентифицирует подачу сообщений, а не подтверждает авторство содержимого письма;
- расширение может дать отправителю некоторые гарантии того, что сообщение будет доставлено на следующий этап (next hop) в тех случаях, когда отправитель имеет взаимную аутентификацию со следующим этапом и согласовал подходящий уровень безопасности.
Дополнительное рассмотрение вопросов безопасности приводится в спецификации SASL [SASL].
10. Адрес автора
John Gardiner Myers
Netscape Communications
501 East Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043
EMail: moc.epacsten@sreymgj