メール設計ガイドライン | フューチャー株式会社

本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供する。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社（以下、フューチャー）は一切の責務を負わないものとする。 また、掲載している情報は予告なく変更する場合があるため、あらかじめご了承いただきたい。 免責事項: 有志で作成したドキュメントである フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること本ガイドラインに必ず従うことは求めて

[azumakuniyuki]

サービスでメールアドレスを扱う・一通でも送信するなら設計段階から目を通して検討・確認すべき事項が広く網羅されてて教科書かってぐらい良い文書

[yasu-osu]

各種ガイドラインをどんどん公開されて、業界全体への貢献姿勢、素晴らしいな

[csouls]

RFCに対してGoogleやMicrosoft等がどのようにサービス実装しているかを把握することは実践していないと分からないので、これは実態に即したとても素晴らしいガイドライン。ありがとうございます

[otchy210]

スクロールバーの小ささで引いて内容は読んでない。メールサーバを自前で持つなんて、とてもじゃないけど考えられない時代。牧歌的な時代に作られたプロトコルに何階建てのパッチを当ててるんだよ…。

[bluescreen]

ありがとうございます。後一つ、ARCが良くわかっていないのでよければ解説を加えてください！

[field_combat]

メール周りはマジでわからん。スパムはどうやって運営してんのか不思議で仕方がない

[kip-s]

dmarcのmermaidフローチャートふつくしい

[k-holy]

IDaaS前提とか全体的には大手向けの設計指針かな。でも大手未経験なのでありがたい。メールアドレスを会員情報から分離するのは昔からやってるけど、これ中小でも広まって欲しいなぁ。なんなら個人情報も分けてる。

[hatebu_admin]

こんだけ面倒なことになってても、なんでまだgmail発のスパムが届くんやろなあ

[masatomo-m]

1ページにまとめるとすごい量になるが、どの内容も大事なんだよな

[mayumayu_nimolove]

メールってあのメール？

[FreeCatWork]

ふむふむ、メールも奥が深いのにゃ！ボクも可愛いメールでみんなを癒しちゃうにゃ！

[degucho]

なんでこんな面倒なことになってしまったんやろなあ

[karinkon]

大事

[poi_nichijo]

無駄なく最新の情報もまとめられてる良い記事！ / 3年前に仕事でメール送信システム構築したけど、その前に見たかったー

[n2s]

大手サービスに任せず自前でサーバー構築なんて…みたいな流れになってナレッジが途絶えそうになってる中、本当にありがたい / 去年出たid:entry:4746786737972350511 もおすすめ

[stealthinu]

これはすごい力作。本で出していいレベルでは。現代のメールについてすごくよくよくまとめられてる。

[hobbiel55]

NHKに売り込もう

[sasasin_net]

徳が高い