The restricted gmail server (aspmx.l.google.com) is not intended for customers that aren't using Google Workspace. It worked in the past for you, but it appears that Google has changed things. When I lookup the mx record for a known Google Workspace domain the response is aspmx.l.google.com but when I lookup the mx record for gmail.com the server is gmail-smtp-in.l.google.com. I don't believe that what you are attempting is a valid configuration anymore.
Continue using SMTP2GO, purchase a Google Workspace account, use a different SMTP service provider that doesn't require modern encryption, or purchase a newer MFD that does support more modern encryption. Those are the options that I see for you.
I responded to your other post about the Workcentre 75 series machines. Those do support STARTTLS 1.2 and they can send directly through smtp.gmail.com which is always the preferred method when supported.
MRCAnalyst,
Hello there. Thank you for jumping in and helping us get this issue resolved. We are dead in the water with respect to getting the scan to email working with the Google server. Right now, we are having users scan to email via SMTP2GO with SMTP AUTH turned on, and using a linked SMTP2GO account. It is working successfully and with no errors or issues. However, we would like to get to the bottom of the aspmx.l.google.com SMTP server problem and the continued failure (error code 027-504, invalid SMTP server’s response). But first, here are the answers to the questions/comments you posed. Specifically:
So, we just tried it with the aspmx.l.google.com SMTP server, with port 25 as the sender, and with NONE selected as the credentials to send automated emails. We still got an error code 027-504, invalid SMTP server’s response.
Any further thoughts/suggestions/things to try will be appreciated. Do you know of anyone else having this issue?
Thank you,
johnnyd
I hope that you have resolved this already. If not though, I might be able to help point you in the right direction toward a resolution. First I have to ask if you have changed the primary account password for the account at all since creating an app password? I didn't see you mention that but if you do change the primary account password it invalidates all app passwords; requiring you to generate a new one to use on the device. I would expect that to generate a different authentication fault code though.
Authentication is not required for the restricted Gmail SMTP server (aspmx.l.google.com). So turning off authentication in your Xerox SMTP settings shouldn't cause a failure. You might get a different error after turning off SMTP Auth, and that might be helpful.
You can refer to the Google documentation at the link below for assistance in properly configuring your device to use the restricted Gmail SMTP server. Most importantly adding the public IP that the device is sending from to the allowlist in the GSuite admin settings. The instructions that you want to follow are in the Option 3 section.
https://support.google.com/a/answer/176600?hl=en#restricted-gmail-smtp-option
Hello johnnyd,
Unfortunately Joe is no longer with the company.
Hi Tammy L,
Thanks for the response. Is Joe still around and active in addressing cases that are confusing?
Thank you,
johnnyd
Hello johnnyd,
I suggest you call into the support department and speak with a 2nd level analyst at 1-800-821-2797. Your questions are beyond my expertise.
Hi Tammy L,
I did take a look at the article and tried to address both suggested solutions. For the first one, I was able to open a Telnet session and contact the server. I was opening gmail server aspmx.l.google.com on port 25. However, this is as far as I could get becuase I kept getting command line syntax errors using the commands listed in the article. Is there an update to this article using the correct command line syntax? As for the second one (domain name configured properly), we have been using WORKGROUP.local with success. All credit for this goes to Joe Arseneau because he picked up on this error a couple of years ago and suggested this change. The domain name correction is what got us working in the first place.
Since we have to use the Google server aspmx.l.google.com because the 7435 is not capable of TLS, is there a way to completely shut off the login credentials completely (both credentials to access the server as well as the credentials for sending the emails) on the SMTP server page for this machine? This is because the error we keep getting back is that the aspmx.l.google.com server does not support authentication. Please let us know.
Thank you,
johnnyd
Hello johnnyd,
Please take a look at this article for the fault code 027-504. If you are still having issues after trying these steps, I suggest that you call into our support department for assistance @ 1-800-821-2797
Hello Xerox Community,
I was called in late this afternoon because users in our operation are unable to scan to email. We keep getting error code 027-504, invalid SMTP server’s response. The machine is a Xerox WorkCentre 7435, software version 75.3.1.
As background to the issue, at the end of May 2022, we were forced to incorporate two step verification for emailing from this unit. We followed the Xerox document BR35970 (Create and Use App Password to send mail to Gmail). Based on the direction given in this document, we turned on two step verification in the Gmail email serving the unit and created an app password as well. We then loaded this 16 character app password into the 7435 CenterWare SMTP Server password box. We were using the Google aspmx.l.google.com on port 25 as the SMTP server since this machine does not have SSL/TLS protocol. I pinged the aspmx.l.google.com server today and got 4 packets sent, 4 packets received.
All was good since the end of May 2022 and users were able to scan to Gmail emails. Now this has changed and the error code 027-504 keeps popping up on the Job Undelivered Transmission Report. I am not exactly sure when it changed and when we went from being able to scan to unable to scan. No other changes to the settings/communications were made to the best of my knowledge.
What are we doing wrong and how do we fix this? Is this something that recently changed on the Google servers? What is different now from the change at the end of May 2022 to two step verification? Is there a solution or work around?
Any help, support, guidance would be much appreciated as they are driving me nuts and claiming that I changed something. Thank you.
johnnyd