Long delays receiving mail from Google Mail hosted domains

Problem If you have been having difficulty with delays receiving mail from people that use either Gmail or have their domain Google Mail hosted, then you might like to have a look at your firewall and see if it is blocking the incoming mail. We have been having a great deal of problems with mail being delayed on receipt, and in some cases this can be minutes growing to hours. In one case exceeded the 2 day limit and bounced back to the sender. In all cases we had no record of the mail being anywhere near our servers until it was actually delivered to a mail client, usually seconds after being recorded hitting our servers. We used the incredibly useful Analyze Headers feature of MXToolbox on delayed mail and found that in every case it came through a Google mail server. What was most alarming was the indication that it was on a blacklist! Hop Delay From By With Time (UTC) Blacklist 1 * 10.25.225.211 HTTP 6/23/2017 8:24:31 AM 2 59 minutes mail-lf0-f54.google.com SMTP 6/23/2017 9:23:56 AM 3 0 seconds mail-lf0-f54.google.com 209.85.215.54 HE1EUR02FT018.mail.protection.outlook.com 10.152.10.248 Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) 6/23/2017 9:23:56 AM So we then ran the mail server through the RBL checker on MXToolbox and low and behold: Not all blacklists had been fired, and it seems that SORBS was used by our SonicWall firewall as a RBL checker, which was installed by default. Resolution We understand that there have been issues recorded with SORBS. Therefore we looked up what to change these to on our firewall, and picked the following as potentials with the help of...

Cure those RDSH printing blues with TSPrint

Anybody out there fed up to the back teeth with firefighting printing problems on your remote desktops? Bet it’s most of you. I have found that a good deal of my management time in an RDSH farm is taking calls from users that can’t print from their remote session. There are such a huge range of printers and client desktops out there that installing printer drivers of the right sort on the server (or worse in a farm, many servers) becomes a management nightmare and can even lead to instability of the platform and availability issues for other users. I needed another solution, and after discounting some really quite eye-wateringly expensive options that may have worked, but would have seriously impacted my deployment budget, I came across TSPrint from TerminalWorks. This application is simplicity itself, you just install the server application on each server of your RDSH farm, and then each user installs a (free) client application on their workstation. Then when a client connects to the farm it forms a secure tunnel in which all print operations are sent to the client and processed locally with their drivers. On the farm you just select the generic “TSPrint” printer and there is nothing more to do. The print channel is also compressed to make the best of WAN connections, and there are advanced options that allow you to select different printers if required, as well as a simple print to default printer option. Since installing this product issues with printing have almost dropped to zero. I recently had an issue where at setup a user was printing fine for a...