タグ付けされた質問 「rfc」

私たちが持っている2つの異なるサードパーティのメール製品は、メールのMIMEソースのcontent-idヘッダーの存在に異なる反応を示しています。これにより、解決しようとしているユーザーエクスペリエンスに一貫性がなくなります。 次に例を示します。 --boundary-example Content-Location: CID:somethingatelse Content-ID: <foo4atfoo1atbar.net> Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV wbGljYXRpb24gcHJvaGliaXRlZC4A etc.. 1つのメール製品がこれを埋め込み画像として解釈します。もう1つは、これを通常の添付ファイル（埋め込みではない）として解釈します。Content-ID行を完全に削除すると、どちらの製品も添付ファイルが埋め込まれていないと見なします。 どの動作が正しいかを明確に結論付ける特定のRFCはありますか？同僚と私は、冒頭の要約で次のように述べているRFC2392をレビューしました。 電子メール内で[MIME]を使用してWebページとその 関連画像を伝達するには、HTML がメッセージに含まれる画像やその他のデータを参照できるようにするためのURLスキームが必要です。Content-IDの Uniform Resource Locator、「cid：」がその目的を果たします。[…]「cid」スキームは、メッセージの特定の本文部分を指します。通常、その使用は、参照している本文部分と同じメッセージ内の他の本文部分への参照に限定されます。「中間」スキームは、コンテンツIDのアドレスを含めることにより、指定されたメッセージ内の特定のボディパーツを指す場合もあります。 したがって、絶対的ではありませんが、すべての埋め込みアイテムはそれらを参照するためにcidを必要とするため、「通常は同じメッセージ内の他のボディパーツに限定されます」、添付ファイルには cid は必要ないと考えます、電子メール製品がcidの存在を「埋め込み意図」の指標として扱うことは合理的な動作です。 これについて確認をもらえますか？

11 email  mime  rfc 

RFC 2822（電子メールの定義）で定義されているように、78文字（CRLFを除く）を超えてはならず、998文字を超えてはなりません（SHOULD）。quoted-printableを使用すると、長い行はより多くの行に分割され、実際の改行に達するまで各行は「=」で終了します。メールが標準（78（または998）文字より長い行を含むがquoted-printableでエンコードされている場合） quoted-printableメッセージをデコードした後、受信メールクライアントに長い行があるため、これは準拠していないという議論があります。 編集：David Caryの質問のとおりに質問を明確にするために：はい、私はquote-printableでエンコードされたメールはquoted-printableと互換性があるべきであることを意味します、つまり行が76文字を超えないことを意味します。ただし、デコードされたメッセージには、この制限より長い行がある場合があります。だから私の質問です：RFC 1521を実装するクライアントソフトウェアは、quoted-printableテキストコンテンツをデコードした後、無期限に長い行を処理するはずですか？これは、これまでの両方の回答で「はい」と回答されています（ありがとう）。これは、ネチケット（RFC 1855）によって推奨されないという制限があります。しかし、Netiquetteは、行の長さを65文字に制限し、誰も守らない制限にさえしています。

9 email  rfc 

ドメインとそのネームサーバーがTLDを共有していない場合、通常、グルーレコードは使用できません。また、同じセカンドレベルドメインを共有していない場合、技術的には必要ありません。これにより、ドメインを解決するための追加の手順が必要になる場合があります。リゾルバーは、ドメインのアドレスを見つける前に、まずネームサーバーのアドレスを調べる必要があります。ただし、理論的には、これらの2つのステップよりも多くのステップを追加できます。 ここでの問題は、そのチェーンがどれだけ長く許されるかということです。 もしxyz.com用途はネームサーバns1.xyz.info、 およびxyz.info用途ネームサーバns1.xyz.co、 およびxyz.co用途ネームサーバns1.xyz.cc、 およびxyz.ccネームサーバ用途ns1.xyz.co.ukなど、...と ...本来必要な名前を解決する前に、リゾルバがもつれを解くための非常に長いチェーンになる可能性があります。 おそらく実用的な制限があると思います-BINDは非常に多くのリンクをトラバースするだけであるはずです。そうでなければ、サービス拒否の可能性があります。しかし、公式の制限はありますか？それを超えるとリゾルバーが公式に続行する必要がないいくつかのステップ？

8 domain-name-system  rfc 

アプライアンス内にイーサネットで接続されたいくつかのサブデバイスで構成されるアプライアンスを構築しています。アプライアンスはお客様のネットワークに接続します。カスタマーネットワークはプライベートIPアドレスを使用できます。内部ネットワークとのアドレスの競合が問題になります（両方のネットワークに接続されているサブデバイスが混乱します）。IPv6はオプションではありません。 IPv4アドレスを購入する必要がありますか？または、TEST-NET-3（203.0.113.0/24）などを使用して問題を回避できますか？ベストプラクティスは何ですか？

8 networking  local-area-network  ip-address  ipv4  rfc