SMG needs to support AUTH LOGIN

Idea ID 2835353

SMG needs to support AUTH LOGIN

AUTH LOGIN provides the ability for clients to authenticate to an SMTP server.

AUTH LOGIN was supported in GWAVA 6.5 but support was not provided in SMG.

Some SMTP servers require clients to authenticate before they will accept email. If you want to use your SMTP server to send email to external email addresses, this is known as relaying. To prevent abuse from spammers, SMTP servers are configured to permit relaying only after the client authenticates (via AUTH LOGIN).

If your email app allows you to specify a username and a password and indicate that your SMTP server requires authentication, it will use that information to authenticate to the SMTP server using AUTH LOGIN.

If your mobile devices have been sending SMTP email to GWAVA or to your SMTP server (like GroupWise/GWIA), things probably have been working pretty much as expected.

If you upgrade from GWAVA to SMG or deploy a new SMG appliance to front end your SMTP server, this is what will happen:

  • During the SMTP handshake SMG will not advertise that it supports AUTH LOGIN ("220 AUTH LOGIN") and the client will most likely disconnect.
  • If the client attempts an AUTH LOGIN, SMG will return "500 Command unknown" and the client will disconnect.
  • In short, SMG will not accept SMTP email from your mobile clients!
  • If your clients don't try to authenticate, SMG will accept email for internal users only but, for most of us, that's not a workable solution.

This is an important feature that can severely impact certain customers and was provided in previous versions.

Please vote!



This is absolutely an issue!  I don't know how any full featured SMTP product can miss this!  Didn't anyone who tested this product have a user with a laptop out in the field?

I've got my back against the wall now that GWAVA will basically stop functioning in 28 days (EOL).  I'm working through the SMG7 migration and I'm appalled at how bad the documentation is...

There is also one more SMTP Auth related issue for us...

I wrote a GWAVA logfile analyzer which runs in the background to trap SMTP Auth failures.  It watches each GWAVA thread (as identified in the log file) and then notes if/when an AUTH FAIL occurs.  (No small task to track multiple running threads).  Anyway, if we see an AUTH FAIL it pushes the offending IP address up to our firewall/router to block ANY/ALL traffic from that host from entering our network.  I also have a version which monitors POSTFIX logs and have done used it to modify a local firewall (iptables) as well.

If you haven't watched for SMTP AUTH FAILures, then you likely do not know what you are missing!  We can see thousands of these during a single day as hackers and botnets try known email addresses against established lists of popular passwords.  I've also seen them use well known first names with well known passwords.

Basically, if some IP address tries unsuccessfully to log in to my SMTP server, then I don't want ANY traffic from that host entering my network!  (My users know to contact me if they somehow fat-finger an email login on the road - but email clients normally store the authentication creds anyway).

I have shared my code with the folks at GWAVA (beginfinite) a long time ago and I think they even worked something in to one of the Gwava releases.  However, they didn't do it with the granularity I wanted so I just continued using my own scripts.

In any case, SMTP AUTH support needs to be implemented ASAP.  ...and if SMG7 is not going to support some method of blocking hosts with SMTP AUTH failures, then I will need to run my own scanner inside the SMG VM.



I'm in the process of migrating GWAVA 6.5 to SMG 7.0...  How is this NOT supported?  I'm going to get reamed by my users in the field.  There is no way for them to autheticate so they can relay mail?

Who tested this stuff?

Knowledge Partner Knowledge Partner
Knowledge Partner


Please vote for this idea. The number of votes an idea receives influences when a new feature may be incorporated into a product.


So, I opened up a ticket and spoke with an amazingly patient tech support guy..

CONFIRMED: SMG 7.0 DOES NOT support SMTP AUTH logins...

Tech Support suggested I simply allow the remote IP's of my users to RELAY mail.  This obviously is NOT going to work as we need this for REMOTE access (i.e. hotels, etc).  The IP addresses my users get will not be static.

Then they suggested I set up another external (static NAT) IP that my remote users can use to send SMTP mail through.  This second IP would simply bypass SMG and talk directly with my GWIA.  So, let me get this straight...  Another external IP to support SMTP that simply eliminates SMG from the path?  Anyone see a problem with this?  Port scanning for SMTP? 

