ElyOffice/tasks/reviews/C12.1-r1.md

FAIL

1. crates/ely-mail-engine/src/smtp.rs:70 — [P1] SMTP envelope addresses can inject additional commands. from and every to string reach mail-send's command formatting without validation. Passing one recipient, bo@example.com>\r\nRCPT TO:<hidden@example.com, transmits two separate RCPT TO commands. A scripted TLS server accepted both recipients and DATA, and send returned Ok(()), silently delivering to an extra envelope recipient. Reject invalid envelope mailbox syntax, including CR/LF, for the sender and all recipients before transmitting the transaction; add regression coverage for both inputs. Reproduced on Windows and Linux: smtp_envelope_cannot_inject_an_additional_recipient, .work/c12.1-r1-probe.log and .work/c12.1-r1-linux-probe.log.

2. crates/ely-mail-engine/Cargo.toml:10 — [P1] The selected async-imap and async-pop dependencies emit credentials and complete fetched messages through the shared log facade at trace level. Neither the dependency configuration nor the engine suppresses or redacts those records. With trace enabled, successful TLS login and fetch recorded the literal IMAP password, POP3 PASS password, and both message bodies. The project's logger enables these targets with ELY_LOG=trace, violating agents.md's prohibition on credentials and content in logs. Remove or redact sensitive protocol tracing, or reliably exclude those records from logging, and test actual dependency logs rather than only the engine's own messages. Reproduced on both platforms: trace_logs_exclude_password_token_and_message, the two probe logs above.

3. crates/ely-mail-engine/src/smtp.rs:62 — [P2] SMTP XOAUTH2 does not complete an authentication error challenge correctly. After the initial token, a server replying 334 <base64 JSON error> receives the token again from mail-send's generic authentication loop. The required response is an empty line, after which the server supplies its final 535 refusal (Gmail protocol). The scripted server expecting that exchange instead observed the repeated token; connect returned a connection error and lost the final refusal. Implement the stateful XOAUTH2 error exchange for SMTP and preserve the final server reply. Existing SMTP tests cover password refusal and token success only. Reproduced on both platforms: smtp_refused_oauth_answers_the_error_challenge_empty, the two probe logs above.

4. crates/ely-mail-engine/src/pop.rs:106 — [P2] POP3 XOAUTH2 stops handling challenges immediately after sending the token. If the server then returns a base64 error challenge, async-pop receives a challenge where it expects final success and returns Protocol("Did not received the expected auith response"); the engine never sends the empty response and never reads the server's final -ERR explanation. This loses the required credential refusal and server wording for the documented XOAUTH2 error exchange. Complete the challenge/final-response exchange, preserving both successful authentication and the final rejection; add a token-refusal test. Reproduced on both platforms: pop_refused_oauth_answers_the_error_challenge_empty, the two probe logs above.

5. crates/ely-mail-engine/src/pop.rs:32 — [P2] POP3 login can report success after swallowing a connection failure. Both async-pop authentication paths call update_capabilities, which discards every CAPA error. A TLS server that answers USER/PASS successfully and then closes after receiving the post-login CAPA causes Pop::connect to return Ok(Pop) and emit the successful-login log despite the failed operation and unusable connection. Surface transport and malformed-response errors from capability discovery; distinguish an explicitly handled unsupported CAPA reply from other failures. Cover the same behavior for password and OAuth authentication. Reproduced on both platforms: pop_connection_loss_during_capabilities_is_an_error, the two probe logs above.

6. crates/ely-mail-engine/src/imap.rs:101 — [P2] The IMAP greeting is discarded without checking its response type or status. When a TLS server sends * BYE [UNAVAILABLE] Maintenance in progress and closes, the client treats the greeting as successful and attempts authentication. The returned error is an OS connection failure (Windows 10053 / Linux broken pipe), with the already-received maintenance explanation lost. This breaks C12.1's requirement to retain server wording on failure. Interpret the greeting, return BYE's reason immediately, and avoid authentication after a refusing greeting; add a greeting-refusal regression. Reproduced on both platforms: imap_greeting_refusal_keeps_the_server_words, the two probe logs above.