ESMTP authentication mechanism

In order to restrict non-official users from using the email server to distribute spam or conduct other improper behaviors, various free/paid email providers in China have successively upgraded to ESMTP and opened security authentication services. On the ESMTP server, the user's identity must be verified when sending emails. Compared with the traditional SMTP method, there is an additional authentication procedure for user identity, and the mail sending process after verification is consistent with the traditional SMTP method.

Almost all ESMTP servers inherit the account and password setting system of the POP3 server, that is, they use the same account and password to send and receive emails. Of course, you can also use different accounts and passwords. However, maintenance by email service providers and user usage are troublesome and therefore seldom used.

There are many ESMTP authentication mechanisms. The most common is the login mechanism, which is similar to the POP3 authentication method, that is, entering the account and password in two steps. All information in all authentication mechanisms is base64-encoded.

For example, if you use the smtp.elong.com email server to send an email, the process of connecting to the authentication is as follows (red and blue represent the client and server respectively ):

(Connect to smtp.elong.com: 25) 220 SP1 ESMTP v2.1ehlo ABCDEFG250-smtp.elong.com250-PIPELINING250-SIZE sans login plain DIGEST-MD5 CRAM-MD5 (supported authentication mechanism types: Login, plain, etc.) 250 8 bitmimeauth login334 vxnlcm5hbwu6 (base64 decoded after: username :) ymh3yw5n (before base64 encoding: bhwang) 334 ugfzc3dvcmq6 (after base64 decoding: Password :) encoding = (before base64 encoding: *******) 235 authentication successful

Another common mechanism is plain. The difference from the login mechanism lies in the one-time account and password, in the format of "<NUL> account <NUL> password", where <NUL> is byte 0. Replace the above authentication process with the plain mechanism:

Auth plain334 agjod2fuzwbtexbhc3n3b3jkiw15cgfzc3dvcmqhiq = (before base64 encoding: <NUL> bhwang <NUL> *******) 235 authentication successful

Some ESMTP servers, such as smtp.163.com, smtp.163.net, smtp.tom.com, and smtp.netease.com in coremail system, do not reply to line 334. After the client inputs auth plain, enter the account and password that meet the format requirements.

The login and plain mechanisms do not encrypt accounts and passwords, which is equivalent to plain text transmission. base64 encoding is just a piece of paper. Authentication mechanisms such as DIGEST-MD5, CRAM-MD5, gssapi, and javasos_v4 can encrypt the transmitted content.

Taking CRAM-MD5 as an example, the authentication process is:
A. Client declaration with CRAM-MD5 authentication method
B. The server provides a tag (stamp)
C. The client uses the mailbox password as the key to encrypt the mark in MD5 mode to generate an HMAC, and then sends the user name along with the HMAC.
D. The server receives the user name and HMAC, checks the correctness, and replies.

Auth CRAM-MD5334 encoding = (base64 decoded:) encoding (base64 pre-encoding: bhwang 5feb0c711ee0d3ae5e3eb087ea0e6a27) 235 authentication successful

Among them, "5feb0c711ee0d3ae5e3eb087ea0e6a27" is the HMAC obtained by MD5 calculation with the "" Mailbox password. For specific algorithms, see RFC 1321 and RFC 2104.

 

[Related resources]

RFC 1321-the MD5 message-Digest algorithm

RFC 2104-HMAC: keyed-Hashing for Message Authentication

RFC 2195-imap/pop authorize extension for simple challenge/response

RFC 2222-simple authentication and security layer (SASL)

RFC 2554-SMTP service extension for authentication

Bhw98 columns: http://www.csdn.net/develop/author/netauthor/bhw98/

First Release: 2003-07-22
Final revision: