Showing results for 
Search instead for 
Did you mean: 
Level 7

MEG 7.5.x and Lyris List Servers

I wanted to share something we have run into since we upgraded from 6.7.2 to MEG 7.5.x. It has to do with external Lyris Servers sending to us.  I had issues with two seperate senders using Lyris.  Bottom line, I was wondering if anyone has altered their default RCPTTO "550 Denied by Policy" response since upgrading to MEG.

What we found was the Lyris Servers are not liking the default 550 rejection message that MEG 7.5.x spits back for an invalid user.  Lyris is treating the default message “550 Denied by Policy “ as an IP block rather than the recipient is unknown.  Since Lyris is thinking it is an IP block, it puts that domain into the mailstream block domain/IP anddoes not try again.  If the Lyris server had a perfect recipient list(which for any list server is pretty much impossible), then you would not run into a mailstream block when sending to McAfee Email Gateways.

I did some testing in our lab and was able to reproduce this issue.  To fix the issue, the McAfee Email Gateway needs to change its Default RCPTTO “550 Deny by policy”.  When I changed it to "Recipient rejected: User %RECIPIENT% not found" , Lyris understood this better and realized it was an invalid recipient and treated it as such.

If you follow this link and changed the RCPTTO response ,then anyone with Lyris will be able to deliver even if there are bad recipients.  Understand this is a global change to the Bounce message for invalid LDAP recipients on the MEG.  Personally,  I this should had been the default out of the box for MEG and we will implement this very soon. Below is the link to the KB on McAfee

Just to note, I still had an Ironmail powered up and the response from it for an invalid recipient is  "550 mailbox unavailable or access denied - <>

If changing this 550 response is not doable, then you will need to create a new protocol preset under Recipient Authentication. Create a group and populate it with any IP addresses that would be coming from a Lyris server.  For that group, do not do Recipient checks.  This will allow the Lyris servers to deliver both valid and invalid recipients. The invalid recipients would eventually bounce back to Lyris, but they at least get past the “550 denied by policy” that triggers the mailstream block on Lyris. This is currently what we have in place until we change the RCPTTO message.

I have not opened a ticket with Lyris or McAfee on this issue. I just finished testing this in lab today so I am ready to let them both know the issue and see what their suggestions are.

Anyone else run into anything similar?

0 Kudos
1 Reply
Level 10

Re: MEG 7.5.x and Lyris List Servers

Ran into a similar issue where we wanted to have customized "550" messages for specific SMTP presets: can't be done.

The 550 messages are global and we were instructed to open a PER to reuest this feature in future versions of the product.

The generic "550" message for all 'denies' is very infuriating, especially when the proper messages could be sent back using Ironmail... feels like a stepback.

0 Kudos