rabbit51

it's since Nov.30 2005
May.29 2014, transferred from broach

ぷららメールサービスのsmtp仕様が変更されていた

2024-07-14 13:00:00 | ネットワーク
6月25日から毎日送られてくるSynolog DS216JとDS220Jのバックアップ通知メールが届かない。
26日、27日には、DS216Jからは届いた。DS216J及びDS220Jのメール通知確認を行うと送信が出来る。様子見をしていたらDS216J及びDS220J共にメール通知がされなくなった。エラーは、認証の失敗と出てくる。時間帯により認証に失敗するのかと思っていたが全く通知されなくなったので調べてみた。

DS216J


DS220J


opensslによる手打ちメール送信は問題なく送信できる。
SMTP接続後の「auth login」の認証も問題ない。
「mail from」でぷららのメールアドレス以外のアドレスを設定するとエラーが発生。
ドメインを合わせてもエラーが発生。

ぷららの「お知らせ」を確認しに訪問。
2024年6月21日にそれらしき通知がある。実施の5日前であるがメールお知らせ通知は無かった。



「送信者認証を実施したメールアドレスとそのメールの送信者情報メールアドレスが一致するかを確認」との事。「mail from」がぷららの契約メールアカウントでないと送信できなくなった。
まあ、しょうがないか。。。いくつかのメール送信設定を変更して対応した。

2010年4月19日から実施されているらしいこの対策

「sub mission port」からの認証接続であれば、この対策はメール送信を遅くするだけなのでやめてほしい。
送信時の認証で誰がこのような送信をしているのか「ぷらら」が認識できるのでアカウント停止にすれば良いだけだと思う。

 

6月27日 「ぷらら」および「BUSINESSぷらら」の一部オプションサービス等の提供終了について」でプライベートホームページも来年2025年3月31日で終了とアナウンスされている。
ぷららISPでは、毎月契約金額相当のポイントが付与され、ポイント対象のぷららサービス(プライベートホームページ)を使ってきたのだが、ポイント対象の使いたいサービスがメールアカウント以外、無くなってきた。そろそろISPの変更を検討する必要がありそうだ。
ISP変更で一番問題なのが「メールアドレス」。悩む。。。

 
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ぷららメールで廃止されたSMTP認証CRAM-MD5と未提供のDIGEST-MD5を確認

2023-11-16 11:00:00 | ネットワーク
ぷららメールサーバーがセキュリティ対策を実施」でSMTPの認証方式「CRAM-MD5」が廃止された。暫定対策のため「 Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果」でDebian10にPostfixメールサーバーを稼働させCRAM-MD5認証でメールを受け、ぷららメールサーバーへPLAIN認証を使いTLS接続で中継させた。
平文パスワードを送信する必要がある「LOGIN」と「PLAIN」認証だけにするとは、どの様な「セキュリティ」対策なのだろうか?
「LOGIN」「PLAIN」認証より「CRAM-MD5」認証の方がよほどセキュリティが高い気がする。
「DIGEST-MD5」認証とか「OAUTH」認証とかを加えるなら理解出来るが、、、

今更だが、Postfixメールサーバーで「CRAM-MD5」と「DIGEST-MD5」の認証をsmtpコマンドレベルで確認してみた。

(1)CRAM-MD5
「CRAM-MD5」は、検索するとコマンドレベルでの確認事例が出てくる。
smtp接続後、コマンドで「auth cram-md5」で認証方法を提示すると「base64でエンコードされたチャレンジ文字列」応答がある。
チャレンジ文字列をアカウントのパスワードをkeyとしてHMAC-MD5でhashコードを生成する。
ユーザIDとhashコードをスペース連結した文字列をbase64エンコードしてチャレンジ応答とする。
CRAM-MD5でSMTP認証テスト」を参考にして掲載のシェルスクリプトをmacOS Big Sur(11.7.10)で実行したがエラーとなる。
cram-md5.sh
#!/bin/bash

