Jump to content

Google Workspace - GMail - changing 'Mail Relay' (currently LGfL)


Recommended Posts

Posted

I'm so confused! We don't use this function much, so I've never really got to grips with how it actually works...

 

Firstly we have FMS sending BACS, then we also have FSRM on the server sending notifications.

 

Both currently use the LGfL mail relay.

 

I can only currently see 2 options, so I'm looking for the easiest one obviously!

 

1. Change the LGfL relay settings to deliver to/from Google GMail accounts.

 

2. Somehow work out how to do this through Google Gmail setting and not use the LGfL mail relay at all.

 

Of course I don't actually know how to do either of these things, in fact thinking about it now FMS BACS emails might have already started messing up with some of the other things that are happening around DNS and us losing the old email accounts that were being used.

 

Anyway, if anyone can give me the ELI5 version of what should be happening that would be appreciated...

 

If FMS sends an email to the LGfL mail relay, then that sends it on, using a 'from' email address (that we no longer have access to) that is listed in LGfL as one of our Domains...

 

If FSRM sends an email to the LGfL mail relay, then that sends it on, using a 'from' email address (that actually doesn't exist)... I thought it was some sort of alias within the LGfL settings, but can't find anything there now! There does appear to be some sort of DNS TXT record on our Domain host for this, but I think this is only for mail going the other way as it seems to forward email to the domain on to an LGfL mail account.

 

I really want to stop everything being so complicated and try to streamline this process to stop myself tripping over it further on down the line and really try to centralise it all onto one platform.

 

So I guess do it all through Google?

Posted (edited)

In Google Admin, you can create an "SMTP relay service". https://support.google.com/a/answer/2956491?hl=en&fl=1&sjid=4498946212216932989-NA

 

There are various options available when configuring an SMTP relay service, most of which are security-related, with Google nudging you away from having the relay service left too open.

 

It's worth having a generic user in your Google domain that you just use for authenticating with the mail relay from your onsite systems that need to send mail. Turn on 2FA for that account and then create an app-specific password (which is what you'd then configure onsite systems with that need to authenticate with your Google SMTP relay service).

Edited by jthompson
Posted
It might be simpler than that, even.

 

I hope it is!

 

Not only for me, but I don't think FSRM allows any configuration/authentication at all (not sure about FMS at the moment).

Posted

We run an on-prem postfix server which is basically relaying up to a Google SMTP relay service. Postfix configured to not require any auth, but to accept incoming connections only from certain local IPs. It then relays up to Google, using a generic account from our Google domain to authenticate. As long as the on-site stuff (like FSRM) that can't do the auth are pointed to the postfix server, and the sender address includes our domain name, it all works.

 

I originallyworked from this guide: https://www.howtoforge.com/tutorial/configure-postfix-to-use-gmail-as-a-mail-relay/

Posted (edited)
Are you on LGfL @fiza ?

yes but I can't get the LGfL mail relay to work on FSRM either! LGfL gave up trying to help me! edit: I should say I gave up in the end as I wasn't getting anywhere. As we use Smoothwall they seemed to think something our end was blocking the traffic.

Edited by fiza
Posted (edited)

I've never tried it, but I'm wondering if Windows SMTP Server might solve this problem for you. e.g. https://phoenixnap.com/kb/windows-smtp-server. Configure that on one of your servers to accept messages from your FSRM server(s), relaying them on to the Google service.

 

Never used it myself, since we've already got a postfix server running that serves this purpose.

Edited by jthompson
Posted
If FMS sends an email to the LGfL mail relay, then that sends it on, using a 'from' email address (that we no longer have access to) that is listed in LGfL as one of our Domains...

If FSRM sends an email to the LGfL mail relay, then that sends it on, using a 'from' email address (that actually doesn't exist)... I thought it was some sort of alias within the LGfL settings, but can't find anything there now! There does appear to be some sort of DNS TXT record on our Domain host for this, but I think this is only for mail going the other way as it seems to forward email to the domain on to an LGfL mail account.

Just to hopefully 'help' - the LGfL relay will accept from [email protected] - it only cares that your domain is genuine. You could send from [email protected] if you wanted, as long as paddysschool.kent.sch.uk is legitimate and has DNS records to help with bounced messages, would need to be able to post the failure back via MX.

 

The TXT record you have might be SPF, which denotes mailrelay.lgfl.org.uk as a valid sender.

 

Always happy to help folk use the relay, but if you need to not authenticate at the user side, but at the Google SMTP side then... Microsofts own SMTP can be used, you can set zero authentication on the inside to all can post to that, then you set up the outbound via Googles own SMTP address with authentication. That does work fine, and means you can post all your stuff to your on prem server.

 

Happy to take a PM if you need a hand :) same with @fiza

  • Thanks 2