What good is an SMTP security product if I have to deploy another IP address which BYPASSES it so my remote users can send mail?  Hey hackers, don't use that second IP address cause its only for my users!  Ugh!

I'm going to get killed by my iPhone, Android and laptop users cause they won't be able to send mail via simple SMTP.  I can hear it now:  "Why don't we use EXCGHANGE?"  "Why don't we just put our EMAIL into the cloud?"  "Why are we using this Groupwise crap?"...

So now we are forced to "upgrade" from GWAVA 6.5 to SMG before Feb 28th.  Thing is, SMG is missing some core functionality!

I'm told, its on the list of things to do but it might be many months away (we all know what that means).  "The developers are working on more important stuff".  More important than core functionality?

We have been forced off one tool and onto another that doesn't have the same core functionality for our users!  ...and the developers have more important things to do? Really?

I've been doing this stuff since the early 80's.  I was with Novell when Netware still used the bindery.  I wrote tools to migrate govt facilities from bindery services to NDS.  I hung on through OES and even went to SLES with them.  But this is really starting to be an uphill battle all the time.  I'm tired of all this thoughtless crap!

I'm tired of working for software which should be working for ME!

Time to put everything in "the cloud" so I can say "not my problem" when stuff doesn't work...

Knowledge Partner Knowledge Partner
Knowledge Partner

I understand your frustration.  But here's a suggestion...
* Have iPhone/Android users sync via GMS.
* Have laptop users run the GroupWise client and connect directly to the POA.

Then you eliminate the need for SMTP AUTH logins.


I appreciate the suggestions but we tried GMS a long time ago.  My users didn't like it.  They just wanted to use their own smart phone clients natively.  Same for laptops...

These are all needless workarounds if the SMG just supported the standard SMTP functionality.

What OTHER standard SMTP functionality is missing in SMG?

Knowledge Partner Knowledge Partner
Knowledge Partner


I appreciate that you have some tough choices to make and are disappointed that some features are missing or only partially implemented in SMG. You are not alone!

  • Check the forums to see what issues other customers have.
  • Check the SMG ideas to see what new features customers are asking for. This should give you an idea of what is missing from the current product.
  • Vote for the ideas you want to see implemented (including this one).
  • Create new ideas to request features you feel are important and would like to see incorporated into the product.

In the end it's up to you how you wish to proceed. In the meantime voting for good ideas can only help the rest of us!

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

I had the pleasure of working with @evanevery today. He had a great idea of leaving GWAVA 6.5 up an running but use a different SMTP port other than the default port 25 so that users could use SMTP AUTH login and then have SMG do the regular mail scanning.

To do this we went into the GWAVA 6.5 > Server / Interface Management > SMTP scanner > Interface settings > TCP/IP listen address: 

If you don't specify a port then it will default to 25. If you specify a unique port, restart gwavaman services, then it will listen to the unique defined port.

Until this feature gets added to SMG this is a viable workaround in case others run into this issue.

Knowledge Partner Knowledge Partner
Knowledge Partner

No chance to put a Like to your approach!

Knowledge Partner Knowledge Partner
Knowledge Partner

@JParkes @evanevery 

While the continued use of GWAVA 6.5 may sound appealing everyone should be aware of the Micro Focus Support Alert that was sent out last week. In part, it states

Final reminder: GWAVA 6.5 end-of-life may impact your virus and spam definition updates.

As previously announced, version 7 of Micro Focus Secure Messaging Gateway (SMG) released in October 2019, marked the end-of-life for the GroupWise Anti-Virus Agent 6.5 (GWAVA).

After February 28, 2021 Secure Messaging Gateway 6.5 will no longer receive virus and spam definition updates. It is therefore imperative for you to upgrade from version 6.5 to the Secure Messaging Gateway version 7 (March 2020 release or later), to continue to receive virus and spam definition updates. If you don’t update to the latest version, your systems could be at risk from older and outdated scanning. Additionally, the March 2020 release and later releases contain critical updates that include SUSE Linux Enterprise Server (SLES) as a base for the Secure Messaging Gateway appliance and the latest updates.

This advisory reinforcers the need to have the AUTH LOGIN feature incorporated into SMG sooner rather than later!

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.