if [ $# -ne 3 ]; then
  echo "構文:"
  echo "cram-md5.sh [ユーザID] [パスワード] [Base64コード]"
  exit 1
fi
USERID=${1:?}
PASSWD=${2:?}
WORD=${3:?}

function hmac-md5() {
  CODE=${1:?}
  KEY=${2:?}
# normal openssl require awk because the output is (stdin)= 'result'
#        echo "$CODE" | base64 -d  | openssl dgst -md5 -hmac "$KEY" | awk '{print $2}'
# openssl in macOS Big Sur
        echo -n "$CODE" | base64 -d  | openssl dgst -md5 -hmac "$KEY"
}

echo
echo "出力:"
echo "以下のコードを貼り付けてください"

echo
echo -n  "${USERID}" $(hmac-md5 "${WORD}" "${PASSWD}") | base64 | tr -d '\n'
echo
echo

exit 0
赤字の修正で正しいレスポンスコードが生成される。
Debian10には、「/usr/bin/gen-auth」がインストールされていた。
/usr/bin/gen-auth
gen-auth cram-md5 someone@somehost.plala.or.jp himitsunokotoba PDk1NTA5Njk2LjM0NjA3MDhAc29tZWhvc3QucGxhbGEub3IuanA+
c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==

echo -n "c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==" | base64 -d
someone@somehost.plala.or.jp 9168fff5fe4db2a00537cebb88d98870
$ openssl s_client -connect somehost.plala.or.jp:587 -starttls smtp -quiet
250 CHUNKING
auth cram-md5
334 PDk1NTA5Njk2LjM0NjA3MDhAc29tZWhvc3QucGxhbGEub3IuanA+
c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==
235 2.7.0 Authentication successful
quit
221 2.0.0 Bye

(2)DIGEST-MD5
DIGEST-MD5(RFC2831)を検索してもコマンドレベルでの確認事例を見つけられなかった。「今更ながら DIGEST-MD5 SMTP認証」が詳細にプロトコルを記載していた。これを参考にDIGEST-MD5を確認してみた(「今更ながら CRAM-MD5 SMTP認証」も参考になった)。
「今更ながらDIGEST-MD5 SMTP認証」には、パラメータ類とhash計算結果が書かれているのでmacOSのopensslを使い計算式をシュミレートしてみた。同記事 「2)レスポンスMD5ハッシュの生成」で式
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
           ":", nonce-value, ":", cnonce-value }
の H( { username-value, ":", realm-value, ":", passwd } を計算するとHEX表記で
$ echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5
0e50b2e5e12c4b08c865045a4bb780d1
記載値と一致する。この値を使い、HEX(H(A1))値を計算する
md5a1x=`echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5 -binary`
echo -n $md5a1x | od -t x1
0000000    0e  50  b2  e5  e1  2c  4b  08  c8  65  04  5a  4b  b7  80  d1
0000020
echo -n "$md5a1x:JQMKtdgbEhMra4GdAYmAjQ==:lWF{[QuiRj}_L[PW" | openssl dgst -md5
7ab35907e69a040ad638cb3cd61ba9ff
値が違う。。。
示されたハッシュ値は「46 a5 d6 cc c1 56 d8 ca 8d a9 70 72 3d 45 5d 17」
「H( { username-value, ":", realm-value, ":", passwd } )」を「HEX( H( { username-value, ":", realm-value, ":", passwd } ) )」としてハッシュ値を確認もしてみた。
$ md5a1x=`echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5`
$ echo $md5a1x
0e50b2e5e12c4b08c865045a4bb780d1
$ echo -n "$md5a1x:JQMKtdgbEhMra4GdAYmAjQ==:lWF{[QuiRj}_L[PW" | openssl dgst -md5
352faec92f18b88e728c0ae086ead7f5
やはり違うようだ。
同記事「2-2) A2 データ列の生成」の式
A2 = { "AUTHENTICATE:", digest-uri-value }は
echo -n "AUTHENTICATE:smtp/mx.example.com" | openssl dgst -md5
e7280b0554e7e6636bd6a32ec6d5d2cf
で一致する。

smtpコマンドデータを検証するため、XPS8300上のDebian10にpostfixを稼働させ、VAIO上のDebian10を使い、DIGEST-MD5認証でメール送信する設定をしたEvolutionメールツールで送信を行い、Wiresharkでsmtpコマンドをキャプチャして確認した。
auth digest-md5
334 ---challenge(base64)
--- response(base64)
334 ---- rspauth(base64)
\r\n
235 2.7.0 Authentication successful
「auth digest-md5」smtpコマンドに対しサーバーから「334 ---challenge」の応答がある。
base64デコードしてnonce値、realm値を得る。
その他のパラメータは「qop=auth,charset=utf-8,algorithm=md5-sess」。charsetの値は、「"」無し。
responseデータからcnonce値、digest-uri値を得て、opensslで確認すると、式H( { username-value, ":", realm-value, ":", passwd }は、md5バイナリー値にnonce値とcnonce値を":"で結合したデータがA1となる事が判った。 
記事のA1ハッシュ値は、
「46 a5 d6 cc c1 56 d8 ca 8d a9 70 72 3d 45 5d 17」
でなく
「7a b3 59 07 e6 9a 04 0a d6 38 cb 3c d6 1b a9 ff」
となる。従って、「2-3) response ハッシュ値の算出」のハッシュ値は、
「9a ac 0f 21 5f 22 9c f8 20 83 b8 64 72 a2 78 8d」
となる。
「KD は2つの文字列を':'で連結の意」と注釈されているが、「RFC2617の3.2.1 The WWW-Authenticate Response Header」の解説で結合後にハッシュ化した値とされている。

「2-4) サーバに返すレスポンスデータ列の生成(base64)」は、
「dXNlcm5hbWU9ImluZm8uZXhhbXBsZS5jb20iLHJlYWxtPSJleGFtcGxlLmNvbSIsbm9uY2U9IkpRTUt0ZGdiRWhNcmE0R2RBWW1BalE9PSIsY25vbmNlPSJsV0Z7W1F1aVJqfV9MW1BXIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL214LmV4YW1wbGUuY29tIixyZXNwb25zZT05YWFjMGYyMTVmMjI5Y2Y4MjA4M2I4NjQ3MmEyNzg4ZCxjaGFyc2V0PXV0Zi04」
となる。
base64デコード値は、
「username="info.example.com",realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",cnonce="lWF{[QuiRj}_L[PW",nc=00000001,qop=auth,digest-uri="smtp/mx.example.com",response=9aac0f215f229cf82083b86472a2788d,charset=utf-8」
(*charset=の値は、「"」でクォートしていない)

記事の「3)認証確認」で「クライアント側は、肯定応答をするために同じように A2 データ列を上記のものに変更したレスポンスハッシュ値を算出し、サーバ側に送り返します。」と解説されていたが、wiresharkの例では、単に「\r\n」を返すだけだった。
「rspauth」は、「A2 = { ":", digest-uri-value }」のハッシュ値(HEX)と定義されている。digest-uri-valueは、変化無いので、
「rspauth=8252052849c337d2b318ef3b11d8db83」
となる。

一応、肯定応答を記事のように作成してみた(base64)
「dXNlcm5hbWU9ImluZm8uZXhhbXBsZS5jb20iLHJlYWxtPSJleGFtcGxlLmNvbSIsbm9uY2U9IkpRTUt0ZGdiRWhNcmE0R2RBWW1BalE9PSIsY25vbmNlPSJsV0Z7W1F1aVJqfV9MW1BXIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL214LmV4YW1wbGUuY29tIixyZXNwb25zZT04MjUyMDUyODQ5YzMzN2QyYjMxOGVmM2IxMWQ4ZGI4MyxjaGFyc2V0PXV0Zi04」
base64デコード値
「username="info.example.com",realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",cnonce="lWF{[QuiRj}_L[PW",nc=00000001,qop=auth,digest-uri="smtp/mx.example.com",response=8252052849c337d2b318ef3b11d8db83,charset=utf-8」

(3)DIGEST-MD5のチャレンジレスポンス生成スクリプト
macOSで動作するperlスクリプトを作成してみた
digest-md5.pl
#!/usr/bin/perl
# digest-md5 smtpfqdn userid password challenge
#
use Digest::MD5 qw(md5 md5_hex md5_base64);
use MIME::Base64;

$fqdnhostnm=$ARGV[0];
$userid=$ARGV[1];
$password=$ARGV[2];
$chleg=decode_base64($ARGV[3]);
#----
$chleg =~ /nonce="([^"]*)"/; $nonce=$1;
$chleg =~ /realm="([^"]*)"/; $realm=$1;
$chleg =~ /qop="([^"]*)"/; $qop=$1;
$chleg =~ /charset=([^,]*)/; $charset=$1;
$chleg =~ /algorithm=([^,]*)/; $algorithm=$1;
#----
$cnonce=`openssl rand -base64 16`;
chomp $cnonce;
$md5a1=md5_hex(md5("$userid:$realm:$password"),":$nonce:$cnonce");
$digesturi="smtp/$fqdnhostnm";
$md5a2=md5_hex("AUTHENTICATE:$digesturi");
$md5a2r=md5_hex(":$digesturi");
$response=md5_hex("$md5a1:$nonce:00000001:$cnonce:$qop:$md5a2");
$rspauth=md5_hex("$md5a1:$nonce:00000001:$cnonce:$qop:$md5a2r");
$drx="username=\"$userid\",realm=\"$realm\",nonce=\"$nonce\",cnonce=\"$cnonce\",nc=00000001,qop=auth,digest-uri=\"$digesturi\",response=$response,charset=$charset";
$drxra="username=\"$userid\",realm=\"$realm\",nonce=\"$nonce\",cnonce=\"$cnonce\",nc=00000001,qop=auth,digest-uri=\"$digesturi\",response=$rspauth,charset=$charset";
print "Digest-Response: \n";
print encode_base64($drx,""),"\n";
printf("\nResponseAuth: %s\n",encode_base64($drxra,""));


