Sparrow supports SMTP-AUTH and APOP mechanism.
The authentication only once as long as the session continues is effective. The session continues between TCP connected and TCP closed.
Explains SMTP-AUTH with sample user as follows.
Sparrow doesn't correspond to RCPT-AUTH though this specification refers to RFC2554.
01 C:AUTH CRAM-MD5 02 S:334 PDI3NDguMjE3MzY1OTI1QGxvY2FsaG9zdD4== 03 C:dGVzdHVzZXIgMTliNThlM2JhMTQwY2I5NDI1Mjg5NjQ3YjFkYThhZjc= 04 S:235 Authentication successful
01 C:AUTH CRAM-MD5 02 S:334 <2748.217365925@localhost> 03 C:testuser 19b58e3ba140cb9425289647b1da8af7 04 S:235 Authentication successful
01 C:AUTH PLAIN AHRlc3R1c2VyAFRlc3RVc2VyMDA= 02 S:235 Authentication successful
01 C:AUTH PLAIN <\0>TestUser<\0>TestUser00 02 S:235 Authentication successful
Though the client should transmit <authorize-id>, <authenticate-id>, and <password> if original, but the Sparrow doesn't use <authorize-id>.
The format is following according to RFC2595.
It doesn't come recommended.
01 C:AUTH LOGIN 02 S:334 VXNlcm5hbWU6 03 C:dGVzdHVzZXI= 04 S:334 UGFzc3dvcmQ6 05 C:VGVzdFVzZXIwMA== 06 S:235 Authentication successful
01 C:AUTH LOGIN 02 S:334 Username: 03 C:testuser 04 S:334 Password: 05 C:TestUser00 06 S:235 Authentication successful
This authentic method is necessary to make it correspond to Outlook Express. However, it doesn't come recommended.
01 S:+OK <3284.223037520@localhost> 02 C:APOP testuser fce30c559101f86a4376f46b93ba2c3e 03 S:+OK testuser logged in(127.0.0.1).
More detail, see RFC1939.