Posted
Happy to take a PM if you need a hand :) same with @fiza

 

Many thanks for your input as always @PaddyNewman - I will probably take you up on that offer when I get 5 minutes spare...

 

I am also grateful for all the other suggestions, however I would really like to try and simplify things mainly for my own benefit (but for anyone who takes over).

 

I do look at all the wonderful (and sometimes slightly left-field) workarounds to find ways to do what should be the simplest things... Sometimes it's just the workaround means setting up and learning a whole new process!

 

Unfortunately even if documented somewhere, these are always the things that trip me up 3 years later when either the OS get an update, or I change a setting to do something else and bring everything to a grinding halt... The thing is I never seem to have the time or resources to ever actually get to the bottom of the real problem, just deploy the workaround and move on, without ever actually solving the problem...

 

The message in event viewer is the same as @fiza had on another thread which says

 

"A File Server Resource Manager Service email action could not be run.

 

Error-specific details:

Error: IFsrmEmailExternal::SendMail, 0x8004531c, Failure sending mail.: Unable to connect to the remote server"

 

So that could mean firewall (possibly LGfLs as it never had a problem getting to the LGfL relay)?

 

Unfortunately, I don't know the process or the ports FSRM is using to send the message as it's a very basic interface with no configuration options.

 

Or something on the Google side rejecting it, which might return as being unable to contact the mail server?

 

Again, I've read the Google help pages and set-up what it's telling me to do, but I don't really know if I've done it correctly.

Posted

Yep, if you cannot get there on the port specified, thats the error.

 

Can you telnet to the address you are using (smtp.gmail.com or whatever they tell you to use these days) on port 587 (again might be different depending on the choice of relay..)

 

If you can't telnet, its the firewall.

If you can, the SMTP commands your object is sending are not supported.

 

Some stuff expects the first SMTP command to state that STARTTLS needs to be on, then it continues as there is auth, sometimes it wants AUTH... all depends again on the server host :) if you are the school I think you are, you do have those rules open HOWEVER, not via FQDN, so feel free to ask for the FQDN to be opened :)

Posted

I can Telnet from the server to both smtp-relay.gmail.com and 74.125.133.28 which I found from an NSLOOKUP (but returns 28250 for some reason).

 

Port 25 does not connect

 

Port 465 gets me to a blank screen (so connected?)

 

Port 587 gets me to a connected session and returns the EHLO details in the screenshot...

 

TELNET_GMAIL_SMTP_RELAY.jpg

Posted

25 won't connect, we don't allow port 25.

465 is old school relay, only one of theirs allows that port.

587 looks to work as expected.

 

You'd need to check their requirements, but presumably you need to provide credentials as per this doc - https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F176600%3Fhl%3Den&assistant_id=generic-unu&product_context=176600&product_name=UnuFlow&trigger_context=a

 

They state "Only accept mail from the specified IP addresses—System accepts only messages sent from IP addresses that you specify" which means you can yuse your public NAT address, that won't change... I have never done so and I can't test as my workspace is not at that subsciption level!

Posted
We use our public IP address as a condition in a Google SMTP relay service, so it does work. We also specify that it requires authentication, but it looks as though you can disable that requirement. There's obviously a risk attached to that, but in theory it would allow FSRM, which doesn't have any auth options available, to make us of it directly without any intermediary relay.
  • Thanks 1
Posted (edited)
25 won't connect, we don't allow port 25.

465 is old school relay, only one of theirs allows that port.

587 looks to work as expected.

 

You'd need to check their requirements, but presumably you need to provide credentials as per this doc - https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F176600%3Fhl%3Den&assistant_id=generic-unu&product_context=176600&product_name=UnuFlow&trigger_context=a

 

They state "Only accept mail from the specified IP addresses—System accepts only messages sent from IP addresses that you specify" which means you can yuse your public NAT address, that won't change... I have never done so and I can't test as my workspace is not at that subsciption level!

 