(4)DIGEST-MD5のチャレンジレスポンス生成スクリプトで接続確認
openssl s_client -connect debian10.familyname:587 -starttls smtp -quiet
depth=1 CN = Private Network CA, OU = Root Certificate Authority, O = 1A72E31E-EA31-4576-AAE6-8C03A00091CD, C = JP
verify error:num=19:self signed certificate in certificate chain
verify return:0
250 CHUNKING
auth digest-md5
334 bm9uY2U9IncxNWdkdm1oeEhKMExwVmVjWWlXbzE3cDNWcmpNZCtXMVI4eWFmeXNHaEk9IixyZWFsbT0iZGViaWFuMTAuZmFtaWx5bmFtZSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPWEwMGYyN2I5NDNjZDk0Nzg4MWE1YzIwNTc0MDlmYWY3LGNoYXJzZXQ9dXRmLTg=

334 cnNwYXV0aD03NGI5Nzg1ZDkxNmUzYTYwMTcxODJhMWZjMGE1MWM2Mg==
--<RETURN KEY>--
235 2.7.0 Authentication successful
レスポンス応答は、RETURN KEYで応答した。
 ./digest-md5.pl debian10.familyname someone@somehost.plala.or.jp himitunokagi bm9uY2U9IncxNWdkdm1oeEhKMExwVmVjWWlXbzE3cDNWcmpNZCtXMVI4eWFmeXNHaEk9IixyZWFsbT0iZGViaWFuMTAuZmFtaWx5bmFtZSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
Digest-Response: 
dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPWEwMGYyN2I5NDNjZDk0Nzg4MWE1YzIwNTc0MDlmYWY3LGNoYXJzZXQ9dXRmLTg=

ResponseAuth: dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPTc0Yjk3ODVkOTE2ZTNhNjAxNzE4MmExZmMwYTUxYzYyLGNoYXJzZXQ9dXRmLTg=
レスポンス応答を「今更ながら DIGEST-MD5 SMTP認証」記載に従って応答(ResponseAuthを送信)し、認証が成功する事を確認した。

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

フレッツ光NGNのIPv6(IPoE)インターネット接続業者(VNE)とIPv6 Prefix #4

2023-09-25 23:00:00 | ネットワーク
2023年9月20日 12:34:56にフレッツのprefix情報レコードの更新が行われた。

フレッツ光NGNのIPv6(IPoE)インターネット接続業者(VNE)とIPv6 Prefix #3」と比較して調べてもprefix情報の変更が無い。

2011/01/14 12:59:13 3社VNEでPrefix/23
2013/02/04 12:14:50 3社VNEでPrefix/30に変更
2018/02/02 11:27:52 4社追加され7社VNE体制
2018/08/31 10:03:19 1社追加され8社VNE体制
2020/09/17 09:23:31 1社追加され9社VNE体制
2023/03/22 10:27:31 1社追加され10社VNE体制
2023/09/20 12:34:56 プレフィックス変更なし 謎の「0000」レコード更新
=== NgnRouteInfo ===
0000,2023/09/20 12:34:56--
1111,2404:01a8:7e00:0000:0000:0000:0000:0000/40--東日本電信電話(NTT-EAST)(JPNIC)
1211,2404:01a8:0000:0000:0000:0000:0000:0000/32--東日本電信電話(NTT-EAST)(JPNIC)
1212,2001:0c90:0000:0000:0000:0000:0000:0000/33--東日本電信電話(NTT-EAST)(JPNIC)
1311,2408:0210:0000:0000:0000:0000:0000:0000/30--東日本電信電話(NTT-EAST)(JPNIC)
1411,2400:2410:0000:0000:0000:0000:0000:0000/30--BBIX-IPv6 ソフトバンク(APNIC)
1412,2409:0010:0000:0000:0000:0000:0000:0000/30--MF-Transix-E-1 インターネット・マルチフィード(JPNIC)
1413,240b:0010:0000:0000:0000:0000:0000:0000/30--日本ネットワークイネーヴラ(JPNIC)
1414,2404:7a80:0000:0000:0000:0000:0000:0000/30--ビッグローブ(APNIC)
1415,2405:6580:0000:0000:0000:0000:0000:0000/30--朝日ネット(JPNIC)
1416,2400:4050:0000:0000:0000:0000:0000:0000/30--NTTコミュニケーションズ(OCN)(JPNIC)
1417,2401:4d40:0000:0000:0000:0000:0000:0000/30--フリービット(JPNIC)
1418,2001:0f70:0000:0000:0000:0000:0000:0000/30--アルテリア・ネットワーク(JPNIC)
1419,240b:c0c4:0000:0000:0000:0000:0000:0000/30--RAKUTEN Mobile  Network, Inc(APNIC)
1421,2406:ab48:0000:0000:0000:0000:0000:0000/30--デジタル庁(JPNIC)


 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ぷららメールサーバーがセキュリティ対策を実施

2023-09-21 10:00:00 | ネットワーク
「ぷらら」からメールサーバーのセキュリティ強化を行う通知が来た。随分と急な話だ。


メールマニュアルのリンク先を確認してみたがどのようなセキュリティ強化策か解らない。
今までと何の変化も無い。


メール送信が出来なくなったら対策を考えれば良いかと放置していたら9月11日から開始と通告が来た。

通告されても、「セキュリティ強化」がどのような対策なのか何も記述されていない。

9月11日からセキュリティ強化を実施しましたと9月14日にメールで通知された。
「CRAM-MD5」を廃止すると記載されている。
最初から「書けよ!」


ホームページにも記載された
9月14日「更新」?
いつ記載されたんだい。8月25日の日時記載があるが25日には、探しても見つからなかった。


