少なくとも10年前まで、ビジネスで主に用いられる連絡手段は電子メールだったと記憶しています。多数のメーリングリストを使い分け、メールスレッドがどんどん長くなり……という経験をされた方も多いと思います。
（いわゆるグループウェアを導入している企業もあり、前職で私も利用していた時期はありますが、インターネットとのメール送受信がオプション機能で互換性がなく、困る事も多々ありました）
ひるがえって現在、SlackやTeamsに代表されるクラウドネイティブのコラボレーションツールが広く普及し、社内連絡に全くメールを使わなくなった、という方も多いことでしょう。
コミュケーションツールとしてのメールの重要度が下がり、「レガシー」な技術として顧みられる機会が少なくなるのもやむを得ないところです。
（OSSメールサーバーのpostfixがSNIに対応して複数のSSL証明書を設定できるようになったのですが、2019年頃に対応されていたにも関わらず、私も最近まで情報をキャッチできていませんでした）
（そして「なぜ複数SSL証明書を設定できる事が大事なのか」という話をするのに、とても長い前フリが必要です……）
では、これからのインフラエンジニアはメール関係の技術を学ばなくていいのでしょうか？
答えは否だと思います。
例として、ユーザー登録が必要なクラウドサービスを考えてみましょう。
多くの場合、アカウント登録にはメールアドレスを利用し、初回のユーザー確認、認証の際にユーザーへメールを送信します。
もしクラウドサービスからのメール送信に問題があり、登録しようとしているユーザーにメールが届かなければ、せっかく関心を持ってくれたユーザーを離脱させてしまうことになります。
また、クラウドサービスからの通知やメンテナンスを連絡するメールが届かない、遅延する、というトラブルもユーザーの不満や不信を招いてしまいます。
大量メール送信サービス（SendGrid等）や、AWSであればSES(Simple Email Service)を利用する事もできますが、「バウンスメールの対応」「送信アドレスのクレンジング」といった管理ができておらず、メールが送信できなくなってしまうトラブルも耳にします。
私自身もメール関係の技術は複雑でとても面倒だと思っています（苦笑）。
長年の歴史や事情が積み重なって分かりづらい上に、「スパム判定対策」などは技術なのに「相手サーバーのご機嫌次第」という理不尽な要素が入ってくるので、本当に大嫌いです（苦笑）。
それでも、まだまだメールは過去の技術にはならず、当面使われ続けるのは確実なので、私たちエンジニアも付き合っていかなければなりません。
メールは「レガシー」で脚光を浴びることも少ない技術ですが、運悪く？担当しなければならなくなったエンジニアの手助けになる情報を今後、発信していければと思います。
