2011/8/17 Sergei Golovan <sgolo...@nes.ru>: > 2011/8/17 Bogdan <bog...@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