We use our public IP address as a condition in a Google SMTP relay service, so it does work. We also specify that it requires authentication, but it looks as though you can disable that requirement. There's obviously a risk attached to that, but in theory it would allow FSRM, which doesn't have any auth options available, to make us of it directly without any intermediary relay.

 

Yup, you'd think so as this is exactly as I've set it up in GW (and I'm guessing @fiza has done the same)...

 

GMAIL_SMTP_RELAY.jpg

 

In section one (1. Allowed senders - Only addresses in my domains) I presume it means you need a 'user' account to send from/as and I have created a user for this purpose, which I have entered in FSRM.

 

In section two (2. Authentication - Only accept mail from the specified IP addresses) The IP address is the Public NAT address (this was also returned in the telnet query so I know it's correct).

 

I just have no idea what else could be wrong... obviously the error message returned from FSRM isn't explicit enough for me to know 'why' it can't connect to the remote server!

Edited by Koldov
Posted
25 won't connect, we don't allow port 25.

 

Just a thought then...

 

What if for some reason FSRM is trying to send on port 25...?

 

The last couple of internet searches I've done for FSRM > SMTP have mentioned port 25!

 

If it was sending on port 25 (although you say it's not allowed), could it go on that port to mailrelay.lgfl.org.uk (as the LGfL relay works with FSRM)?

 

Because I just used telnet from my server to mailrelay.lgfl.org.uk 25 and it connected... and weirdly 465 & 587 failed...

 

Or is there something else going on and I'm going to look stupid when you explain how it actually works...? :p

 

TELNET_LGFL_SMTP_RELAY.jpg

Posted
FSRM has ultra-basic options, so yeah, it's probably just using port 25 with no auth.

 

Ok, so it was just the fact that if that is true, but @PaddyNewman says port 25 is blocked on the LGfL firewall, how does FSRM send OK when using the LGfL mailrelay...?

 

It must mean that port 25 isn't blocked between us and LGfL (or at least the mailrelay - only to the outside world).

 

Another thing is (and I seem to remember it was another reason I started looking at this) when I set my new GMail account to be the one receiving alerts from FSRM (using the LGfL mail relay), Google rejects it. I guess the LGfL mailrelay messes with the header? Or the sending account I'm using doesn't have something set-up correctly?

 

"Messages missing a valid Message-ID header are not 550-5.7.1 accepted"

Posted

For clarity as my wording was pony...

 

Port 25 = closed to the outside world.

Port 25 = open to our 'semi authenticated' relay, semi in the fact its based on source IP and from address with an imposed limit of mail per minute to prevent spam and sender blacklisting.

 

"Messages missing a valid Message-ID header are not 550-5.7.1 accepted"

 

Typically means missing SPF on the sender domain - GMail do love to drop unauthenticated mail.

  • Thanks 1
Posted
For clarity as my wording was pony...

 

Port 25 = closed to the outside world.

Port 25 = open to our 'semi authenticated' relay, semi in the fact its based on source IP and from address with an imposed limit of mail per minute to prevent spam and sender blacklisting.

 

So just to clarify, if you are on an LGfL network, FSRM (which I believe uses port 25) will work when pointed to the LGfL mail relay, but when pointed anywhere else will fail.

 

 

"Messages missing a valid Message-ID header are not 550-5.7.1 accepted"

 

Typically means missing SPF on the sender domain - GMail do love to drop unauthenticated mail.

 

Yes, that makes sense, it just always got through on O365, so I've never needed to configure SPF on the sending domain .

Posted

Point 1 - Yes as long as we are aware of sending IP and from address/domain :)

 

Point 2 - Google has really tightened up unauthenticated email (thats email without authorised sender lists, not actual authentication) and we see it daily!

  • 4 months later...
Posted

Hmmmmmm.... can't even really remember why I was trying to do it any differently now!

 

I've also migrated the shares onto a VM, so FSRM went with it obviously.

 

I asked LGfL to add the new server IP into the mail relay and it worked, so I'm going to say 'yes' for that part.

 

Think I had too much on (as usual) to stick with trying to bypass the LGfL mail relay and do it all via Google.

 

Just checked and have a DNS entry with our Domain Registrar on our Google domain for LGfL.

 

Feel free to PM for details.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...