Hi Andy,

I use Zen's mailservers to send outbound from gmail for reasons I don't remember. Works fine.

Here are my settings: http://imgur.com/a/tqoLK

This guides may also be useful:
https://support.zen.co.uk/kb/KnowledgebaseArticle.as...
https://www.authsmtp.com/exchange-2016/exchange2016_...

Hope it helps.

Edited by Geordish (Sun 30-Jul-17 08:59:07)

Hi All, firstly thanks for all the comments, its appreciated. I'm going to respond to each of them below so if your interested read on, otherwise I understand!

10forcash - I genuinely appreciate your feedback and comments but I'm really sorry but what you are saying is incorrect. In the simplest sense of the world I am trying to send email via Zen's mail servers (mailhost.zen.co.uk) but on a non-Zen Internet Connection. In my case this network connection is on BT's network, but if we simplified it, it could be a wifi hotspot in a cafe, airport terminal, sky broadband, plusnet etc. It does not matter, just as long as the connection is not one of Zen's

Zen offer 2 ways to send mail via their mail servers:

1. If your on a Zen Internet connection (like Zen FTTP/FTTC) then you can send via Zen's mailserver (mailhost.zen.co.uk) with no authentication needed in any sense. This is because of course your on their network so they automatically "trust" you. You also dont need to tell them what email domains (e.g [email protected]) your sending from.

