Submission（ポート587）

この用語をシェア

Submissionとは

Submission（メール投稿）は、メールクライアントからメールサーバーへのメール送信に使用される専用のプロトコルです。RFC 6409（旧RFC 4409）で標準化され、ポート587を使用します。従来のSMTPポート25が「サーバー間の配送」を担うのに対し、Submissionは「メールクライアントからサーバーへの投稿」という役割に特化して切り出された仕組みです。認証（SMTP AUTH）と暗号化を前提とした設計となっており、なりすまし送信や不正リレーを防止しつつ、セキュアなメール送信を実現します。

Submissionが生まれた背景には、1990年代後半から広がったISPによるポート25ブロッキング（OP25B）とスパム対策があります。ポート25を無条件に開放していると、ボットネットやマルウェアに感染した端末が第三者中継の踏み台にされやすいため、「認証済みユーザーのみが使える専用の送信口」としてポート587が切り出されました。

Submissionの仕組み・技術的詳細

ポート25との役割分離

項目	ポート587（Submission）	ポート25（SMTP）
用途	クライアントからサーバーへの投稿	サーバー間通信（MTAリレー）
認証	必須（SMTP AUTH）	通常なし
暗号化	STARTTLS推奨（実質必須）	オプション
ISPブロック（OP25B）	されにくい	される可能性が高い
標準RFC	RFC 6409	RFC 5321

コマンドシーケンス例

ポート587への接続は、次のようにSTARTTLSでの暗号化アップグレードとSMTP AUTHによる認証を経てからメール送信に進みます。

S: 220 mail.example.com ESMTP Postfix (Submission)
C: EHLO client.example.com
S: 250-mail.example.com
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (TLSハンドシェイク)
C: EHLO client.example.com
C: AUTH PLAIN <base64エンコードされたuser/pass>
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<user@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<recipient@example.jp>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
...
S: 250 2.0.0 Ok: queued as 7F3A21

セキュリティ機能

• SASL認証: ユーザー名・パスワード等による送信者認証
• STARTTLS: 平文接続からの暗号化通信への切り替え
• 送信者・認証情報の整合性チェック: Postfixのreject_sender_login_mismatch等で、認証ユーザーとFromアドレスの一致を強制
• レート制限: 単位時間あたりの送信数制限によるスパム送信の防止

具体例

Postfixでの設定例

# master.cf - Submission設定
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_restrictions=reject_sender_login_mismatch
  -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,permit_sasl_authenticated,reject
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth

Docker Mailserverでの設定

Docker Mailserverでは、Submission設定がデフォルトで有効になっています。

services:
  mailserver:
    environment:
      - ENABLE_SASLAUTHD=1
      - SSL_TYPE=letsencrypt
    ports:
      - "587:587"  # Submission
      - "465:465"  # Submissions（暗黙的TLS）

メールクライアント設定例

• サーバー: mail.example.com
• ポート: 587
• 暗号化: STARTTLS
• 認証: ユーザー名・パスワード（またはOAuth 2.0）

メリット・デメリット

• メリット：ISPブロックの影響を受けにくい - OP25Bの対象外であるため、一般の回線からでも安定してメール送信できる。
• メリット：認証必須で不正利用を防ぎやすい - オープンリレー化のリスクがなく、送信元を常に特定できる。
• メリット：暗号化とセットで運用しやすい - STARTTLSまたは暗黙的TLS（465）と組み合わせることが前提のため、平文送信を避けやすい設計になっている。
• デメリット：認証情報の管理が必要 - SASLバックエンド（Dovecot等）の構築・保守コストが発生する。
• デメリット：クライアント設定の手間 - ユーザーごとにポート・暗号化方式・認証情報を正しく設定する必要がある。

類似技術との違い：SSL・TLS・STARTTLSの位置づけ

方式	概要	Submissionでの位置づけ
SSL（旧世代）	TLSの前身。既知の脆弱性により非推奨	現在は使用しない
TLS（暗黙的/ポート465）	接続開始時から暗号化	RFC 8314で推奨。Submissionsと呼ばれる
STARTTLS（ポート587）	平文接続後に暗号化へアップグレード	従来からのSubmission標準方式

実務での活用シーン・導入時の注意点

• 社外からのメール送信の標準経路: 在宅勤務や外出先など、動的IPアドレスの回線からメールを送信する場合、Submissionが実質的に唯一の安定した手段です。
• グループウェア・業務システムからの送信: 社内システムがメール送信機能を持つ場合も、ポート25直送ではなく認証付きSubmission経由にすることで到達率とセキュリティが向上します。
• 注意点：認証情報の管理体制: 退職者・異動者のSASLアカウントを放置すると、不正送信の踏み台になるリスクがあるため、アカウントのライフサイクル管理を徹底します。
• 注意点：ポート465への移行検討: RFC 8314でポート465（暗黙的TLS）が推奨されているため、新規構築時は587と465の両対応、あるいは465優先の案内を検討します。
• 注意点：送信ドメイン認証との併用: Submissionで認証されたメールであっても、受信側での信頼性を高めるにはDKIM署名の付与が別途必要です。

関連ブログ記事

• Docker Mailserver完全ガイド
• メール認証技術SPF/DKIM/DMARC

まとめ

Submission（ポート587）は、クライアントからのメール送信に特化した安全なプロトコルです。認証と暗号化を前提とした設計により、不正なメール送信やなりすましを防止します。自社メールサーバーを構築する際は、ポート25（サーバー間通信用）とポート587/465（クライアント投稿用）を明確に分離し、SASL認証とTLS暗号化を必ずセットで設定することが重要です。

よくある質問（FAQ）

この用語についてもっと詳しく

Submissionに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。