Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Tìm hiểu thêm

Accessing MS Exchange Acct w/ IMAP/SMTP SSL Problem

  • 4 trả lời
  • 1 gặp vấn đề này
  • 2 lượt xem
  • Trả lời mới nhất được viết bởi ANub

more options

Hello,

My system is Ubuntu 16.04 (but I have tested it on Windows machine as well and problem remains the same). I have installed Exquilla extension to access MS Exchange account through EWS and things are working fine.

Other day I was trying to access Exchange account without Exquilla and surely I can but only for IMAP (incoming mail only). I can not send mail using SMTP no matter what settings I try. So I decided to capture packets from a successful SMTP login as compared to a failed one. I am attaching both the Packet Captures (IMAP based / EWS based) so that if I am missing something, someone may point it out. Just by looking at first 13 packets we can see that they are all the same. 14th packet (while using EWS) is started from Thunderbird client containing the encrypted Application Data. In case of IMAP based account that packet never gets generated and hence clients keep stuck at "Connected to XXXX Mail server message" when trying to send Email. Any ideas ??

Wireshark captures:

Link for IMAP file: https://ufile.io/yzn3i Link for EWS file: https://ufile.io/xhycg

Hello, My system is Ubuntu 16.04 (but I have tested it on Windows machine as well and problem remains the same). I have installed Exquilla extension to access MS Exchange account through EWS and things are working fine. Other day I was trying to access Exchange account without Exquilla and surely I can but only for IMAP (incoming mail only). I can not send mail using SMTP no matter what settings I try. So I decided to capture packets from a successful SMTP login as compared to a failed one. I am attaching both the Packet Captures (IMAP based / EWS based) so that if I am missing something, someone may point it out. Just by looking at first 13 packets we can see that they are all the same. 14th packet (while using EWS) is started from Thunderbird client containing the encrypted Application Data. In case of IMAP based account that packet never gets generated and hence clients keep stuck at "Connected to XXXX Mail server message" when trying to send Email. Any ideas ?? Wireshark captures: Link for IMAP file: https://ufile.io/yzn3i Link for EWS file: https://ufile.io/xhycg

Tất cả các câu trả lời (4)

more options

I have not looked at the captures, but first do you have anti virus scanning mail. A rather unfortunate cause of mail issues. Especially as they either can not cope with SSL/TLS mail at all, or rely on the user over riding Thunderbird certificate store and inserting the av as a certifying authority. Obviously both approached have failure in them.

more options

Matt said

I have not looked at the captures, but first do you have anti virus scanning mail. ........

Ubuntu, ahmm

more options

ANub said

Matt said
I have not looked at the captures, but first do you have anti virus scanning mail. ........

Ubuntu, ahmm

Ubuntu... ahh not common, except in business where it is often required. https://www.maketecheasier.com/ubuntu-antivirus-programs/

What is the server name? best I can get is some sort of timeout and what looks like a router in the Saudi telecom.

Given the request to change cypher's, I am guessing that we have incompatible cypher's being used on the mail server and in Thunderbird.

more options

Change cyphers request is the same as in case of EWS based account. As I had mentioned in my first post that first 13 packets for both the captures are all the same kind (except minor changes like session ID, originating ports etc).

I've also tried openssl but just could not get it to username / password part. Here is the most relevant portion of the outputs. One good thing is that while I was doing openssl testing, I was capturing traffic as well and this time I can see the there is TLS communication between client and server after the handshake which is basically missing in TB IMAP based account setup while trying to send mail. ____________________________________________________________________________________________ openssl s_client -crlf -connect mail.stcgroup.stc.com.sa:443 CONNECTED(00000003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4 verify return:1 depth=0 C = SA, ST = Riyadh, L = Riyadh, O = Saudi Telecom Company, OU = Cloud, CN = mail.stcgroup.stc.com.sa verify return:1 --- Certificate chain

0 s:/C=SA/ST=Riyadh/L=Riyadh/O=Saudi Telecom Company/OU=Cloud/CN=mail.stcgroup.stc.com.sa
  i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
  i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

--- Server certificate


BEGIN CERTIFICATE-----

