Upping to Major, as this prevents an important part of continuous integration workflow, namely directly identifying and emailing developers the results of their checkins.

In general, mapping from user names to email addresses is the job of plugins implementing MailAddressResolver in Jenkins. It should be pretty automatic if your SCM user names are the same as your Jenkins user names and you're using e.g. LDAP, otherwise, a different implementation may be needed. Still, not really necessary to change the user names returned by P4.

https://wiki.jenkins-ci.org/display/JENKINS/Additional+Identities+Plugin may work for you. It associates additional identities (e.g. p4 user names) to Jenkins user records, and through those, to their email addresses.

I am in an environment where I do require the email address to come directly from the Perforce account info, it's the only available data source.

The email address cannot be inferred from the Perforce username, Perforce users do not necessarily have accounts on the Jenkins server (nor do I want them to if at all possible), nor are all users in LDAP (or any other accessible directory) - using Additional Identities as a workaround would be a real pain.

The email address is easily accessible from the 'user' spec in Perforce. I just need to know how to make it available to the email-ext plugin.

Create an Extension implementing MailAddressResolver from the mailer plugin. This can be an optional dependency to the mailer plugin, with your implementation annotated Extension(optional=true). If the mailer plugin exists and is enabled, p4 will provide the feature, otherwise it won't.

I'm also in the same boat as A C and kind of a deal breaker for the plugin at the moment (don't get me wrong, the plugin is coming along real well). Collecting the email addresses from Perforce appears to be a feature of the other Perforce plugin in case that helps.

I'm curious if I can set hudson.tasks.Mailer.UserProperty.UserProperty. MailAddressResolver claims to look for the email as a UserProperty:

So the common technique for a mail address resolution is to define your own {@link UserProperty} types and
add it to {@link User} objects where more context is available. For example, an {@link SCM} implementation
can have a lot more information about a particular user during a check out, so that would be a good place
to capture information as {@link UserProperty}, which then later used by a {@link MailAddressResolver}.