Re: Забанили в гугле - не могу найти RFC на SMTP-авторизацию.
2011/8/17 Sergei Golovan <sgolovan@nes.ru>:
> 2011/8/17 Bogdan <bogdar@gmail.com>:
>> Request for Comments: 2554 читал.
>>
>> Ищу RFC на AUTH LOGIN / AUTH PLAIN / AUTH CRAM-MD5
>
> http://www.ietf.org/rfc/rfc4616.txt (это про PLAIN).
>
>>
>> Эти ворпосы вообще RFC регулирует или какой-то другой тип документов?
>>
>> Вопрос возник после тыкания в Exim (stable) из Zend'а :
>>
>> Может (согласно RFC) работать конструкция вида:
>> C: AUTH PLAIN
>> S: 334
>> C: ODczZjM5MDBhNGNmYzhjMmE5ZjMxY2JlZjRkMjc3YTMgIG5vZGVfY2xhc3NpZmllci5wbAo=
>> S: Authentication succeeded
>>
>> Но не работает - Incorrect authentication data при верном логине и пароле.
>
> В том RFC 4616 ясно сказано, что имя с паролем надо сразу же передавать.
> Цитата: The mechanism consists of a single message, a string of
> [UTF-8] encoded [Unicode] characters, from the client to the server.
>
> Cheers!
> --
> Sergei Golovan
>
Имя с паролем - да, они и передаются одной base64 строкой в
неработающем примере выше.
А вот о том, что эта строка должна передаваться в качестве параметра
для команды авторизации там не сказано, более того, показано обратное
поведение в примере ACAP-сессии:
The first example shows how the PLAIN mechanism might be used for
user authentication.
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN"
S: + ""
C: {21}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a002 OK "Authenticated"
Всё-таки выглядит как баг в exim.
--
WBR, Bogdan B. Rudas
Reply to: