回答編集履歴
2
追記
test
CHANGED
@@ -43,3 +43,105 @@
|
|
43
43
|
|
44
44
|
|
45
45
|
ただし、そもそもSTARTTLSははじめに平文通信を利用してSTARTTLS対応の確認を行いますので、その時点での安全性は担保されていません。
|
46
|
+
|
47
|
+
|
48
|
+
|
49
|
+
|
50
|
+
|
51
|
+
# 2017.06.01. 23:20 頃の追記
|
52
|
+
|
53
|
+
|
54
|
+
|
55
|
+
> ①MTA同士の暗号化においては、SMTP over SSLは使用されず、使用されるのであれば、SMTP STARTTLSが使用されるという認識で合っていますでしょうか。
|
56
|
+
|
57
|
+
|
58
|
+
|
59
|
+
これは「送信サーバ側の設定(ポリシー)による」というのが回答になります。
|
60
|
+
|
61
|
+
|
62
|
+
|
63
|
+
ただ現実的に送信側のサーバは特定のサーバあてのみ送信するわけでなく様々なサーバあてに送信することになるはずなので、相手先が SMTP over SSL である前提の送信方法よりも、相手に合わせる方法であるSTARTSSLの方が都合がいいことは多いでしょう。
|
64
|
+
|
65
|
+
|
66
|
+
|
67
|
+
|
68
|
+
|
69
|
+
> ②頂いた1つ目のリンク先を参照すると、SSLの証明書については、Submission用にはオレオレ証明書もありだが、受信MTAとしてはきちんと購入しましょうとあります。これは何か理由があるのでしょうか?
|
70
|
+
|
71
|
+
|
72
|
+
|
73
|
+
ここを理解するためにはSSL証明書がどのように有効性が確認されるのかを理解している必要がありますが、ご存知でしょうか。
|
74
|
+
|
75
|
+
|
76
|
+
|
77
|
+
|
78
|
+
|
79
|
+
## SSL証明書の有効性確認の仕組みについて
|
80
|
+
|
81
|
+
|
82
|
+
|
83
|
+
少し端折りますが。
|
84
|
+
|
85
|
+
一般的にSSL(TLS)証明書は、信頼されている認証局(CA)により署名された証明書であることが確認されます。
|
86
|
+
|
87
|
+
信頼されている認証局は、あらかじめ各サーバで設定されています。
|
88
|
+
|
89
|
+
例えば Symantec(旧VeriSign)で購入したSSL証明書が設定されているWebサイトをブラウザで閲覧した際、鍵マークが表示されるのは
|
90
|
+
|
91
|
+
|
92
|
+
|
93
|
+
- 「その証明書が有効である」とブラウザが判断したから
|
94
|
+
|
95
|
+
|
96
|
+
|
97
|
+
であり、判断理由は
|
98
|
+
|
99
|
+
|
100
|
+
|
101
|
+
- ブラウザが信頼している認証局による署名がある証明書だから
|
102
|
+
|
103
|
+
|
104
|
+
|
105
|
+
です。
|
106
|
+
|
107
|
+
同様にオレオレ証明書(自己署名証明書)が設定されているWebサイトを表示した際は、特に設定をいじっていない限り安全ではないサイトとされますが、これは
|
108
|
+
|
109
|
+
|
110
|
+
|
111
|
+
- ブラウザが信頼している認証局による署名が**ない**証明書だから
|
112
|
+
|
113
|
+
|
114
|
+
|
115
|
+
です。
|
116
|
+
|
117
|
+
これを「安全」と判断させるためには、その証明書を署名した証明書を「信頼する認証局」として登録することが必要になります。
|
118
|
+
|
119
|
+
|
120
|
+
|
121
|
+
## その上で、ご質問について
|
122
|
+
|
123
|
+
|
124
|
+
|
125
|
+
追記の 1. の回答とも関係しますが、受信側のサーバも様々なサーバからメール送信が行われることになります。
|
126
|
+
|
127
|
+
|
128
|
+
|
129
|
+
この時、送信側のサーバがクライアント、受信側のサーバがサーバとして、サーバ認証をSSL証明書を利用して行います。
|
130
|
+
|
131
|
+
受信側のサーバがオレオレ証明書を利用している場合、送信側のサーバは信頼できる証明書ではないと判断し送信を中止します。
|
132
|
+
|
133
|
+
これを回避するためには送信される可能性があるすべてのSMTPサーバにそのオレオレ証明書を信頼してもらう必要がありますが、これは非現実的です。
|
134
|
+
|
135
|
+
|
136
|
+
|
137
|
+
Submissionポート用はオレオレ証明書でも構わない、というのは、Submissionポートが利用されるのはメーラから送信用SMTPに利用するためであり、限られた接続元でのみ信頼できればいいものとなります。
|
138
|
+
|
139
|
+
メーラには「証明書の有効性チェックを無視する」設定があることも多いですので、その送信用SMTPサーバを利用する人の間で使い方のコンセンサスがとれていれば大きな問題にならないことも多いでしょう。
|
140
|
+
|
141
|
+
|
142
|
+
|
143
|
+
|
144
|
+
|
145
|
+
そういった背景でそのような説明がされているものと思います。
|
146
|
+
|
147
|
+
※今となっては Let's Encrypt もありますので、公開されているサーバでオレオレ証明書を利用する必要はほとんどないかと思いますが。。
|
1
書式の改善、補足
test
CHANGED
@@ -6,7 +6,7 @@
|
|
6
6
|
|
7
7
|
|
8
8
|
|
9
|
-
参考) https://blog.nhiroki.net/2014/01/18/postfix-tls-setting
|
9
|
+
参考) [https://blog.nhiroki.net/2014/01/18/postfix-tls-setting](https://blog.nhiroki.net/2014/01/18/postfix-tls-setting)
|
10
10
|
|
11
11
|
|
12
12
|
|
@@ -14,7 +14,7 @@
|
|
14
14
|
|
15
15
|
よく知られている例でいえば、Gmail などでSTARTTLSによる受信に対応し始めており、送信元のSMTPサーバがSTARTTLSに対応しておらず平文で送られてきた場合はそのメールに警告を表示するといったことを始めています。
|
16
16
|
|
17
|
-
参考) https://japan.cnet.com/article/35073528/
|
17
|
+
参考) [https://japan.cnet.com/article/35073528/](https://japan.cnet.com/article/35073528/)
|
18
18
|
|
19
19
|
|
20
20
|
|
@@ -36,4 +36,10 @@
|
|
36
36
|
|
37
37
|
|
38
38
|
|
39
|
-
①が誤りですが、 25番ポートをSTARTTLSで待ち受けることにより、送信元の対応状況に応じて平文・暗号化通信いずれかが選択されます。
|
39
|
+
①が誤りですが、 25番ポートをSTARTTLS対応で待ち受けることにより、送信元の対応状況に応じて平文・暗号化通信いずれかが選択されます。
|
40
|
+
|
41
|
+
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
ただし、そもそもSTARTTLSははじめに平文通信を利用してSTARTTLS対応の確認を行いますので、その時点での安全性は担保されていません。
|