5
理論的には、Request For Comments（RFC）のセットには、開発者がSMTPクライアントを構築するために知る必要があるすべてが含まれています。しかし、どのRFCを考慮する必要があり、どのRFCを無視できるかを知ることは必ずしも容易ではありません。SMTPクライアントの開発にはどのようなRFCを考慮する必要がありますか？
これを介して開発者を誘導するRFCロードマップを持っている人はいますか？ RFCのロードマップでは、私は意味：
- に必要なRFCの完全なリストを読み理解することが、 するために、SMTPクライアントを開発します。
- が置き換えられたため、 を考慮する必要がなくなったRFCの表示。
- 関連するRFCの要約。
- 関連するRFCの相互関係の詳細。
- への論理的順序の指示は、関連する RFCを読んで理解しています。
これは本当に私が質問した理由です。 RFCに集中するのはあまりにも簡単ですが、後で大部分またはすべてが別のRFCに取って代わられていることがわかります。もちろん、SMTPサーバーがRFCを実装するとき、遅れの問題があります。その実装の遅れのために、標準設定の用語では、それらが置き換えられていても、古いRFCに含まれているものを忘れないようにする必要があることがあります。 –
これらの新しいRFCが古い言語を明確にし、より完全であるという利点があります。スパムエンジンやMTAではなく、SMTPクライアントを構築するだけなので、これで必要なものはほぼすべてです。これは、あなたの文章がMTAやスパムエンジンと言っているとはるかに複雑になります。多くの迷惑メール対策技術は公開されていますが、多くは – LamonteCristo
ではありません。新しいバージョンでは、変更された内容と（もしあれば）どのように適応すべきかが概説されています。古いRFCが廃止されると、新しいRFCに固執するのはかなり安全です。 – tripleee