SMTP Protocol logs are an invaluable tool when troubleshooting message delivery in on-premises Exchange Server.

I have just had a support case closed because Office 365 support cannot provide SMTP Protocol logs and I'm stuck, not able to determine the cause of a mail flow issue without the logs. The only option for send/receive information on a particular message is advanced message trace, which does not provide details of the message conversation.

Can you provide a way for admins to request these logs from the Office 365 support team, if not provide a way to access them via Remote PowerShell? Obviously, these logs exist, as you're running Exchange Servers in your data centers.

Thank you.

Microsoft use various Spamhaus blocklists for filtering incoming mail. As an Office 365 user myself, I am grateful for this, as without such tools I'm sure I would receive a lot more spam.

However, today I discovered that an email from one Office 365 user to another Office 365 user was rejected because the sender's IP was on the Spamhaus PBL and XBL lists. The IP address was not on the SBL list. Please note that the message was submitted using an Exchange client with their Office 365 username and password. It was not submitted by SMTP.

If I understand the Spamhaus documentation correctly, this is not the right thing for Microsoft to be doing. Spamhaus says of the PBL, "PBL listings do not prevent you sending email unless your email program is not authenticating properly when it connects to your ISP or to your company's mail server".

About the CBL Spamhaus says:
"We're getting a lot of reports of spurious blocking caused by sites using the CBL to block authenticated access to smarthosts / outgoing mail servers. THE CBL is only designed to be used on INCOMING mail, i.e. on the hosts that your MX records point to.

If you use the same hosts for incoming mail and smarthosting, then you should always ensure that you exempt authenticated clients from CBL checks, just as you would for dynamic/dialup blocklists.

Another way of putting this is: 'Do not use the CBL to block your own users'. "

This policy is very important for Office 365 customers who use Outlook on their mobile phone around town, or for people who send mail on their home computers. Such users typically have dynamic IP addresses which are prone to being listed on the PBL and XBL blocklists due to the actions of other users with whom they share the same pool of IP addresses. This is not the fault of the users, nor of Spamhaus, nor of their ISP. If I've understand the Spamhaus documentation correctly, this is a fault that Microsoft must fix.

I have a request which I imagine will benefit a number of your customers.

As you know, O365 no longer supports sending email to legacy Exchange (2003 and older) systems on Windows Server 2003 running TLS 1.0. ( See these articles:

http://bit.ly/1JoVsJT
http://bit.ly/1gkfSK6
http://bit.ly/1IgpknD )

Unfortunately, we have a client that is running such an environment and we are unable to send them email. If you wish to see details, the SR is SRX615081193192636ID.

We have encountered around a dozen other clients who’s email systems do not support TLS at all. For these cases, I have configured a rule which sends email to them using Office 365 Message Encryption (I’ll call it O3ME for short). This didn’t work for the case in question. After speaking to the technician, it appears that O3ME uses Opportunistic TLS. Because of this, delivery to a system which uses TLS 1.0 fails because O365 says “Oh, they negotiate TLS so let’s do it!” but in fact the recipient is negotiating a TLS version that O365 can’t support so the mail fails.

My request is that you provide an secondary O3ME option which can be configured via Transport Rule which will send entirely without the use of TLS. This, I believe, would solve the problem for any Office 365 customer trying to send to a recipient with a legacy system but who cannot do so since your change to deprecate this possibility.

Thank you for your time.