Emails originating from Gmail are being delayed or rejected (banner related errors)

What email service are you using to receive email?

Exchange Server 2013, local on-site machine, running under Windows Server 2012, R2

Did you check blacklist ?
https://mxtoolbox.com/blacklists.aspx
Are you receiving other emails. e.g yahoo, hotmail, live etc?

Thanks for the blacklist link. I ran the check on the mail server's address and got green "ok" results from all entities in the list.

Until a few moments ago, I had some second-hand information that hotmail may also be delayed/rejected. But I have now successfully sent-from and replied-to my hotmail account, and the round trip was only seconds in duration. So, hotmail seems unaffected, gmail is likely the only sender affected.

I should add that the Exchange server is, otherwise, receiving daily email successfully from many dozens of sending domains across mostly the US, and some UK/Germany. No problems reported in the majority of email transactions, etc.

Unfortunately, Google "changes things". And, they don't tell anyone. Last October they changed a certificate somewhere that knocked one of our customer's voicemail servers out from delivering phone recordings and alerts to their google-hosted email accounts. It was more than a week to discover the issue. Once the cert was updated, the voicemail system started magically working again. NO notice was provided...things just broke.

I guess when you're as massive and pervasive as Google, the consequences of even minor, undetected problems have the potential to screw up downstream systems in various ways!

I'm laughing as I type this, but is there any way to report things like this to Google? (None of the services in this system are paying customers of Google, also)

The only time the particular customer has every received any quality, (IOW no "gotta go check with my mentor" comments) is when tech support comes to them from Europe. Depends on time of day when ticket is opened. It was actually the cloud-provider phone system support that found the changed certificate. We worked on all sorts of things that would have been completely unnecessary IF they had just sent notice of the pending change!

Roger that, thank you, I'll keep this in mind if I end up attempting Google assistance.

New info:

I just became aware of testconnectivity.microsoft.com , and ran their test:

~~~~~

Also, there is a SonicWall sitting at the front of ISP connection to this location.

I guess you're not familiar with telnet?

Anyway, alternative: https://www.checktls.com/TestReceiver
Fill in your email domain.


The line with 220 is the banner.

Thanks, Kimputer, I'll check that out.

And, actually, yes, I've heard of telnet. But, as a recording engineer/worm farmer who has been conscripted into technical service, I plead guilty to not being fluent in any of this! I'm just known for solving problems others give up on... :)

Results from checktls.com:



If my limited understanding is correct, shouldn't the 220 prefix be followed by information about the Exchange server's name or static IP? (I think SonicWall may be hijacking this function? ... I've been informed that SonicWall pre-filters all incoming email to compare it to known bad actors)

Are you sure you NATed SMTP to your Exchange server?

NAT should be fine, I'm assuming, because the vast majority of email works perfectly, both incoming and outgoing. Only incoming Gmail gets delayed or prevented entirely.

My hunch is that something about Google's inspection of the "220 banner" entity is more discriminating, and so their servers drop the connection? Most other sending servers don't mind as much that sonicwall's information seems to be taking the place of the expected mailserver name/address?

I really appreciate your time and effort. What you've detailed makes the most sense to me, and I just have to find out how to correctly format the revised banner (I'm assuming it's a modifiable file in Exchange server, somewhere)

I should be able to finish this, now that I know what changes to make! Thank You :)

In the end, although the 220 banner was mismatched, the heart of the problem was happening with a known issue between SonicWall's recent migration to AWS servers for hosting their CASS (Comprehensive Anti-Spam Service) functions and Gmail's fussiness in AWS connections. SonicWall now has a dedicated, work-around server setup to handle customers who are having problems with CASS and Gmail interoperability.

Anyway, the problem is solved, and Gmail senders are now hitting the Exchange Server between 10 and 30 seconds, consistently.