2023-01-30 16:27:06 +03:00
|
|
|
|
package smtpserver
|
|
|
|
|
|
|
|
|
|
// todo: test delivery with failing spf/dkim/dmarc
|
|
|
|
|
// todo: test delivering a message to multiple recipients, and with some of them failing.
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"bytes"
|
|
|
|
|
"context"
|
|
|
|
|
"crypto/ed25519"
|
|
|
|
|
cryptorand "crypto/rand"
|
|
|
|
|
"crypto/tls"
|
|
|
|
|
"crypto/x509"
|
|
|
|
|
"encoding/base64"
|
|
|
|
|
"errors"
|
|
|
|
|
"fmt"
|
2024-02-08 16:49:01 +03:00
|
|
|
|
"log/slog"
|
2023-01-30 16:27:06 +03:00
|
|
|
|
"math/big"
|
|
|
|
|
"mime/quotedprintable"
|
|
|
|
|
"net"
|
|
|
|
|
"os"
|
|
|
|
|
"path/filepath"
|
2023-03-30 11:38:36 +03:00
|
|
|
|
"sort"
|
2023-01-30 16:27:06 +03:00
|
|
|
|
"strings"
|
|
|
|
|
"testing"
|
|
|
|
|
"time"
|
|
|
|
|
|
|
|
|
|
"github.com/mjl-/bstore"
|
|
|
|
|
|
|
|
|
|
"github.com/mjl-/mox/config"
|
|
|
|
|
"github.com/mjl-/mox/dkim"
|
|
|
|
|
"github.com/mjl-/mox/dmarcdb"
|
|
|
|
|
"github.com/mjl-/mox/dns"
|
2023-02-08 00:56:03 +03:00
|
|
|
|
"github.com/mjl-/mox/mlog"
|
2023-01-30 16:27:06 +03:00
|
|
|
|
"github.com/mjl-/mox/mox-"
|
|
|
|
|
"github.com/mjl-/mox/queue"
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
"github.com/mjl-/mox/sasl"
|
2023-01-30 16:27:06 +03:00
|
|
|
|
"github.com/mjl-/mox/smtp"
|
|
|
|
|
"github.com/mjl-/mox/smtpclient"
|
|
|
|
|
"github.com/mjl-/mox/store"
|
|
|
|
|
"github.com/mjl-/mox/subjectpass"
|
|
|
|
|
"github.com/mjl-/mox/tlsrptdb"
|
|
|
|
|
)
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
var ctxbg = context.Background()
|
|
|
|
|
|
2023-02-08 23:45:32 +03:00
|
|
|
|
func init() {
|
|
|
|
|
// Don't make tests slow.
|
|
|
|
|
badClientDelay = 0
|
2023-03-10 12:23:43 +03:00
|
|
|
|
authFailDelay = 0
|
|
|
|
|
unknownRecipientsDelay = 0
|
2023-02-08 23:45:32 +03:00
|
|
|
|
}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
func tcheck(t *testing.T, err error, msg string) {
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Helper()
|
|
|
|
|
t.Fatalf("%s: %s", msg, err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var submitMessage = strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
var deliverMessage = strings.ReplaceAll(`From: <remote@example.org>
|
|
|
|
|
To: <mjl@mox.example>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@example.org>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
2023-08-09 19:03:29 +03:00
|
|
|
|
var deliverMessage2 = strings.ReplaceAll(`From: <remote@example.org>
|
|
|
|
|
To: <mjl@mox.example>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test2@example.org>
|
|
|
|
|
|
|
|
|
|
test email, unique.
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
type testserver struct {
|
|
|
|
|
t *testing.T
|
|
|
|
|
acc *store.Account
|
2023-08-08 00:14:31 +03:00
|
|
|
|
switchStop func()
|
2023-01-30 16:27:06 +03:00
|
|
|
|
comm *store.Comm
|
|
|
|
|
cid int64
|
|
|
|
|
resolver dns.Resolver
|
2023-12-24 01:07:21 +03:00
|
|
|
|
auth func(mechanisms []string, cs *tls.ConnectionState) (sasl.Client, error)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
user, pass string
|
|
|
|
|
submission bool
|
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
|
|
|
|
requiretls bool
|
2023-01-30 16:27:06 +03:00
|
|
|
|
dnsbls []dns.Domain
|
2023-02-08 00:56:03 +03:00
|
|
|
|
tlsmode smtpclient.TLSMode
|
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
|
|
|
|
tlspkix bool
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
2024-03-09 01:29:15 +03:00
|
|
|
|
const password0 = "te\u0301st \u00a0\u2002\u200a" // NFD and various unicode spaces.
|
|
|
|
|
const password1 = "tést " // PRECIS normalized, with NFC.
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
func newTestServer(t *testing.T, configPath string, resolver dns.Resolver) *testserver {
|
2023-02-08 00:56:03 +03:00
|
|
|
|
limitersInit() // Reset rate limiters.
|
|
|
|
|
|
|
|
|
|
ts := testserver{t: t, cid: 1, resolver: resolver, tlsmode: smtpclient.TLSOpportunistic}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
|
if dmarcdb.EvalDB != nil {
|
|
|
|
|
dmarcdb.EvalDB.Close()
|
|
|
|
|
dmarcdb.EvalDB = nil
|
|
|
|
|
}
|
|
|
|
|
|
2023-12-05 15:35:58 +03:00
|
|
|
|
log := mlog.New("smtpserver", nil)
|
2023-05-22 15:40:36 +03:00
|
|
|
|
mox.Context = ctxbg
|
2023-01-30 16:27:06 +03:00
|
|
|
|
mox.ConfigStaticPath = configPath
|
2023-06-16 14:27:27 +03:00
|
|
|
|
mox.MustLoadConfig(true, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
dataDir := mox.ConfigDirPath(mox.Conf.Static.DataDir)
|
|
|
|
|
os.RemoveAll(dataDir)
|
2024-04-24 20:15:30 +03:00
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
var err error
|
2023-12-05 15:35:58 +03:00
|
|
|
|
ts.acc, err = store.OpenAccount(log, "mjl")
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "open account")
|
2024-03-09 01:29:15 +03:00
|
|
|
|
err = ts.acc.SetPassword(log, password0)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "set password")
|
2024-04-24 20:15:30 +03:00
|
|
|
|
|
2023-08-08 00:14:31 +03:00
|
|
|
|
ts.switchStop = store.Switchboard()
|
2023-01-30 16:27:06 +03:00
|
|
|
|
err = queue.Init()
|
|
|
|
|
tcheck(t, err, "queue init")
|
|
|
|
|
|
|
|
|
|
ts.comm = store.RegisterComm(ts.acc)
|
|
|
|
|
|
|
|
|
|
return &ts
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (ts *testserver) close() {
|
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
|
|
|
|
if ts.acc == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.comm.Unregister()
|
|
|
|
|
queue.Shutdown()
|
2023-08-08 00:14:31 +03:00
|
|
|
|
ts.switchStop()
|
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
|
|
|
|
err := ts.acc.Close()
|
|
|
|
|
tcheck(ts.t, err, "closing account")
|
2024-04-16 18:33:54 +03:00
|
|
|
|
ts.acc.CheckClosed()
|
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
|
|
|
|
ts.acc = nil
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
2024-04-24 20:15:30 +03:00
|
|
|
|
func (ts *testserver) checkCount(mailboxName string, expect int) {
|
|
|
|
|
t := ts.t
|
|
|
|
|
t.Helper()
|
|
|
|
|
q := bstore.QueryDB[store.Mailbox](ctxbg, ts.acc.DB)
|
|
|
|
|
q.FilterNonzero(store.Mailbox{Name: mailboxName})
|
|
|
|
|
mb, err := q.Get()
|
|
|
|
|
tcheck(t, err, "get mailbox")
|
|
|
|
|
qm := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB)
|
|
|
|
|
qm.FilterNonzero(store.Message{MailboxID: mb.ID})
|
|
|
|
|
qm.FilterEqual("Expunged", false)
|
|
|
|
|
n, err := qm.Count()
|
|
|
|
|
tcheck(t, err, "count messages in mailbox")
|
|
|
|
|
if n != expect {
|
|
|
|
|
t.Fatalf("messages in mailbox, found %d, expected %d", n, expect)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
func (ts *testserver) run(fn func(helloErr error, client *smtpclient.Client)) {
|
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
|
|
|
|
ts.t.Helper()
|
2024-01-01 20:30:31 +03:00
|
|
|
|
ts.runRaw(func(conn net.Conn) {
|
|
|
|
|
ts.t.Helper()
|
|
|
|
|
|
|
|
|
|
auth := ts.auth
|
|
|
|
|
if auth == nil && ts.user != "" {
|
|
|
|
|
auth = func(mechanisms []string, cs *tls.ConnectionState) (sasl.Client, error) {
|
|
|
|
|
return sasl.NewClientPlain(ts.user, ts.pass), nil
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ourHostname := mox.Conf.Static.HostnameDomain
|
|
|
|
|
remoteHostname := dns.Domain{ASCII: "mox.example"}
|
|
|
|
|
opts := smtpclient.Opts{
|
|
|
|
|
Auth: auth,
|
|
|
|
|
RootCAs: mox.Conf.Static.TLS.CertPool,
|
|
|
|
|
}
|
|
|
|
|
log := pkglog.WithCid(ts.cid - 1)
|
|
|
|
|
client, err := smtpclient.New(ctxbg, log.Logger, conn, ts.tlsmode, ts.tlspkix, ourHostname, remoteHostname, opts)
|
|
|
|
|
if err != nil {
|
|
|
|
|
conn.Close()
|
|
|
|
|
} else {
|
|
|
|
|
defer client.Close()
|
|
|
|
|
}
|
|
|
|
|
fn(err, client)
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (ts *testserver) runRaw(fn func(clientConn net.Conn)) {
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.t.Helper()
|
|
|
|
|
|
|
|
|
|
ts.cid += 2
|
|
|
|
|
|
|
|
|
|
serverConn, clientConn := net.Pipe()
|
|
|
|
|
defer serverConn.Close()
|
|
|
|
|
// clientConn is closed as part of closing client.
|
|
|
|
|
serverdone := make(chan struct{})
|
|
|
|
|
defer func() { <-serverdone }()
|
|
|
|
|
|
|
|
|
|
go func() {
|
|
|
|
|
tlsConfig := &tls.Config{
|
|
|
|
|
Certificates: []tls.Certificate{fakeCert(ts.t)},
|
|
|
|
|
}
|
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
|
|
|
|
serve("test", ts.cid-2, dns.Domain{ASCII: "mox.example"}, tlsConfig, serverConn, ts.resolver, ts.submission, false, 100<<20, false, false, ts.requiretls, ts.dnsbls, 0)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
close(serverdone)
|
|
|
|
|
}()
|
|
|
|
|
|
2024-01-01 20:30:31 +03:00
|
|
|
|
fn(clientConn)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
2024-04-24 20:15:30 +03:00
|
|
|
|
func (ts *testserver) smtperr(err error, expErr *smtpclient.Error) {
|
|
|
|
|
ts.t.Helper()
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Code != expErr.Code || cerr.Secode != expErr.Secode) {
|
|
|
|
|
ts.t.Fatalf("got err %#v (%q), expected %#v", err, err, expErr)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
// Just a cert that appears valid. SMTP client will not verify anything about it
|
|
|
|
|
// (that is opportunistic TLS for you, "better some than none"). Let's enjoy this
|
|
|
|
|
// one moment where it makes life easier.
|
|
|
|
|
func fakeCert(t *testing.T) tls.Certificate {
|
|
|
|
|
privKey := ed25519.NewKeyFromSeed(make([]byte, ed25519.SeedSize)) // Fake key, don't use this for real!
|
|
|
|
|
template := &x509.Certificate{
|
|
|
|
|
SerialNumber: big.NewInt(1), // Required field...
|
|
|
|
|
}
|
|
|
|
|
localCertBuf, err := x509.CreateCertificate(cryptorand.Reader, template, template, privKey.Public(), privKey)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("making certificate: %s", err)
|
|
|
|
|
}
|
|
|
|
|
cert, err := x509.ParseCertificate(localCertBuf)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("parsing generated certificate: %s", err)
|
|
|
|
|
}
|
|
|
|
|
c := tls.Certificate{
|
|
|
|
|
Certificate: [][]byte{localCertBuf},
|
|
|
|
|
PrivateKey: privKey,
|
|
|
|
|
Leaf: cert,
|
|
|
|
|
}
|
|
|
|
|
return c
|
|
|
|
|
}
|
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
|
// check expected dmarc evaluations for outgoing aggregate reports.
|
|
|
|
|
func checkEvaluationCount(t *testing.T, n int) []dmarcdb.Evaluation {
|
|
|
|
|
t.Helper()
|
|
|
|
|
l, err := dmarcdb.Evaluations(ctxbg)
|
|
|
|
|
tcheck(t, err, "get dmarc evaluations")
|
|
|
|
|
tcompare(t, len(l), n)
|
|
|
|
|
return l
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
// Test submission from authenticated user.
|
|
|
|
|
func TestSubmission(t *testing.T) {
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
// Set DKIM signing config.
|
|
|
|
|
dom, _ := mox.Conf.Domain(dns.Domain{ASCII: "mox.example"})
|
|
|
|
|
sel := config.Selector{
|
|
|
|
|
HashEffective: "sha256",
|
|
|
|
|
HeadersEffective: []string{"From", "To", "Subject"},
|
|
|
|
|
Key: ed25519.NewKeyFromSeed(make([]byte, ed25519.SeedSize)), // Fake key, don't use for real.
|
|
|
|
|
Domain: dns.Domain{ASCII: "mox.example"},
|
|
|
|
|
}
|
|
|
|
|
dom.DKIM = config.DKIM{
|
|
|
|
|
Selectors: map[string]config.Selector{"testsel": sel},
|
|
|
|
|
Sign: []string{"testsel"},
|
|
|
|
|
}
|
|
|
|
|
mox.Conf.Dynamic.Domains["mox.example"] = dom
|
|
|
|
|
|
2023-12-24 01:07:21 +03:00
|
|
|
|
testAuth := func(authfn func(user, pass string, cs *tls.ConnectionState) sasl.Client, user, pass string, expErr *smtpclient.Error) {
|
2023-01-30 16:27:06 +03:00
|
|
|
|
t.Helper()
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
if authfn != nil {
|
2023-12-24 01:07:21 +03:00
|
|
|
|
ts.auth = func(mechanisms []string, cs *tls.ConnectionState) (sasl.Client, error) {
|
|
|
|
|
return authfn(user, pass, cs), nil
|
|
|
|
|
}
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
} else {
|
|
|
|
|
ts.auth = nil
|
|
|
|
|
}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
mailFrom := "mjl@mox.example"
|
|
|
|
|
rcptTo := "remote@example.org"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(submitMessage)), strings.NewReader(submitMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Secode != expErr.Secode) {
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
t.Fatalf("got err %#v (%q), expected %#v", err, err, expErr)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, 0)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ts.submission = true
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
testAuth(nil, "", "", &smtpclient.Error{Permanent: true, Code: smtp.C530SecurityRequired, Secode: smtp.SePol7Other0})
|
2023-12-24 01:07:21 +03:00
|
|
|
|
authfns := []func(user, pass string, cs *tls.ConnectionState) sasl.Client{
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client { return sasl.NewClientPlain(user, pass) },
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client { return sasl.NewClientLogin(user, pass) },
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client { return sasl.NewClientCRAMMD5(user, pass) },
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client {
|
|
|
|
|
return sasl.NewClientSCRAMSHA1(user, pass, false)
|
|
|
|
|
},
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client {
|
|
|
|
|
return sasl.NewClientSCRAMSHA256(user, pass, false)
|
|
|
|
|
},
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client {
|
|
|
|
|
return sasl.NewClientSCRAMSHA1PLUS(user, pass, *cs)
|
|
|
|
|
},
|
|
|
|
|
func(user, pass string, cs *tls.ConnectionState) sasl.Client {
|
|
|
|
|
return sasl.NewClientSCRAMSHA256PLUS(user, pass, *cs)
|
|
|
|
|
},
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
}
|
|
|
|
|
for _, fn := range authfns {
|
2024-03-09 01:29:15 +03:00
|
|
|
|
testAuth(fn, "mjl@mox.example", "test", &smtpclient.Error{Secode: smtp.SePol7AuthBadCreds8}) // Bad (short) password.
|
|
|
|
|
testAuth(fn, "mjl@mox.example", password0+"test", &smtpclient.Error{Secode: smtp.SePol7AuthBadCreds8}) // Bad password.
|
|
|
|
|
testAuth(fn, "mjl@mox.example", password0, nil)
|
|
|
|
|
testAuth(fn, "mjl@mox.example", password1, nil)
|
|
|
|
|
testAuth(fn, "móx@mox.example", password0, nil)
|
|
|
|
|
testAuth(fn, "móx@mox.example", password1, nil)
|
|
|
|
|
testAuth(fn, "mo\u0301x@mox.example", password0, nil)
|
|
|
|
|
testAuth(fn, "mo\u0301x@mox.example", password1, nil)
|
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
|
|
|
|
}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test delivery from external MTA.
|
|
|
|
|
func TestDelivery(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@127.0.0.10"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("deliver to ip address, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@test.example" // Not configured as destination.
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("deliver to unknown domain, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "unknown@mox.example" // User unknown.
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("deliver to unknown user for known domain, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("deliver from user without reputation, valid iprev required, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Set up iprev to get delivery from unknown user to be accepted.
|
|
|
|
|
resolver.PTR["127.0.0.10"] = []string{"example.org."}
|
2024-03-08 23:08:40 +03:00
|
|
|
|
|
|
|
|
|
// Only ascii o@ is configured, not the greek and cyrillic lookalikes.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
2024-03-08 23:08:40 +03:00
|
|
|
|
rcptTo := "ο@mox.example" // omicron \u03bf, looks like the configured o@
|
|
|
|
|
msg := strings.ReplaceAll(deliverMessage, "mjl@mox.example", rcptTo)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
if err == nil {
|
2024-03-08 23:08:40 +03:00
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, true, false)
|
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("deliver to omicron @ instead of ascii o @, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
recipients := []string{
|
|
|
|
|
"mjl@mox.example",
|
2024-03-09 01:29:15 +03:00
|
|
|
|
"o@mox.example", // ascii o, as configured
|
|
|
|
|
"\u2126@mox.example", // ohm sign, as configured
|
|
|
|
|
"ω@mox.example", // lower-case omega, we match case-insensitively and this is the lowercase of ohm (!)
|
|
|
|
|
"\u03a9@mox.example", // capital omega, also lowercased to omega.
|
|
|
|
|
"móx@mox.example", // NFC
|
|
|
|
|
"mo\u0301x@mox.example", // not NFC, but normalized as móx@, see https://go.dev/blog/normalization
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
2024-03-08 23:08:40 +03:00
|
|
|
|
|
|
|
|
|
for _, rcptTo := range recipients {
|
|
|
|
|
// Ensure SMTP RCPT TO and message address headers are the same, otherwise the junk
|
|
|
|
|
// filter treats us more strictly.
|
|
|
|
|
msg := strings.ReplaceAll(deliverMessage, "mjl@mox.example", rcptTo)
|
|
|
|
|
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, true, false)
|
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver to remote")
|
|
|
|
|
|
|
|
|
|
changes := make(chan []store.Change)
|
|
|
|
|
go func() {
|
|
|
|
|
changes <- ts.comm.Get()
|
|
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
timer := time.NewTimer(time.Second)
|
|
|
|
|
defer timer.Stop()
|
|
|
|
|
select {
|
|
|
|
|
case <-changes:
|
|
|
|
|
case <-timer.C:
|
|
|
|
|
t.Fatalf("no delivery in 1s")
|
|
|
|
|
}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
})
|
2023-11-01 19:55:40 +03:00
|
|
|
|
|
|
|
|
|
checkEvaluationCount(t, 0)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func tinsertmsg(t *testing.T, acc *store.Account, mailbox string, m *store.Message, msg string) {
|
2023-12-05 15:35:58 +03:00
|
|
|
|
mf, err := store.CreateMessageTemp(pkglog, "queue-dsn")
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "temp message")
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
defer os.Remove(mf.Name())
|
|
|
|
|
defer mf.Close()
|
2023-01-30 16:27:06 +03:00
|
|
|
|
_, err = mf.Write([]byte(msg))
|
|
|
|
|
tcheck(t, err, "write message")
|
2023-12-05 15:35:58 +03:00
|
|
|
|
err = acc.DeliverMailbox(pkglog, mailbox, m, mf)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "deliver message")
|
|
|
|
|
err = mf.Close()
|
|
|
|
|
tcheck(t, err, "close message")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func tretrain(t *testing.T, acc *store.Account) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
// Fresh empty junkfilter.
|
|
|
|
|
basePath := mox.DataDirPath("accounts")
|
|
|
|
|
dbPath := filepath.Join(basePath, acc.Name, "junkfilter.db")
|
|
|
|
|
bloomPath := filepath.Join(basePath, acc.Name, "junkfilter.bloom")
|
|
|
|
|
os.Remove(dbPath)
|
|
|
|
|
os.Remove(bloomPath)
|
2023-12-05 15:35:58 +03:00
|
|
|
|
jf, _, err := acc.OpenJunkFilter(ctxbg, pkglog)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "open junk filter")
|
|
|
|
|
defer jf.Close()
|
|
|
|
|
|
|
|
|
|
// Fetch messags to retrain on.
|
2023-05-22 15:40:36 +03:00
|
|
|
|
q := bstore.QueryDB[store.Message](ctxbg, acc.DB)
|
2023-07-24 22:21:05 +03:00
|
|
|
|
q.FilterEqual("Expunged", false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
q.FilterFn(func(m store.Message) bool {
|
|
|
|
|
return m.Flags.Junk || m.Flags.Notjunk
|
|
|
|
|
})
|
|
|
|
|
msgs, err := q.List()
|
|
|
|
|
tcheck(t, err, "fetch messages")
|
|
|
|
|
|
|
|
|
|
// Retrain the messages.
|
|
|
|
|
for _, m := range msgs {
|
|
|
|
|
ham := m.Flags.Notjunk
|
|
|
|
|
|
|
|
|
|
f, err := os.Open(acc.MessagePath(m.ID))
|
|
|
|
|
tcheck(t, err, "open message")
|
|
|
|
|
r := store.FileMsgReader(m.MsgPrefix, f)
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
jf.TrainMessage(ctxbg, r, m.Size, ham)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
|
|
|
|
err = r.Close()
|
|
|
|
|
tcheck(t, err, "close message")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = jf.Save()
|
|
|
|
|
tcheck(t, err, "save junkfilter")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test accept/reject with DMARC reputation and with spammy content.
|
|
|
|
|
func TestSpam(t *testing.T) {
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.1"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
|
|
|
|
"example.org.": {"v=spf1 ip4:127.0.0.10 -all"},
|
2023-11-01 19:55:40 +03:00
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject; rua=mailto:dmarcrpt@example.org"},
|
2023-01-30 16:27:06 +03:00
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/junk/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
// Insert spammy messages. No junkfilter training yet.
|
|
|
|
|
m := store.Message{
|
|
|
|
|
RemoteIP: "127.0.0.10",
|
|
|
|
|
RemoteIPMasked1: "127.0.0.10",
|
|
|
|
|
RemoteIPMasked2: "127.0.0.0",
|
|
|
|
|
RemoteIPMasked3: "127.0.0.0",
|
|
|
|
|
MailFrom: "remote@example.org",
|
|
|
|
|
MailFromLocalpart: smtp.Localpart("remote"),
|
|
|
|
|
MailFromDomain: "example.org",
|
|
|
|
|
RcptToLocalpart: smtp.Localpart("mjl"),
|
|
|
|
|
RcptToDomain: "mox.example",
|
|
|
|
|
MsgFromLocalpart: smtp.Localpart("remote"),
|
|
|
|
|
MsgFromDomain: "example.org",
|
|
|
|
|
MsgFromOrgDomain: "example.org",
|
|
|
|
|
MsgFromValidated: true,
|
|
|
|
|
MsgFromValidation: store.ValidationStrict,
|
|
|
|
|
Flags: store.Flags{Seen: true, Junk: true},
|
2023-08-08 23:10:53 +03:00
|
|
|
|
Size: int64(len(deliverMessage)),
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
for i := 0; i < 3; i++ {
|
|
|
|
|
nm := m
|
|
|
|
|
tinsertmsg(t, ts.acc, "Inbox", &nm, deliverMessage)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Delivery from sender with bad reputation should fail.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("delivery by bad sender, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-24 20:15:30 +03:00
|
|
|
|
ts.checkCount("Rejects", 1)
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, 0) // No positive interactions yet.
|
2023-08-09 19:03:29 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Delivery from sender with bad reputation matching AcceptRejectsToMailbox should
|
|
|
|
|
// result in accepted delivery to the mailbox.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl2@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage2)), strings.NewReader(deliverMessage2), false, false, false)
|
2023-08-09 19:03:29 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
2024-04-24 20:15:30 +03:00
|
|
|
|
ts.checkCount("mjl2junk", 1) // In ruleset rejects mailbox.
|
|
|
|
|
ts.checkCount("Rejects", 1) // Same as before.
|
|
|
|
|
checkEvaluationCount(t, 0) // This is not an actual accept.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Mark the messages as having good reputation.
|
2023-05-22 15:40:36 +03:00
|
|
|
|
q := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB)
|
2023-07-24 22:21:05 +03:00
|
|
|
|
q.FilterEqual("Expunged", false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
_, err := q.UpdateFields(map[string]any{"Junk": false, "Notjunk": true})
|
|
|
|
|
tcheck(t, err, "update junkiness")
|
|
|
|
|
|
|
|
|
|
// Message should now be accepted.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
2023-08-09 19:03:29 +03:00
|
|
|
|
// Message should now be removed from Rejects mailboxes.
|
2024-04-24 20:15:30 +03:00
|
|
|
|
ts.checkCount("Rejects", 0)
|
|
|
|
|
ts.checkCount("mjl2junk", 1)
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, 1)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Undo dmarc pass, mark messages as junk, and train the filter.
|
|
|
|
|
resolver.TXT = nil
|
2023-05-22 15:40:36 +03:00
|
|
|
|
q = bstore.QueryDB[store.Message](ctxbg, ts.acc.DB)
|
2023-07-24 22:21:05 +03:00
|
|
|
|
q.FilterEqual("Expunged", false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
_, err = q.UpdateFields(map[string]any{"Junk": true, "Notjunk": false})
|
|
|
|
|
tcheck(t, err, "update junkiness")
|
|
|
|
|
tretrain(t, ts.acc)
|
|
|
|
|
|
|
|
|
|
// Message should be refused for spammy content.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("attempt to deliver spamy message, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, 1) // No new evaluation, this isn't a DMARC reject.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-09 23:31:37 +03:00
|
|
|
|
// Test accept/reject with forwarded messages, DMARC ignored, no IP/EHLO/MAIL
|
|
|
|
|
// FROM-based reputation.
|
|
|
|
|
func TestForward(t *testing.T) {
|
|
|
|
|
// Do a run without forwarding, and with.
|
|
|
|
|
check := func(forward bool) {
|
|
|
|
|
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"bad.example.": {"127.0.0.1"}, // For mx check.
|
|
|
|
|
"good.example.": {"127.0.0.1"}, // For mx check.
|
|
|
|
|
"forward.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
|
|
|
|
"bad.example.": {"v=spf1 ip4:127.0.0.1 -all"},
|
|
|
|
|
"good.example.": {"v=spf1 ip4:127.0.0.1 -all"},
|
|
|
|
|
"forward.example.": {"v=spf1 ip4:127.0.0.10 -all"},
|
2023-11-01 19:55:40 +03:00
|
|
|
|
"_dmarc.bad.example.": {"v=DMARC1;p=reject; rua=mailto:dmarc@bad.example"},
|
|
|
|
|
"_dmarc.good.example.": {"v=DMARC1;p=reject; rua=mailto:dmarc@good.example"},
|
|
|
|
|
"_dmarc.forward.example.": {"v=DMARC1;p=reject; rua=mailto:dmarc@forward.example"},
|
2023-08-09 23:31:37 +03:00
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"forward.example."}, // For iprev check.
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
rcptTo := "mjl3@mox.example"
|
|
|
|
|
if !forward {
|
|
|
|
|
// For SPF and DMARC pass, otherwise the test ends quickly.
|
|
|
|
|
resolver.TXT["bad.example."] = []string{"v=spf1 ip4:127.0.0.10 -all"}
|
|
|
|
|
resolver.TXT["good.example."] = []string{"v=spf1 ip4:127.0.0.10 -all"}
|
|
|
|
|
rcptTo = "mjl@mox.example" // Without IsForward rule.
|
|
|
|
|
}
|
|
|
|
|
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/junk/mox.conf"), resolver)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
|
totalEvaluations := 0
|
|
|
|
|
|
2023-08-09 23:31:37 +03:00
|
|
|
|
var msgBad = strings.ReplaceAll(`From: <remote@bad.example>
|
2023-11-27 12:34:01 +03:00
|
|
|
|
To: <mjl@mox.example>
|
2023-08-09 23:31:37 +03:00
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <bad@example.org>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
var msgOK = strings.ReplaceAll(`From: <remote@good.example>
|
2023-11-27 12:34:01 +03:00
|
|
|
|
To: <mjl@mox.example>
|
2023-08-09 23:31:37 +03:00
|
|
|
|
Subject: other
|
|
|
|
|
Message-Id: <good@example.org>
|
|
|
|
|
|
|
|
|
|
unrelated message.
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
var msgOK2 = strings.ReplaceAll(`From: <other@forward.example>
|
2023-11-27 12:34:01 +03:00
|
|
|
|
To: <mjl@mox.example>
|
2023-08-09 23:31:37 +03:00
|
|
|
|
Subject: non-forward
|
|
|
|
|
Message-Id: <regular@example.org>
|
|
|
|
|
|
|
|
|
|
happens to come from forwarding mail server.
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
// Deliver forwarded messages, then classify as junk. Normally enough to treat
|
|
|
|
|
// other unrelated messages from IP as junk, but not for forwarded messages.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
tcheck(t, err, "connect")
|
|
|
|
|
|
|
|
|
|
mailFrom := "remote@forward.example"
|
|
|
|
|
if !forward {
|
|
|
|
|
mailFrom = "remote@bad.example"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for i := 0; i < 10; i++ {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msgBad)), strings.NewReader(msgBad), false, false, false)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
tcheck(t, err, "deliver message")
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
totalEvaluations += 10
|
2023-08-09 23:31:37 +03:00
|
|
|
|
|
|
|
|
|
n, err := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB).UpdateFields(map[string]any{"Junk": true, "MsgFromValidated": true})
|
|
|
|
|
tcheck(t, err, "marking messages as junk")
|
|
|
|
|
tcompare(t, n, 10)
|
|
|
|
|
|
|
|
|
|
// Next delivery will fail, with negative "message From" signal.
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msgBad)), strings.NewReader(msgBad), false, false, false)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("delivery by bad sender, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
|
|
|
|
|
checkEvaluationCount(t, totalEvaluations)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Delivery from different "message From" without reputation, but from same
|
|
|
|
|
// forwarding email server, should succeed under forwarding, not as regular sending
|
|
|
|
|
// server.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
tcheck(t, err, "connect")
|
|
|
|
|
|
|
|
|
|
mailFrom := "remote@forward.example"
|
|
|
|
|
if !forward {
|
|
|
|
|
mailFrom = "remote@good.example"
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msgOK)), strings.NewReader(msgOK), false, false, false)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
if forward {
|
|
|
|
|
tcheck(t, err, "deliver")
|
2023-11-01 19:55:40 +03:00
|
|
|
|
totalEvaluations += 1
|
2023-08-09 23:31:37 +03:00
|
|
|
|
} else {
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("delivery by bad ip, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, totalEvaluations)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Delivery from forwarding server that isn't a forward should get same treatment.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
tcheck(t, err, "connect")
|
|
|
|
|
|
|
|
|
|
mailFrom := "other@forward.example"
|
|
|
|
|
|
2023-11-27 12:34:01 +03:00
|
|
|
|
// Ensure To header matches.
|
|
|
|
|
msg := msgOK2
|
|
|
|
|
if forward {
|
|
|
|
|
msg = strings.ReplaceAll(msg, "<mjl@mox.example>", "<mjl3@mox.example>")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, false)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
if forward {
|
|
|
|
|
tcheck(t, err, "deliver")
|
2023-11-01 19:55:40 +03:00
|
|
|
|
totalEvaluations += 1
|
2023-08-09 23:31:37 +03:00
|
|
|
|
} else {
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("delivery by bad ip, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, totalEvaluations)
|
2023-08-09 23:31:37 +03:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
check(true)
|
|
|
|
|
check(false)
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
// Messages that we sent to, that have passing DMARC, but that are otherwise spammy, should be accepted.
|
|
|
|
|
func TestDMARCSent(t *testing.T) {
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.1"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
2023-11-01 19:55:40 +03:00
|
|
|
|
"example.org.": {"v=spf1 ip4:127.0.0.1 -all"},
|
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject;rua=mailto:dmarcrpt@example.org"},
|
2023-01-30 16:27:06 +03:00
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/junk/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
|
// First check that DMARC policy rejects message and results in optional evaluation.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("attempt to deliver spamy message, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
l := checkEvaluationCount(t, 1)
|
|
|
|
|
tcompare(t, l[0].Optional, true)
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Update DNS for an SPF pass, and DMARC pass.
|
|
|
|
|
resolver.TXT["example.org."] = []string{"v=spf1 ip4:127.0.0.10 -all"}
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
// Insert spammy messages not related to the test message.
|
|
|
|
|
m := store.Message{
|
|
|
|
|
MailFrom: "remote@test.example",
|
|
|
|
|
RcptToLocalpart: smtp.Localpart("mjl"),
|
|
|
|
|
RcptToDomain: "mox.example",
|
|
|
|
|
Flags: store.Flags{Seen: true, Junk: true},
|
2023-08-08 23:10:53 +03:00
|
|
|
|
Size: int64(len(deliverMessage)),
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
for i := 0; i < 3; i++ {
|
|
|
|
|
nm := m
|
|
|
|
|
tinsertmsg(t, ts.acc, "Archive", &nm, deliverMessage)
|
|
|
|
|
}
|
|
|
|
|
tretrain(t, ts.acc)
|
|
|
|
|
|
|
|
|
|
// Baseline, message should be refused for spammy content.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("attempt to deliver spamy message, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
2023-11-01 19:55:40 +03:00
|
|
|
|
checkEvaluationCount(t, 1) // No new evaluation.
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Insert a message that we sent to the address that is about to send to us.
|
2023-08-08 23:10:53 +03:00
|
|
|
|
sentMsg := store.Message{Size: int64(len(deliverMessage))}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tinsertmsg(t, ts.acc, "Sent", &sentMsg, deliverMessage)
|
2023-05-22 15:40:36 +03:00
|
|
|
|
err := ts.acc.DB.Insert(ctxbg, &store.Recipient{MessageID: sentMsg.ID, Localpart: "remote", Domain: "example.org", OrgDomain: "example.org", Sent: time.Now()})
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "inserting message recipient")
|
|
|
|
|
|
2023-11-01 19:55:40 +03:00
|
|
|
|
// Reject a message due to DMARC again. Since we sent a message to the domain, it
|
|
|
|
|
// is no longer unknown and we should see a non-optional evaluation that will
|
|
|
|
|
// result in a DMARC report.
|
|
|
|
|
resolver.TXT["example.org."] = []string{"v=spf1 ip4:127.0.0.1 -all"}
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("attempt to deliver spamy message, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
l := checkEvaluationCount(t, 2) // New evaluation.
|
|
|
|
|
tcompare(t, l[1].Optional, false)
|
|
|
|
|
})
|
|
|
|
|
|
2023-01-30 16:27:06 +03:00
|
|
|
|
// We should now be accepting the message because we recently sent a message.
|
2023-11-01 19:55:40 +03:00
|
|
|
|
resolver.TXT["example.org."] = []string{"v=spf1 ip4:127.0.0.10 -all"}
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
2023-11-01 19:55:40 +03:00
|
|
|
|
l := checkEvaluationCount(t, 3) // New evaluation.
|
|
|
|
|
tcompare(t, l[2].Optional, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test DNSBL, then getting through with subjectpass.
|
|
|
|
|
func TestBlocklistedSubjectpass(t *testing.T) {
|
|
|
|
|
// Set up a DNSBL on dnsbl.example, and get DMARC pass.
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
"2.0.0.127.dnsbl.example.": {"127.0.0.2"}, // For healthcheck.
|
|
|
|
|
"10.0.0.127.dnsbl.example.": {"127.0.0.10"}, // Where our connection pretends to come from.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
|
|
|
|
"10.0.0.127.dnsbl.example.": {"blocklisted"},
|
|
|
|
|
"example.org.": {"v=spf1 ip4:127.0.0.10 -all"},
|
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject"},
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"example.org."}, // For iprev check.
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
ts.dnsbls = []dns.Domain{{ASCII: "dnsbl.example"}}
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
// Message should be refused softly (temporary error) due to DNSBL.
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C451LocalErr {
|
|
|
|
|
t.Fatalf("attempted deliver from dnsblocklisted ip, got err %v, expected smtpclient.Error with code %d", err, smtp.C451LocalErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
// Set up subjectpass on account.
|
|
|
|
|
acc := mox.Conf.Dynamic.Accounts[ts.acc.Name]
|
|
|
|
|
acc.SubjectPass.Period = time.Hour
|
|
|
|
|
mox.Conf.Dynamic.Accounts[ts.acc.Name] = acc
|
|
|
|
|
|
|
|
|
|
// Message should be refused quickly (permanent error) due to DNSBL and Subjectkey.
|
|
|
|
|
var pass string
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C550MailboxUnavail {
|
|
|
|
|
t.Fatalf("attempted deliver from dnsblocklisted ip, got err %v, expected smtpclient.Error with code %d", err, smtp.C550MailboxUnavail)
|
|
|
|
|
}
|
|
|
|
|
i := strings.Index(cerr.Line, subjectpass.Explanation)
|
|
|
|
|
if i < 0 {
|
|
|
|
|
t.Fatalf("got error line %q, expected error line with subjectpass", cerr.Line)
|
|
|
|
|
}
|
|
|
|
|
pass = cerr.Line[i+len(subjectpass.Explanation):]
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
passMessage := strings.Replace(deliverMessage, "Subject: test", "Subject: test "+pass, 1)
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(passMessage)), strings.NewReader(passMessage), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver with subjectpass")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test accepting a DMARC report.
|
|
|
|
|
func TestDMARCReport(t *testing.T) {
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
|
|
|
|
"example.org.": {"v=spf1 ip4:127.0.0.10 -all"},
|
2023-11-01 19:55:40 +03:00
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject; rua=mailto:dmarcrpt@example.org"},
|
2023-01-30 16:27:06 +03:00
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"example.org."}, // For iprev check.
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/dmarcreport/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
run := func(report string, n int) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
tcheck(t, err, "run")
|
|
|
|
|
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
|
|
|
|
|
msgb := &bytes.Buffer{}
|
|
|
|
|
_, xerr := fmt.Fprintf(msgb, "From: %s\r\nTo: %s\r\nSubject: dmarc report\r\nMIME-Version: 1.0\r\nContent-Type: text/xml\r\n\r\n", mailFrom, rcptTo)
|
|
|
|
|
tcheck(t, xerr, "write msg headers")
|
|
|
|
|
w := quotedprintable.NewWriter(msgb)
|
|
|
|
|
_, xerr = w.Write([]byte(strings.ReplaceAll(report, "\n", "\r\n")))
|
|
|
|
|
tcheck(t, xerr, "write message")
|
|
|
|
|
msg := msgb.String()
|
|
|
|
|
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
records, err := dmarcdb.Records(ctxbg)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "dmarcdb records")
|
|
|
|
|
if len(records) != n {
|
|
|
|
|
t.Fatalf("got %d dmarcdb records, expected %d or more", len(records), n)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
run(dmarcReport, 0)
|
|
|
|
|
run(strings.ReplaceAll(dmarcReport, "xmox.nl", "mox.example"), 1)
|
2023-11-01 19:55:40 +03:00
|
|
|
|
|
|
|
|
|
// We always store as an evaluation, but as optional for reports.
|
|
|
|
|
evals := checkEvaluationCount(t, 2)
|
|
|
|
|
tcompare(t, evals[0].Optional, true)
|
|
|
|
|
tcompare(t, evals[1].Optional, true)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const dmarcReport = `<?xml version="1.0" encoding="UTF-8" ?>
|
|
|
|
|
<feedback>
|
|
|
|
|
<report_metadata>
|
|
|
|
|
<org_name>example.org</org_name>
|
|
|
|
|
<email>postmaster@example.org</email>
|
|
|
|
|
<report_id>1</report_id>
|
|
|
|
|
<date_range>
|
|
|
|
|
<begin>1596412800</begin>
|
|
|
|
|
<end>1596499199</end>
|
|
|
|
|
</date_range>
|
|
|
|
|
</report_metadata>
|
|
|
|
|
<policy_published>
|
|
|
|
|
<domain>xmox.nl</domain>
|
|
|
|
|
<adkim>r</adkim>
|
|
|
|
|
<aspf>r</aspf>
|
|
|
|
|
<p>reject</p>
|
|
|
|
|
<sp>reject</sp>
|
|
|
|
|
<pct>100</pct>
|
|
|
|
|
</policy_published>
|
|
|
|
|
<record>
|
|
|
|
|
<row>
|
|
|
|
|
<source_ip>127.0.0.10</source_ip>
|
|
|
|
|
<count>1</count>
|
|
|
|
|
<policy_evaluated>
|
|
|
|
|
<disposition>none</disposition>
|
|
|
|
|
<dkim>pass</dkim>
|
|
|
|
|
<spf>pass</spf>
|
|
|
|
|
</policy_evaluated>
|
|
|
|
|
</row>
|
|
|
|
|
<identifiers>
|
|
|
|
|
<header_from>xmox.nl</header_from>
|
|
|
|
|
</identifiers>
|
|
|
|
|
<auth_results>
|
|
|
|
|
<dkim>
|
|
|
|
|
<domain>xmox.nl</domain>
|
|
|
|
|
<result>pass</result>
|
|
|
|
|
<selector>testsel</selector>
|
|
|
|
|
</dkim>
|
|
|
|
|
<spf>
|
|
|
|
|
<domain>xmox.nl</domain>
|
|
|
|
|
<result>pass</result>
|
|
|
|
|
</spf>
|
|
|
|
|
</auth_results>
|
|
|
|
|
</record>
|
|
|
|
|
</feedback>
|
|
|
|
|
`
|
|
|
|
|
|
|
|
|
|
// Test accepting a TLS report.
|
|
|
|
|
func TestTLSReport(t *testing.T) {
|
|
|
|
|
// Requires setting up DKIM.
|
|
|
|
|
privKey := ed25519.NewKeyFromSeed(make([]byte, ed25519.SeedSize)) // Fake key, don't use this for real!
|
|
|
|
|
dkimRecord := dkim.Record{
|
|
|
|
|
Version: "DKIM1",
|
|
|
|
|
Hashes: []string{"sha256"},
|
|
|
|
|
Flags: []string{"s"},
|
|
|
|
|
PublicKey: privKey.Public(),
|
|
|
|
|
Key: "ed25519",
|
|
|
|
|
}
|
|
|
|
|
dkimTxt, err := dkimRecord.Record()
|
|
|
|
|
tcheck(t, err, "dkim record")
|
|
|
|
|
|
|
|
|
|
sel := config.Selector{
|
|
|
|
|
HashEffective: "sha256",
|
|
|
|
|
HeadersEffective: []string{"From", "To", "Subject", "Date"},
|
|
|
|
|
Key: privKey,
|
|
|
|
|
Domain: dns.Domain{ASCII: "testsel"},
|
|
|
|
|
}
|
|
|
|
|
dkimConf := config.DKIM{
|
|
|
|
|
Selectors: map[string]config.Selector{"testsel": sel},
|
|
|
|
|
Sign: []string{"testsel"},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
resolver := &dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
TXT: map[string][]string{
|
|
|
|
|
"testsel._domainkey.example.org.": {dkimTxt},
|
2023-11-01 19:55:40 +03:00
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject;rua=mailto:dmarcrpt@example.org"},
|
2023-01-30 16:27:06 +03:00
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"example.org."}, // For iprev check.
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/tlsrpt/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
2023-11-13 15:48:52 +03:00
|
|
|
|
run := func(rcptTo, tlsrpt string, n int) {
|
2023-01-30 16:27:06 +03:00
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
|
|
|
|
|
msgb := &bytes.Buffer{}
|
|
|
|
|
_, xerr := fmt.Fprintf(msgb, "From: %s\r\nTo: %s\r\nSubject: tlsrpt report\r\nMIME-Version: 1.0\r\nContent-Type: application/tlsrpt+json\r\n\r\n%s\r\n", mailFrom, rcptTo, tlsrpt)
|
|
|
|
|
tcheck(t, xerr, "write msg")
|
|
|
|
|
msg := msgb.String()
|
|
|
|
|
|
2023-12-05 23:13:57 +03:00
|
|
|
|
selectors := mox.DKIMSelectors(dkimConf)
|
|
|
|
|
headers, xerr := dkim.Sign(ctxbg, pkglog.Logger, "remote", dns.Domain{ASCII: "example.org"}, selectors, false, strings.NewReader(msg))
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, xerr, "dkim sign")
|
|
|
|
|
msg = headers + msg
|
|
|
|
|
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, false)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
records, err := tlsrptdb.Records(ctxbg)
|
2023-01-30 16:27:06 +03:00
|
|
|
|
tcheck(t, err, "tlsrptdb records")
|
|
|
|
|
if len(records) != n {
|
|
|
|
|
t.Fatalf("got %d tlsrptdb records, expected %d", len(records), n)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const tlsrpt = `{"organization-name":"Example.org","date-range":{"start-datetime":"2022-01-07T00:00:00Z","end-datetime":"2022-01-07T23:59:59Z"},"contact-info":"tlsrpt@example.org","report-id":"1","policies":[{"policy":{"policy-type":"no-policy-found","policy-domain":"xmox.nl"},"summary":{"total-successful-session-count":1,"total-failure-session-count":0}}]}`
|
|
|
|
|
|
2023-11-13 15:48:52 +03:00
|
|
|
|
run("mjl@mox.example", tlsrpt, 0)
|
|
|
|
|
run("mjl@mox.example", strings.ReplaceAll(tlsrpt, "xmox.nl", "mox.example"), 1)
|
|
|
|
|
run("mjl@mailhost.mox.example", strings.ReplaceAll(tlsrpt, "xmox.nl", "mailhost.mox.example"), 2)
|
2023-11-01 19:55:40 +03:00
|
|
|
|
|
|
|
|
|
// We always store as an evaluation, but as optional for reports.
|
2023-11-13 15:48:52 +03:00
|
|
|
|
evals := checkEvaluationCount(t, 3)
|
2023-11-01 19:55:40 +03:00
|
|
|
|
tcompare(t, evals[0].Optional, true)
|
|
|
|
|
tcompare(t, evals[1].Optional, true)
|
2023-11-13 15:48:52 +03:00
|
|
|
|
tcompare(t, evals[2].Optional, true)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestRatelimitConnectionrate(t *testing.T) {
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
2023-02-08 00:56:03 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
// We'll be creating 300 connections, no TLS and reduce noise.
|
|
|
|
|
ts.tlsmode = smtpclient.TLSSkip
|
2023-12-05 15:35:58 +03:00
|
|
|
|
mlog.SetConfig(map[string]slog.Level{"": mlog.LevelInfo})
|
2023-02-08 00:56:03 +03:00
|
|
|
|
|
|
|
|
|
// We may be passing a window boundary during this tests. The limit is 300/minute.
|
|
|
|
|
// So make twice that many connections and hope the tests don't take too long.
|
|
|
|
|
for i := 0; i <= 2*300; i++ {
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
if err != nil && i < 300 {
|
|
|
|
|
t.Fatalf("expected smtp connection, got %v", err)
|
|
|
|
|
}
|
|
|
|
|
if err == nil && i == 600 {
|
|
|
|
|
t.Fatalf("expected no smtp connection due to connection rate limit, got connection")
|
|
|
|
|
}
|
|
|
|
|
if client != nil {
|
|
|
|
|
client.Close()
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestRatelimitAuth(t *testing.T) {
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
2023-02-08 00:56:03 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.submission = true
|
|
|
|
|
ts.tlsmode = smtpclient.TLSSkip
|
|
|
|
|
ts.user = "bad"
|
|
|
|
|
ts.pass = "bad"
|
|
|
|
|
|
|
|
|
|
// We may be passing a window boundary during this tests. The limit is 10 auth
|
|
|
|
|
// failures/minute. So make twice that many connections and hope the tests don't
|
|
|
|
|
// take too long.
|
|
|
|
|
for i := 0; i <= 2*10; i++ {
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Fatalf("got auth success with bad credentials")
|
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
badauth := errors.As(err, &cerr) && cerr.Code == smtp.C535AuthBadCreds
|
|
|
|
|
if !badauth && i < 10 {
|
|
|
|
|
t.Fatalf("expected auth failure, got %v", err)
|
|
|
|
|
}
|
|
|
|
|
if badauth && i == 20 {
|
|
|
|
|
t.Fatalf("expected no smtp connection due to failed auth rate limit, got other error %v", err)
|
|
|
|
|
}
|
|
|
|
|
if client != nil {
|
|
|
|
|
client.Close()
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestRatelimitDelivery(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"example.org."},
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
orig := limitIPMasked1MessagesPerMinute
|
|
|
|
|
limitIPMasked1MessagesPerMinute = 1
|
|
|
|
|
defer func() {
|
|
|
|
|
limitIPMasked1MessagesPerMinute = orig
|
|
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver to remote")
|
2023-01-30 16:27:06 +03:00
|
|
|
|
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C452StorageFull {
|
|
|
|
|
t.Fatalf("got err %v, expected smtpclient error with code 452 for storage full", err)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
limitIPMasked1MessagesPerMinute = orig
|
|
|
|
|
|
|
|
|
|
origSize := limitIPMasked1SizePerMinute
|
|
|
|
|
// Message was already delivered once. We'll do another one. But the 3rd will fail.
|
|
|
|
|
// We need the actual size with prepended headers, since that is used in the
|
|
|
|
|
// calculations.
|
2023-05-22 15:40:36 +03:00
|
|
|
|
msg, err := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB).Get()
|
2023-02-08 00:56:03 +03:00
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("getting delivered message for its size: %v", err)
|
|
|
|
|
}
|
|
|
|
|
limitIPMasked1SizePerMinute = 2*msg.Size + int64(len(deliverMessage)/2)
|
|
|
|
|
defer func() {
|
|
|
|
|
limitIPMasked1SizePerMinute = origSize
|
|
|
|
|
}()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver to remote")
|
|
|
|
|
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-02-08 00:56:03 +03:00
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != smtp.C452StorageFull {
|
|
|
|
|
t.Fatalf("got err %v, expected smtpclient error with code 452 for storage full", err)
|
|
|
|
|
}
|
|
|
|
|
})
|
2023-01-30 16:27:06 +03:00
|
|
|
|
}
|
2023-03-10 12:23:43 +03:00
|
|
|
|
|
|
|
|
|
func TestNonSMTP(t *testing.T) {
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
2023-03-10 12:23:43 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
ts.cid += 2
|
|
|
|
|
|
|
|
|
|
serverConn, clientConn := net.Pipe()
|
|
|
|
|
defer serverConn.Close()
|
|
|
|
|
serverdone := make(chan struct{})
|
|
|
|
|
defer func() { <-serverdone }()
|
|
|
|
|
|
|
|
|
|
go func() {
|
|
|
|
|
tlsConfig := &tls.Config{
|
|
|
|
|
Certificates: []tls.Certificate{fakeCert(ts.t)},
|
|
|
|
|
}
|
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
|
|
|
|
serve("test", ts.cid-2, dns.Domain{ASCII: "mox.example"}, tlsConfig, serverConn, ts.resolver, ts.submission, false, 100<<20, false, false, false, ts.dnsbls, 0)
|
2023-03-10 12:23:43 +03:00
|
|
|
|
close(serverdone)
|
|
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
defer clientConn.Close()
|
|
|
|
|
|
|
|
|
|
buf := make([]byte, 128)
|
|
|
|
|
|
|
|
|
|
// Read and ignore hello.
|
|
|
|
|
if _, err := clientConn.Read(buf); err != nil {
|
|
|
|
|
t.Fatalf("reading hello: %v", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if _, err := fmt.Fprintf(clientConn, "bogus\r\n"); err != nil {
|
|
|
|
|
t.Fatalf("write command: %v", err)
|
|
|
|
|
}
|
|
|
|
|
n, err := clientConn.Read(buf)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("read response line: %v", err)
|
|
|
|
|
}
|
|
|
|
|
s := string(buf[:n])
|
|
|
|
|
if !strings.HasPrefix(s, "500 5.5.2 ") {
|
|
|
|
|
t.Fatalf(`got %q, expected "500 5.5.2 ...`, s)
|
|
|
|
|
}
|
|
|
|
|
if _, err := clientConn.Read(buf); err == nil {
|
|
|
|
|
t.Fatalf("connection not closed after bogus command")
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-03-28 21:50:36 +03:00
|
|
|
|
|
|
|
|
|
// Test limits on outgoing messages.
|
|
|
|
|
func TestLimitOutgoing(t *testing.T) {
|
2023-11-09 20:19:47 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtpserversendlimit/mox.conf"), dns.MockResolver{})
|
2023-03-28 21:50:36 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.user = "mjl@mox.example"
|
2024-03-09 01:29:15 +03:00
|
|
|
|
ts.pass = password0
|
2023-03-28 21:50:36 +03:00
|
|
|
|
ts.submission = true
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
err := ts.acc.DB.Insert(ctxbg, &store.Outgoing{Recipient: "a@other.example", Submitted: time.Now().Add(-24*time.Hour - time.Minute)})
|
2023-03-28 21:50:36 +03:00
|
|
|
|
tcheck(t, err, "inserting outgoing/recipient past 24h window")
|
|
|
|
|
|
|
|
|
|
testSubmit := func(rcptTo string, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
mailFrom := "mjl@mox.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(submitMessage)), strings.NewReader(submitMessage), false, false, false)
|
2023-03-28 21:50:36 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Limits are set to 4 messages a day, 2 first-time recipients.
|
|
|
|
|
testSubmit("b@other.example", nil)
|
|
|
|
|
testSubmit("c@other.example", nil)
|
|
|
|
|
testSubmit("d@other.example", &smtpclient.Error{Code: smtp.C451LocalErr, Secode: smtp.SePol7DeliveryUnauth1}) // Would be 3rd recipient.
|
|
|
|
|
testSubmit("b@other.example", nil)
|
|
|
|
|
testSubmit("b@other.example", nil)
|
|
|
|
|
testSubmit("b@other.example", &smtpclient.Error{Code: smtp.C451LocalErr, Secode: smtp.SePol7DeliveryUnauth1}) // Would be 5th message.
|
|
|
|
|
}
|
2023-03-29 22:11:43 +03:00
|
|
|
|
|
2023-12-20 22:54:12 +03:00
|
|
|
|
// Test account size limit enforcement.
|
|
|
|
|
func TestQuota(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"other.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"other.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtpserverquota/mox.conf"), resolver)
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
testDeliver := func(rcptTo string, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
mailFrom := "mjl@other.example"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testDeliver("mjl@mox.example", &smtpclient.Error{Code: smtp.C452StorageFull, Secode: smtp.SeMailbox2Full2})
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-29 22:11:43 +03:00
|
|
|
|
// Test with catchall destination address.
|
|
|
|
|
func TestCatchall(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"other.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"other.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
2023-11-09 20:19:47 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtpservercatchall/mox.conf"), resolver)
|
2023-03-29 22:11:43 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
testDeliver := func(rcptTo string, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
mailFrom := "mjl@other.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(submitMessage)), strings.NewReader(submitMessage), false, false, false)
|
2023-03-29 22:11:43 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testDeliver("mjl@mox.example", nil) // Exact match.
|
|
|
|
|
testDeliver("mjl+test@mox.example", nil) // Domain localpart catchall separator.
|
|
|
|
|
testDeliver("MJL+TEST@mox.example", nil) // Again, and case insensitive.
|
|
|
|
|
testDeliver("unknown@mox.example", nil) // Catchall address, to account catchall.
|
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
|
n, err := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB).Count()
|
2023-03-29 22:11:43 +03:00
|
|
|
|
tcheck(t, err, "checking delivered messages")
|
|
|
|
|
tcompare(t, n, 3)
|
|
|
|
|
|
2023-12-05 15:35:58 +03:00
|
|
|
|
acc, err := store.OpenAccount(pkglog, "catchall")
|
2023-03-29 22:11:43 +03:00
|
|
|
|
tcheck(t, err, "open account")
|
2024-04-16 18:33:54 +03:00
|
|
|
|
defer func() {
|
|
|
|
|
acc.Close()
|
|
|
|
|
acc.CheckClosed()
|
|
|
|
|
}()
|
2023-05-22 15:40:36 +03:00
|
|
|
|
n, err = bstore.QueryDB[store.Message](ctxbg, acc.DB).Count()
|
2023-03-29 22:11:43 +03:00
|
|
|
|
tcheck(t, err, "checking delivered messages to catchall account")
|
|
|
|
|
tcompare(t, n, 1)
|
|
|
|
|
}
|
2023-03-30 11:38:36 +03:00
|
|
|
|
|
|
|
|
|
// Test DKIM signing for outgoing messages.
|
|
|
|
|
func TestDKIMSign(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"mox.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"mox.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
2023-03-30 11:38:36 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
// Set DKIM signing config.
|
|
|
|
|
var gen byte
|
|
|
|
|
genDKIM := func(domain string) string {
|
|
|
|
|
dom, _ := mox.Conf.Domain(dns.Domain{ASCII: domain})
|
|
|
|
|
|
|
|
|
|
privkey := make([]byte, ed25519.SeedSize) // Fake key, don't use for real.
|
|
|
|
|
gen++
|
|
|
|
|
privkey[0] = byte(gen)
|
|
|
|
|
|
|
|
|
|
sel := config.Selector{
|
|
|
|
|
HashEffective: "sha256",
|
|
|
|
|
HeadersEffective: []string{"From", "To", "Subject"},
|
|
|
|
|
Key: ed25519.NewKeyFromSeed(privkey),
|
|
|
|
|
Domain: dns.Domain{ASCII: "testsel"},
|
|
|
|
|
}
|
|
|
|
|
dom.DKIM = config.DKIM{
|
|
|
|
|
Selectors: map[string]config.Selector{"testsel": sel},
|
|
|
|
|
Sign: []string{"testsel"},
|
|
|
|
|
}
|
|
|
|
|
mox.Conf.Dynamic.Domains[domain] = dom
|
|
|
|
|
pubkey := sel.Key.Public().(ed25519.PublicKey)
|
|
|
|
|
return "v=DKIM1;k=ed25519;p=" + base64.StdEncoding.EncodeToString(pubkey)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dkimtxt := genDKIM("mox.example")
|
|
|
|
|
dkimtxt2 := genDKIM("mox2.example")
|
|
|
|
|
|
|
|
|
|
// DKIM verify needs to find the key.
|
|
|
|
|
resolver.TXT = map[string][]string{
|
|
|
|
|
"testsel._domainkey.mox.example.": {dkimtxt},
|
|
|
|
|
"testsel._domainkey.mox2.example.": {dkimtxt2},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ts.submission = true
|
|
|
|
|
ts.user = "mjl@mox.example"
|
2024-03-09 01:29:15 +03:00
|
|
|
|
ts.pass = password0
|
2023-03-30 11:38:36 +03:00
|
|
|
|
|
|
|
|
|
n := 0
|
|
|
|
|
testSubmit := func(mailFrom, msgFrom string) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
msg := strings.ReplaceAll(fmt.Sprintf(`From: <%s>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, msgFrom), "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
rcptTo := "remote@example.org"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, false)
|
2023-03-30 11:38:36 +03:00
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
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
|
|
|
|
msgs, err := queue.List(ctxbg, queue.Filter{}, queue.Sort{})
|
2023-03-30 11:38:36 +03:00
|
|
|
|
tcheck(t, err, "listing queue")
|
|
|
|
|
n++
|
|
|
|
|
tcompare(t, len(msgs), n)
|
|
|
|
|
sort.Slice(msgs, func(i, j int) bool {
|
|
|
|
|
return msgs[i].ID > msgs[j].ID
|
|
|
|
|
})
|
2023-05-22 15:40:36 +03:00
|
|
|
|
f, err := queue.OpenMessage(ctxbg, msgs[0].ID)
|
2023-03-30 11:38:36 +03:00
|
|
|
|
tcheck(t, err, "open message in queue")
|
|
|
|
|
defer f.Close()
|
2023-12-05 15:35:58 +03:00
|
|
|
|
results, err := dkim.Verify(ctxbg, pkglog.Logger, resolver, false, dkim.DefaultPolicy, f, false)
|
2023-03-30 11:38:36 +03:00
|
|
|
|
tcheck(t, err, "verifying dkim message")
|
|
|
|
|
tcompare(t, len(results), 1)
|
|
|
|
|
tcompare(t, results[0].Status, dkim.StatusPass)
|
|
|
|
|
tcompare(t, results[0].Sig.Domain.ASCII, strings.Split(msgFrom, "@")[1])
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testSubmit("mjl@mox.example", "mjl@mox.example")
|
|
|
|
|
testSubmit("mjl@mox.example", "mjl@mox2.example") // DKIM signature will be for mox2.example.
|
|
|
|
|
}
|
2023-04-24 13:04:46 +03:00
|
|
|
|
|
|
|
|
|
// Test to postmaster addresses.
|
|
|
|
|
func TestPostmaster(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"other.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"other.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/postmaster/mox.conf"), resolver)
|
2023-04-24 13:04:46 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
testDeliver := func(rcptTo string, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
mailFrom := "mjl@other.example"
|
|
|
|
|
if err == nil {
|
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
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(deliverMessage)), strings.NewReader(deliverMessage), false, false, false)
|
2023-04-24 13:04:46 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Code != expErr.Code || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testDeliver("postmaster", nil) // Plain postmaster address without domain.
|
|
|
|
|
testDeliver("postmaster@host.mox.example", nil) // Postmaster address with configured mail server hostname.
|
|
|
|
|
testDeliver("postmaster@mox.example", nil) // Postmaster address without explicitly configured destination.
|
|
|
|
|
testDeliver("postmaster@unknown.example", &smtpclient.Error{Code: smtp.C550MailboxUnavail, Secode: smtp.SeAddr1UnknownDestMailbox1})
|
|
|
|
|
}
|
2023-06-03 16:29:18 +03:00
|
|
|
|
|
|
|
|
|
// Test to address with empty localpart.
|
|
|
|
|
func TestEmptylocalpart(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"other.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"other.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
make mox compile on windows, without "mox serve" but with working "mox localserve"
getting mox to compile required changing code in only a few places where
package "syscall" was used: for accessing file access times and for umask
handling. an open problem is how to start a process as an unprivileged user on
windows. that's why "mox serve" isn't implemented yet. and just finding a way
to implement it now may not be good enough in the near future: we may want to
starting using a more complete privilege separation approach, with a process
handling sensitive tasks (handling private keys, authentication), where we may
want to pass file descriptors between processes. how would that work on
windows?
anyway, getting mox to compile for windows doesn't mean it works properly on
windows. the largest issue: mox would normally open a file, rename or remove
it, and finally close it. this happens during message delivery. that doesn't
work on windows, the rename/remove would fail because the file is still open.
so this commit swaps many "remove" and "close" calls. renames are a longer
story: message delivery had two ways to deliver: with "consuming" the
(temporary) message file (which would rename it to its final destination), and
without consuming (by hardlinking the file, falling back to copying). the last
delivery to a recipient of a message (and the only one in the common case of a
single recipient) would consume the message, and the earlier recipients would
not. during delivery, the already open message file was used, to parse the
message. we still want to use that open message file, and the caller now stays
responsible for closing it, but we no longer try to rename (consume) the file.
we always hardlink (or copy) during delivery (this works on windows), and the
caller is responsible for closing and removing (in that order) the original
temporary file. this does cost one syscall more. but it makes the delivery code
(responsibilities) a bit simpler.
there is one more obvious issue: the file system path separator. mox already
used the "filepath" package to join paths in many places, but not everywhere.
and it still used strings with slashes for local file access. with this commit,
the code now uses filepath.FromSlash for path strings with slashes, uses
"filepath" in a few more places where it previously didn't. also switches from
"filepath" to regular "path" package when handling mailbox names in a few
places, because those always use forward slashes, regardless of local file
system conventions. windows can handle forward slashes when opening files, so
test code that passes path strings with forward slashes straight to go stdlib
file i/o functions are left unchanged to reduce code churn. the regular
non-test code, or test code that uses path strings in places other than
standard i/o functions, does have the paths converted for consistent paths
(otherwise we would end up with paths with mixed forward/backward slashes in
log messages).
windows cannot dup a listening socket. for "mox localserve", it isn't
important, and we can work around the issue. the current approach for "mox
serve" (forking a process and passing file descriptors of listening sockets on
"privileged" ports) won't work on windows. perhaps it isn't needed on windows,
and any user can listen on "privileged" ports? that would be welcome.
on windows, os.Open cannot open a directory, so we cannot call Sync on it after
message delivery. a cursory internet search indicates that directories cannot
be synced on windows. the story is probably much more nuanced than that, with
long deep technical details/discussions/disagreement/confusion, like on unix.
for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
2023-06-03 16:29:18 +03:00
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
testDeliver := func(rcptTo string, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
2023-11-27 12:34:01 +03:00
|
|
|
|
|
2023-06-03 16:29:18 +03:00
|
|
|
|
mailFrom := `""@other.example`
|
2023-11-27 12:34:01 +03:00
|
|
|
|
msg := strings.ReplaceAll(deliverMessage, "To: <mjl@mox.example>", `To: <""@mox.example>`)
|
2023-06-03 16:29:18 +03:00
|
|
|
|
if err == nil {
|
2023-11-27 12:34:01 +03:00
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, false)
|
2023-06-03 16:29:18 +03:00
|
|
|
|
}
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Code != expErr.Code || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testDeliver(`""@mox.example`, nil)
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
|
// Test handling REQUIRETLS and TLS-Required: No.
|
|
|
|
|
func TestRequireTLS(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"mox.example.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"mox.example."},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), resolver)
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.submission = true
|
|
|
|
|
ts.requiretls = true
|
|
|
|
|
ts.user = "mjl@mox.example"
|
2024-03-09 01:29:15 +03:00
|
|
|
|
ts.pass = password0
|
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
|
|
|
|
|
|
|
|
|
no := false
|
|
|
|
|
yes := true
|
|
|
|
|
|
|
|
|
|
msg0 := strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
TLS-Required: No
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
msg1 := strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
TLS-Required: No
|
|
|
|
|
TLS-Required: bogus
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
msg2 := strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
testSubmit := func(msg string, requiretls bool, expRequireTLS *bool) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
rcptTo := "remote@example.org"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, "mjl@mox.example", rcptTo, int64(len(msg)), strings.NewReader(msg), false, false, requiretls)
|
|
|
|
|
}
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
|
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
|
|
|
|
msgs, err := queue.List(ctxbg, queue.Filter{}, queue.Sort{})
|
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
|
|
|
|
tcheck(t, err, "listing queue")
|
|
|
|
|
tcompare(t, len(msgs), 1)
|
|
|
|
|
tcompare(t, msgs[0].RequireTLS, expRequireTLS)
|
2024-03-18 10:50:42 +03:00
|
|
|
|
_, err = queue.Drop(ctxbg, pkglog, queue.Filter{IDs: []int64{msgs[0].ID}})
|
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
|
|
|
|
tcheck(t, err, "deleting message from queue")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
testSubmit(msg0, true, &yes) // Header ignored, requiretls applied.
|
|
|
|
|
testSubmit(msg0, false, &no) // TLS-Required header applied.
|
|
|
|
|
testSubmit(msg1, true, &yes) // Bad headers ignored, requiretls applied.
|
|
|
|
|
testSubmit(msg1, false, nil) // Inconsistent multiple headers ignored.
|
|
|
|
|
testSubmit(msg2, false, nil) // Regular message, no RequireTLS setting.
|
|
|
|
|
testSubmit(msg2, true, &yes) // Requiretls applied.
|
|
|
|
|
|
|
|
|
|
// Check that we get an error if remote SMTP server does not support the requiretls
|
|
|
|
|
// extension.
|
|
|
|
|
ts.requiretls = false
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
rcptTo := "remote@example.org"
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = client.Deliver(ctxbg, "mjl@mox.example", rcptTo, int64(len(msg0)), strings.NewReader(msg0), false, false, true)
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Fatalf("delivered with requiretls to server without requiretls")
|
|
|
|
|
}
|
|
|
|
|
if !errors.Is(err, smtpclient.ErrRequireTLSUnsupported) {
|
|
|
|
|
t.Fatalf("got err %v, expected ErrRequireTLSUnsupported", err)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
2024-01-01 20:30:31 +03:00
|
|
|
|
|
|
|
|
|
func TestSmuggle(t *testing.T) {
|
|
|
|
|
resolver := dns.MockResolver{
|
|
|
|
|
A: map[string][]string{
|
|
|
|
|
"example.org.": {"127.0.0.10"}, // For mx check.
|
|
|
|
|
},
|
|
|
|
|
PTR: map[string][]string{
|
|
|
|
|
"127.0.0.10": {"example.org."}, // For iprev check.
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtpsmuggle/mox.conf"), resolver)
|
|
|
|
|
ts.tlsmode = smtpclient.TLSSkip
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
test := func(data string) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ts.runRaw(func(conn net.Conn) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ourHostname := mox.Conf.Static.HostnameDomain
|
|
|
|
|
remoteHostname := dns.Domain{ASCII: "mox.example"}
|
|
|
|
|
opts := smtpclient.Opts{
|
|
|
|
|
RootCAs: mox.Conf.Static.TLS.CertPool,
|
|
|
|
|
}
|
|
|
|
|
log := pkglog.WithCid(ts.cid - 1)
|
|
|
|
|
_, err := smtpclient.New(ctxbg, log.Logger, conn, ts.tlsmode, ts.tlspkix, ourHostname, remoteHostname, opts)
|
|
|
|
|
tcheck(t, err, "smtpclient")
|
|
|
|
|
defer conn.Close()
|
|
|
|
|
|
|
|
|
|
write := func(s string) {
|
|
|
|
|
_, err := conn.Write([]byte(s))
|
|
|
|
|
tcheck(t, err, "write")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
readPrefixLine := func(prefix string) string {
|
|
|
|
|
t.Helper()
|
|
|
|
|
buf := make([]byte, 512)
|
|
|
|
|
n, err := conn.Read(buf)
|
|
|
|
|
tcheck(t, err, "read")
|
|
|
|
|
s := strings.TrimRight(string(buf[:n]), "\r\n")
|
|
|
|
|
if !strings.HasPrefix(s, prefix) {
|
|
|
|
|
t.Fatalf("got smtp response %q, expected line with prefix %q", s, prefix)
|
|
|
|
|
}
|
|
|
|
|
return s
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
write("MAIL FROM:<remote@example.org>\r\n")
|
|
|
|
|
readPrefixLine("2")
|
|
|
|
|
write("RCPT TO:<mjl@mox.example>\r\n")
|
|
|
|
|
readPrefixLine("2")
|
|
|
|
|
|
|
|
|
|
write("DATA\r\n")
|
|
|
|
|
readPrefixLine("3")
|
|
|
|
|
write("\r\n") // Empty header.
|
|
|
|
|
write(data)
|
|
|
|
|
write("\r\n.\r\n") // End of message.
|
|
|
|
|
line := readPrefixLine("5")
|
|
|
|
|
if !strings.Contains(line, "smug") {
|
|
|
|
|
t.Errorf("got 5xx error with message %q, expected error text containing smug", line)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("\r\n.\n")
|
|
|
|
|
test("\n.\n")
|
|
|
|
|
test("\r.\r")
|
|
|
|
|
test("\n.\r\n")
|
|
|
|
|
}
|
2024-02-10 19:55:56 +03:00
|
|
|
|
|
|
|
|
|
func TestFutureRelease(t *testing.T) {
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
|
|
|
|
ts.tlsmode = smtpclient.TLSSkip
|
|
|
|
|
ts.user = "mjl@mox.example"
|
2024-03-09 01:29:15 +03:00
|
|
|
|
ts.pass = password0
|
2024-02-10 19:55:56 +03:00
|
|
|
|
ts.submission = true
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.auth = func(mechanisms []string, cs *tls.ConnectionState) (sasl.Client, error) {
|
|
|
|
|
return sasl.NewClientPlain(ts.user, ts.pass), nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test := func(mailtoMore, expResponsePrefix string) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ts.runRaw(func(conn net.Conn) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ourHostname := mox.Conf.Static.HostnameDomain
|
|
|
|
|
remoteHostname := dns.Domain{ASCII: "mox.example"}
|
|
|
|
|
opts := smtpclient.Opts{Auth: ts.auth}
|
|
|
|
|
log := pkglog.WithCid(ts.cid - 1)
|
|
|
|
|
_, err := smtpclient.New(ctxbg, log.Logger, conn, ts.tlsmode, false, ourHostname, remoteHostname, opts)
|
|
|
|
|
tcheck(t, err, "smtpclient")
|
|
|
|
|
defer conn.Close()
|
|
|
|
|
|
|
|
|
|
write := func(s string) {
|
|
|
|
|
_, err := conn.Write([]byte(s))
|
|
|
|
|
tcheck(t, err, "write")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
readPrefixLine := func(prefix string) string {
|
|
|
|
|
t.Helper()
|
|
|
|
|
buf := make([]byte, 512)
|
|
|
|
|
n, err := conn.Read(buf)
|
|
|
|
|
tcheck(t, err, "read")
|
|
|
|
|
s := strings.TrimRight(string(buf[:n]), "\r\n")
|
|
|
|
|
if !strings.HasPrefix(s, prefix) {
|
|
|
|
|
t.Fatalf("got smtp response %q, expected line with prefix %q", s, prefix)
|
|
|
|
|
}
|
|
|
|
|
return s
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
write(fmt.Sprintf("MAIL FROM:<mjl@mox.example>%s\r\n", mailtoMore))
|
|
|
|
|
readPrefixLine(expResponsePrefix)
|
|
|
|
|
if expResponsePrefix != "2" {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
write("RCPT TO:<mjl@mox.example>\r\n")
|
|
|
|
|
readPrefixLine("2")
|
|
|
|
|
|
|
|
|
|
write("DATA\r\n")
|
|
|
|
|
readPrefixLine("3")
|
|
|
|
|
write("From: <mjl@mox.example>\r\n\r\nbody\r\n\r\n.\r\n")
|
|
|
|
|
readPrefixLine("2")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test(" HOLDFOR=1", "2")
|
|
|
|
|
test(" HOLDUNTIL="+time.Now().Add(time.Minute).UTC().Format(time.RFC3339), "2")
|
|
|
|
|
test(" HOLDUNTIL="+time.Now().Add(time.Minute).UTC().Format(time.RFC3339Nano), "2")
|
|
|
|
|
|
|
|
|
|
test(" HOLDFOR=0", "501") // 0 is invalid syntax.
|
|
|
|
|
test(fmt.Sprintf(" HOLDFOR=%d", int64((queue.FutureReleaseIntervalMax+time.Minute)/time.Second)), "554") // Too far in the future.
|
|
|
|
|
test(" HOLDUNTIL="+time.Now().Add(-time.Minute).UTC().Format(time.RFC3339), "554") // In the past.
|
|
|
|
|
test(" HOLDUNTIL="+time.Now().Add(queue.FutureReleaseIntervalMax+time.Minute).UTC().Format(time.RFC3339), "554") // Too far in the future.
|
|
|
|
|
test(" HOLDUNTIL=2024-02-10T17:28:00+00:00", "501") // "Z" required.
|
|
|
|
|
test(" HOLDUNTIL=24-02-10T17:28:00Z", "501") // Invalid.
|
|
|
|
|
test(" HOLDFOR=1 HOLDFOR=1", "501") // Duplicate.
|
|
|
|
|
test(" HOLDFOR=1 HOLDUNTIL="+time.Now().Add(time.Hour).UTC().Format(time.RFC3339), "501") // Duplicate.
|
|
|
|
|
}
|
2024-03-31 16:23:53 +03:00
|
|
|
|
|
|
|
|
|
// Test SMTPUTF8
|
|
|
|
|
func TestSMTPUTF8(t *testing.T) {
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.user = "mjl@mox.example"
|
|
|
|
|
ts.pass = password0
|
|
|
|
|
ts.submission = true
|
|
|
|
|
|
|
|
|
|
test := func(mailFrom string, rcptTo string, headerValue string, filename string, clientSmtputf8 bool, expectedSmtputf8 bool, expErr *smtpclient.Error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ts.run(func(_ error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
msg := strings.ReplaceAll(fmt.Sprintf(`From: <%s>
|
|
|
|
|
To: <%s>
|
|
|
|
|
Subject: test
|
|
|
|
|
X-Custom-Test-Header: %s
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
Content-type: multipart/mixed; boundary="simple boundary"
|
|
|
|
|
|
|
|
|
|
--simple boundary
|
|
|
|
|
Content-Type: text/plain; charset=UTF-8;
|
|
|
|
|
Content-Disposition: attachment; filename="%s"
|
|
|
|
|
Content-Transfer-Encoding: base64
|
|
|
|
|
|
|
|
|
|
QW4gYXR0YWNoZWQgdGV4dCBmaWxlLg==
|
|
|
|
|
|
|
|
|
|
--simple boundary--
|
|
|
|
|
`, mailFrom, rcptTo, headerValue, filename), "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
err := client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(msg)), strings.NewReader(msg), true, clientSmtputf8, false)
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
if expErr == nil && err != nil || expErr != nil && (err == nil || !errors.As(err, &cerr) || cerr.Code != expErr.Code || cerr.Secode != expErr.Secode) {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
if err != nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
msgs, _ := queue.List(ctxbg, queue.Filter{}, queue.Sort{Field: "Queued", Asc: false})
|
|
|
|
|
queuedMsg := msgs[0]
|
2024-03-31 16:23:53 +03:00
|
|
|
|
if queuedMsg.SMTPUTF8 != expectedSmtputf8 {
|
|
|
|
|
t.Fatalf("[%s / %s / %s / %s] got SMTPUTF8 %t, expected %t", mailFrom, rcptTo, headerValue, filename, queuedMsg.SMTPUTF8, expectedSmtputf8)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test(`mjl@mox.example`, `remote@example.org`, "header-ascii", "ascii.txt", false, false, nil)
|
|
|
|
|
test(`mjl@mox.example`, `remote@example.org`, "header-ascii", "ascii.txt", true, false, nil)
|
|
|
|
|
test(`mjl@mox.example`, `🙂@example.org`, "header-ascii", "ascii.txt", true, true, nil)
|
|
|
|
|
test(`mjl@mox.example`, `🙂@example.org`, "header-ascii", "ascii.txt", false, true, &smtpclient.Error{Permanent: true, Code: smtp.C553BadMailbox, Secode: smtp.SeMsg6NonASCIIAddrNotPermitted7})
|
|
|
|
|
test(`Ω@mox.example`, `remote@example.org`, "header-ascii", "ascii.txt", true, true, nil)
|
|
|
|
|
test(`Ω@mox.example`, `remote@example.org`, "header-ascii", "ascii.txt", false, true, &smtpclient.Error{Permanent: true, Code: smtp.C550MailboxUnavail, Secode: smtp.SeMsg6NonASCIIAddrNotPermitted7})
|
|
|
|
|
test(`mjl@mox.example`, `remote@example.org`, "header-utf8-😍", "ascii.txt", true, true, nil)
|
|
|
|
|
test(`mjl@mox.example`, `remote@example.org`, "header-utf8-😍", "ascii.txt", false, true, nil)
|
|
|
|
|
test(`mjl@mox.example`, `remote@example.org`, "header-ascii", "utf8-🫠️.txt", true, true, nil)
|
|
|
|
|
test(`Ω@mox.example`, `🙂@example.org`, "header-utf8-😍", "utf8-🫠️.txt", true, true, nil)
|
|
|
|
|
test(`mjl@mox.example`, `remote@xn--vg8h.example.org`, "header-ascii", "ascii.txt", true, false, nil)
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
|
// TestExtra checks whether submission of messages with "X-Mox-Extra-<key>: value"
|
|
|
|
|
// headers cause those those key/value pairs to be added to the Extra field in the
|
|
|
|
|
// queue.
|
|
|
|
|
func TestExtra(t *testing.T) {
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.user = "mjl@mox.example"
|
|
|
|
|
ts.pass = password0
|
|
|
|
|
ts.submission = true
|
|
|
|
|
|
|
|
|
|
extraMsg := strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
X-Mox-Extra-Test: testvalue
|
|
|
|
|
X-Mox-Extra-a: 123
|
|
|
|
|
X-Mox-Extra-☺: ☹
|
|
|
|
|
X-Mox-Extra-x-cANONICAL-z: ok
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
tcheck(t, err, "init client")
|
|
|
|
|
mailFrom := "mjl@mox.example"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(extraMsg)), strings.NewReader(extraMsg), true, true, false)
|
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
|
})
|
|
|
|
|
msgs, err := queue.List(ctxbg, queue.Filter{}, queue.Sort{})
|
|
|
|
|
tcheck(t, err, "queue list")
|
|
|
|
|
tcompare(t, len(msgs), 1)
|
|
|
|
|
tcompare(t, msgs[0].Extra, map[string]string{
|
|
|
|
|
"Test": "testvalue",
|
|
|
|
|
"A": "123",
|
|
|
|
|
"☺": "☹",
|
|
|
|
|
"X-Canonical-Z": "ok",
|
|
|
|
|
})
|
|
|
|
|
// note: these headers currently stay in the message.
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TestExtraDup checks for an error for duplicate x-mox-extra-* keys.
|
|
|
|
|
func TestExtraDup(t *testing.T) {
|
|
|
|
|
ts := newTestServer(t, filepath.FromSlash("../testdata/smtp/mox.conf"), dns.MockResolver{})
|
|
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
|
|
ts.user = "mjl@mox.example"
|
|
|
|
|
ts.pass = password0
|
|
|
|
|
ts.submission = true
|
|
|
|
|
|
|
|
|
|
extraMsg := strings.ReplaceAll(`From: <mjl@mox.example>
|
|
|
|
|
To: <remote@example.org>
|
|
|
|
|
Subject: test
|
|
|
|
|
X-Mox-Extra-Test: testvalue
|
|
|
|
|
X-Mox-Extra-Test: testvalue
|
|
|
|
|
Message-Id: <test@mox.example>
|
|
|
|
|
|
|
|
|
|
test email
|
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
|
|
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
tcheck(t, err, "init client")
|
|
|
|
|
mailFrom := "mjl@mox.example"
|
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
err = client.Deliver(ctxbg, mailFrom, rcptTo, int64(len(extraMsg)), strings.NewReader(extraMsg), true, true, false)
|
|
|
|
|
var cerr smtpclient.Error
|
|
|
|
|
expErr := smtpclient.Error{Code: smtp.C554TransactionFailed, Secode: smtp.SeMsg6Other0}
|
|
|
|
|
if err == nil || !errors.As(err, &cerr) || cerr.Code != expErr.Code || cerr.Secode != expErr.Secode {
|
|
|
|
|
t.Fatalf("got err %#v, expected %#v", err, expErr)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|