2023-01-30 16:27:06 +03:00
|
|
|
package main
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"os"
|
|
|
|
"time"
|
|
|
|
|
2023-02-27 16:12:58 +03:00
|
|
|
"github.com/mjl-/mox/dmarcdb"
|
2023-01-30 16:27:06 +03:00
|
|
|
"github.com/mjl-/mox/dns"
|
2023-02-27 16:12:58 +03:00
|
|
|
"github.com/mjl-/mox/http"
|
|
|
|
"github.com/mjl-/mox/imapserver"
|
2023-01-30 16:27:06 +03:00
|
|
|
"github.com/mjl-/mox/mlog"
|
|
|
|
"github.com/mjl-/mox/mox-"
|
2023-02-27 16:12:58 +03:00
|
|
|
"github.com/mjl-/mox/mtastsdb"
|
|
|
|
"github.com/mjl-/mox/queue"
|
|
|
|
"github.com/mjl-/mox/smtpserver"
|
2023-01-30 16:27:06 +03:00
|
|
|
"github.com/mjl-/mox/store"
|
2023-02-27 16:12:58 +03:00
|
|
|
"github.com/mjl-/mox/tlsrptdb"
|
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
|
|
|
"github.com/mjl-/mox/tlsrptsend"
|
2023-01-30 16:27:06 +03:00
|
|
|
)
|
|
|
|
|
2023-12-05 15:35:58 +03:00
|
|
|
func shutdown(log mlog.Log) {
|
2023-03-12 12:38:02 +03:00
|
|
|
// We indicate we are shutting down. Causes new connections and new SMTP commands
|
|
|
|
// to be rejected. Should stop active connections pretty quickly.
|
|
|
|
mox.ShutdownCancel()
|
|
|
|
|
|
|
|
// Now we are going to wait for all connections to be gone, up to a timeout.
|
|
|
|
done := mox.Connections.Done()
|
|
|
|
second := time.Tick(time.Second)
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
log.Print("connections shutdown, waiting until 1 second passed")
|
|
|
|
<-second
|
|
|
|
|
|
|
|
case <-time.Tick(3 * time.Second):
|
|
|
|
// We now cancel all pending operations, and set an immediate deadline on sockets.
|
|
|
|
// Should get us a clean shutdown relatively quickly.
|
|
|
|
mox.ContextCancel()
|
|
|
|
mox.Connections.Shutdown()
|
|
|
|
|
|
|
|
second := time.Tick(time.Second)
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
log.Print("no more connections, shutdown is clean, waiting until 1 second passed")
|
|
|
|
<-second // Still wait for second, giving processes like imports a chance to clean up.
|
|
|
|
case <-second:
|
|
|
|
log.Print("shutting down with pending sockets")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
err := os.Remove(mox.DataDirPath("ctl"))
|
|
|
|
log.Check(err, "removing ctl unix domain socket during shutdown")
|
|
|
|
}
|
|
|
|
|
2023-02-27 16:12:58 +03:00
|
|
|
// start initializes all packages, starts all listeners and the switchboard
|
|
|
|
// goroutine, then returns.
|
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
|
|
|
func start(mtastsdbRefresher, sendDMARCReports, sendTLSReports, skipForkExec bool) error {
|
2023-02-27 16:12:58 +03:00
|
|
|
smtpserver.Listen()
|
|
|
|
imapserver.Listen()
|
|
|
|
http.Listen()
|
|
|
|
|
|
|
|
if !skipForkExec {
|
|
|
|
// If we were just launched as root, fork and exec as unprivileged user, handing
|
|
|
|
// over the bound sockets to the new process. We'll get to this same code path
|
|
|
|
// again, skipping this if block, continuing below with the actual serving.
|
|
|
|
if os.Getuid() == 0 {
|
|
|
|
mox.ForkExecUnprivileged()
|
|
|
|
panic("cannot happen")
|
|
|
|
} else {
|
2023-05-31 15:09:53 +03:00
|
|
|
mox.CleanupPassedFiles()
|
2023-02-27 16:12:58 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := mtastsdb.Init(mtastsdbRefresher); err != nil {
|
|
|
|
return fmt.Errorf("mtasts init: %s", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := tlsrptdb.Init(); err != nil {
|
|
|
|
return fmt.Errorf("tlsrpt init: %s", err)
|
|
|
|
}
|
|
|
|
|
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
|
|
|
done := make(chan struct{}, 4) // Goroutines for messages and webhooks, and cleaners.
|
2023-02-27 16:12:58 +03:00
|
|
|
if err := queue.Start(dns.StrictResolver{Pkg: "queue"}, done); err != nil {
|
|
|
|
return fmt.Errorf("queue start: %s", err)
|
|
|
|
}
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
// dmarcdb starts after queue because it may start sending reports through the queue.
|
|
|
|
if err := dmarcdb.Init(); err != nil {
|
|
|
|
return fmt.Errorf("dmarc init: %s", err)
|
|
|
|
}
|
|
|
|
if sendDMARCReports {
|
|
|
|
dmarcdb.Start(dns.StrictResolver{Pkg: "dmarcdb"})
|
|
|
|
}
|
|
|
|
|
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
|
|
|
if sendTLSReports {
|
|
|
|
tlsrptsend.Start(dns.StrictResolver{Pkg: "tlsrptsend"})
|
|
|
|
}
|
|
|
|
|
2023-02-27 16:12:58 +03:00
|
|
|
store.StartAuthCache()
|
|
|
|
smtpserver.Serve()
|
|
|
|
imapserver.Serve()
|
|
|
|
http.Serve()
|
|
|
|
|
|
|
|
go func() {
|
2023-08-08 00:14:31 +03:00
|
|
|
store.Switchboard()
|
|
|
|
<-make(chan struct{})
|
2023-02-27 16:12:58 +03:00
|
|
|
}()
|
|
|
|
return nil
|
|
|
|
}
|