MIIFOTCCBCGgAwIBAgIQEj+DrqUupc4kn2jlBxD1UTANBgkqhkiG9w0BAQsFADB+ MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE1MTEwMjAwMDAwMFoX DTE4MTEwMjIzNTk1OVowgYIxCzAJBgNVBAYTAlNBMQ8wDQYDVQQIDAZSaXlhZGgx DzANBgNVBAcMBlJpeWFkaDEeMBwGA1UECgwVU2F1ZGkgVGVsZWNvbSBDb21wYW55 MQ4wDAYDVQQLDAVDbG91ZDEhMB8GA1UEAwwYbWFpbC5zdGNncm91cC5zdGMuY29t LnNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqMKcVpz+HMxOa7Y0 YT9nASiU2D7etkTQ6Yk4kcVbTShX5ud0+JYqvVVmaLe7HxrGIxFBf8OPqba9Hmcy fCl5zO3vVyko5F39ZRYnr1h5+3dCYO8S5CRgKLuLh/d99bQgWOgbSaFNo7JWNL48 XVOitRGcPjNGI1LruuL5JFSDHk3Z3X+DXdbVp14WboNGJFRdO9gBt4kgGKBrPyUO iLhvYh8oRGpu2bkeQFgcv1zG6ZOGbgav0O1lXVbSvMhZp+QrkMdy22/D2Mj0nE9Y 6OofNENQ0xjDyttTK2yQ9qJ8gPhJe5EtUUIlL9PPYgmAqw5Slk3eejvO0I2cNr7Q syJ/GwIDAQABo4IBrDCCAagwYgYDVR0RBFswWYIYbWFpbC5zdGNncm91cC5zdGMu Y29tLnNhgiBhdXRvZGlzY292ZXIuc3RjZ3JvdXAuc3RjLmNvbS5zYYIbZ2F0ZXdh eS5zdGNncm91cC5zdGMuY29tLnNhMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWg MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBhBgNVHSAEWjBYMFYGBmeB DAECAjBMMCMGCCsGAQUFBwIBFhdodHRwczovL2Quc3ltY2IuY29tL2NwczAlBggr BgEFBQcCAjAZGhdodHRwczovL2Quc3ltY2IuY29tL3JwYTAfBgNVHSMEGDAWgBRf YM9hkFXfhEMUimAqsvV69EMY7zArBgNVHR8EJDAiMCCgHqAchhpodHRwOi8vc3Mu c3ltY2IuY29tL3NzLmNybDBXBggrBgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0 dHA6Ly9zcy5zeW1jZC5jb20wJgYIKwYBBQUHMAKGGmh0dHA6Ly9zcy5zeW1jYi5j b20vc3MuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCPPn2j4qYYO7E/ydgh8dM4S6VA qDOrfictlyauIqOF+bR42Ugc+787fTRy9FUEqOueX0yEfygruf/7EK8tbI88BDD+ vvF2DHXZUSZfD57ttTfERjCw2lj2wp4LNErCLtMNBNvsYi0GuDKrOK5FJFzKnC/j f89wgX/ZpcE9cE/lYGV8pSbyObRBpOJjHb2ik4SOF7lolJqi3YleufLjCwxW1ZWb rkl9u5QMKdJIZgOFUCEQ2cETncVkhF97wBVPxz813uJrQk9UVJmTRDdJZ0ToBJ3E 6xeChA0iXCQzShBDr5iBMFNIUK/GkQfqlR5pkiT/3VftddlpwT8xit1qQTIi


END CERTIFICATE-----

subject=/C=SA/ST=Riyadh/L=Riyadh/O=Saudi Telecom Company/OU=Cloud/CN=mail.stcgroup.stc.com.sa issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4 --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: DH, 1024 bits --- SSL handshake has read 3377 bytes and written 495 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session:

   Protocol  : TLSv1.2
   Cipher    : DHE-RSA-AES256-GCM-SHA384
   Session-ID: 90F66F302246C333FCF6450E565083B731B8DC3E1B5CC33337ACCCDFFF77B04E
   Session-ID-ctx: 
   Master-Key: 0C640CF49772611CF4B821952C2331D855F30291B61A0B220EB8EDDD8A5585E3A3A8D2C25FAF16CC11191D12447F191F
   Key-Arg   : None
   PSK identity: None
   PSK identity hint: None
   SRP username: None
   Start Time: 1519039698
   Timeout   : 300 (sec)
   Verify return code: 0 (ok)

--- HEAD / HTTP/1.1 Host: mail.stcgroup.stc.com.sa GET / HTTP/1.1 Host: mail.stcgroup.stc.com.sa

HTTP/1.0 302 Found Location: https://mail.stcgroup.stc.com.sa/owa/ Server: BigIP Connection: Keep-Alive Content-Length: 0

GET / HTTP/1.1 Host: mail.stcgroup.stc.com.sa

HTTP/1.0 302 Found Location: https://mail.stcgroup.stc.com.sa/owa/ Server: BigIP Connection: Keep-Alive Content-Length: 0

Host: mail.stcgroup.stc.com.sa/my.policy HTTP/1.0 302 Found Server: BigIP Cache-Control: no-cache, no-store Connection: Close Content-Length: 0 Location: /vdesk/hangup.php3 Set-Cookie: LastMRH_Session=cede7a96;path=/;secure Set-Cookie: MRHSession=e64e05bf262730873ec35023cede7a96;path=/;secure

read:errno=0 ______________________________________________________________________________________________

Can you please point how to give username / password in openssl command. I've tried AUTH LOGIN and auth login but server disconnects it.

Secondly, all I want is some kind of detailed TB debugging with which I could find out what the heck is wrong. I've got Virtual Machines (VM) so I've no problem in testing anything as I save all the emails in local folders. I also tried thunderbird-dbg package but I suppose it does not debug client --- server communication rather only debugs if there are errors / clashes within the application.