はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? BIMIを使ってメールにロゴを表示する方法 (受信編) はじめに ウェブメールやメーラーなどでどのようなプロセスでBIMIのロゴが表示されるのかを説明します。 ここまでの詳細はウェブメールの開発者でもなければ必要のない内容なのですが、どのように表示されるのかを知ることで、送信者としてもロゴが表示されないときの原因究明の助けになればと思います。 本記事は3部作の受信編になります。 概要編: BIMIに至るまでの歴史と概要 受信編: 受信側としてロゴを表示するための技術仕様 (本記事) 送信者編: 送信側としてロゴを表示してもらう方法 受信

BIMIを使ってメールにロゴを表示する方法 (概要編) はじめに SPF、DKIM、DMARCなどのメールセキュリティの延長線上にBIMIというものがあります。BIMIは信頼できる送信元からのメールにロゴを表示するという仕組みです。まだRFCにはなっていませんが、ドラフトの作成が引き続き行われています。 BIMIを使ってロゴを表示するための仕組みを送信側、受信側の視点を交えながら説明し、また、実際にやってみてわかった苦労した点や、それをどうやって乗り越えたのか、乗り越えられなかったかなどについて、3部作で紹介します。 以前JPAAWGやJANOGで発表した「これから始めるBIMI ～メールにロゴを表示するまでの長い道のり ～」をベースに資料を最新にした内容になっています。 概要編: BIMIに至るまでの歴史と概要 (本記事) 受信編: 受信側としてロゴを表示するための技術仕様 送信者編:

DANEとは DANEとは、MTA-STS同様にメールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのものです。 受信側が宣言することで、送信サーバーに対して、 STARTTLSを必ず使う TLS1.0以上、できれば1.2以上を必ず使う DNSSECが検証できなければ配送しない 公開鍵が正しくない場合は配送しない ようにしてもらうことを、お願いする仕組みです。 MTA-STSとの違いは、送信先が正しいということの検証を、証明書のトラストチェーンでおこなうのではなく、DNSSECのトラストチェーンと公開鍵や証明書をDNSの値と比較することで正当性の検証をおこなうというところです。 設定方法 DNSSECの有効 DANEが有効になるためには、DNSSECが有効になっている必要があります。 DNSSECは自分で管理するには敷居が高いので、今回の検証では、QUA

MTA-STSとは MTA-STSとは、メールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのものです。 具体的には、受信側が、送信サーバーに対して STARTTLSを必ず使う TLS1.2以上を必ず使う 証明書が有効でなければ配送しない ようにしてもらうことを、お願いする仕組みです。 STARTTLSだけでは、何が不足なのかということについては、後ほど説明します。 例として、sender.example.comからreceiver.example.jpへのメールの配送を考えてみます。 まず、あらかじめ、receiver.example.jpのメール管理者は、自分のところのreceiver.example.jpにメールを送るときには、ちゃんと暗号化してね、とMTA-STSのポリシーでアピールしておきます。 receiver.example.jpのMTA-