Resolving LOGO! 8.4.1 Email Validation Bug with Multi-Segment

Problem Summary

Siemens LOGO! 8.4 Base Modules (BM) programmed with LOGO! Soft Comfort (LSC) V8.4.1 and Base Module firmware V1.84.03 incorrectly classify valid Internet email addresses as malformed. The LSC recipient editor silently discards any address whose top-level domain (TLD) contains more than one dot, or whose final label is shorter than the length expected by the embedded validator. As a result, recipient entries ending in .co.uk, .com.au, .co.za, .sms.telia.ee, @sms.orange.pl, or any other public-suffix containing two or more labels are removed with the dialog text "Removed invalid or duplicate email address" before the project can be compiled and downloaded to the BM.

The bug is in the LSC client-side validator, not in the BM SMTP client. The firmware on the module will accept and route any well-formed RFC 5321 address the configuration server forwards, so the symptom only appears during project engineering inside LSC. The behavior is identical for the Ethernet Web Server email-notification feature and for any program block (for example, the UDF/email function block in the LOGO! 8.4 library) that requires a recipient list.

Affected Products, Firmware, and Software Versions

The bug first surfaced in the LSC 8.4 line coincident with the October 2024 firmware release V1.84.03. Reports against firmware V1.84.02 indicate the same LSC-side defect, so the regression is in the LSC editor, not in the BM firmware. A new BM hardware revision is not required to obtain a fix; the patch is delivered in an LSC service pack.

Root Cause Analysis: The Embedded Address Validator

The LSC email-recipient dialog enforces a simple regular expression that approximates an Internet address as [email protected] with the following implicit constraints:

1. Exactly one @ character separating local-part and domain.
2. At least one dot inside the domain part.
3. The TLD label following the final dot must be between 2 and 6 characters and must not contain digits.

This is a textbook single-label TLD matcher. Public suffixes delegated by ICANN through the Public Suffix List, however, frequently contain multiple labels, for example:

• co.uk, org.uk, ac.uk (United Kingdom)
• com.au, net.au, gov.au (Australia)
• co.za, co.nz (Africa and Pacific)
• sms.telia.ee, sms.orange.pl, sms.clickatell.com (operator SMS gateways)
• appspot.l.googleusercontent.com (Google Cloud)

For each of those suffixes the validator sees more than one dot after the host portion and stops at the first dot it can match, which causes it to evaluate co as a TLD candidate and then fail length or character-class rules, or it sees the second dot as a syntax violation and removes the address. The host label itself (e.g. sms.telia.ee) is RFC-compliant; the validator is the non-conforming element.

Siemens Technical Support has confirmed the issue and committed the fix to the upcoming Service Pack 2 for LOGO! 8.4. The release date is not yet officially published.

Symptoms and Error Messages

Three distinct symptoms are observed in the field:

1. Silent removal in the recipient dialog. Typing or pasting an address such as [email protected] and pressing Apply causes LSC to clear the entry and display the dialog text "Removed invalid or duplicate email address". The error appears regardless of whether TLS, authentication, or any other SMTP option is configured.
2. Successful compile, failed delivery. When the validator is bypassed by an operator who edits the underlying project XML (see workaround), the LOGO! BM itself accepts the address and the SMTP relay attempts delivery, but the upstream mail server may reject the message if reverse-DNS or SPF checks are not satisfied. This is unrelated to the LSC bug and must be verified separately.
3. No error during online test. Online tests in LSC do not perform address validation; they only confirm that a connection to the SMTP server is possible. The bug therefore does not surface during a quick Online > Test session and is typically discovered only at production rollout.

Impact on SMS Gateway and Modern Email Routing

The validation defect disproportionately affects two common deployment patterns:

SMS-to-email gateway addresses

Mobile operators expose SMS delivery as an email-to-SMS bridge. Typical formats include +44xxxxxxxxxx@sms.telia.ee, [email protected], or [email protected]. The first two use multi-segment operator domains. Any alerting flow that relies on the LOGO! to send a single email that is then re-transmitted as an SMS by an operator relay is blocked by the LSC validator.

Modern regional or industry domains

Many corporate, governmental, and academic infrastructures use multi-label TLDs, for example police.uk, mod.uk, health.nsw.gov.au, or customer.com.au. Industrial end customers headquartered in the UK, Australia, New Zealand, or South Africa cannot be added as alert recipients on a stock LSC 8.4.1 build.

Workarounds and Interim Solutions

Option 1 - Mail-relay through a domain that the validator accepts

Configure a Gmail, Outlook, or corporate mail account as the destination on the LOGO! side, then create a forwarding rule on that mail account that re-sends the message to the original multi-segment address. The LOGO! is configured with a *.com address; the actual recipient is reached through the relay. This is the most common temporary workaround reported by integrators.

Option 2 - SMS gateway that uses a single-label TLD

Use an SMS gateway provider whose MX target uses a single-label TLD, for example @textmagic.com or @bulksms.com. Confirm with the provider that they will accept SMTP relay from a third-party IP and that they will accept messages without a registered reverse-DNS entry.

Option 3 - Operator direct via SMTP-to-SMS providers

Several vendors (for example, Esendex, Clickatell, MessageBird) expose an HTTPS API instead of an email interface. In that case, the LOGO! is not a viable mailer and the alert must be re-routed through a small industrial PC or a Siemens S7-1200 with the S7-1200 web server that performs the HTTPS POST.

Option 4 - Project XML edit (advanced, not supported)

