{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
        "slug": "negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time",
        "url": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/"
        },
        "title": "Negotiate requested DSN outcomes and returned content at SMTP time",
        "summary": "Use RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "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:57+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 641,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)",
        "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 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)",
            "url": "https://www.rfc-editor.org/rfc/rfc3461.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>Use this document to connect an official requirement or behavior to observable evidence: Negotiate requested DSN outcomes and returned content at SMTP time. 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/rfc3461.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>The RCPT NOTIFY parameter requests DSNs for SUCCESS, FAILURE, or DELAY; NEVER must appear alone and requests no DSN for that recipient. The research record locates this support at <strong>Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command)</strong>.</li>\n<li>The RCPT ORCPT parameter preserves the original recipient address that corresponds to the actual delivery recipient. The research record locates this support at <strong>Section 4.2 (The ORCPT parameter to the ESMTP RCPT command)</strong>.</li>\n<li>The MAIL RET parameter requests either the full message or only its headers in a failed DSN; it does not apply when no recipient failed. The research record locates this support at <strong>Section 4.3 (The RET parameter of the ESMTP MAIL command)</strong>.</li>\n</ul>\n<p>The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee.</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 4.1 (The NOTIFY parameter of the ESMTP RCPT command)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 4.2 (The ORCPT parameter to the ESMTP RCPT command)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 4.3 (The RET parameter of the ESMTP MAIL command)</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. Make the source, asset scope, owner, and expected outcome explicit in the review record. 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>For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.</p>\n<h2>Verification and evidence</h2>\n<p>A reviewer should be able to retrace the decision from <strong>Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command)</strong>; <strong>Section 4.2 (The ORCPT parameter to the ESMTP RCPT command)</strong>; <strong>Section 4.3 (The RET parameter of the ESMTP MAIL command)</strong> through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents.</p>\n<p>Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today&#8217;s observation is not a continuing guarantee.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc3461.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Use this document to connect an official requirement or behavior to observable evidence: Negotiate requested DSN outcomes and returned content at SMTP time. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe RCPT NOTIFY parameter requests DSNs for SUCCESS, FAILURE, or DELAY; NEVER must appear alone and requests no DSN for that recipient. The research record locates this support at Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command).\nThe RCPT ORCPT parameter preserves the original recipient address that corresponds to the actual delivery recipient. The research record locates this support at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command).\nThe MAIL RET parameter requests either the full message or only its headers in a failed DSN; it does not apply when no recipient failed. The research record locates this support at Section 4.3 (The RET parameter of the ESMTP MAIL command).\n\nThe source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee.\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 4.1 (The NOTIFY parameter of the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 4.3 (The RET parameter of the ESMTP MAIL command), 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. Make the source, asset scope, owner, and expected outcome explicit in the review record. 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.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nA reviewer should be able to retrace the decision from Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command); Section 4.2 (The ORCPT parameter to the ESMTP RCPT command); Section 4.3 (The RET parameter of the ESMTP MAIL command) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Use this document to connect an official requirement or behavior to observable evidence: Negotiate requested DSN outcomes and returned content at SMTP time. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)](https://www.rfc-editor.org/rfc/rfc3461.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- The RCPT NOTIFY parameter requests DSNs for SUCCESS, FAILURE, or DELAY; NEVER must appear alone and requests no DSN for that recipient. The research record locates this support at Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command).\n\n- The RCPT ORCPT parameter preserves the original recipient address that corresponds to the actual delivery recipient. The research record locates this support at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command).\n\n- The MAIL RET parameter requests either the full message or only its headers in a failed DSN; it does not apply when no recipient failed. The research record locates this support at Section 4.3 (The RET parameter of the ESMTP MAIL command).\n\nThe source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee.\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 4.1 (The NOTIFY parameter of the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 4.3 (The RET parameter of the ESMTP MAIL command), 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. Make the source, asset scope, owner, and expected outcome explicit in the review record. 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\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\n\n## Verification and evidence\n\nA reviewer should be able to retrace the decision from Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command); Section 4.2 (The ORCPT parameter to the ESMTP RCPT command); Section 4.3 (The RET parameter of the ESMTP MAIL command) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents.\n\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\n\n## Official references\n\n- [RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)](https://www.rfc-editor.org/rfc/rfc3461.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/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
                "url": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Negotiate requested DSN outcomes and returned content at SMTP time",
                        "item": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/#article",
                "identifier": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
                "url": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/",
                "headline": "Negotiate requested DSN outcomes and returned content at SMTP time",
                "description": "Use RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) to review this narrow operational…",
                "abstract": "Use RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Use this document to connect an official requirement or behavior to observable evidence: Negotiate requested DSN outcomes and returned content at SMTP time. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe RCPT NOTIFY parameter requests DSNs for SUCCESS, FAILURE, or DELAY; NEVER must appear alone and requests no DSN for that recipient. The research record locates this support at Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command).\nThe RCPT ORCPT parameter preserves the original recipient address that corresponds to the actual delivery recipient. The research record locates this support at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command).\nThe MAIL RET parameter requests either the full message or only its headers in a failed DSN; it does not apply when no recipient failed. The research record locates this support at Section 4.3 (The RET parameter of the ESMTP MAIL command).\n\nThe source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee.\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 4.1 (The NOTIFY parameter of the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 4.3 (The RET parameter of the ESMTP MAIL command), 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. Make the source, asset scope, owner, and expected outcome explicit in the review record. 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.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nA reviewer should be able to retrace the decision from Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command); Section 4.2 (The ORCPT parameter to the ESMTP RCPT command); Section 4.3 (The RET parameter of the ESMTP MAIL command) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:16:57+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/"
                },
                "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/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/#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": "Negotiate requested DSN outcomes and returned content at SMTP time"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Advisory priority"
                ],
                "genre": "Guide",
                "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": 641,
                "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 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)",
                    "url": "https://www.rfc-editor.org/rfc/rfc3461.html"
                }
            }
        ]
    }
}