Caddy L4 cannot close non-SMTP probes on 25 and 587 without stalling banner-first clients
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 65/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
調査の方向性
deploy/k8s/caddy/Caddyfile の30〜48行から着手する: この変更は、issue の結論に基づき、:25 と :587 における @x http / @x tls マッチャーとそれらの close ルートを削除し、これらのポートが無条件にプロキシするようにすることだ。削除する設定に対して、caddy-l4 の記載された挙動（layer4/routes.go の ErrMatchingTimeout とマッチャーなしフォールバックのガード）を照合し、issue #409 のサブクエストの結果を記録する。完了の意味は、Caddyfile に 25/587 上の data マッチャーが含まれておらず、プロキシレベルでのフィルタリングは代わりに CrowdSec/nginx/HAProxy から来る必要があることを計画ノートが反映していることだ。
索引モデルが issue の本文から書いたものです。
説明
The planned Caddy close rules for non-SMTP probes drop every real SMTP client. Step 2 of #409 (@x http and @x tls plus close on 25 and 587) cannot ship as written.
What I measured
A layer4 data matcher before the proxy route makes caddy-l4 read the first bytes of the client before it forwards the connection. A router with a matcher that still needs data skips the matcherless fallback. Real SMTP clients wait for the banner, so no bytes arrive. The 3 s matching_timeout hits, and the server closes the connection instead of proxying it.
I built Caddy v2.11.7 with github.com/mholt/caddy-l4 and ran the planned config in front of a banner-first backend:
:18025 {
@http http
@tls tls
route @http @tls {
close
}
route {
proxy 127.0.0.1:18026
}
}
| Client | Result |
|---|---|
| Passive client, waits for the banner (all real SMTP clients) | closed after 3.00 s, no banner |
| HTTP probe | closed immediately |
| TLS probe | closed after 3.00 s |
Pre-greet EHLO (10+ bytes on one line) |
proxied, got the banner |
caddy-l4's RouteList.Compile returns nil on ErrMatchingTimeout (layer4/routes.go). Server.handle closes every connection it returns nil for (layer4/server.go). The matcherless fallback route is skipped while an earlier matcher reports ErrConsumedAllPrefetchedBytes (layer4/routes.go, the len(route.matcherSets) == 0 guard). No ordering saves the connection.
What follows
Keep :25 and :587 proxying unconditionally. The non-SMTP probe cost stays. The app-level guard from this work is what bounds it: per-IP connection limits in Redis, a deny set, and RELAY_PROXY_PROTOCOL_TIMEOUT. If proxy-level filtering is still wanted later, it needs a different tool. CrowdSec with a firewall bouncer, or nginx or HAProxy in front.
side quest: sec @x http/@x tls close routes on 25 and 587 drop every banner-first SMTP client. Cannot be implemented in caddy-l4 as planned. [deploy/k8s/caddy/Caddyfile:L30-L48]
Work reference: codingjoe/relay#409, branch codingjoe-mx-msa-connect-abuse-protection.
- 主要言語
- Python
- スター
- 4
- フォーク
- 0
- 平均マージ
- 2時間 30分
- マージ済み PR（30日）
- 165
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
codingjoe/relay のほかの issue
-
bug side quest
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
bug side quest
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
bug side quest
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
side quest test
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
side quest test
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
codingjoe/relay の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
namespace operations
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
EclipseFdn/open-vsx.org#15057 ·
メンテナーはふだん 1 日以内に返信
-
Mission statement: why this is free, in the README, Why This Exists and the wiki Home対応中かも @ChiefGyk3D が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ChiefGyk3D/Clouds-Against-Humanity#348 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
vllm-project/vime#508 ·
メンテナーはふだん 4 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信