Maybe you can provide a way to add a few ids to the ignore list so Jenkins doesn't send email to these predefined list of ids. eg. I see its trying to resolve an Ids called "VisualSVN Server" which will not exist but my build takes forever to finish.

INFO: No results found for filter sAMAccountName=VisualSVN Server inside baseDN ...

Also look at Issue JENKINS-14837

Jenkins version - 1.447.2
Email Ext Plugin version - 2.24.1

We are experiencing these very same symptoms (JIRA Issue 13700) just wanted to add some info that may be helpful in diagnosing the issue. We have seen jobs hang on the e-mail step on jobs configured for Base Clear Case, Clear Case UCM, TFS, as well as jobs that have no SCM component configured. The delay seems to be related to the number of email addresses the plug-in is attempting to send to. So large projects (largest number of developers) take the longest. Also as far as Jenkins is concerned the job is done so subsequent builds of the same jobs may kick off while the hung job is still spinning on another slave. Please let us know if any additional info will be helpful.

For what it's worth - I see this is marked as bug, but it is a blocker for us as we have a pretty large environment (60 slaves) and will cause us to go back a version. Thanks!

Just to follow up on bbonn's comment, we were finally able to figure this out in our environment.

We began experiencing this problem when we upgraded our Jenkins core from 1.424.6 to 1.447.2. We were using Email Ext version 1.8 at the time. We updated to the latest Email Ext (2.24.1) with no luck. Then we updated our Active Directory plug-in from version 1.6 to 2.9, again with no luck. Finally, in the main configuration for the AD plug-in we removed our domain name from the advanced configuration. For us, that's what got our configuration of Jenkins resolving email addresses normally again.

I doubt the email-ext plug-in is even related in our case. I have NOT proven that out, but I'm assuming that if we had kept our email ext plug-in version on 1.8 but made all the other changes, we would have had success there as well.

Just in case anyone has a similar setup, this is what worked for us.

@bbonn, this would have nothing to do with going back a version, the email address resolution has been around for a long time. What version were you using previously that did not show the issue?

This should be resolved by the move to remove the mail address resolution pieces from various plugins into plugins. This will allow you to enable/disable specific mail address resolution mechanisms by installing/uninstalling plugins.

Should be fixed when the mail address resolvers are extracted. See JENKINS-16437

Tracked by JENKINS-16437