IMAP_PROXY_URL=socks5://... -> IMAP connection đi qua SOCKS5 path.
IMAP_PROXY_URL=http://... -> IMAP connection đi qua HTTP CONNECT tunnel.
IMAP_PROXY_URL=https://... -> IMAP connection đi qua HTTPS proxy + CONNECT tunnel.
Proxy auth qua user:pass@ hoạt động cho các scheme hỗ trợ auth.
IMAP_PROXY_URL sai format hoặc scheme không hỗ trợ -> fail rõ ràng, không fallback sang direct.
Proxy auth / CONNECT / tunnel failure -> fail rõ ràng, reconnect loop vẫn tiếp tục.
Khi không set IMAP_PROXY_URL, behavior direct hiện tại không đổi.
Test matrix tối thiểu
socks5://... -> dùng SOCKS5 path.
http://... -> dùng HTTP CONNECT path.
https://... -> dùng HTTPS CONNECT path.
Proxy URL có auth -> request dùng đúng credential.
Scheme không hỗ trợ -> error rõ ràng.
Proxy URL malformed -> error rõ ràng.
Proxy tunnel/auth fail -> không direct fallback.
Proxy unset -> direct path vẫn pass như cũ.
Nếu muốn giữ scope nhỏ hơn cho v1.1 thì có thể tách thành 2 phase:
phase 1: http:// support
phase 2: https:// support
Nhưng nếu để title là Support http/https proxy for imap thì req nên chốt cả 2 scheme ngay từ đầu để tránh mismatch giữa issue title và behavior thực tế.
Đề xuất hoàn thiện requirement cho `Support http/https proxy for imap`:
## Scope
- Mở rộng `IMAP_PROXY_URL` từ SOCKS5-only thành hỗ trợ 3 scheme:
- `socks5://`
- `http://`
- `https://`
- Đây chỉ áp dụng cho IMAP ingress.
- OpenClaw HTTP client vẫn đi direct như requirement hiện tại, không kế thừa proxy hệ thống và không dùng `IMAP_PROXY_URL`.
## Contract mong muốn
- Nếu `IMAP_PROXY_URL` không set: giữ nguyên direct dial hiện tại.
- Nếu set `socks5://`: đi qua SOCKS5 proxy.
- Nếu set `http://` hoặc `https://`: đi qua HTTP CONNECT tunnel tới `IMAP_HOST:IMAP_PORT`.
- Nếu proxy URL có `user:pass@`, bridge phải dùng credential đó để authenticate với proxy.
- Với `https://`, chặng từ bridge tới proxy phải có TLS trước khi tạo CONNECT tunnel.
- Nếu URL sai format, scheme không hỗ trợ, auth lỗi, CONNECT lỗi, hoặc proxy/tunnel fail:
- current connect attempt phải fail rõ ràng,
- log phải có error đủ để debug,
- không được silently fallback sang direct dial,
- reconnect loop của watcher vẫn tiếp tục như behavior hiện tại.
## Config examples
- `IMAP_PROXY_URL="socks5://user:pass@proxy-host:port"`
- `IMAP_PROXY_URL="http://user:pass@proxy-host:port"`
- `IMAP_PROXY_URL="https://user:pass@proxy-host:port"`
## Acceptance criteria
1. `IMAP_PROXY_URL=socks5://...` -> IMAP connection đi qua SOCKS5 path.
2. `IMAP_PROXY_URL=http://...` -> IMAP connection đi qua HTTP CONNECT tunnel.
3. `IMAP_PROXY_URL=https://...` -> IMAP connection đi qua HTTPS proxy + CONNECT tunnel.
4. Proxy auth qua `user:pass@` hoạt động cho các scheme hỗ trợ auth.
5. `IMAP_PROXY_URL` sai format hoặc scheme không hỗ trợ -> fail rõ ràng, không fallback sang direct.
6. Proxy auth / CONNECT / tunnel failure -> fail rõ ràng, reconnect loop vẫn tiếp tục.
7. Khi không set `IMAP_PROXY_URL`, behavior direct hiện tại không đổi.
## Test matrix tối thiểu
1. `socks5://...` -> dùng SOCKS5 path.
2. `http://...` -> dùng HTTP CONNECT path.
3. `https://...` -> dùng HTTPS CONNECT path.
4. Proxy URL có auth -> request dùng đúng credential.
5. Scheme không hỗ trợ -> error rõ ràng.
6. Proxy URL malformed -> error rõ ràng.
7. Proxy tunnel/auth fail -> không direct fallback.
8. Proxy unset -> direct path vẫn pass như cũ.
Nếu muốn giữ scope nhỏ hơn cho v1.1 thì có thể tách thành 2 phase:
- phase 1: `http://` support
- phase 2: `https://` support
Nhưng nếu để title là `Support http/https proxy for imap` thì req nên chốt cả 2 scheme ngay từ đầu để tránh mismatch giữa issue title và behavior thực tế.
Summary: Extend IMAP_PROXY_URL to support http:// and https:// proxy schemes (via HTTP CONNECT tunnel) in addition to the existing socks5:// support.
Scope:
Refactor dialTLSViaSOCKS5 into a generic proxy dialer that handles all three schemes.
http:// — plain TCP to proxy, then HTTP CONNECT tunnel to IMAP_HOST:IMAP_PORT.
https:// — TLS to proxy first, then HTTP CONNECT tunnel to IMAP_HOST:IMAP_PORT.
socks5:// — keep existing behavior unchanged.
Proxy auth via user:pass@ in the URL for all schemes that support it.
On any proxy/tunnel failure (bad URL, unsupported scheme, auth error, CONNECT failure): fail the connection attempt explicitly with a descriptive error log — never silently fall back to direct dial.
Reconnect loop (Run) continues retrying on failure as it does today.
OpenClaw HTTP client remains direct — it does not use IMAP_PROXY_URL.
Out of scope:
System-level proxy env vars (HTTP_PROXY, HTTPS_PROXY) — not inherited.
SOCKS4 or any scheme other than socks5, http, https.
Changes to the OpenClaw outbound HTTP path.
Acceptance criteria:
IMAP_PROXY_URL=socks5://... → IMAP connection uses existing SOCKS5 path (no regression).
IMAP_PROXY_URL=http://... → IMAP connection goes through HTTP CONNECT tunnel.
IMAP_PROXY_URL=https://... → IMAP connection goes through TLS-to-proxy then CONNECT tunnel.
user:pass@ in proxy URL → credentials are used to authenticate with the proxy.
Unsupported scheme or malformed URL → clear error, no direct-dial fallback.
Note: Both http:// and https:// are included in this issue. The implementation difference is minimal (TLS before CONNECT for https), and the issue title explicitly covers both.
## Final Requirements
**Summary:** Extend `IMAP_PROXY_URL` to support `http://` and `https://` proxy schemes (via HTTP CONNECT tunnel) in addition to the existing `socks5://` support.
**Scope:**
- Refactor `dialTLSViaSOCKS5` into a generic proxy dialer that handles all three schemes.
- `http://` — plain TCP to proxy, then HTTP CONNECT tunnel to `IMAP_HOST:IMAP_PORT`.
- `https://` — TLS to proxy first, then HTTP CONNECT tunnel to `IMAP_HOST:IMAP_PORT`.
- `socks5://` — keep existing behavior unchanged.
- Proxy auth via `user:pass@` in the URL for all schemes that support it.
- On any proxy/tunnel failure (bad URL, unsupported scheme, auth error, CONNECT failure): fail the connection attempt explicitly with a descriptive error log — never silently fall back to direct dial.
- Reconnect loop (`Run`) continues retrying on failure as it does today.
- OpenClaw HTTP client remains direct — it does **not** use `IMAP_PROXY_URL`.
**Out of scope:**
- System-level proxy env vars (`HTTP_PROXY`, `HTTPS_PROXY`) — not inherited.
- SOCKS4 or any scheme other than `socks5`, `http`, `https`.
- Changes to the OpenClaw outbound HTTP path.
**Acceptance criteria:**
1. `IMAP_PROXY_URL=socks5://...` → IMAP connection uses existing SOCKS5 path (no regression).
2. `IMAP_PROXY_URL=http://...` → IMAP connection goes through HTTP CONNECT tunnel.
3. `IMAP_PROXY_URL=https://...` → IMAP connection goes through TLS-to-proxy then CONNECT tunnel.
4. `user:pass@` in proxy URL → credentials are used to authenticate with the proxy.
5. Unsupported scheme or malformed URL → clear error, no direct-dial fallback.
6. Proxy auth / CONNECT / tunnel failure → clear error log, reconnect loop continues.
7. `IMAP_PROXY_URL` unset → existing direct-dial behavior unchanged.
**Test matrix (minimum):**
| # | Scenario | Expected |
|---|----------|----------|
| 1 | `socks5://...` | SOCKS5 path |
| 2 | `http://...` | HTTP CONNECT path |
| 3 | `https://...` | HTTPS CONNECT path |
| 4 | URL with `user:pass@` | Auth credentials used |
| 5 | Unsupported scheme (e.g. `ftp://`) | Clear error, no fallback |
| 6 | Malformed URL | Clear error, no fallback |
| 7 | Proxy/tunnel failure | Error logged, no direct fallback |
| 8 | `IMAP_PROXY_URL` empty/unset | Direct dial, no regression |
> **Note:** Both `http://` and `https://` are included in this issue. The implementation difference is minimal (TLS before CONNECT for `https`), and the issue title explicitly covers both.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Đề xuất hoàn thiện requirement cho
Support http/https proxy for imap:Scope
IMAP_PROXY_URLtừ SOCKS5-only thành hỗ trợ 3 scheme:socks5://http://https://IMAP_PROXY_URL.Contract mong muốn
IMAP_PROXY_URLkhông set: giữ nguyên direct dial hiện tại.socks5://: đi qua SOCKS5 proxy.http://hoặchttps://: đi qua HTTP CONNECT tunnel tớiIMAP_HOST:IMAP_PORT.user:pass@, bridge phải dùng credential đó để authenticate với proxy.https://, chặng từ bridge tới proxy phải có TLS trước khi tạo CONNECT tunnel.Config examples
IMAP_PROXY_URL="socks5://user:pass@proxy-host:port"IMAP_PROXY_URL="http://user:pass@proxy-host:port"IMAP_PROXY_URL="https://user:pass@proxy-host:port"Acceptance criteria
IMAP_PROXY_URL=socks5://...-> IMAP connection đi qua SOCKS5 path.IMAP_PROXY_URL=http://...-> IMAP connection đi qua HTTP CONNECT tunnel.IMAP_PROXY_URL=https://...-> IMAP connection đi qua HTTPS proxy + CONNECT tunnel.user:pass@hoạt động cho các scheme hỗ trợ auth.IMAP_PROXY_URLsai format hoặc scheme không hỗ trợ -> fail rõ ràng, không fallback sang direct.IMAP_PROXY_URL, behavior direct hiện tại không đổi.Test matrix tối thiểu
socks5://...-> dùng SOCKS5 path.http://...-> dùng HTTP CONNECT path.https://...-> dùng HTTPS CONNECT path.Nếu muốn giữ scope nhỏ hơn cho v1.1 thì có thể tách thành 2 phase:
http://supporthttps://supportNhưng nếu để title là
Support http/https proxy for imapthì req nên chốt cả 2 scheme ngay từ đầu để tránh mismatch giữa issue title và behavior thực tế.Final Requirements
Summary: Extend
IMAP_PROXY_URLto supporthttp://andhttps://proxy schemes (via HTTP CONNECT tunnel) in addition to the existingsocks5://support.Scope:
dialTLSViaSOCKS5into a generic proxy dialer that handles all three schemes.http://— plain TCP to proxy, then HTTP CONNECT tunnel toIMAP_HOST:IMAP_PORT.https://— TLS to proxy first, then HTTP CONNECT tunnel toIMAP_HOST:IMAP_PORT.socks5://— keep existing behavior unchanged.user:pass@in the URL for all schemes that support it.Run) continues retrying on failure as it does today.IMAP_PROXY_URL.Out of scope:
HTTP_PROXY,HTTPS_PROXY) — not inherited.socks5,http,https.Acceptance criteria:
IMAP_PROXY_URL=socks5://...→ IMAP connection uses existing SOCKS5 path (no regression).IMAP_PROXY_URL=http://...→ IMAP connection goes through HTTP CONNECT tunnel.IMAP_PROXY_URL=https://...→ IMAP connection goes through TLS-to-proxy then CONNECT tunnel.user:pass@in proxy URL → credentials are used to authenticate with the proxy.IMAP_PROXY_URLunset → existing direct-dial behavior unchanged.Test matrix (minimum):
socks5://...http://...https://...user:pass@ftp://)IMAP_PROXY_URLempty/unsetImplementation Plan
Approach: Refactor
dialTLSViaSOCKS5into a genericdialTLSViaProxythat dispatches by URL scheme.Changes in
internal/mail/imap.go:Rename + refactor:
dialTLSViaSOCKS5→dialTLSViaProxysocks5→ existing SOCKS5 logic (extracted to helper)http/https→ newdialViaCONNECTNew
dialViaCONNECT(u, targetAddr):http, TLS forhttps)CONNECT target:port HTTP/1.1with optional Basic authproxyConnif bufio buffered data)New
proxyConntype:net.Conn+bufio.Readerto drain buffered data from CONNECT response before TLS handshakeUpdate
NewIMAPWatcher:dialIMAPViaProxy: dialTLSViaProxyChanges in
internal/mail/imap_test.go:No new dependencies — uses only
net/http,crypto/tls,bufio,encoding/base64from stdlib.