
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-TURN
250-ATRN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
auth no
504 5.7.4 Unrecognized authentication type
auth login
334 VXNlcm5hbWU6
qwert
501 5.7.3 Cannot decode arguments
Auth login
334 VXNlcm5hbWU6
qqqq
334 UGFzc3dvcmQ6
qqqq
535 5.7.3 Authentication unsuccessful
auth login
334 VXNlcm5hbWU6
Таким образом, повторное использование AUTH возможно только после
неудачной авторизации.
Какие проблемы можно решить, используя авторизацию SMTP, а какие
проблемы не решаются? Очевидно, что использование авторизации релейным
сервером, которому пользователи отправляют свою почту, действительно может
ограничить пользователей в возможности рассылки нежелательной почты –
администратор системы может без труда идентифицировать пользователя,
выполняющего такую рассылку. Однако не стоит забывать, что почту любому
пользователю можно отправить серверу, который является MX домена, которому
принадлежит учетная запись пользователя – такой сервер ВСЕГДА должен
принимать почту для своих пользователей. Может ли и такой сервер
использовать авторизацию? Нет, так как этот сервер штатно ДОЛЖЕН принимать
почту от ЛЮБЫХ узлов Интернет! Ясно, что такой сервер, желая авторизовать
пользователей, передающих ему письма, должен распространить учетные
данные ВСЕМ почтовым серверам Интернет, что с одной стороны технически
«сложно» , а с другой бессмысленно, так как известный всем пароль перестает
быть средством защиты! Таким образом, проблема SMTP даже не в отсутствии
авторизации в протоколе (эта проблема решается данным расширением) а в
самой ИДЕОЛОГИИ работы системы электронной почты. Таким образом,
авторизация в SMTP не решает проблемы спама полностью, но может быть
полезна в ряде случаев, например, для авторизации пользователей,
пытающихся отправить почту через релейные сервера, предоставляемые
системами бесплатной почты, например, rambler.ru.
Рассмотрим следующее расширение протокола SMTP, описанное в
RFC1985. Пусть существует сеть небольшой компании, подключение к Интернет
осуществляется с помощью dial-up, таким образом нельзя утверждать, что сеть
компании подключена к Интернет постоянно. Компания зарегистрировала домен,
необходимо обеспечить получение почты в домен, зарегистрированный
компанией. Объявляем в DNS сервере, хранящем зону данной компании, что MX
данного домена является почтовый сервер, размещенный в офисе клиента,