Gravity SMTP 2.3.3 fixes a case where a long email subject containing multibyte characters could prevent the message from being logged. A delivered email without a searchable log breaks support, compliance, retry investigation, and correlation with the provider. Header folding or encoding can also make a subject look correct in one inbox while the stored text is truncated or invalid.
Use this for multilingual stores, international forms, translated notifications, customer names in subjects, emoji, right-to-left languages, CJK text, accented text, and support teams that search Gravity SMTP logs by order, entry, or ticket marker.
Quick answer
Create subject fixtures that cross normal header-folding boundaries in ASCII, accented Latin, Arabic, Hebrew, Japanese, emoji, and mixed text. Put a short stable ASCII marker at the beginning and end. Send each through every active provider, then compare the original WordPress string, encoded MIME header, Gravity SMTP log, provider event, delivered message source, inbox display, search result, resend action, and export. The message and log must exist once, remain valid UTF-8, preserve both markers, and avoid exposing BCC or private body data.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| ASCII | 120 characters | One log and one delivery |
| Japanese | Three folded lines | Markers preserved |
| Emoji mix | Near byte limit | Valid UTF-8 |
| Provider timeout | Accepted before response loss | No duplicate resend |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Build boundary subjects | Record Gravity SMTP, WordPress, PHP, mail provider, locale, database charset and collation, log retention, subject byte length, character count, and encoded header length. | Both fixture markers survive the original subject, encoded source, Gravity SMTP log, provider event, and inbox display. |
| Send through real connectors | Build boundary fixtures at short, near-fold, multi-fold, and very long lengths using ASCII, accents, combining characters, RTL text, CJK, emoji, and mixed scripts. | Log search and export find each multilingual message without replacement characters or silent truncation. |
| Compare encoded and stored text | Send through Google, Microsoft, Zoho, Amazon SES, SMTP, and fallback connectors that are actually used, with To, CC, BCC, Reply-To, and array or string header shapes. | CC and BCC behavior stays private and correct while string and array headers remain supported. |
| Test search and resend | Compare the WordPress input, MIME source, provider message ID, provider event, Gravity SMTP row, log search, export, resend, notification, and final inbox rendering. | Timeout, rejection, refresh, fallback, and resend branches do not lose the log or duplicate the message. |
What to check first
- Record Gravity SMTP, WordPress, PHP, mail provider, locale, database charset and collation, log retention, subject byte length, character count, and encoded header length.
- Build boundary fixtures at short, near-fold, multi-fold, and very long lengths using ASCII, accents, combining characters, RTL text, CJK, emoji, and mixed scripts.
- Send through Google, Microsoft, Zoho, Amazon SES, SMTP, and fallback connectors that are actually used, with To, CC, BCC, Reply-To, and array or string header shapes.
- Compare the WordPress input, MIME source, provider message ID, provider event, Gravity SMTP row, log search, export, resend, notification, and final inbox rendering.
- Force provider rejection, token refresh, timeout after acceptance, and fallback delivery to prove the same logical message cannot be logged zero times or resent twice.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
subject_fixture:
id: SMTP233-I18N-004
prefix: CASE-004
scripts: [latin, japanese, emoji]
characters: 148
utf8_bytes: 312
expected_logs: 1
expected_deliveries: 1
Why this usually happens
- Byte length is used where the log store or header encoder expects a character-aware boundary.
- Header folding splits an encoded word at an invalid position.
- The provider accepts the message before a logging exception ends the WordPress request.
- Search normalizes the typed query differently from the stored Unicode string.
Decision rule
Approve the update when every supported subject remains valid and searchable from WordPress through the provider and inbox, while failure handling produces one durable log and no duplicate delivery.
Production verification checklist
- Both fixture markers survive the original subject, encoded source, Gravity SMTP log, provider event, and inbox display.
- Log search and export find each multilingual message without replacement characters or silent truncation.
- CC and BCC behavior stays private and correct while string and array headers remain supported.
- Timeout, rejection, refresh, fallback, and resend branches do not lose the log or duplicate the message.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Build boundary subjects
- Send through real connectors
- Compare encoded and stored text
- Test search and resend
- Prove retry deduplication
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test multilingual WordPress email.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references