{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
        "slug": "preserve-internationalized-addresses-in-delivery-and-disposition-reports",
        "url": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/preserve-internationalized-addresses-in-delivery-and-disposition-reports/"
        },
        "title": "Preserve internationalized addresses in delivery and disposition reports",
        "summary": "Use RFC 6533 — Internationalized Delivery Status and Disposition Notifications to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "checklist",
            "name": "Checklist"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-27T12:16:54+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 572,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 6533 — Internationalized Delivery Status and Disposition Notifications",
        "dse_recommendation": "Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards.",
        "primary_source": {
            "name": "RFC 6533 — Internationalized Delivery Status and Disposition Notifications",
            "url": "https://www.rfc-editor.org/rfc/rfc6533.html",
            "published_on": null,
            "authority": "www.rfc-editor.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Treat this document as a focused evidence review: Preserve internationalized addresses in delivery and disposition reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.</p>\n<h2>Source fact:</h2>\n<p>The official <a href=\"https://www.rfc-editor.org/rfc/rfc6533.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6533 — Internationalized Delivery Status and Disposition Notifications</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>The UTF-8 address type has native, unitext, and ASCII-safe xtext forms; native UTF-8 cannot be used through a server that lacks SMTPUTF8. The research record locates this support at <strong>Section 3 (UTF-8 Address Type)</strong>.</li>\n<li>A message/global-delivery-status part uses UTF-8 and should preserve non-ASCII recipient addresses in the native UTF-8 address form. The research record locates this support at <strong>Section 4.1 (The message/global-delivery-status Media Type)</strong>.</li>\n<li>A UTF-8 message disposition notification uses message/global-disposition-notification and converts an encoded ORCPT original recipient back to its UTF-8 address form. The research record locates this support at <strong>Section 5 (UTF-8 Message Disposition Notifications)</strong>.</li>\n</ul>\n<p>Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes.</p>\n<h2>What the source does not establish</h2>\n<p>This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>For source statement 1 at <strong>Section 3 (UTF-8 Address Type)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 4.1 (The message/global-delivery-status Media Type)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 5 (UTF-8 Message Disposition Notifications)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?</li>\n<li>Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?</li>\n<li>Who owns the decision, and which observation requires stopping, escalation, or rollback?</li>\n</ul>\n<h2>DSE recommendation:</h2>\n<p>DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.</p>\n<p>An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.</p>\n<h2>Verification and evidence</h2>\n<p>Tie each conclusion back to <strong>Section 3 (UTF-8 Address Type)</strong>; <strong>Section 4.1 (The message/global-delivery-status Media Type)</strong>; <strong>Section 5 (UTF-8 Message Disposition Notifications)</strong> and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set.</p>\n<p>Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc6533.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6533 — Internationalized Delivery Status and Disposition Notifications</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Treat this document as a focused evidence review: Preserve internationalized addresses in delivery and disposition reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6533 — Internationalized Delivery Status and Disposition Notifications from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe UTF-8 address type has native, unitext, and ASCII-safe xtext forms; native UTF-8 cannot be used through a server that lacks SMTPUTF8. The research record locates this support at Section 3 (UTF-8 Address Type).\nA message/global-delivery-status part uses UTF-8 and should preserve non-ASCII recipient addresses in the native UTF-8 address form. The research record locates this support at Section 4.1 (The message/global-delivery-status Media Type).\nA UTF-8 message disposition notification uses message/global-disposition-notification and converts an encoded ORCPT original recipient back to its UTF-8 address form. The research record locates this support at Section 5 (UTF-8 Message Disposition Notifications).\n\nDo not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Section 3 (UTF-8 Address Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.1 (The message/global-delivery-status Media Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 5 (UTF-8 Message Disposition Notifications), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\nVerification and evidence\nTie each conclusion back to Section 3 (UTF-8 Address Type); Section 4.1 (The message/global-delivery-status Media Type); Section 5 (UTF-8 Message Disposition Notifications) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set.\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\nOfficial references\n\nRFC 6533 — Internationalized Delivery Status and Disposition Notifications — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Treat this document as a focused evidence review: Preserve internationalized addresses in delivery and disposition reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 6533 — Internationalized Delivery Status and Disposition Notifications](https://www.rfc-editor.org/rfc/rfc6533.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- The UTF-8 address type has native, unitext, and ASCII-safe xtext forms; native UTF-8 cannot be used through a server that lacks SMTPUTF8. The research record locates this support at Section 3 (UTF-8 Address Type).\n\n- A message/global-delivery-status part uses UTF-8 and should preserve non-ASCII recipient addresses in the native UTF-8 address form. The research record locates this support at Section 4.1 (The message/global-delivery-status Media Type).\n\n- A UTF-8 message disposition notification uses message/global-disposition-notification and converts an encoded ORCPT original recipient back to its UTF-8 address form. The research record locates this support at Section 5 (UTF-8 Message Disposition Notifications).\n\nDo not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes.\n\n## What the source does not establish\n\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\n\n## Applicability questions\n\n- For source statement 1 at Section 3 (UTF-8 Address Type), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 4.1 (The message/global-delivery-status Media Type), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 5 (UTF-8 Message Disposition Notifications), which observable configuration, record, or test can confirm applicability here?\n\n- Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\n\n- Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\n\n- Who owns the decision, and which observation requires stopping, escalation, or rollback?\n\n## DSE recommendation:\n\nDSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\n\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\n\n## Verification and evidence\n\nTie each conclusion back to Section 3 (UTF-8 Address Type); Section 4.1 (The message/global-delivery-status Media Type); Section 5 (UTF-8 Message Disposition Notifications) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set.\n\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\n\n## Official references\n\n- [RFC 6533 — Internationalized Delivery Status and Disposition Notifications](https://www.rfc-editor.org/rfc/rfc6533.html) — RFC Editor / Internet Engineering Task Force"
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
                "url": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Preserve internationalized addresses in delivery and disposition reports",
                        "item": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/#article",
                "identifier": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
                "url": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/",
                "headline": "Preserve internationalized addresses in delivery and disposition reports",
                "description": "Use RFC 6533 — Internationalized Delivery Status and Disposition Notifications to review this narrow operational decision without extending the source…",
                "abstract": "Use RFC 6533 — Internationalized Delivery Status and Disposition Notifications to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Treat this document as a focused evidence review: Preserve internationalized addresses in delivery and disposition reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6533 — Internationalized Delivery Status and Disposition Notifications from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe UTF-8 address type has native, unitext, and ASCII-safe xtext forms; native UTF-8 cannot be used through a server that lacks SMTPUTF8. The research record locates this support at Section 3 (UTF-8 Address Type).\nA message/global-delivery-status part uses UTF-8 and should preserve non-ASCII recipient addresses in the native UTF-8 address form. The research record locates this support at Section 4.1 (The message/global-delivery-status Media Type).\nA UTF-8 message disposition notification uses message/global-disposition-notification and converts an encoded ORCPT original recipient back to its UTF-8 address form. The research record locates this support at Section 5 (UTF-8 Message Disposition Notifications).\n\nDo not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Section 3 (UTF-8 Address Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.1 (The message/global-delivery-status Media Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 5 (UTF-8 Message Disposition Notifications), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\nVerification and evidence\nTie each conclusion back to Section 3 (UTF-8 Address Type); Section 4.1 (The message/global-delivery-status Media Type); Section 5 (UTF-8 Message Disposition Notifications) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set.\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\nOfficial references\n\nRFC 6533 — Internationalized Delivery Status and Disposition Notifications — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:16:54+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Preserve internationalized addresses in delivery and disposition reports"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Checklist",
                    "Advisory priority"
                ],
                "genre": "Checklist",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 572,
                "timeRequired": "PT3M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "RFC 6533 — Internationalized Delivery Status and Disposition Notifications",
                    "url": "https://www.rfc-editor.org/rfc/rfc6533.html"
                }
            }
        ]
    }
}