Troubleshoot BMC SMTP Email Alerts on M4 Platforms

Archived M4-era BMC SMTP troubleshooting procedure. Seven English instructional image localizations cover eight Chinese image references; two original blank spacer images are retained. Passwords remain masked and obscured contact identifiers are replaced with declared placeholders. The screenshots illustrate legacy controls and failure states, not current provider compatibility or an executed server change.

I. Problem Description

After configuring email alerts on the BMC, when an alert occurs, the system can automatically send an alert email to a specified mailbox. The sender is the pre-configured mailbox.

The following three issues may occur:

1. When configuring email alerts on the BMC, the prompt 'SMTP server authentication type not supported' appears.

 

2. If an email ID has been configured for the BMC user, clicking Test while using QQ's SMTP server prompts 'User email ID not configured'.

 

 

3. When using a self-configured SMTP server, no prompt appears, but no alert emails are received.

II. Fault Analysis

The archived M4-era QA attributes these failures to SMTP authentication incompatibility or a mismatched service/port. It lists CRAM-MD5, LOGIN and PLAIN as the BMC-supported mechanisms and port 25 as its default. An overlapping supported authentication mechanism is needed; the server does not have to enable all three. Validate the actual firmware’s capabilities and the intended mail service rather than treating these old settings as a current universal SMTP configuration.

III. Scope of Involvement

The original scope is M4-platform models, plus NF8460M3 and NF8480M3. It does not establish the capabilities of newer BMC generations.

IV. Solution

1. Use an external SMTP email server

The original QA reports Sina and Sohu as working external sender examples for this old implementation and reports a problem with numeric QQ sender names. This is historical compatibility information, not a current certification or an exhaustive list of all mail services. Check the chosen service’s present authentication, encryption and port requirements against the exact BMC firmware.

The recipient address belongs to the BMC user/alert destination and is distinct from the authenticated sender account. The source lists several recipient mailbox services as examples; actual delivery can still be affected by recipient validity, filtering, relay policy and service restrictions.

2. Use a self-configured SMTP email server

For a separately managed SMTP server, configure a permitted service compatible with the actual BMC. The historical article uses port 25 and one supported authentication mechanism from CRAM-MD5, LOGIN or PLAIN. Do not infer support for a different port, TLS mode or hostname from a newer vendor’s UI, or assume the legacy settings satisfy current service requirements.

Appendix: BMC Email Alert Configuration Method

1. Set the recipient's email address

In BMC Settings → User Settings, configure the intended recipient’s Email ID and verify the alert destination refers to that user. The English example replaces the partially obscured address with recipient@example.invalid; it is a non-deliverable placeholder. Enabled is a user state, Administrator a privilege and Disabled the shown SNMP state; the original header wording is ambiguous, so the illustration labels these columns by their displayed meaning.

 

2. Configure sender information and SMTP server

Open BMC Settings → SMTP Settings. Select the actual management network interface. The source prose describes dedicated eth1 and shared eth0 for its platform, while the pictured selection is Shared management port. These names are not a universal mapping for all server generations. The English sender@example.invalid address is a non-deliverable placeholder replacing the obscured source address.

 

Enable the intended primary SMTP service and supply the verified server address and authorized sender-account details using the actual firmware’s supported controls. The illustration keeps SMTP enabled, the historical example IP and a fully masked password; its user name is redacted. It does not demonstrate a submitted configuration or working authentication.

Legacy input restrictions: this source says its server-address field accepts an IP address and its sender user name excludes the @domain part and cannot be purely numeric. The article names smtp.sina.com and smtp.sohu.com as historical examples. Resolve and verify the actual service with its operator; do not copy 202.108.6.242 from the archived screenshot or assume a fixed DNS answer, user-name format or TLS capability applies today.

 

3. Configure alert filtering and alert destination information

Open BMC Settings → Alert Management and review the intended event filter. The pictured filter is Voltage with All Sensors, not every sensor type. Save only the required policy and use the actual controls for any additional event types.

 

Configure and save the intended destination and matching management interface. The example policy is enabled, uses Email and points to the selected BMC user. A controlled Test can help verify delivery after the actual configuration is reviewed. Confirm the destination inbox and mail-server results; a UI button or the absence of an error does not prove the alert was received. No test email was sent while preparing this guide.

 

The same English policy illustration is reused here; its Test highlight is instructional. The source figures show the same enabled shared-port Email policy, not proof of delivered mail.

Source research and applicability

The OEM QA’s English link leads to the vendor’s English home page; no corresponding English edition or complete equivalent M4 image set was verified. The Supermicro X9 SMM IPMI manual supplies a related official English SMTP explanation, but it is for different hardware and is not evidence of identical M4 firmware fields or settings. Its figures were not substituted for the source screenshots.