Problem when using smtp-relay.gmail.com for email notifications

Problem when using smtp-relay.gmail.com for email notifications

Problem when using smtp-relay.gmail.com for email notifications
Problem when using smtp-relay.gmail.com for email notifications
Wednesday
Model: OC200  
Hardware Version: V1
Firmware Version: 1.37.11 Build 20251201 Rel.43290

We use google workspace for our business email, so I'm trying to use smtp-relay.gmail.com to send email notifications from my Omada controller, as described here: https://support.google.com/a/answer/176600?hl=en. I tried very variation of port and TLS enabling on the Omada side, and also every variation of requiring TLS and restricting the sender address in the google admin portal, but the test email failed to send every time. The only way that I could get a test email to send was by using the third option described in the article above, the restricted SMTP server: aspmx.l.google.com with no encryption and using port 25. However this method means that the email travels unencrypted and also can only be sent to Gmail or Google Workspace users - not at all ideal.

 

I belive that I am still being affected by the exact same issue described here, which was brilliantly investigated by gantzm: https://community.tp-link.com/en/business/forum/topic/634266

 

Please can someone from the TP-Link staff investigate this as a priority? Sending localhost in the EHLO message is ridiculous in 2026 and its understandable that Google blocks it on their mail relay.  I think this is the only reason that the test email can send when I use aspmx.l.google.com - Google is more lax with the security and ignores the error of sending localhost.

 

Thanks in advance!

  1      
  1      
#1
Options
3 Reply
Re:Problem when using smtp-relay.gmail.com for email notifications
Thursday - last edited Thursday

Just adding to the above, I have just verified that Google's SMTP relay does indeed immediately close the connection when localhost is used with the EHLO command:

 

liamriley@eros ~ % nc smtp-relay.gmail.com 587

220 smtp-relay.gmail.com ESMTP 5b1f17b1804b1-47d7f6b1a08sm9979345e9.12 - gsmtp

HELO smtp-relay.gmail.com

250 smtp-relay.gmail.com at your service

EHLO omadacontroller.int.example.com

250-smtp-relay.gmail.com at your service, [xx.xx.xx.xx]

250-SIZE 157286400

250-8BITMIME

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-CHUNKING

250 SMTPUTF8

^C

liamriley@eros ~ % nc smtp-relay.gmail.com 587

220 smtp-relay.gmail.com ESMTP 2adb3069b0e04-59b6c7173ddsm1111338e87.15 - gsmtp

HELO smtp-relay.gmail.com

250 smtp-relay.gmail.com at your service

EHLO localhost

421-4.7.0 Try again later, closing connection. (EHLO)

421-4.7.0  For more information, go to

421 4.7.0  https://support.google.com/a/answer/3221692 2adb3069b0e04-59b6c7173ddsm1111338e87.15 - gsmtp

liamriley@eros ~ %

 

But there is no such issue when using the less secured relay:

 

liamriley@eros ~ % nc aspmx.l.google.com 25   

220 mx.google.com ESMTP ffacd0b85a97d-432bd62b3c5si10092886f8f.470 - gsmtp

HELO aspmx.l.google.com 

250 mx.google.com at your service

EHLO localhost

250-mx.google.com at your service, [xx.xx.xx.xx]

250-SIZE 157286400

250-8BITMIME

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-CHUNKING

250 SMTPUTF8

^C

liamriley@eros ~ %

 

If there was the option to set the name to use during the SMTP handshake, or even if the controller's own hostname was used instead of localhost, this issue would be resolved entirely! Please fix this as soon as possible!

  1  
  1  
#2
Options
Re:Problem when using smtp-relay.gmail.com for email notifications
23 hours ago

Hi  @liamriley 

As Hank mentioned in the post, 

"smtp-relay[.]gmail[.]com" is not supported.

 

https://community.tp-link.com/en/business/forum/topic/634266?replyId=1276220

 

Is this more of a feature request?

 

  0  
  0  
#3
Options
Re:Problem when using smtp-relay.gmail.com for email notifications
19 hours ago

  @Vincent-TP 

 

You can call it a "feature request" if you like, but in my opinion this is a bug report - the SMTP client in the Omada controller software is clearly not RFC2821 compliant and this is why Google's SMTP server rejects the connection

 

See here: https://www[.]ietf[.]org/rfc/rfc2821.txt

 

Specifically this part:

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see section
   4.1.3), optionally followed by information that will help to identify
   the client system. The SMTP server identifies itself to the SMTP
   client in the connection greeting reply and in the response to this
   command.

 

See the document for the exact definition of address literal, but if my Omada controller has an IP address of 192.168.1.5 then its SMTP client should use [192.168.1.5] in the EHLO command rather than localhost. This would lead to SMTP servers accepting the connection from the Omada controller.

 

Please try and fix this as soon as possible!

  1  
  1  
#4
Options