作成者: roroi_ng

メールのヘッダーって一度に受け取る情報が多くて苦手。
例えば下記のようなもの

<hornertsukada@sikaku.com>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <〇@□.net>
Received: (qmail 31328 invoked from network); 2 Feb 2021 16:34:11 +0900
Received: from unknown (HELO ?118.47.236.▲?) (118.47.236.▲)
  by mail.val.co.jp with SMTP; 2 Feb 2021 16:34:11 +0900
Message-ID: <4B9A42455D939D5A8B53544C828C4B9A@ROR8C5ND8V>
From: <〇@□.net>
To: <hornertsukada@sikaku.com>

メールのヘッダーの読み解き方としては、下から上へと読み解いていくのが基本なので、
上記の場合、To,From,Message-ID....から読んでいく。
個人的に苦手なのが、Receivedから。
改めて調べてみたところ、Receivedは中継しているサーバーのホストやIPを指す。
上記の場合はIP。
さらに上のRecivedはqmail っていうMTAによって送信されていることを指している。
Return-Path、はメールのエラーが発生したときに通知されるメールアドレス。
上記の場合は、<〇@□.net>

ちなみの上記はエラーメールであり存在しないアカウントに送信したために送られてきた
Sorry, no mailbox here by that name. (#5.1.1)

このメールを例にしたのは最近、偽セクストーションメールが流行っているからだ。
https://twitter.com/ipa_anshin/status/1349590829225021440

適当なメールアドレスを入手してそれを送信元のメールにして、
送信先の相手に恐喝する内容が記載されている。

偽セクストーションメールついては基本的には無視していいんだけど、
アカウントを乗っ取られた可能性や中身に該当するものが場合不安になる人が多いんだそう。
でも大抵はヘッダーを見ると送信元のホストから詐称メールとわかる。

とはいえ、メールアカウントを知られた時点で詐称メールに利用されるのは勘弁だな。
企業とかの場合信用がさがるし。

参考
メールのヘッダ情報の読み方
https://blog.heteml.jp/?p=4897
しつこいウイルスメールへの対処法～Fromを詐称されたメールから送信元を特定
https://www.itmedia.co.jp/broadband/0302/27/lp23.html
あるスパム送信者の環境
https://inuz.hatenablog.com/entry/20060303/p1

ansibleでpostfixを立ち上げようとしても受信ができるが送信はできない。エラーはタイトルの通り。
色々調べてみてたどり着いたのは下記サイト。
ネームサーバー障害なのか。ansibleの使い方が悪かったのか。。。
4日ぐらい行き詰ってるのでメモ
https://fumiyas.github.io/2014/12/19/users-in-nss-failure.postfix-advent-calendar.html

マウントしているディスクについては　df -Tで確認できるけど
マウントされていないディスクについて確認するのが困った。

parted -lで対象のディスクを見る方法もあるが、
blkidコマンドで確認しやすいと思う。

blkid 対象のディスク
例
root@vds05:~# blkid /dev/sda1
/dev/sda1: UUID="a3867239-aa78-4444-8fa2-e64c90c25898" TYPE="ext2"

今まで自分はネームサーバーの存在意義についてよくわからなかった。
ネームサーバーとは一般的にDNSのことを指し、DNSとはドメインとIPを結び付けるものといわれている。
なので、DNSとは、ドメイン＝IPだと思っていて、Aレコード＝DNSと考えていたからだ。
もちろんドメインの使い道はwebサーバーだけじゃないのはわかってたけど。

ネームサーバーはどちらかというと、対象のドメインのレコードを知るための手がかりで、
その手掛かりとしてIPを利用していると思うようにする。
つまりネームサーバーに利用するIPは対象のドメインの各レコードの情報知るための住所。

ややこしいところとしては、各レコードのIPを知りたいのに、それを知る手段がIPだということ。
仮にDNSがIPとかじゃなくて、DPとか違う言い方だったら悩まずに済んだかもしれない。

PacletiXVPNを利用すれば、レイヤー2でVPNを構築するためプロトコルを気にせずに通信ができるそう。
例えば、ポート25が閉じられていて対象のリモートサーバーにメールを飛ばせない時は、
ポート443からメールを飛ばせるようなことができる。

PacletiXVPNはGUI上で操作できるため初心者でも容易だそうな。

なおVPNはトンネリングと暗号化で成り立っており、トンネリングは、
パケットAでしか通せない情報をパケットBも通すためにカプセル化すること。
暗号化はパケット内の情報を第三者にみせないこと。

カプセル化ってものをいつかやってみたい。

lxc-start -d -n <<vmname>>　でエラーが発生することがあった。
気になるところは、
/var/lib/lxc/vmtest/rootfs　をマウントすると出来ないが、
マウントを外すとアタッチすることができた。

どうやら、マウントをする前にlxcをクリエイトしてしまったことが問題だった。
つまり、論理ボリューム上ではなく、サーバーのホスト内にlxcを作成してしまったため、
マウント後の　/var/lib/lxc/vmtest/rootfs　のディレクトリ以下は何も作成されていない状態であった。
もちろんマウントを外すと上記のディレクトリ以下にはファイルがあるためlxcがスタートできる。
なので、論理ボリューム上にlxcを作成したいなら先にマウント先のディレクトリを作ろう

自分が利用しているサーバーのOSがCentOSとかubuntuとか確認したい場合がある。

これまでは下記コマンドでCentOSかubuntuかを確認していた。
CentOSの場合なら下記ファイルが存在するかしないとか

cat /etc/redhat-release

ubuntuの場合なら

cat /etc/os-release

改めてググってみると下記コマンドでよかった

cat /etc/issue

ただし、/etc/issueってログイン前のメッセージを表示するらしいので、
場合によっては表示されない可能性あり