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
|
|
|
|
}
|
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
|
|
|
qm := queue.MakeMsg(smtp.Path{}, rcptTo, has8bit, smtputf8, int64(len(buf)), m.MessageID, nil, reqTLS, time.Now(), m.Subject)
|
2023-11-01 19:55:40 +03:00
|
|
|
qm.DSNUTF8 = bufUTF8
|
2024-04-28 12:03:47 +03:00
|
|
|
if err := queue.Add(ctx, c.log, mox.Conf.Static.Postmaster.Account, f, qm); err != nil {
|
2023-01-30 16:27:06 +03:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|