Scribble at 2024-04-04 10:14:29 Last modified: unmodified

添付画像

Starting in 2024, we’ll require bulk senders to authenticate their emails, allow for easy unsubscription and stay under a reported spam threshold.

New Gmail protections for a safer, less spammy inbox

GMail のアカウントに向けてメールを適正に配送するための要件が出ている。あくまでも「適正に」配送するための条件であるから、これらを満たさないからといって GMail のサーバから受診を拒否されるとまではいかないわけだが、勝手に迷惑メールのフォルダへ仕分けられてしまうリスクがあるので、もちろんビジネスや公的な業務として不特定の相手へメールを送信するような用途でメール・サーバを運用している場合には、これらの要件に準拠することが望ましい。

弊社でも、僕が運用しているメール・サーバは、コーポレート・サイトと受託案件のサーバが一つある。ただ、コーポレート・サイトは問い合わせフォームからの通知をメールで社内へ配送しているわけではなく、いったんこちらでフィルタリングしてから(例の、headless chrome を使った RPA 野郎のスパムなどを除外する)Google Chat へ投稿するという手順で通知しているので、メールは僕だけが受診している。当たり前だが、GMail に配送するための要件は既に満たしているので、特に何もやることはない。そもそも、メール・サーバの設定とは別に、DNS で対応するべき SPF などの要件については、会社のドメインの MX を単独のサーバから Google Workspace に変更したときに、たとえば SPF や DMARC や DKIM に対応していないとスパム扱いになる事例が既にあったので、SPF や DKIM などは5年前ほどから対応済みである。

あと、メール・サーバで対応が必要なのは TLS でメールを送信することだが、これも古い Linux などでは初期設定がディフォールト(無効)となっているようだが、たとえば Amazon Linux 2023 の Postfix などは最初から有効になっているので、さほど心配はないだろう。ともあれ、該当するサーバからメールを GMail のアカウントに送信してみれば分かることだ。また、有効にするとは言っても "smtp_tls_security_level = may" に設定を変更してサービスをリロードすればいいだけである(そういや、Linux でも「デーモン」じゃなくて「サービス」って呼ぶ人が増えてるな)。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook