2023-01-30 16:27:06 +03:00
|
|
|
package smtpserver
|
|
|
|
|
|
|
|
import (
|
2023-05-22 15:40:36 +03:00
|
|
|
"context"
|
2023-01-30 16:27:06 +03:00
|
|
|
"fmt"
|
queue: deliver to multiple recipients in a single smtp transaction
transferring the data only once. we only do this when the recipient domains
are the same. when queuing, we now take care to set the same NextAttempt
timestamp, so queued messages are actually eligable for combined delivery.
this adds a DeliverMultiple to the smtp client. for pipelined requests, it will
send all RCPT TO (and MAIL and DATA) in one go, and handles the various
responses and error conditions, returning either an overal error, or per
recipient smtp responses. the results of the smtp LIMITS extension are also
available in the smtp client now.
this also takes the "LIMITS RCPTMAX" smtp extension into account: if the server
only accepts a single recipient, we won't send multiple.
if a server doesn't announce a RCPTMAX limit, but still has one (like mox does
for non-spf-verified transactions), we'll recognize code 452 and 552 (for
historic reasons) as temporary error, and try again in a separate transaction
immediately after. we don't yet implement "LIMITS MAILMAX", doesn't seem likely
in practice.
2024-03-07 12:07:53 +03:00
|
|
|
"time"
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
"github.com/mjl-/mox/dsn"
|
2023-12-05 23:13:57 +03:00
|
|
|
"github.com/mjl-/mox/mlog"
|
|
|
|
"github.com/mjl-/mox/mox-"
|
2023-01-30 16:27:06 +03:00
|
|
|
"github.com/mjl-/mox/queue"
|
|
|
|
"github.com/mjl-/mox/smtp"
|
|
|
|
"github.com/mjl-/mox/store"
|
|
|
|
)
|
|
|
|
|
|
|
|
// compose dsn message and add it to the queue for delivery to rcptTo.
|
2023-12-05 23:13:57 +03:00
|
|
|
func queueDSN(ctx context.Context, log mlog.Log, c *conn, rcptTo smtp.Path, m dsn.Message, requireTLS bool) error {
|
2023-01-30 16:27:06 +03:00
|
|
|
buf, err := m.Compose(c.log, false)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2023-12-05 23:13:57 +03:00
|
|
|
bufDKIM, err := mox.DKIMSign(ctx, c.log, m.From, false, buf)
|
|
|
|
log.Check(err, "dkim signing dsn")
|
|
|
|
buf = append([]byte(bufDKIM), buf...)
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
var bufUTF8 []byte
|
|
|
|
if c.smtputf8 {
|
|
|
|
bufUTF8, err = m.Compose(c.log, true)
|
|
|
|
if err != nil {
|
|
|
|
c.log.Errorx("composing dsn with utf-8 for incoming delivery for unknown user, continuing with ascii-only dsn", err)
|
2023-12-05 23:13:57 +03:00
|
|
|
} else {
|
|
|
|
bufUTF8DKIM, err := mox.DKIMSign(ctx, log, m.From, true, bufUTF8)
|
|
|
|
log.Check(err, "dkim signing dsn with utf8")
|
|
|
|
bufUTF8 = append([]byte(bufUTF8DKIM), bufUTF8...)
|
2023-01-30 16:27:06 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-05 15:35:58 +03:00
|
|
|
f, err := store.CreateMessageTemp(c.log, "smtp-dsn")
|
2023-01-30 16:27:06 +03:00
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("creating temp file: %w", err)
|
|
|
|
}
|
2023-11-01 20:57:38 +03:00
|
|
|
defer store.CloseRemoveTempFile(c.log, f, "smtpserver dsn message")
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
if _, err := f.Write([]byte(buf)); err != nil {
|
|
|
|
return fmt.Errorf("writing dsn file: %w", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Queue DSN with null reverse path so failures to deliver will eventually drop the
|
|
|
|
// message instead of causing delivery loops.
|
|
|
|
// ../rfc/3464:433
|
|
|
|
const has8bit = false
|
|
|
|
const smtputf8 = false
|
implement "requiretls", rfc 8689
with requiretls, the tls verification mode/rules for email deliveries can be
changed by the sender/submitter. in two ways:
1. "requiretls" smtp extension to always enforce verified tls (with mta-sts or
dnssec+dane), along the entire delivery path until delivery into the final
destination mailbox (so entire transport is verified-tls-protected).
2. "tls-required: no" message header, to ignore any tls and tls verification
errors even if the recipient domain has a policy that requires tls verification
(mta-sts and/or dnssec+dane), allowing delivery of non-sensitive messages in
case of misconfiguration/interoperability issues (at least useful for sending
tls reports).
we enable requiretls by default (only when tls is active), for smtp and
submission. it can be disabled through the config.
for each delivery attempt, we now store (per recipient domain, in the account
of the sender) whether the smtp server supports starttls and requiretls. this
support is shown (after having sent a first message) in the webmail when
sending a message (the previous 3 bars under the address input field are now 5
bars, the first for starttls support, the last for requiretls support). when
all recipient domains for a message are known to implement requiretls,
requiretls is automatically selected for sending (instead of "default" tls
behaviour). users can also select the "fallback to insecure" to add the
"tls-required: no" header.
new metrics are added for insight into requiretls errors and (some, not yet
all) cases where tls-required-no ignored a tls/verification error.
the admin can change the requiretls status for messages in the queue. so with
default delivery attempts, when verified tls is required by failing, an admin
could potentially change the field to "tls-required: no"-behaviour.
messages received (over smtp) with the requiretls option, get a comment added
to their Received header line, just before "id", after "with".
2023-10-24 11:06:16 +03:00
|
|
|
var reqTLS *bool
|
|
|
|
if requireTLS {
|
|
|
|
reqTLS = &requireTLS
|
|
|
|
}
|
queue: deliver to multiple recipients in a single smtp transaction
transferring the data only once. we only do this when the recipient domains
are the same. when queuing, we now take care to set the same NextAttempt
timestamp, so queued messages are actually eligable for combined delivery.
this adds a DeliverMultiple to the smtp client. for pipelined requests, it will
send all RCPT TO (and MAIL and DATA) in one go, and handles the various
responses and error conditions, returning either an overal error, or per
recipient smtp responses. the results of the smtp LIMITS extension are also
available in the smtp client now.
this also takes the "LIMITS RCPTMAX" smtp extension into account: if the server
only accepts a single recipient, we won't send multiple.
if a server doesn't announce a RCPTMAX limit, but still has one (like mox does
for non-spf-verified transactions), we'll recognize code 452 and 552 (for
historic reasons) as temporary error, and try again in a separate transaction
immediately after. we don't yet implement "LIMITS MAILMAX", doesn't seem likely
in practice.
2024-03-07 12:07:53 +03:00
|
|
|
qm := queue.MakeMsg(smtp.Path{}, rcptTo, has8bit, smtputf8, int64(len(buf)), m.MessageID, nil, reqTLS, time.Now())
|
2023-11-01 19:55:40 +03:00
|
|
|
qm.DSNUTF8 = bufUTF8
|
2024-03-05 22:10:28 +03:00
|
|
|
if err := queue.Add(ctx, c.log, "", f, qm); err != nil {
|
2023-01-30 16:27:06 +03:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|