Today every organization/service-provider are having this basic security for SPAM protection. In such scenario NextXMS will fail to send e-mails.
Please consider SMTP AUTH feature on high priority!!!
SMTP AUTH implementation is just addition of 2 send-receive after getting "250 AUTH ..." for EHLO domain-name\r\n.
C: AUTH LOGIN\r\n
S: 334 message <- here message is base64 encoding for constant string "Username:" i.e. VXNlcm5hbWU6
C: base64_encode(Login_str,Login_str.size())\r\n
S: 334 message <- as above here message is base64 encoding for constant string "Password:" i.e. UGFzc3dvcmQ6
C: base64_encode(Passwd_str,Passwd_str.size())\r\n
S: 235 or 334 message
C: MAIL FROM: [email protected]\r\n
PLAIN mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity.
In other words, the correct form of the AUTH PLAIN value is 'authid\0userid\0passwd' where '\0' is the NUL byte into UTF-8 encoding.
C: ehlo client.example.com
S: 250 AUTH PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 ok, go ahead (#2.0.0)
C: RCPT TO:<....>
In this sample, the user name was 'test' and the password 'testpass'.
The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both steps succeed, the user is logged in.
Non-US-ASCII characters are permitted as long as they are represented in UTF-8 [UTF-8]. Use of non-visible characters or characters which a user may be unable to enter on some keyboards is discouraged.
The formal grammar for the client message using Augmented BNF [ABNF] follows.
message = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
password = 1*UTF8-SAFE ; MUST accept up to 255 octets
NUL = %x00
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
Support of CRAM-MD5 DIGEST-MD5 and SMTPS/STARTTLS will require some good amount of work but PLAIN authentication is pretty simple.
Please consider SMTP AUTH feature on high priority!!!
SMTP AUTH implementation is just addition of 2 send-receive after getting "250 AUTH ..." for EHLO domain-name\r\n.
C: AUTH LOGIN\r\n
S: 334 message <- here message is base64 encoding for constant string "Username:" i.e. VXNlcm5hbWU6
C: base64_encode(Login_str,Login_str.size())\r\n
S: 334 message <- as above here message is base64 encoding for constant string "Password:" i.e. UGFzc3dvcmQ6
C: base64_encode(Passwd_str,Passwd_str.size())\r\n
S: 235 or 334 message
C: MAIL FROM: [email protected]\r\n
PLAIN mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity.
In other words, the correct form of the AUTH PLAIN value is 'authid\0userid\0passwd' where '\0' is the NUL byte into UTF-8 encoding.
C: ehlo client.example.com
S: 250 AUTH PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 ok, go ahead (#2.0.0)
C: RCPT TO:<....>
In this sample, the user name was 'test' and the password 'testpass'.
The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both steps succeed, the user is logged in.
Non-US-ASCII characters are permitted as long as they are represented in UTF-8 [UTF-8]. Use of non-visible characters or characters which a user may be unable to enter on some keyboards is discouraged.
The formal grammar for the client message using Augmented BNF [ABNF] follows.
message = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
password = 1*UTF8-SAFE ; MUST accept up to 255 octets
NUL = %x00
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
Support of CRAM-MD5 DIGEST-MD5 and SMTPS/STARTTLS will require some good amount of work but PLAIN authentication is pretty simple.