In order to limit the formal users of non-system to use the mail server to distribute spam or do other improper behavior, the domestic free / charged mailbox providers have upgraded to the ESMTP mode, and the security certification service is opened. On the ESMTP server, sending emails requires authentication of the user's identity. Compared to traditional SMTP modes, there are more authentication procedures for one user identity, and the authentication is consistent with the traditional SMTP mode.
Almost all ESMTP servers have inherited the account and password setting system of the POP3 server, that is, sending and receiving mail with the same account and password. Of course, you can also use different accounts and passwords, but whether it is an email service provider's maintenance or user's use, it is very much.
There are many kinds of ESMTP authentication, the most common is the login mechanism, similar to POP3 authentication mode, ie, enter account and password in two steps. In all verification mechanisms, all information is encoded by Base64.
For example, send mail with a SMTP.elong.com mail server, from starting to connect to authentication, as follows (red and blue represents client and server):
(Connect to SMTP.elong.com: 25)
220 SP1 ESMTP V2.1
Ehlo abcdefg
250-smtp.elong.com
250-Pipelining
250-Size 20480000
250-ETRN
250-Auth login Plain Digest-MD5 CRAM-MD5 (Supported authentication mechanism type: login, plain, etc.)
250 8bitmime
Auth login
334 vxnlcm5hbwu6 (Base64 decoding: username :)
YMH3YW5N (Before the Base64 encoding: bhwang)
334 UGFZC3DVCMQ6 (after Base64 Decoding: Password :)
BXLWYXNZD29YZCFTEXBHC3N3B3JKISE = (Base64) Before: ********)
235 Authentication Successful
Another more common mechanism is Plain. The difference from the Login mechanism is the one-time input account and password, the format is "
Auth Plain
334
Agjod2fuzwbtexbhc3n3b3jkiw15cgfzc3dvcmqhiq == (Base64 before code:
235 Authentication Successful
Some ESMTP servers, such as SMTP.163.com, SMTP.163.net, SMTP.TOM.com, SMTP.163.net, SMTP.TOM.com, SMTP.NETEASE.COM, etc., without replying to the 334 code line, and the client is directly Enter the account and password that meets the format required.
Login and Plain mechanisms are not encrypted on account numbers and passwords, which is equivalent to light transmission, and base64 encoding is just a layer of paper. DiGest-MD5, CRAM-MD5, GSSAPI, Kerberos_V4, etc., can encrypt the transfer content.
Take CRAM-MD5 as an example, the authentication process is: a. Client declaration with CRAM-MD5 authentication mode b. The server provides a tag (stamp) c. The client uses the mailbox password to make a key, encrypt this tag in MD5 mode, Generate HMAC; then send the username along with the HMAC D. The server receives the username and HMAC, check its correctness, give the reply auth CRAM-MD5
334 PDEXMJC5NDA4MTYUMTGWMDM5NEBZBXRWLMVSB25NLMNVBT4 = (Base64 Decoded: <1127940816.1800394@smtp.elong.com>)
YMH3YW5NIDVMZWIWYZCXMWVLMGQZYWU1ZTNLYJA4N2VHMGU2YTI3 (Base64 before: bhwang 5Feb0c711ee0d3ae5e3eb087e0e6a27)
235 Authentication Successful
Among them, "5FEB0C711EE0D3AE5E3E3EB087EA0E6A27" is the HMAC obtained by MD5 operation with "<1127940816.1800394@smtp.elong.com>" with the mailbox password. The specific algorithm can be referred to RFC 1321, RFC 2104, and the like.
[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 column: http://www.9cbs.net/develop/author/netauthor/bhw98/
First release: 2003-07-22 Last revision: 2003-07-22
