[kayahk]

Problem

paca.send_email hard-codes smtp.PlainAuth, which sends AUTH PLAIN unconditionally. Servers that accept only AUTH LOGIN — Azure Communication Services is one, so are several Exchange relays — reject that handshake with:

send_email: auth: 504 "5.7.4 Unrecognized authentication type"

The credential is valid; the mechanism is not one the server offers. SMTP email is therefore impossible against ACS from a Paca plugin today.

Change

• Read the mechanisms the server advertises via smtp.Client.Extension("AUTH") after STARTTLS.
• Try PLAIN first, fall back to AUTH LOGIN (implemented here, since net/smtp ships no LOGIN auth), and fail naming the advertised set when nothing supported is on offer — instead of the opaque 504.
• loginAuth.Start mirrors PlainAuth's protection: it refuses ("unencrypted connection") unless the connection is already encrypted or the host is loopback, so opportunistic STARTTLS failing cannot leak the password.
• The LOGIN handler answers only the username and password prompts it expects; any other challenge fails closed.

No config or plugin-manifest change: existing host/port/username/password/use_tls fields are unchanged, so PLAIN servers behave exactly as before.

Verification

• go test ./internal/platform/plugin/ passes. New tests cover PLAIN+LOGIN (PLAIN chosen even when LOGIN is advertised first), LOGIN only, XOAUTH2 only (error), no AUTH advertisement (error), the LOGIN challenge order including an unexpected challenge, and the unencrypted-connection refusal with its loopback exception.
• End-to-end against smtp.azurecomm.net:587 with a real ACS credential and a plugin-shaped message: AUTH LOGIN accepted, message accepted for delivery (250). Before the change the same server/credential pair returned the 504 above.

Scoped to services/api/internal/platform/plugin/email.go and its test.

[pullfrog]

Important

The new AUTH LOGIN path drops the unencrypted-connection guard that smtp.PlainAuth gave us, so credentials can now be transmitted in cleartext on a connection where TLS was never negotiated. Details inline.

Reviewed changes

• SMTP AUTH negotiation — dialAndSendSMTP now reads the mechanisms from client.Extension("AUTH") after the implicit-TLS/STARTTLS step and picks PLAIN or LOGIN via smtpAuthFor, instead of always assuming PLAIN; when neither is offered it errors naming the advertised set.
• loginAuth — new smtp.Auth implementing the AUTH LOGIN username/password challenge handshake, failing closed on an unexpected challenge so the password is never echoed twice.
• Tests — table test for mechanism selection (PLAIN preferred, LOGIN-only, XOAUTH2-only and empty both error) plus a unit test for the LOGIN challenge order including the unexpected-challenge case.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[kayahk]

All three review points addressed in 7ea0d0f:

• loginAuth.Start now mirrors smtp.PlainAuth: "unencrypted connection" unless server.TLS or the host is loopback. That was a real regression — dialAndSendSMTP only upgrades via STARTTLS when advertised, so a LOGIN-only server without TLS would have received the password in the clear. Test covers both the refusal and the loopback exception.
• smtpAuthFor now scans PLAIN across all mechanisms before LOGIN, so the code matches the stated preference instead of taking advertisement order.
• Both comments corrected: PlainAuth sends AUTH PLAIN unconditionally; ACS/Exchange reject it with 504. PR description says so too.

go test ./internal/platform/plugin/ passes.

[pullfrog]

✅ No new issues found.

Reviewed changes

This run reviewed the delta since the prior pullfrog review (84f494b), which resolves every item that review raised.

• Cleartext guard restored on AUTH LOGIN — loginAuth.Start now returns "unencrypted connection" when !server.TLS && !isLocalhost(server.Name), mirroring plainAuth.Start so opportunistic STARTTLS failing can no longer leak the password.
• Comment corrected — the inline comment now states that PlainAuth sends AUTH PLAIN unconditionally and the server rejected it, instead of claiming a client-side refusal.
• PLAIN-first selection implemented — smtpAuthFor now scans PLAIN before LOGIN regardless of the server's advertisement order, matching its doc comment.
• Tests extended — the LOGIN test now asserts the unencrypted-connection refusal and the loopback exception.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pikann]

LGTM! Thank you for the contribution! 🚀