iloveeyjafjalla opened a new issue, #6856:
URL: https://github.com/apache/rocketmq-dashboard/issues/6856
### Studio Version
branch: `rocketmq-studio` @ `a92c2314`
### Runtime Environment
Not environment specific: the defect is in
`server/src/main/resources/application.yml`, reproduced with a context runner
that loads the real `application.yml`.
### Connected RocketMQ Cluster
Not applicable - the notification email transport, not the cluster.
### Describe the Bug
`docs/studio-native-alerting-design.md` (ยง Notifications and Silences) tells
operators how to configure the email channel:
> Email delivery uses Spring's standard SMTP configuration. Configure
`STUDIO_ALERTING_SMTP_HOST`, `STUDIO_ALERTING_SMTP_PORT`,
`STUDIO_ALERTING_SMTP_USERNAME`, `STUDIO_ALERTING_SMTP_PASSWORD`,
`STUDIO_ALERTING_SMTP_AUTH`, and `STUDIO_ALERTING_SMTP_STARTTLS`; recipient
addresses are configured in General Settings.
Four of those six variables are bridged in `application.yml` (`host`,
`port`, `username`, `password`), the socket timeouts below them are bridged
too, and `STUDIO_ALERTING_SMTP_AUTH` / `STUDIO_ALERTING_SMTP_STARTTLS` are not:
```yaml
mail:
host: ${STUDIO_ALERTING_SMTP_HOST:}
port: ${STUDIO_ALERTING_SMTP_PORT:587}
username: ${STUDIO_ALERTING_SMTP_USERNAME:}
password: ${STUDIO_ALERTING_SMTP_PASSWORD:}
properties:
mail.smtp.auth: true
mail.smtp.starttls.enable: true
mail.smtp.connectiontimeout:
${STUDIO_ALERTING_SMTP_CONNECTION_TIMEOUT:5000}
mail.smtp.timeout: ${STUDIO_ALERTING_SMTP_READ_TIMEOUT:10000}
mail.smtp.writetimeout: ${STUDIO_ALERTING_SMTP_WRITE_TIMEOUT:10000}
```
Nothing maps either variable onto `spring.mail.properties.mail.smtp.auth` /
`...starttls.enable`: there is no bridge, and the relaxed-binding path
`studio.alerting.smtp.auth` matches neither `AlertingProperties` (prefix
`studio.alerting`, no `smtp` field) nor `spring.mail`. The two literals
therefore always win.
The operator-visible effect: a relay that requires no credentials (trusted
internal relay) or that speaks implicit TLS on 465 instead of STARTTLS on 587
cannot be configured. Studio keeps sending `AUTH` and keeps requiring STARTTLS,
the relay rejects the message, and the outbox row keeps retrying with the
relay's error while the value the operator set is silently ignored - the same
shape as the SOCket timeout variables that #6071 had to wire.
### Steps to Reproduce
1. `STUDIO_ALERTING_SMTP_AUTH=false` (and/or
`STUDIO_ALERTING_SMTP_STARTTLS=false`) in the environment, plus a reachable
`STUDIO_ALERTING_SMTP_HOST`.
2. Start Studio and trigger a notification email (an alert rule with the
email channel, or the test-send action).
3. Observe the relay rejecting the session for the credentials/TLS the
transport still requires.
4. The same two lines reproduce it in a context runner without a mail server:
```java
runner.withPropertyValues("STUDIO_ALERTING_SMTP_AUTH=false")
.run(context -> assertThat(context.getEnvironment()
.getProperty("spring.mail.properties.mail.smtp.auth")).isEqualTo("false"));
// expected: "false" but was: "true"
```
### What Did You Expect to See?
`STUDIO_ALERTING_SMTP_AUTH=false` and `STUDIO_ALERTING_SMTP_STARTTLS=false`
reach the mail session, exactly as the six neighbouring variables do, with
`true` remaining the default for both.
### What Did You See Instead?
Both settings are ignored: the transport always authenticates and always
requires STARTTLS, whatever the operator configures.
### Additional Context
`deploy/.env.example` does not mention any of the SMTP variables, so the
design doc is the only place that documents them; the fix keeps its promise
rather than editing it, because the variable names and defaults are already the
ones the doc names.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
