Twitterログ: メールシステム関連
今日やっとruaも設定された。
— YAMASHITA Masayoshi (@ymstmsys) June 19, 2024
p=reject に向けてようやくスタートラインに立った感じ。
KDDIのpovoの請求書のPDFがメールで送られてきたけど、わざわざPDFを暗号化し、しかもそのパスワードは誕生日だよと本文に書いているのは、誰を何から守ろうとしているのか謎。
— YAMASHITA Masayoshi (@ymstmsys) June 12, 2024
せめて、povoと受信側MXのサーバ間でTLS通信している場合は、PDFの暗号化なんて無駄なことをやめて欲しい。
大きいほうの自社のメールドメインにようやく DMARC レコードが設定された。
— YAMASHITA Masayoshi (@ymstmsys) February 4, 2024
とりあえず none ポリシーなのは別に良いのだけど、rua が設定されてなくて草。
様々な外部サービスから送ってるメールは軒並み dmarc fail するだろうに、自ら気づける仕組みを用意したらいいのに。
企業にとって差出人部が自社の人・ドメインになりすまされたメールを受信したときは警戒感が薄れるので、B2B企業であってもDMARCの設定とフィルタリング設定は必須なんだけどねぇ…。
— YAMASHITA Masayoshi (@ymstmsys) January 31, 2024
今年8月の時点で、OCNですら p=reject で DMARC fail するメールが普通に受信フォルダに配信されていたので。。
— YAMASHITA Masayoshi (@ymstmsys) December 26, 2023
金融庁としては市民に『迷惑メールフィルターの強度を上げる』と述べるしかないけど、メールサービスを提供する電気通信事業者に対して総務省からちゃんと指導して欲しいねぇ。
— YAMASHITA Masayoshi (@ymstmsys) December 26, 2023
／
フィッシングによる不正送金被害が過去最多 金融庁と警察庁が注意喚起 - ITmedia NEWS https://t.co/GR7qTaCldc
あるいは、そもそもなりすましと同等の方法で送信されたメールをrejectしておらず、システムを変えたことでrejectするようになったとか。
— Masayoshi Yamashita (@ymstmsys) November 7, 2023
大阪市の発表にも詳細は書かれてないけど、メールの経路切替で発生ということは、メールのセキュリティゲートウェイを手前に置いたことで、後ろから見たらSPFやDMARCがfailしたとかかなぁ。
— Masayoshi Yamashita (@ymstmsys) November 7, 2023
／
大阪市宛てのメールが届かない障害、原因はセキュリティー機能の過剰反応 https://t.co/lAwBWJIcRn
記事ではAmazon Japanのドメインを例として使われているが、https://t.co/nysoZM8uazドメインは p=quarantine でDMARCが設定されているので、ちゃんとしたメールシステムを使っていれば迷惑メールに分類されるはず。
— Masayoshi Yamashita (@ymstmsys) October 3, 2023
受信ボックスに入ってくるようなら、そんなメールシステムを使うべきではない。
エンベロープ情報は基本的に偽れないと書かれているが、実際は容易に詐称できる。
— Masayoshi Yamashita (@ymstmsys) October 3, 2023
今はメール送信サービスを使うことも多く、そこを確認して詐称が同課の判定に意味があるのは、結局はDMARCがpassするパターンだけ。
記事では正規メールがSES経由で送られていることを確認しているが、意味がない。
いろいろおかしい記事。
— Masayoshi Yamashita (@ymstmsys) October 3, 2023
差出人の部分を信じてはいけないという主張はおかしいし、その主張のせいでDMARCの説明だけ中途半端な内容になっている。
他にもおかしい部分はある。以下続く
／
言葉巧みな偽メールに偽サイト、フィッシング詐欺の手口を知って真偽を見抜こう https://t.co/WkeUvksx1n
ちょっと気になったので調べてまとめました。
— Masayoshi Yamashita (@ymstmsys) September 15, 2023
DMARC導入状況の定点観測は前からやりたいと思っているものの、始めると止められなくなるのが嫌でやれていない。。
／
銀行のDMARC導入状況一覧 | ymstmsys site https://t.co/QAsbVZLGXQ
以下のツイートの件、今回発送分のメールは差出人がヤマト運輸に戻ってた。
— Masayoshi Yamashita (@ymstmsys) May 1, 2023
そりゃそうよねという感じ。https://t.co/cDS28uQRRs
DMARC も DNSSEC も、自社を守るためにやるというよりも、顧客・他社・ステークホルダーを守るためにやる必要があるのだということを理解してもらえるよう、ちゃんと説明できるようにしておこう。
— Masayoshi Yamashita (@ymstmsys) February 26, 2023
DMARC の RFC を隅々までちゃんと読み返しているけど、DMARC を展開するなら DNSSEC も真剣に検討しろと書いてあるね。https://t.co/S5MlCoucx9
— Masayoshi Yamashita (@ymstmsys) February 26, 2023
DNSSEC を導入してる企業はまだ少ない印象だし、みんな大好きな Route 53 を使ってる組織は DNSSEC をサクッと有効にすればいいのにねぇ。
ヤマトの荷物お届け予定の通知メールで、先月から特定の荷主の場合に、メールのFromの部分に荷主の名前が入るようになった。
— Masayoshi Yamashita (@ymstmsys) February 21, 2023
ヤマトのサブドメインでSPFもDKIMもpassしているので本物のメールだというのはわかるのだけど、ぱっと見では質の悪いなりすましメールにしか見えないよねぇ…。 pic.twitter.com/5Eb2rpPseh
どういうメーラーを使えば、送信ドメイン認証の検証結果を良い感じに表示してくれるのだろう。
— Masayoshi Yamashita (@ymstmsys) February 10, 2023
OutlookもThunderbirdも標準では生ヘッダを見るしか方法はないはずだし。
Gmailは少しマシだけど。
／
「ドメイン認証でフィッシングを避けられる」、過信は釣られる第一歩 https://t.co/MmiQeCK3xW
先日のJANOGでのフィッシング対策協議会の人の資料で、『DMARC は p=reject がゴールです』という目標が広く理解されれば良いのだけどなぁ。
— Masayoshi Yamashita (@ymstmsys) February 1, 2023
目標として定めれば、あとは時間をかけて少しずつ順を追って変更していけばいいのだし。
／
最新フィッシング動向と対策https://t.co/u0fGo356KW
総務省や経産省が連名でDMARC導入の要請を出してて良い感じ。
— Masayoshi Yamashita (@ymstmsys) February 1, 2023
しかも、rejectポリシーでの運用を求めているのが良い。
消費者自身が騙されないように気を付けるのは当然必要だけど、メールの生のヘッダ見ないと見破れない状態はひどかったので。https://t.co/sMPymRWQ0B
正しい。
— Masayoshi Yamashita (@ymstmsys) September 22, 2022
あと、いつもhttps://t.co/ARFZyckHeGで確認をしているけど、クオリティアのやつはかなり簡易的に結果が出るのね。
ともあれ、確認ツールが増えるのは嬉しい。(OP25Bが無ければ自分で確認するけど。)
／
メール暗号化を自動判定 「脱PPAP」に新手法: 日本経済新聞 https://t.co/yE5hbkpDlJ
メールのHeader Fromがなりすまされていることを認識したのなら、noneポリシーでもいいからDMARCを設定して欲しいねぇ。
— Masayoshi Yamashita (@ymstmsys) June 13, 2022
／
「お荷物：現金2800万円」 ヤマト運輸かたる偽メール・SMSに注意 文面例も公開 - ITmedia NEWS https://t.co/I9z6X1RO6I
ドコモ系のdDREAMSのメールシステムとか未だにMTA間通信の暗号化に対応してくれないよねぇ。
— Masayoshi Yamashita (@ymstmsys) June 1, 2022
あと、金融機関ですらシステムから自動で送信するメールが暗号化されてないことがあるし。
／
10通に1通が「盗聴」されるリスク、メールの危険な現状が明らかに https://t.co/88JNJtdEV6
メール転送のやり方だと、送信元がSPFチェックでDMARCをpassさせている場合、Gmail側ではDMARCがfailしてしまうねぇ…。
— Masayoshi Yamashita (@ymstmsys) April 16, 2022
こういうことをする人に備えて、DKIMの作成者署名を付けて送信しないといけない。
／
プロバイダーの対策に不満ならGmailに一元化を検討 : NIKKEI STYLE https://t.co/xEVZlEn8Be
PPAP関連の記事はできるだけ読むようにしてるけど、ファイルを暗号化せずにメールで送ることを推奨する記事を未だ見かけないなぁ。
— Masayoshi Yamashita (@ymstmsys) March 2, 2022
シンプルな解なのにね。
／
加速する“脱PPAP”の動きに乗り遅れないために （少しだけならば）変化を受け入れよう(ITmedia エンタープライズ)https://t.co/7YbwCDe1QO
メールのPPAPに代わり、UUTPという面倒なプロトコルが標準になりそうで危惧している…。
— Masayoshi Yamashita (@ymstmsys) June 8, 2021
U（ファイルをオンラインストレージにUpload）
U（ファイルのURLをメールで送信）
T（転送）
P（プロトコル）
このプロトコルは2番目のUをどうやって安全に行うかという点が課題で、PPAPから進歩していない。
『ファイルに対して受信者のアクセス権限を設定』する操作では、メールの送信先誤りと同程度に誤りが発生してしまうんじゃないの。。
— Masayoshi Yamashita (@ymstmsys) April 13, 2021
メールやチャットのコミュニケーションの路の上で送ればミスしにくいのにねぇ。
／
これなら脱PPAPできる、正しいファイルの送り方 https://t.co/EkMzjDWiHd
ファイルのURLをメールで安全に送れるなら、ファイル自体をメールで安全に送れば楽なのに。
— Masayoshi Yamashita (@ymstmsys) December 22, 2020
大きなファイルがメールボックスに入るのを避けることが目的なら記載の方法で良いけど。
／
【Googleドライブ編】「パスワード付きZIP」廃止、じゃあどうすりゃいいのか：Tech TIPS - https://t.co/tgMPxVOY5E
メールの受信側がSMTPSやSTARTTLSに対応していない場合、経路の暗号化を行えないが、その際の手間（代替となる安全な通信手段の用意など）は受信者側が負うべき。
— Masayoshi Yamashita (@ymstmsys) November 25, 2020
やっかいなのは、メールサーバ自体を信用できずにエンドツーエンドで機密性を確保したい場合だけど、そういうメールサーバ（サービス）は使うなとしか言えない。
— Masayoshi Yamashita (@ymstmsys) November 25, 2020
法で担保すべき部分だし。
だからこそ、守るべきものはちゃんと手間をかけて守り、そうじゃないものは手間をかけないのが一番。
— Masayoshi Yamashita (@ymstmsys) November 25, 2020
誤送信対策については、自動でPPAPをやるシステムは全くもって無意味である。
— Masayoshi Yamashita (@ymstmsys) November 25, 2020
ただ、真に誤送信対策をやるなら、ひと手間（※ダブルチェックに相当するやつ）増やす必要があるため、そんなの誰もやりたくない。
ストレージサービスを使ったとしても、人間は誤送信に相当するミスをしてしまうよね。
PPAP実施の目的は「盗聴防止」「誤送信対策」の2つに集約される。
— Masayoshi Yamashita (@ymstmsys) November 25, 2020
盗聴防止については、今の時代多くのメールサーバはSMTPSやSTARTTLSに対応しており、それらを使えば実現できるため、PPAPは不要だしPGPも要らないよね。
"https://t.co/aUX1DGkfYS"にはDMARCもSPFも設定されてるのに、そんなメールを受け取ってしまうメールシステムはひどいから使っちゃダメだよ本当に。。
— Masayoshi Yamashita (@ymstmsys) October 15, 2020
／
“2回目の現金一律給付”の偽メールに注意を 総務省が呼びかけ | NHKニュース https://t.co/XkpQBolR3N
こういうのを見ると、Gmailはほんと安全でいいなぁと思うね。
— Masayoshi Yamashita (@ymstmsys) June 2, 2020
／
自治体の問い合わせフォームを悪用する不正メール、大量すぎてGmailが誤判定 https://t.co/kmTLMEm7Pd
「申請の控えをダウンロード」みたいなボタンもあったけど、それだけでいいのにね。
— Masayoshi Yamashita (@ymstmsys) May 18, 2020
わざわざSendGridを使う必要もなくなるのに。
特別定額給付金の申請の最後で「申請の控えをメールで送信」みたいなボタンを押したら、氏名・住所・生年月日・銀行口座番号が書かれたファイルが平文メールで送られてきた。
— Masayoshi Yamashita (@ymstmsys) May 18, 2020
ファイルの暗号化は要らないけど、MTA間の通信で暗号化に対応してないメールサーバを使ってる人は自己責任なのかなぁ。
お知らせメールにはDKIMが使われていて、それは良いことではある。ただ、それによって挙げられた2点が証明されるのではなく、受信者がその2点を確認できるようにする仕組みなので、確認が必要であることを受信者に伝えるべき。そうしないと、確認なしに一文を信じる人が続出するよ。
— Masayoshi Yamashita (@ymstmsys) July 4, 2017
住信SBIネット銀行からのお知らせメールに次のような一文があった。なんだかなぁ。。（続く）
— Masayoshi Yamashita (@ymstmsys) July 4, 2017
／
※本メールには電子署名を付与しています。これにより“住信SBIネット銀行から送信された電子メールであること”と、“電子メールに改ざんが行われていないこと”が証明されます。
登録メールアドレスに+記号が使えないWebサービスに出くわすことがある。その際に「正しいメールアドレス形式で入力しろ」みたいなバリデーションメッセージが表示されて困惑する。正しい形式はRFCで定められているわけで、それに準拠していないのはそのWebサービス側なのに。
— Masayoshi Yamashita (@ymstmsys) June 16, 2015