The "mail" component is a Jenkins built-in feature, not an external plugin, right?

By the way, if I change the "mail" to "emailext", it will work fine. But the "emailext" is from another plugin.

If possible, I prefer to work with "mail" component, else we will need to make a lot of changes to our code.

I can't duplicate the problem as you've described. I used Jenkins 2.375.1-rc with plugins as documented in my repository, including the Pipeline plugins. I configured an app password to allow me to use smtp.gmail.com to send messages. I ran the following Pipeline and confirmed that the message was sent.

pipeline {
    agent any

    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
                mail body: 'The body of the message', subject: 'A subject', to: 'mark.earl.waite@gmail.com'
                echo 'Goodbye World'
            }
        }
    }
}

I would guess that you have not updated your Jenkins Pipeline plugins or the mailer plugin. Plugins need to be updated when new releases are available. If you'd like further help, you'll need to provide the complete list of plugins and versions as described in "How to report an issue".

Sure, we'll check the plugin versions and the configurations first, thanks.

Just update "Pipeline: Basic Steps" from version "2.22" to "994.vd57e3ca_46d24", rerun the job, and the mail is successfully sent. Thank you so much.

Pardon me for asking:

1. Why are the plugin version naming format are completely different?
2. When I try to update the above plugin, I cannot directly update it via web "pluginManager/installed", I need to go to "https://plugins.jenkins.io/workflow-basic-steps/#releases" and download the ".hpi" file, then install it via "pluginManager/advanced". I guess there must be some reasons behind why there is no direct "update" option. Could you kindly show me?
3. When the plugin version is too old to send an email, the exception message is somehow "vage" for me: "java.lang.NoSuchMethodError". Is it possible that we throw an exception with a message which is more clear? But I guess this is not easy.

Why are the plugin version naming format are completely different?

Jenkins plugins are steadily switching to continuous delivery of new plugin releases each time there is an interesting commit to the master branch of the repository.  Those version numbers are the new format used by the CD process.  The rationale for that format of version number is mentioned on that page and is described in great detail in Jenkins Enhancement Proposal 229.

When I try to update the above plugin, I cannot directly update it via web "pluginManager/installed", I need to go to "https://plugins.jenkins.io/workflow-basic-steps/#releases" and download the ".hpi" file, then install it via "pluginManager/advanced". I guess there must be some reasons behind why there is no direct "update" option. Could you kindly show me?

You didn't mention the version of Jenkins controller that you are running. The Jenkins project provides security fixes and other focused effort on the most recent weekly release and the most recent stable (LTS) release. If you're running a version that is more than about 12 months old, the Jenkins update center may no longer provide update suggestions.

It could also be that you need to press the "Update now" button on the plugin manager to retrieve the most recent list of plugin updates.

It could also be that there is some problem that is preventing your controller from contacting the update center.

Plugin updates are generally presented as you expect.

When the plugin version is too old to send an email, the exception message is somehow "vague" for me: "java.lang.NoSuchMethodError". Is it possible that we throw an exception with a message which is more clear? But I guess this is not easy.

In most cases, we don't make changes that result in a "No such method" exception. This is a rather special case because the Java mail API's moved from one package to another package. Plugin updates had to be made to coincide with the change of the Java Mail API's. That's why the LTS upgrade guides consistently recommend that administrators update all their plugins before a controller upgrade, then upgrade the controller, then upgrade all their plugins after the controller upgrade.

Thanks you so much Mark, that is really some detailed info, also makes my job a lot easier.