9月20日 PR-600MIの交換後、NVR510のsystemログを確認していたら「メール送信エラー」が発生している。
ドアフォンからのメール通知も止まっている。
NVR510のSystem log
2023/09/18 15:45:27: [MAIL] Create Service State(lua, ID: 6)
2023/09/18 15:45:27: [MAIL] [11]Create Task for Waiting Event(lua, ID: 6)
2023/09/18 15:45:27: [MAIL] Create Service State(mail, ID: 41)
2023/09/18 15:45:27: [MAIL] [11]Create task for Service waiting timer(ID: 41, 1 sec)
2023/09/18 15:45:28: [MAIL] [11]Mail Wait Service Is Timeout(mail: 1 sec)
2023/09/18 15:45:28: [MAIL] Create Service State(mail, ID: 42)
2023/09/18 15:45:28: [MAIL] [11]Create Task for Connecting Server(ID: 42)
2023/09/18 15:45:28: [MAIL] [11]Wait Connecting to Server...(0)
2023/09/18 15:45:28: [MAIL] [11]Connected Mail Service Server
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "220 msc14.plala.or.jp ESMTP server ready Mon, 18 Sep 2023 15:45:29 +0900"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "EHLO v6mail.plala.or.jp"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-msc14.plala.or.jp"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-AUTH=LOGIN PLAIN CRAM-MD5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-AUTH LOGIN PLAIN CRAM-MD5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-PIPELINING"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-DSN"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-8BITMIME"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250-STARTTLS"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "250 SIZE 20971520"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "AUTH cram-md5"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "334 PDIwMjMwOTE4MDY0NTI5LlNCRkYxNjI2My5tc2MxNC5wbGFsYS5vci5qcEB2Nm1haWwucGxhbGEub3IuanA+"
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "c29tZW9uZUBzb21ld2hlcmUucGxhbGEub3IuanAgYzExNWExMjMzOWUyNTJmZDBkZDBhYjIzMGJjODAxOTE="
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "535 CRAM-MD5 not supported for someone@somewhere.plala.or.jp"
2023/09/18 15:45:28: [MAIL] Read Error(535 CRAM-MD5 not supported for someone@somewhere.plala.or.jp)
2023/09/18 15:45:28: [MAIL] [11]Mail SMTP Service Receive Error(28)
2023/09/18 15:45:28: [MAIL] [11]Send Msg: "QUIT"
2023/09/18 15:45:28: [MAIL] [11]Recv Msg: "221 msc14.plala.or.jp ESMTP server closing connection"
2023/09/18 15:45:28: [MAIL] [11]End Mail SMTP Process for Error
2023/09/18 15:45:28: [MAIL] [11]Close TCP(0)
2023/09/18 15:45:28: [MAIL] [11]Remove From Mail Service State List(mail:42)
AUTHで「LOGIN」「PLAIN」「CRAM-MD5」で認証しろと応答しているから「CRAM-MD5」で認証しようとすると「CRAM-MD5はサポートしていません」と。
何じゃこりゃ!

ぷららのIPv4メールサーバ、IPv6メールサーバーについてポート465/SSL、サブミッションポート587/startTLSについて確認してみた。
secure.plala.or.jp
$ echo -e "ehlo\nquit" | openssl s_client -4 -connect secure.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc13.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 15:14:39 +0900
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect secure.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc13.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 15:14:49 +0900
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -4 -connect secure.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect secure.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection
secureサーバは、DNSにAAAAアドレスが設定されていない。macOSのopensslは、-6指定でも勝手に-4で接続してしまう。Debian10のopensslは、「No address associated with hostname connect:errno=22」となる。「V6mail」サーバーも確認してみた
v6mail.plala.or.jp
$ echo -e "ehlo\nquit" | openssl s_client -4 -connect v6mail.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc14.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 14:48:13 +0900
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect v6mail.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc14.plala.or.jp ESMTP server ready Wed, 20 Sep 2023 14:48:25 +0900
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -4 -connect v6mail.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc14.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc14.plala.or.jp ESMTP server closing connection

$ echo -e "ehlo\nquit" | openssl s_client -6 -connect v6mail.plala.or.jp:587 -starttls smtp -quiet -crlf 2>/dev/null
250-msc13.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc13.plala.or.jp ESMTP server closing connection
「secure」サーバーも「v6mail」サーバーも実態は同じようだ。
DNS
$ host v6mail.plala.or.jp
v6mail.plala.or.jp has address 60.36.166.240
v6mail.plala.or.jp has IPv6 address 2400:7800:0:502f::240

$ host secure.plala.or.jp
secure.plala.or.jp has address 60.36.166.237
secureサーバーもIPv6対応していますとアナウンスされているがDNSのAAAAにIPv6アドレスを設定していない。誰が使えるの!

サブミッションポート587に「startTLS」なしで接続(telnet接続)してみた

一応「LOGIN」とか「PLAIN」で接続出来そう。やってみた

auth login


auth plain


「セキュリティ強化」ならこれも廃止したら?と言いたいところだ。

(2023年9月26日 追記)
セキュリティ対策されたSMTP-AUTH CRAM-MD5の振舞
someone@somewhere.plala.or.jp(存在しないユーザーID)
WAYWAYWAY(適当なパスワード)
で応答すると当然Authentificationされない。