2. Zen offer the ability to send via their mailservers via authentication if your not on their network (e.g another ISP's internet/airport/cafe etc) - Instead you must auth via TLS so they have another way to trust you.

Its defined very simply here in this Zen KB article for configuring Outlook 2010 to send via their mailserver. You configure it to use Auth via TLS so no matter where you are in the world you can send email. Otherwise it would mean you also need to change your SMTP settings when your travelling to send email depending on the network connection your currently using. That is not really feasible. In addition, Outlook 201x doesn't allow you to send via DNS so your only choice is via a mail server.

https://support.zen.co.uk/kb/Knowledgebase/Broadband...

Quote "This article provides a step-by-step guide on how to change the settings in Outlook 2010 to send and receive your Zen Broadband email while travelling with a laptop, or using a computer, when not connected through your Zen Broadband service."

I should clarify that I configured a Thunderbird mail client on the same BT internet connection as our Exchange environment to send via Auth with TLS using one of my own domain names via Zen's mailserver (mailhost.zen.co.uk) and it works fine. This proves it works, just not playing ball via Exchange.

I'm well versed in DNS mail delivery via MX records and yes its not best practice and while it can work reasonably well if your rPTR's are configured etc its not foolproof.

On the other hand, sending email via BT's mail servers even if your on their network requires you to tell them about your own domain names your sending from (that are not registered via BT) so they are added to their mail relay 'whitelist' as you mention. Again, I'm well across this having done this many times.

I should clarify I have no issue sending via BT's mail servers, if I want to send via them I'll use "mail.btconnect.com". My issue is when sending via Zen's mail servers on a non-Zen network connection.

@jchamier - The reason why is for resiliency. I have also found sometimes BT's mail servers have more bad days than others (that of course is subjective and just my own experience) plus the hassle of registering new domains for mail relay whitelisting can be a challenge depending who you speak to on the end of the phone at BT. Zen dont have this restriction as long as your authenticated either by being on one of their network connections, or as we have discussed, via Authentication credentials over TLS.

@10forcash - Correct, failover is an option and costings I'm well across. Its something we are doing now, but I'm just looking into other options which was the original reason for the post.

@CecilWard - Thanks, this is interesting and I appreciate the info and links. I'll take a look. This was something I was using with another company a few years back but reverted back to our ISP's mail servers for mail relay (for reasons I can't recall), but appreciate the links. Thanks

@Geordish - Thanks for this, this again backs up my comments that this ability to send email via Zen's mail servers while not on their network is indeed possible so appreciate the image and link. Your settings look right to me which is why they are working (!) but for me something is awry.

We are actually bumping up the protocol logging tomorrow so we can see if we can fish out why its failing.

I hope my responses are read in the correct manner but again thanks for all the feedback

Cheers

Edited by deleted (Sun 30-Jul-17 10:04:56)

Having re-read your posts, I'm pretty sure you've rule out the problem being Zen or BT - the problem is how to configure Exchange to handle the authentication in the same way as Thunderbird did. In times gone by I would have suggested a wireshark capture from both applications, but given TLS this is no longer any use.

You might need to find an Exchange forum rather than this Broadband forum - as you've already proved, the connection works if you can authenticate - so the real issue is that Exchange isn't sending what you need it to send. I used to know Exchange, but never had to do authenticated send, and its changed a lot in the last 5 / 6 years.

In reply to a post by jchamier:

Having re-read your posts, I'm pretty sure you've rule out the problem being Zen or BT - the problem is how to configure Exchange to handle the authentication in the same way as Thunderbird did. In times gone by I would have suggested a wireshark capture from both applications, but given TLS this is no longer any use.

You might need to find an Exchange forum rather than this Broadband forum - as you've already proved, the connection works if you can authenticate - so the real issue is that Exchange isn't sending what you need it to send. I used to know Exchange, but never had to do authenticated send, and its changed a lot in the last 5 / 6 years.

Thanks Jchamier. You have hit the nail on the head. It does work just not via Exchange. I work with Exchange every day since the days of Exchange 4.0 so well versed in the technology which bugs me as to why this one isnt working!

The reason for posting here was because I wanted to see if anyone else had got any mail server (Unix/IIS/Exchange etc) to work with Zen Mail Servers using Auth with TLS and not just Exchange. I have asked a similar question on the Exchange forums also

I'll see what the verbose protocol logging throws up tomorrow... I'm sure its something simple.

Cheers

Andy

I'm no expert so not surprised if I've got the wrong end of the stick here

You're trying to relay mail from your exchange server via Zen, but using instruction Zen have provided for setting up a mail client to authenticate to their server for send / receive mail from you own account? Aren't they two different things ?

I can use my Exchange 2016 server to send direct without using a smarthost from my Zen FTTP connection so really don't understand why you need to use one

In reply to a post by fredfox:

I can use my Exchange 2016 server to send direct without using a smarthost from my Zen FTTP connection so really don't understand why you need to use one

He wants to send mail from his Zen smarthost while connected to BT

In reply to a post by fredfox:

I'm no expert so not surprised if I've got the wrong end of the stick here

You're trying to relay mail from your exchange server via Zen, but using instruction Zen have provided for setting up a mail client to authenticate to their server for send / receive mail from you own account? Aren't they two different things ?

I can use my Exchange 2016 server to send direct without using a smarthost from my Zen FTTP connection so really don't understand why you need to use one

Hi Fred, no problem!

Yes and no, they are 2 different things (sending email via Zen using Authentication from an Outlook client directly over the internet) or (sending email via Zen using Authentication from Microsoft Exchange directly over the internet)

While they are 2 different things, they are using (or should be using) the same method to send email via Zen's mail servers.

Exchange with no smart host defined will send via DNS which means Exchange will do a direct MX record lookup of the recipients email address, find their mail server and send direct to that. It does work, but sometimes can fail if for example the recipients mail server is restricted to only receive email from their ISPs/AntiSpam host mail servers or can't successfully do a reverse DNS lookup of your IP address your Exchange server is sending from. Best practice is generally to send via a mail server (like Zen's for example)

My issue is I'm trying to send email from our Exchange 2016 environment via Zen's mail server but from a non Zen internet connection, in this example a BT internet connection but it could be any provider, just not Zen. Unfortunately its just not working, but does work if I use a simple mail client over the same internet circuit

I'm 99.9% sure its a config in Exchange that needs tweaking, just got to find it.

Cheers

Andy

Are both the endpoint and mail server using the same TLS Version? You should have SSL 3.0 & TLS 1.0 disabled on exchange.- also confused that you mentioned Unix and IIS as mail servers...

Edited by deleted (Sun 30-Jul-17 20:56:55)

Thank you and good luck ! Can you update this thread when you find a solution, never looked at smarthost (seen when setting up Exchange) so I'd be interested in knowing how you fixed it

Ok, update.. problem fixed after I decided to have a look this evening remotely... all working now via Exchange 2016 sending to Zen's mail servers on a non-Zen Internet circuit via Authentication with TLS.

Problem was we had a setting enabled on our Exchange Send connector to "Proxy" outbound messages via the Client Access Role on Exchange (this feature was introduced in Exchange 2013). It allows organisations to simplify (as one example) how outbound mail flow is sent out to the internet and force it through a single/group of Client Access servers. This only applies to Exchange 2013/2016-->

Problem seemed to be that Zen's mail server didn't introduce back the AUTH command (telling Exchange to send the zen username/password to authenticate with) during the telnet negotiation after the STARTTLS command was issued (for reasons I'm not yet clear on). Instead I changed this specific Send Connector in Exchange to not proxy outbound email via our Client Access Servers and instead just send it straight out via the Transport "Service" on the mailbox server directly to Zen's 'mailhost.zen.co.uk' and hey presto, it worked. Looking at the protocol logs that I set to verbose to troubleshoot you can then see the session getting stood up, TLS negotiating, authentication credentials getting sent, email being sent and then the session stood down.

This kind of 'proxy' setup would only apply to people using Exchange 2013 onwards and I suspect that other mail server platforms probably dont have the ability to "proxy" outbound email via different parts of their platform.

Fred - Hope this helps, but its not really related to smarthost(s)... they are just a mail server you assign in your send connectors to send mail via.. in this case, I am using Zen's "mailhost.zen.co.uk". If you don't populate anything (which is the default) then Exchange will just send via DNS as explained earlier.

10forcash - Yep, SSL 3 and TLS 1.0 disabled as part of our standard server build. As for UNIX and IIS, what I am referring to is the ability to have a mail server running on UNIX (like Exim or Postfix) or say using the SMTP service built into IIS to send mail.

Hope some, no matter how little of this has been useful.. as suspected it turns out it was a setting/config change on Exchange and nothing to do with BT and/or Zen from a network connection/mail relay perspective.

Cheers

Andy

p.s Here is a snippet from the Exchange logs showing the transaction. I've edited a few names and removed all the certificate CN names etc (too much to word wrap)

The 81.x.x.x is my BT Business FTTP Static IP range.

220 smarthost01b.mail.zen.net.uk ESMTP Exim 4.80 Sun, 30 Jul 2017 20:56:11 +0000",
EHLO mx.mydomain.com,
250 smarthost01b.mail.zen.net.uk Hello mx.mydomain.com [81.x.x.x] SIZE 36700160 8BITMIME ETRN PIPELINING STARTTLS HELP,
STARTTLS,
220 TLS go ahead,
CN=*.mydomain.com, OU=PositiveSSL Wildcard, OU=Domain Control Validated CN=COMODO RSA Domain Validation Secure Server CA,
CN=*.zen.co.uk, OU=COMODO SSL Wildcard, OU=Hosted by Zen Internet LTD, OU=Domain Control Validated
TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits,
Valid,Chain validation status
CN=*.zen.co.uk, OU=COMODO SSL Wildcard, OU=Hosted by Zen Internet LTD, OU=Domain Control Validated
EHLO mx.mydomain.com,
250 smarthost01b.mail.zen.net.uk Hello mx.mydomain.com [81.x.x.x] SIZE 36700160 8BITMIME ETRN PIPELINING AUTH PLAIN LOGIN HELP,
AUTH LOGIN,
334 <authentication information>,
<Binary Data>,
<,334 <authentication information>,
<Binary Data>,
<,235 Authentication succeeded,
,,sending message with RecordId 43142946488393 and InternetMessageId <[email protected]>
MAIL FROM:<[email protected]> SIZE=4739,
RCPT TO:<[email protected]>,
250 OK,
250 Accepted,
DATA,
354 Enter message, ending with ""."" on a line by itself",
250 OK id=1dbvFz-0000Ih-HH,
QUIT,
221 smarthost01b.mail.zen.net.uk closing connection,

Edited by deleted (Sun 30-Jul-17 22:31:26)