{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/decode-encoded-words-only-where-message-header-syntax-allows-them/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/",
        "slug": "decode-encoded-words-only-where-message-header-syntax-allows-them",
        "url": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/decode-encoded-words-only-where-message-header-syntax-allows-them/"
        },
        "title": "Decode encoded-words only where message header syntax allows them",
        "summary": "Use RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "briefing",
            "name": "Briefing"
        },
        "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:17:05+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 614,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text",
        "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 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text",
            "url": "https://www.rfc-editor.org/rfc/rfc2047.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 resolve one bounded operational decision: Decode encoded-words only where message header syntax allows them. 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/rfc2047.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>Encoded-words are allowed only in specified text fields, comments, and phrase words; they are forbidden in addr-specs, quoted strings, Received fields, and MIME parameters. The research record locates this support at <strong>Section 5 (Use of encoded-words in message headers)</strong>.</li>\n<li>A reader first parses each header according to that field&#8217;s syntax, then recognizes encoded-words only in the locations that syntax permits. The research record locates this support at <strong>Section 6.1 (Recognition of encoded-words in message headers)</strong>.</li>\n<li>Decoded display occurs after a structured field has been parsed into tokens; decoding cannot safely turn the header into new parseable syntax. The research record locates this support at <strong>Section 6.2 (Display of encoded-words)</strong>.</li>\n</ul>\n<p>Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source&#8217;s stated conditions.</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 5 (Use of encoded-words in message headers)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 6.1 (Recognition of encoded-words in message headers)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 6.2 (Display of encoded-words)</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. Anchor the review in the cited section and keep observation separate from interpretation. 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>Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets.</p>\n<h2>Verification and evidence</h2>\n<p>Keep the source locations <strong>Section 5 (Use of encoded-words in message headers)</strong>; <strong>Section 6.1 (Recognition of encoded-words in message headers)</strong>; <strong>Section 6.2 (Display of encoded-words)</strong> adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.</p>\n<p>Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc2047.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Use this document to resolve one bounded operational decision: Decode encoded-words only where message header syntax allows them. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nEncoded-words are allowed only in specified text fields, comments, and phrase words; they are forbidden in addr-specs, quoted strings, Received fields, and MIME parameters. The research record locates this support at Section 5 (Use of encoded-words in message headers).\nA reader first parses each header according to that field’s syntax, then recognizes encoded-words only in the locations that syntax permits. The research record locates this support at Section 6.1 (Recognition of encoded-words in message headers).\nDecoded display occurs after a structured field has been parsed into tokens; decoding cannot safely turn the header into new parseable syntax. The research record locates this support at Section 6.2 (Display of encoded-words).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\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 5 (Use of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 6.1 (Recognition of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 6.2 (Display of encoded-words), 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. Anchor the review in the cited section and keep observation separate from interpretation. 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.\nTranslate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets.\nVerification and evidence\nKeep the source locations Section 5 (Use of encoded-words in message headers); Section 6.1 (Recognition of encoded-words in message headers); Section 6.2 (Display of encoded-words) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\nOfficial references\n\nRFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Use this document to resolve one bounded operational decision: Decode encoded-words only where message header syntax allows them. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- Encoded-words are allowed only in specified text fields, comments, and phrase words; they are forbidden in addr-specs, quoted strings, Received fields, and MIME parameters. The research record locates this support at Section 5 (Use of encoded-words in message headers).\n\n- A reader first parses each header according to that field’s syntax, then recognizes encoded-words only in the locations that syntax permits. The research record locates this support at Section 6.1 (Recognition of encoded-words in message headers).\n\n- Decoded display occurs after a structured field has been parsed into tokens; decoding cannot safely turn the header into new parseable syntax. The research record locates this support at Section 6.2 (Display of encoded-words).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\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 5 (Use of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 6.1 (Recognition of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 6.2 (Display of encoded-words), 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. Anchor the review in the cited section and keep observation separate from interpretation. 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\nTranslate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets.\n\n## Verification and evidence\n\nKeep the source locations Section 5 (Use of encoded-words in message headers); Section 6.1 (Recognition of encoded-words in message headers); Section 6.2 (Display of encoded-words) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\n\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\n\n## Official references\n\n- [RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047.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/decode-encoded-words-only-where-message-header-syntax-allows-them/",
                "url": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Decode encoded-words only where message header syntax allows them",
                        "item": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/#article",
                "identifier": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/",
                "url": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/",
                "headline": "Decode encoded-words only where message header syntax allows them",
                "description": "Use RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text to review this narrow operational…",
                "abstract": "Use RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Use this document to resolve one bounded operational decision: Decode encoded-words only where message header syntax allows them. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nEncoded-words are allowed only in specified text fields, comments, and phrase words; they are forbidden in addr-specs, quoted strings, Received fields, and MIME parameters. The research record locates this support at Section 5 (Use of encoded-words in message headers).\nA reader first parses each header according to that field’s syntax, then recognizes encoded-words only in the locations that syntax permits. The research record locates this support at Section 6.1 (Recognition of encoded-words in message headers).\nDecoded display occurs after a structured field has been parsed into tokens; decoding cannot safely turn the header into new parseable syntax. The research record locates this support at Section 6.2 (Display of encoded-words).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\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 5 (Use of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 6.1 (Recognition of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 6.2 (Display of encoded-words), 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. Anchor the review in the cited section and keep observation separate from interpretation. 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.\nTranslate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets.\nVerification and evidence\nKeep the source locations Section 5 (Use of encoded-words in message headers); Section 6.1 (Recognition of encoded-words in message headers); Section 6.2 (Display of encoded-words) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\nOfficial references\n\nRFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:17:05+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/"
                },
                "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/decode-encoded-words-only-where-message-header-syntax-allows-them/#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": "Decode encoded-words only where message header syntax allows them"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Briefing",
                    "Advisory priority"
                ],
                "genre": "Briefing",
                "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": 614,
                "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 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text",
                    "url": "https://www.rfc-editor.org/rfc/rfc2047.html"
                }
            }
        ]
    }
}