Wcallender

Hi all Has anyone who uses Cirqa and office 365 had any luck getting cirqa to send mail? I've followed MS's guide to setting up application SMTP to the letter and Cirqa can not send. After a few calls with iso oxford we've run through a few different options and are now discovering that MS themselves are kicking back authentication as per the cirqa mail log: System.Net.Mail.SmtpException: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [HE1PR0402CA0015.eurprd04.prod.outlook.com] I've got a feeling that the words "anonymous" and "Mail From" are Microsoft's way of telling us that the mail headers are not being populated with a mail from address. Before i go through the MS support process just wanted to ask if anyone else has run into this issue?

So after finally getting this issue bumped to the escalations team after a few weeks of regular MS support, they found the issue in a matter of minutes - typical. For anyone following/anyone that has issues not receiving NDR's and bounces from AD synced and/or incloud Distribution groups with office365 it turns out the 'report-to-originator' field for the DG wasn't populated. For AD, a quick ADSIedit will sort that out. For incloud DG's that have the same issue, connect to 365 exchange in powershell and: Get-DistributionGroup | fl *report* - this will show true/false on 'report to manager' or 'report to originator' Set-DistributionGroup -ReportToOriginatorEnabled $true - sets as true Our mail for both synced and incloud DG's now returns NDR's and after passing them onto postmasters we're now sending mail just fine again.

Thanks for that. It seems the conclusions here were: the invaluement block list - checking against it shows us as not listed. Issue's with the disclaimer - we've tested sending email without disclaimer but still encounter the issue. Having all BT customers we send to add us to safe senders - a rather daunting task but I guess we'll have to get them to if it'll help. I don't suppose you've come across issues like this where no bounceback email ever surfaces? I did a quick search but couldn't find any threads on that. It's a common issue were seeing with the failed emails to these addresses on top of message trace 'null sender' and 'blocked by spam policy' messages.

Hi everyone We've recently got onboard the office365 train but have run into a problem sending mail to btinternet/openworld, virgin/blueyonder, aol.com/aol.co.uk email addresses. I've endured the torture of MS support for a few days who assure me that SPF is fine, DKIM is fine, Headers are fine, their IP's and reverse are fine. The email content is text nothing else, no fancy HTML, no fancy graphics, nothing. I've even sent a test message with MS support watching via screen sharing. I've checked our sending reputation which comes up neutral or good with services and I've checked us against block lists of which we don't appear on any. So I turn to you wonderful people. Firstly and rather unfortunately, for reasons unknown we receive no bouncebacks whatsoever, from any mail provider. The MS engineer seems as baffled at this as I am. Using message trace in exchange admin shows that our email fails to virgin/BY and aol and is being stopped for a number of reasons "null sender to multiple recipients" and variants of the phrase are most common. Other messages will simply tell us that the external mail server is treating our mail as spam. Emails to BT addresses sit 'Pending' in message trace with a 'defer' message saying we've sent too much spam. I've been in touch with postmasters at BT and AOL who both requested bounceback message and headers despite the fact I've told them the sending account receives no bouncebacks, I've sent both all the info I can but neither has come back to me thus far. We're sitting here thinking surely we cant be the only office365 school that's had this issue. Can anyone shed any light on this situation? Thanks!

We experienced this issue and it started last week. No matter what printer, even printers that our machine had never been connected to before would print TRUE in all caps in the bottom left of every page. Even if we printed to the adobe PDF printer! Turns out in our case it was the Intel graphics driver causing havoc, we have 80 odd machines with an identical image that don't have the TRUE issue so I bet the driver was pulled down as an optional MS update. Downloaded a new driver from the boards manufacturer (in this case MSI) installed and voila! No more TRUE. As to the cause we're not sure, maybe something going on with GDI in the windows print process either way a graphics driver update fixed the issue for us. Good Luck!