The LSC project file is a structured XML. Operators have successfully edited the recipient tag directly in project.lsc prior to download, replacing <Recipient>[email protected]</Recipient> with <Recipient>[email protected]</Recipient>. The BM accepts the address on the next download. This workaround is not supported by Siemens and will be overwritten the moment the project is opened and saved in LSC. Use only as a last resort.

Official Resolution Path: Service Pack 2 for LOGO! 8.4

Siemens Technical Support has acknowledged the defect and confirmed the fix is targeted at the next Service Pack (SP2) for the LOGO! 8.4 platform. Until that SP is published, integrators should:

1. Open a Siemens support ticket and reference the project so the support record is linked to the published fix.
2. Pin the BM firmware at V1.84.02 or V1.84.03 in the project header; the firmware itself is not the source of the bug.
3. Apply the SP2 update on a test bench before pushing it to production BMs.
4. Re-validate every email recipient list with at least one address whose TLD contains two or more labels.

Track the SP2 release on the Siemens Industry Online Support portal under product LOGO! 8.4, filter by Firmware / Software Updates, and subscribe to the entry to receive an e-mail notification.

SMTP Authentication and Port 25 Behavior

A second, recurring question concerns the SMTP port and credential requirements of the LOGO! BM. The default SMTP port is 25 (plain SMTP). Port 25 is unauthenticated by IETF convention, but in modern deployments the LOGO! 8.4 BM will nonetheless submit the configured credentials whenever the dialog contains a username and password. Behavior per port:

If the upstream relay does not require credentials on port 25, leave the username and password fields blank in LSC. If the relay requires authentication, configure the credentials even on port 25; modern relays (for example, Postfix with smtpd_sasl_auth_enable = yes) will reject anonymous submissions on port 25 from a third-party IP regardless of convention. The BM does not implement OAuth 2.0 or any modern token-based authentication, so if the relay is locked to OAuth, the LOGO! cannot send mail and a relay that accepts username/password (or a previously described Gmail/Outlook relay) must be inserted.

Configuring Email on LOGO! 8.4 - Procedure

The following sequence produces a working email configuration on LOGO! 8.4 / LSC 8.4.1 that complies with the current validator. The procedure is identical to the SP2 fix workflow once the patch is applied.

Prerequisites

• LOGO! 8.4 Base Module on firmware V1.84.02 or V1.84.03 with Ethernet connected to a network that has outbound SMTP access (TCP 25/465/587).
• LOGO! Soft Comfort V8.4.1 installed on the engineering station.
• Coordinated SMTP relay host, port, and (if required) credentials.
• A test recipient address whose TLD contains only one label (for example, [email protected]) to confirm basic operation before testing multi-segment addresses.

Step-by-step

1. Open the project in LSC and navigate to Tools > Ethernet Connections or to the web-server/email block configuration panel.
2. Enter the SMTP server as an IP address or fully qualified host name. Avoid host names that resolve to multiple A records unless your relay can handle load-balanced sessions.
3. Set the SMTP port. Use 587 with STARTTLS wherever the relay supports it; otherwise 465 with implicit TLS; otherwise 25 with credentials configured.
4. Enter the sender address (the From: field). The validator accepts a single-label TLD on the sender side as well, so use [email protected] rather than [email protected] until SP2 is installed.
5. Add recipients one per row. The LSC validator will accept *.com, *.net, *.org, *.edu, and other single-label TLDs without complaint. Multi-segment TLDs will be silently removed; see Workarounds above.
6. If the relay requires authentication, enter the username and password in the corresponding fields.
7. Click Apply, then OK. Compile the project (File > Compile) and download to the BM (Tools > Download).
8. On the BM, navigate to Card > Network > Email on the integrated HMI (LOGO! 8.4 with display variants) to verify the configured sender and recipient lists.
9. Trigger the email through the logic program and watch the diagnostic LEDs or web-server diagnostic page to confirm a Mail sent OK status code.

Verification

After triggering, the BM's web server diagnostic page reports one of the following SMTP result codes. Match the code to the action in the table below.

Related Configuration Limits and Engineering Notes

• Maximum number of recipients: 16 per project, regardless of whether they are email or SMS targets.
• Maximum message body length: 512 bytes in plain-text mode. Binary attachments are not supported.
• DNS dependency: When the SMTP server is configured by host name, the BM queries the DNS server configured under Tools > Ethernet Connections > DNS. If DNS returns a CNAME chain longer than 4, the BM will time out after 5 s and report code 451.
• Time synchronization: Email headers carry the LOGO!'s RTC timestamp. A LOGO! with an unset RTC sends messages with a 1970-01-01 epoch and some relays will drop them as spam. Set the RTC on the BM or enable SNTP under Tools > Ethernet Connections > Time using a reachable NTP server.
• Firewall posture: Many corporate firewalls block outbound TCP 25. Verify that the engineering network's egress ACL allows the BM's IP to reach the relay on the configured port. If the egress policy is restrictive, use the relay's submission port 587 with STARTTLS instead.

Best Practices for Email Integration on LOGO! 8.4

1. Designate a single corporate relay as the only SMTP target for every LOGO! in the fleet; do not point individual BMs at external providers.
2. Use a dedicated sub-domain such as logo.alarms.acme.com with a single-label TLD until SP2 is installed, and a proper sub-domain once SP2 is in production.
3. Document every recipient list in the project revision log; the LOGO! does not export a runtime recipient inventory, so the project file is the only source of truth.
4. Trigger a test email after every firmware update, including SP2 when it is released, to confirm the validator has been corrected for multi-segment TLDs.
5. Monitor relay logs for SMTP code 501 entries; they are the first indication that an address was bypassed in LSC and is now arriving on the relay without a proper domain label.

Troubleshooting Matrix

FAQ