auth cram-md5
334 PDIwMjMwOTI1MjM1NzUzLkdNS1Q2NzczLm1zYzEyLnBsYWxhLm9yLmpwQG9wZW5zc2wuY2xpZW50Lm5ldD4=
c29tZW9uZUBzb21ld2hlcmUucGxhbGEub3IuanAgYzVmYTY3MzkwYWQ4MTlmYjhmZTg1YTQwODlmMWM1YTc=
535 Authentication failed
------------------------------------------
realuser@realserver.plala.or.jp(存在するユーザーID)
WAYWAYWAY(適当なパスワード)
で応答するとパスワードが適当でも認証された時と同じ応答が返される。

auth cram-md5
334 PDIwMjMwOTI1MjM1OTMxLlNKTFkxNjI2My5tc2MxNC5wbGFsYS5vci5qcEBvcGVuc3NsLmNsaWVudC5uZXQ+
cmVhbHVzZXJAcmVhbHNlcnZlci5wbGFsYS5vci5qcCAwNWY3YTUyYmZkZDk0MDkwM2Q3NTZhNjE5MWYzM2YxYg==
535 CRAM-MD5 not supported for realuser@realserver.plala.or.jp


 

ぷららメールサーバーがセキュリティ対策を実施
Panasonic ドアフォン VL-SWH705KLのメール通知が停止した
Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果
Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果#2
ぷららメールサーバーのセキュリティ対策とPanasonicドアフォンメール通知
 
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

フレッツ光NGNのIPv6(IPoE)インターネット接続業者(VNE)とIPv6 Prefix #3

2023-06-13 17:00:00 | ネットワーク
気が付いたら2023年3月22日にIPv6(IPoE)インターネット接続業者(VNE)がまた一つ追加されていた
前回が2020年9月17日の更新だったので約2年6ヶ月ぶり



2011/01/14 12:59:13 3社VNEでPrefix/23
2013/02/04 12:14:50 3社VNEでPrefix/30に変更
2018/02/02 11:27:52 4社追加され7社VNE体制
2018/08/31 10:03:19 1社追加され8社VNE体制
2020/09/17 09:23:31 1社追加され9社VNE体制
2023/03/22 10:27:31 1社追加され10社VNE体制

=== NgnRouteInfo ===
0000,2023/03/22 10:27:31--
1111,2404:01a8:7e00:0000:0000:0000:0000:0000/40--東日本電信電話(NTT-EAST)(JPNIC)
1211,2404:01a8:0000:0000:0000:0000:0000:0000/32--東日本電信電話(NTT-EAST)(JPNIC)
1212,2001:0c90:0000:0000:0000:0000:0000:0000/33--東日本電信電話(NTT-EAST)(JPNIC)
1311,2408:0210:0000:0000:0000:0000:0000:0000/30--東日本電信電話(NTT-EAST)(JPNIC)
1411,2400:2410:0000:0000:0000:0000:0000:0000/30--BBIX-IPv6 ソフトバンク(APNIC)
1412,2409:0010:0000:0000:0000:0000:0000:0000/30--MF-Transix-E-1 インターネット・マルチフィード(JPNIC)
1413,240b:0010:0000:0000:0000:0000:0000:0000/30--日本ネットワークイネーヴラ(JPNIC)
1414,2404:7a80:0000:0000:0000:0000:0000:0000/30--ビッグローブ(APNIC)
1415,2405:6580:0000:0000:0000:0000:0000:0000/30--朝日ネット(JPNIC)
1416,2400:4050:0000:0000:0000:0000:0000:0000/30--NTTコミュニケーションズ(OCN)(JPNIC)
1417,2401:4d40:0000:0000:0000:0000:0000:0000/30--フリービット(JPNIC)
1418,2001:0f70:0000:0000:0000:0000:0000:0000/30--アルテリア・ネットワーク(JPNIC)
1419,240b:c0c4:0000:0000:0000:0000:0000:0000/30--RAKUTEN Mobile  Network, Inc(APNIC)
1421,2406:ab48:0000:0000:0000:0000:0000:0000/30--デジタル庁(JPNIC)
prefixを調べてみると「デジタル庁」。何をするのか?全国自治体向けにフレッツのprefixを配布するのか?
2023/6/14 追記:マイナ保険証読取端末用かも知れない(「マイナ保険証の資格確認はNTTの光回線」)。

「1420」が飛ばされているけどまだ追加される「VNE」があるのか?


 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする