I'm going to bump this.  We just had this issue with a client.  They had someone send email from outlook.com and it bounced around for over 1 1/2 hours.  Is there a way to maybe instead of using IP's to use the reverse DNS (confirmed with forward DNS) and failback to IP? and consider CIDR grouping instead of single IP's..  (Allow us to set minimum CIDR span a IP must reside in..)

 

Example.. 

mail-bl2nam02on0056.outbound.protection.outlook.com hits the server.. then...

mail-co1nam03on0058.outbound.protection.outlook.com hits the server since outlook.com is already in the accepted list.. then it's good to go.  

 

This is becoming a large issue.

We have had to manually maintain whitelists for outlook.com to get around this greylisting issue  as well as a seperate whitelist to handle SMTP relay issues as described in this thread

 

https://portal.smartertools.com/community/a87687/550-authentication-is-required-for-relay-enable-domains-smtp-auth-setting-for-local-deliveries.aspx

 

Whitelists are not simply maintainable in this day and age, let alone having to maintain two different whitelists to address two different (yet similar) problems.

 

One would think that this type of list could be programmatically determined by looking up SPF records for a few key hosts (Outlook.com, Gmail.com, InsertYourFavoriteHostHere.com) and automatically whitelisting those IPs if a setting is enabled to do so.

 

If SmarterMail is not in a position to dedicate development bandwidth for solving  these issues, perhaps they could at least maintain one central Whitelist for common senders like Google and Outlook that could be pushed out during SM updates.  That would benefit the entire community. 

 

Make it available only to those with a valid support contract, so SM can still get paid for these efforts.

</rant>

 

CCC, good suggestions. I asked for something similar here (need votes):

 

Hopefully SmarterMail can make a few tweaks to the SMTP In to help out the admins and give users a better experience with quicker delivery.

Thank you everyone for the feedback and suggestions. I've created an internal ticket for this community post that I'd like to bring up with our SmarterMail developers. 

 

I'll be meeting with them on Wednesday to discuss further. I'll report back with more information from our discussion and hopefully we can get some of these suggestions implemented. 

Von, sounds good. I'm sure the developers will say they're busy with SM16, but I think I speak for the community when I say:

Thanks again, as we appreciate your efforts!

Kevin

Greetings all, I met with the developers this morning. We will be adding a feature request for an option to automatically whitelist grey listing based on SPF Records for certain domains. 

Hello, just following up on this thread from 7 months ago.

 

Was this SPF feature added to the 15.x series? Is it in the v16 release? Could really use it, especially for O365 servers.

 

Thanks!

Hello!

 

Is there any update on this? Is there any plan for another method of exempting a whole SMTP cluster from Greylisting other than by manually adding lists of IPs?

 

We`re recently dealing with some clients that use a mailing system from OVH.net and their servers are really bad at handling Greylisting - if they receive the try again later message, their mailing system will cycle through dozens of gateways like 1.mo1.mail-out.ovh.net, 9.mo1.mail-out.ovh.net, 2.mo1.mail-out.ovh.net, 15.mo1.mail-out.ovh.net, 3.mo167.mail-out.ovh.net and so on and so on, each time with increase lag between tries. This causes huge delays in email delivery for clients that use OVH. We`ve tried whitelisting the IPs that we see in our SMTP logs, but almost each time they use another server and they have lots of them. We`ve also not been able to find any IP lists or IP ranges that they use, so this is getting out of hand.

 

Implementing a check based on SPF or something like that would be a business and life-saver - this could be seen as a basic feature that should go with Greylisting.

 

Looking forward to any updates on this.

• Ignore greylisting if SPF passes
• Ignore greylisting if RDNS passes