on 2016 Oct 10 11:18 AM
I was able to get email working from a SQLA 17 database using a GMail account with the help of Breck's great article.
For reference, the current Google certificate is a Geotrust certificate.
My question is what certificate (or any other adjustment) needs to be used for a hosted exchange type of setup, specifically Office 365. When I connect through our webmail, the certificate information lists a Baltimore CyberTrust certificate, but using that root certificate in SQLA 17 gives the error 6 on xp_startSMTP, which is what I was getting on the GMail testing until I got the certificate correct.
Quick DCX References for SA-17:
MAPI and SMTP System Procedures
Thanks in advance for any help or ideas.
Edited to add error checking results: These are the calls:
@return_code = CALL xp_startsmtp (
smtp_sender = @smtp_sender,
smtp_server = @smtp_server,
smtp_port = @smtp_port,
timeout = @timeout,
smtp_sender_name = @smtp_sender_name,
smtp_auth_username = @smtp_auth_username,
smtp_auth_password = @smtp_auth_password,
trusted_certificates = @trusted_certificates );
MESSAGE STRING ( 'xp_startsmtp return_code = ', @return_code ) TO CLIENT;
MESSAGE STRING ( 'xp_startsmtp error code = ', xp_get_mail_error_code()) TO CLIENT;
MESSAGE STRING ( 'xp_startsmtp error text = ', xp_get_mail_error_text()) TO CLIENT;
For these results:
6 0 ''
Removing the username, password, and certificate parameters for a simple call gives these results:
0 235 ''
The IANA.ORG SMTP code list says 235 is a status used for security errors without detail to protect the server's policies ("Something related to security caused the message to be returned, and the problem cannot be well expressed with any of the other provided detail codes. This status code may also be used when the condition cannot be further described because of security policies in force.") But it references a message return, not a login to the server so I'm not sure if that's the right 235 that I'm getting.
UPDATE: The username and password combo was bad (doh!). So with a good username and password by using the BALTIMORE certificate or the * (which allows use of the local computer's certificate store) and the secure = 1 or secure = NULL parameter (didn't matter) I was able to get to these error codes
`8 504 Authentication mechanism not supported'
Which leads me to the answer(?) below.
Request clarification before answering.
Not sure if this is an answer yet or not, but my research into other products' interactions with Office 365 indicates that it is looking for the "LOGIN" method of SMTP authentication.
The docs indicate that xp_startsmtp supports only "PLAIN" or "CRAM-MD5."
Can anyone verify that these two are true? If so would there be any plans to support the "LOGIN" method of SMTP authentication?
Example 1 - If the E-Mail-Server does not support "PLAIN", E-Mail-Notifications will fail - typically with "Auth...
Example 2 - Office365 only supports the LOGIN SASL on TLS port 587
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I can confirm that PLAIN and CRAM-MD5 are the only authentication methods supported. We have no current plans to change this. If Office365 doesn't support any other authentication methods, I can't think of any workarounds.
Don't you mind if I suggest you to play with the Mail API.
I know people like struggling with old solutions that were working for them for years, but you can extend SA with a "relatively short" Java code to use Java API for emails (in case you don't like MS Mail API).
If Java is not your taste, you can use 3rd party services or google for some SMTP relay server.
User | Count |
---|---|
64 | |
8 | |
7 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.