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"
|
|
|
|
"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
|
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
|
|
|
auth []sasl.Client
|
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
|
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-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)
|
|
|
|
var err error
|
|
|
|
ts.acc, err = store.OpenAccount("mjl")
|
|
|
|
tcheck(t, err, "open account")
|
|
|
|
err = ts.acc.SetPassword("testtest")
|
|
|
|
tcheck(t, err, "set password")
|
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")
|
|
|
|
ts.acc = nil
|
2023-01-30 16:27:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
func (ts *testserver) run(fn func(helloErr error, client *smtpclient.Client)) {
|
|
|
|
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)
|
|
|
|
}()
|
|
|
|
|
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
|
|
|
var auth []sasl.Client
|
|
|
|
if len(ts.auth) > 0 {
|
|
|
|
auth = ts.auth
|
|
|
|
} else if ts.user != "" {
|
|
|
|
auth = append(auth, sasl.NewClientPlain(ts.user, ts.pass))
|
2023-01-30 16:27:06 +03:00
|
|
|
}
|
|
|
|
|
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
|
|
|
ourHostname := mox.Conf.Static.HostnameDomain
|
|
|
|
remoteHostname := dns.Domain{ASCII: "mox.example"}
|
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
|
|
|
client, err := smtpclient.New(ctxbg, xlog.WithCid(ts.cid-1), clientConn, ts.tlsmode, ourHostname, remoteHostname, auth, nil, nil, nil)
|
2023-01-30 16:27:06 +03:00
|
|
|
if err != nil {
|
|
|
|
clientConn.Close()
|
|
|
|
} else {
|
|
|
|
defer client.Close()
|
|
|
|
}
|
|
|
|
fn(err, client)
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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
|
|
|
|
|
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 := func(authfn func(user, pass string) 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 {
|
|
|
|
ts.auth = []sasl.Client{authfn(user, pass)}
|
|
|
|
} 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
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
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})
|
|
|
|
authfns := []func(user, pass string) sasl.Client{
|
|
|
|
sasl.NewClientPlain,
|
|
|
|
sasl.NewClientCRAMMD5,
|
|
|
|
sasl.NewClientSCRAMSHA1,
|
|
|
|
sasl.NewClientSCRAMSHA256,
|
|
|
|
}
|
|
|
|
for _, fn := range authfns {
|
|
|
|
testAuth(fn, "mjl@mox.example", "test", &smtpclient.Error{Secode: smtp.SePol7AuthBadCreds8}) // Bad (short) password.
|
|
|
|
testAuth(fn, "mjl@mox.example", "testtesttest", &smtpclient.Error{Secode: smtp.SePol7AuthBadCreds8}) // Bad password.
|
|
|
|
testAuth(fn, "mjl@mox.example", "testtest", nil)
|
|
|
|
}
|
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."}
|
|
|
|
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 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")
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func tinsertmsg(t *testing.T, acc *store.Account, mailbox string, m *store.Message, msg string) {
|
|
|
|
mf, err := store.CreateMessageTemp("queue-dsn")
|
|
|
|
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")
|
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
|
|
|
err = acc.DeliverMailbox(xlog, 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-05-22 15:40:36 +03:00
|
|
|
jf, _, err := acc.OpenJunkFilter(ctxbg, xlog)
|
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"},
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject"},
|
|
|
|
},
|
|
|
|
}
|
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)
|
|
|
|
}
|
|
|
|
|
2023-08-09 19:03:29 +03:00
|
|
|
checkCount := func(mailboxName string, expect int) {
|
2023-01-30 16:27:06 +03:00
|
|
|
t.Helper()
|
2023-05-22 15:40:36 +03:00
|
|
|
q := bstore.QueryDB[store.Mailbox](ctxbg, ts.acc.DB)
|
2023-08-09 19:03:29 +03:00
|
|
|
q.FilterNonzero(store.Mailbox{Name: mailboxName})
|
2023-01-30 16:27:06 +03:00
|
|
|
mb, err := q.Get()
|
|
|
|
tcheck(t, err, "get rejects mailbox")
|
2023-05-22 15:40:36 +03:00
|
|
|
qm := bstore.QueryDB[store.Message](ctxbg, ts.acc.DB)
|
2023-01-30 16:27:06 +03:00
|
|
|
qm.FilterNonzero(store.Message{MailboxID: mb.ID})
|
2023-07-24 22:21:05 +03:00
|
|
|
qm.FilterEqual("Expunged", false)
|
2023-01-30 16:27:06 +03:00
|
|
|
n, err := qm.Count()
|
|
|
|
tcheck(t, err, "count messages in rejects mailbox")
|
|
|
|
if n != expect {
|
|
|
|
t.Fatalf("messages in rejects mailbox, found %d, expected %d", n, expect)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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)
|
|
|
|
}
|
|
|
|
|
2023-08-09 19:03:29 +03:00
|
|
|
checkCount("Rejects", 1)
|
|
|
|
})
|
|
|
|
|
|
|
|
// 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")
|
|
|
|
|
|
|
|
checkCount("mjl2junk", 1) // In ruleset rejects mailbox.
|
|
|
|
checkCount("Rejects", 1) // Same as before.
|
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.
|
|
|
|
checkCount("Rejects", 0)
|
|
|
|
checkCount("mjl2junk", 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-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"},
|
|
|
|
"_dmarc.bad.example.": {"v=DMARC1;p=reject"},
|
|
|
|
"_dmarc.good.example.": {"v=DMARC1;p=reject"},
|
|
|
|
"_dmarc.forward.example.": {"v=DMARC1;p=reject"},
|
|
|
|
},
|
|
|
|
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()
|
|
|
|
|
|
|
|
var msgBad = strings.ReplaceAll(`From: <remote@bad.example>
|
|
|
|
To: <mjl3@mox.example>
|
|
|
|
Subject: test
|
|
|
|
Message-Id: <bad@example.org>
|
|
|
|
|
|
|
|
test email
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
var msgOK = strings.ReplaceAll(`From: <remote@good.example>
|
|
|
|
To: <mjl3@mox.example>
|
|
|
|
Subject: other
|
|
|
|
Message-Id: <good@example.org>
|
|
|
|
|
|
|
|
unrelated message.
|
|
|
|
`, "\n", "\r\n")
|
|
|
|
var msgOK2 = strings.ReplaceAll(`From: <other@forward.example>
|
|
|
|
To: <mjl3@mox.example>
|
|
|
|
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")
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
// 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")
|
|
|
|
} 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)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
// 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"
|
|
|
|
|
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(msgOK2)), strings.NewReader(msgOK2), false, false, false)
|
2023-08-09 23:31:37 +03:00
|
|
|
if forward {
|
|
|
|
tcheck(t, err, "deliver")
|
|
|
|
} 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)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
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{
|
|
|
|
"example.org.": {"v=spf1 ip4:127.0.0.10 -all"},
|
|
|
|
"_dmarc.example.org.": {"v=DMARC1;p=reject"},
|
|
|
|
},
|
|
|
|
}
|
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 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)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
// 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")
|
|
|
|
|
|
|
|
// We should now be accepting the message because we recently sent a message.
|
|
|
|
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")
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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"},
|
|
|
|
"_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/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)
|
|
|
|
}
|
|
|
|
|
|
|
|
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},
|
|
|
|
"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/tlsrpt/mox.conf"), resolver)
|
2023-01-30 16:27:06 +03:00
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
run := func(tlsrpt string, n int) {
|
|
|
|
t.Helper()
|
|
|
|
ts.run(func(err error, client *smtpclient.Client) {
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
mailFrom := "remote@example.org"
|
|
|
|
rcptTo := "mjl@mox.example"
|
|
|
|
|
|
|
|
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-05-22 15:40:36 +03:00
|
|
|
headers, xerr := dkim.Sign(ctxbg, "remote", dns.Domain{ASCII: "example.org"}, dkimConf, 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}}]}`
|
|
|
|
|
|
|
|
run(tlsrpt, 0)
|
|
|
|
run(strings.ReplaceAll(tlsrpt, "xmox.nl", "mox.example"), 1)
|
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
|
|
|
|
mlog.SetConfig(map[string]mlog.Level{"": mlog.LevelInfo})
|
|
|
|
|
|
|
|
// 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) {
|
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/sendlimit/mox.conf"), dns.MockResolver{})
|
2023-03-28 21:50:36 +03:00
|
|
|
defer ts.close()
|
|
|
|
|
|
|
|
ts.user = "mjl@mox.example"
|
|
|
|
ts.pass = "testtest"
|
|
|
|
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
|
|
|
|
|
|
|
// 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."},
|
|
|
|
},
|
|
|
|
}
|
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/catchall/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)
|
|
|
|
|
|
|
|
acc, err := store.OpenAccount("catchall")
|
|
|
|
tcheck(t, err, "open account")
|
|
|
|
defer acc.Close()
|
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"
|
|
|
|
ts.pass = "testtest"
|
|
|
|
|
|
|
|
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")
|
|
|
|
|
2023-05-22 15:40:36 +03:00
|
|
|
msgs, err := queue.List(ctxbg)
|
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-05-22 15:40:36 +03:00
|
|
|
results, err := dkim.Verify(ctxbg, 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()
|
|
|
|
mailFrom := `""@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-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"
|
|
|
|
ts.pass = "testtest"
|
|
|
|
|
|
|
|
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")
|
|
|
|
|
|
|
|
msgs, err := queue.List(ctxbg)
|
|
|
|
tcheck(t, err, "listing queue")
|
|
|
|
tcompare(t, len(msgs), 1)
|
|
|
|
tcompare(t, msgs[0].RequireTLS, expRequireTLS)
|
|
|
|
_, err = queue.Drop(ctxbg, msgs[0].ID, "", "")
|
|
|
|
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)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|