2023-01-30 16:27:06 +03:00
package smtpclient
import (
"bufio"
"context"
"crypto/ed25519"
cryptorand "crypto/rand"
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
"crypto/sha1"
"crypto/sha256"
2023-01-30 16:27:06 +03:00
"crypto/tls"
"crypto/x509"
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
"encoding/base64"
2023-01-30 16:27:06 +03:00
"errors"
"fmt"
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
"hash"
2023-01-30 16:27:06 +03:00
"io"
2024-02-08 16:49:01 +03:00
"log/slog"
2023-01-30 16:27:06 +03:00
"math/big"
"net"
"reflect"
"strings"
"testing"
"time"
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/dns"
2023-01-30 16:27:06 +03:00
"github.com/mjl-/mox/mlog"
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"
"github.com/mjl-/mox/scram"
2023-01-30 16:27:06 +03:00
"github.com/mjl-/mox/smtp"
)
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 zerohost dns . Domain
var localhost = dns . Domain { ASCII : "localhost" }
2023-01-30 16:27:06 +03:00
func TestClient ( t * testing . T ) {
ctx := context . Background ( )
2023-12-05 15:35:58 +03:00
log := mlog . New ( "smtpclient" , nil )
2023-01-30 16:27:06 +03:00
2023-12-05 15:35:58 +03:00
mlog . SetConfig ( map [ string ] slog . Level { "" : mlog . LevelTrace } )
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
2023-01-30 16:27:06 +03:00
type options struct {
pipelining bool
ecodes bool
maxSize int
starttls bool
eightbitmime bool
smtputf8 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
ehlo 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
tlsMode TLSMode
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
tlsPKIX bool
roots * x509 . CertPool
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
tlsHostname dns . Domain
need8bitmime bool
needsmtputf8 bool
needsrequiretls bool
auths [ ] string // Allowed mechanisms.
2023-01-30 16:27:06 +03:00
nodeliver bool // For server, whether client will attempt a delivery.
}
// Make fake cert, and make it trusted.
cert := fakeCert ( t , false )
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
roots := x509 . NewCertPool ( )
roots . AddCert ( cert . Leaf )
2023-01-30 16:27:06 +03:00
tlsConfig := tls . Config {
Certificates : [ ] tls . Certificate { cert } ,
}
2023-12-24 01:07:21 +03:00
test := func ( msg string , opts options , auth func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) , expClientErr , expDeliverErr , expServerErr error ) {
2023-01-30 16:27:06 +03:00
t . Helper ( )
if opts . tlsMode == "" {
opts . tlsMode = TLSOpportunistic
}
clientConn , serverConn := net . Pipe ( )
defer serverConn . Close ( )
result := make ( chan error , 2 )
go func ( ) {
defer func ( ) {
x := recover ( )
if x != nil && x != "stop" {
panic ( x )
}
} ( )
fail := func ( format string , args ... any ) {
err := fmt . Errorf ( "server: %w" , fmt . Errorf ( format , args ... ) )
if err != nil && expServerErr != nil && ( errors . Is ( err , expServerErr ) || errors . As ( err , reflect . New ( reflect . ValueOf ( expServerErr ) . Type ( ) ) . Interface ( ) ) ) {
err = nil
}
result <- err
panic ( "stop" )
}
br := bufio . NewReader ( serverConn )
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
readline := func ( prefix string ) string {
2023-01-30 16:27:06 +03:00
s , err := br . ReadString ( '\n' )
if err != nil {
fail ( "expected command: %v" , err )
}
if ! strings . HasPrefix ( strings . ToLower ( s ) , strings . ToLower ( prefix ) ) {
fail ( "expected command %q, got: %s" , prefix , s )
}
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
s = s [ len ( prefix ) : ]
return strings . TrimSuffix ( s , "\r\n" )
2023-01-30 16:27:06 +03:00
}
writeline := func ( s string ) {
fmt . Fprintf ( serverConn , "%s\r\n" , s )
}
haveTLS := false
ehlo := true // Initially we expect EHLO.
var hello func ( )
hello = func ( ) {
if ! ehlo {
readline ( "HELO" )
writeline ( "250 mox.example" )
return
}
readline ( "EHLO" )
if ! opts . ehlo {
// Client will try again with HELO.
writeline ( "500 bad syntax" )
ehlo = false
hello ( )
return
}
writeline ( "250-mox.example" )
if opts . pipelining {
writeline ( "250-PIPELINING" )
}
if opts . maxSize > 0 {
writeline ( fmt . Sprintf ( "250-SIZE %d" , opts . maxSize ) )
}
if opts . ecodes {
writeline ( "250-ENHANCEDSTATUSCODES" )
}
if opts . starttls && ! haveTLS {
writeline ( "250-STARTTLS" )
}
if opts . eightbitmime {
writeline ( "250-8BITMIME" )
}
if opts . smtputf8 {
writeline ( "250-SMTPUTF8" )
}
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
if opts . requiretls && haveTLS {
writeline ( "250-REQUIRETLS" )
}
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 opts . auths != nil {
writeline ( "250-AUTH " + strings . Join ( opts . auths , " " ) )
}
2023-01-30 16:27:06 +03:00
writeline ( "250 UNKNOWN" ) // To be ignored.
}
writeline ( "220 mox.example ESMTP test" )
hello ( )
if opts . starttls {
readline ( "STARTTLS" )
writeline ( "220 go" )
tlsConn := tls . Server ( serverConn , & tlsConfig )
nctx , cancel := context . WithTimeout ( context . Background ( ) , 3 * time . Second )
defer cancel ( )
err := tlsConn . HandshakeContext ( nctx )
if err != nil {
fail ( "tls handshake: %w" , err )
}
serverConn = tlsConn
br = bufio . NewReader ( serverConn )
haveTLS = true
hello ( )
}
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 opts . auths != nil {
more := readline ( "AUTH " )
t := strings . SplitN ( more , " " , 2 )
switch t [ 0 ] {
case "PLAIN" :
writeline ( "235 2.7.0 auth ok" )
case "CRAM-MD5" :
writeline ( "334 " + base64 . StdEncoding . EncodeToString ( [ ] byte ( "<123.1234@host>" ) ) )
readline ( "" ) // Proof
writeline ( "235 2.7.0 auth ok" )
2023-12-24 01:07:21 +03:00
case "SCRAM-SHA-256-PLUS" , "SCRAM-SHA-256" , "SCRAM-SHA-1-PLUS" , "SCRAM-SHA-1" :
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
// Cannot fake/hardcode scram interactions.
var h func ( ) hash . Hash
salt := scram . MakeRandom ( )
var iterations int
2023-12-24 01:07:21 +03:00
switch t [ 0 ] {
case "SCRAM-SHA-1-PLUS" , "SCRAM-SHA-1" :
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
h = sha1 . New
iterations = 2 * 4096
2023-12-24 01:07:21 +03:00
case "SCRAM-SHA-256-PLUS" , "SCRAM-SHA-256" :
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
h = sha256 . New
iterations = 4096
2023-12-24 01:07:21 +03:00
default :
panic ( "missing case for scram" )
}
var cs * tls . ConnectionState
if strings . HasSuffix ( t [ 0 ] , "-PLUS" ) {
if ! haveTLS {
writeline ( "501 scram plus without tls not possible" )
readline ( "QUIT" )
writeline ( "221 ok" )
result <- nil
return
}
xcs := serverConn . ( * tls . Conn ) . ConnectionState ( )
cs = & xcs
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
}
saltedPassword := scram . SaltPassword ( h , "test" , salt , iterations )
clientFirst , err := base64 . StdEncoding . DecodeString ( t [ 1 ] )
if err != nil {
fail ( "bad base64: %w" , err )
}
2023-12-24 01:07:21 +03:00
s , err := scram . NewServer ( h , clientFirst , cs , cs != nil )
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
if err != nil {
fail ( "scram new server: %w" , err )
}
serverFirst , err := s . ServerFirst ( iterations , salt )
if err != nil {
fail ( "scram server first: %w" , err )
}
writeline ( "334 " + base64 . StdEncoding . EncodeToString ( [ ] byte ( serverFirst ) ) )
xclientFinal := readline ( "" )
clientFinal , err := base64 . StdEncoding . DecodeString ( xclientFinal )
if err != nil {
fail ( "bad base64: %w" , err )
}
serverFinal , err := s . Finish ( [ ] byte ( clientFinal ) , saltedPassword )
if err != nil {
fail ( "scram finish: %w" , err )
}
writeline ( "334 " + base64 . StdEncoding . EncodeToString ( [ ] byte ( serverFinal ) ) )
readline ( "" )
writeline ( "235 2.7.0 auth ok" )
default :
writeline ( "501 unknown mechanism" )
}
}
2023-01-30 16:27:06 +03:00
if expClientErr == nil && ! opts . nodeliver {
readline ( "MAIL FROM:" )
writeline ( "250 ok" )
readline ( "RCPT TO:" )
writeline ( "250 ok" )
readline ( "DATA" )
writeline ( "354 continue" )
reader := smtp . NewDataReader ( br )
io . Copy ( io . Discard , reader )
writeline ( "250 ok" )
if expDeliverErr == nil {
readline ( "RSET" )
writeline ( "250 ok" )
readline ( "MAIL FROM:" )
writeline ( "250 ok" )
readline ( "RCPT TO:" )
writeline ( "250 ok" )
readline ( "DATA" )
writeline ( "354 continue" )
reader = smtp . NewDataReader ( br )
io . Copy ( io . Discard , reader )
writeline ( "250 ok" )
}
}
readline ( "QUIT" )
writeline ( "221 ok" )
result <- 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
// todo: should abort tests more properly. on client failures, we may be left with hanging test.
2023-01-30 16:27:06 +03:00
go func ( ) {
defer func ( ) {
x := recover ( )
if x != nil && x != "stop" {
panic ( x )
}
} ( )
fail := func ( format string , args ... any ) {
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 := fmt . Errorf ( "client: %w" , fmt . Errorf ( format , args ... ) )
result <- err
2023-01-30 16:27:06 +03:00
panic ( "stop" )
}
2023-12-24 01:07:21 +03:00
client , err := New ( ctx , log . Logger , clientConn , opts . tlsMode , opts . tlsPKIX , localhost , opts . tlsHostname , Opts { Auth : auth , RootCAs : opts . roots } )
2023-01-30 16:27:06 +03:00
if ( err == nil ) != ( expClientErr == nil ) || err != nil && ! errors . As ( err , reflect . New ( reflect . ValueOf ( expClientErr ) . Type ( ) ) . Interface ( ) ) && ! errors . Is ( err , expClientErr ) {
fail ( "new client: got err %v, expected %#v" , err , expClientErr )
}
if err != nil {
result <- nil
return
}
2023-12-24 01:07:21 +03:00
err = client . Deliver ( ctx , "postmaster@mox.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , opts . need8bitmime , opts . needsmtputf8 , opts . needsrequiretls )
2023-01-30 16:27:06 +03:00
if ( err == nil ) != ( expDeliverErr == nil ) || err != nil && ! errors . Is ( err , expDeliverErr ) {
fail ( "first deliver: got err %v, expected %v" , err , expDeliverErr )
}
if err == nil {
2023-12-24 01:07:21 +03:00
err = client . Reset ( )
2023-01-30 16:27:06 +03:00
if err != nil {
fail ( "reset: %v" , err )
}
2023-12-24 01:07:21 +03:00
err = client . Deliver ( ctx , "postmaster@mox.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , opts . need8bitmime , opts . needsmtputf8 , opts . needsrequiretls )
2023-01-30 16:27:06 +03:00
if ( err == nil ) != ( expDeliverErr == nil ) || err != nil && ! errors . Is ( err , expDeliverErr ) {
fail ( "second deliver: got err %v, expected %v" , err , expDeliverErr )
}
}
2023-12-24 01:07:21 +03:00
err = client . Close ( )
2023-01-30 16:27:06 +03:00
if err != nil {
fail ( "close client: %v" , err )
}
result <- nil
} ( )
var errs [ ] error
for i := 0 ; i < 2 ; i ++ {
err := <- result
if err != nil {
errs = append ( errs , err )
}
}
if errs != nil {
t . Fatalf ( "%v" , errs )
}
}
msg := strings . ReplaceAll ( ` From : < postmaster @ mox . example >
To : < mjl @ mox . example >
Subject : test
test
` , "\n" , "\r\n" )
allopts := options {
pipelining : true ,
ecodes : true ,
maxSize : 512 ,
eightbitmime : true ,
smtputf8 : true ,
starttls : true ,
ehlo : true ,
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 : true ,
2023-01-30 16:27:06 +03:00
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
tlsMode : TLSRequiredStartTLS ,
tlsPKIX : true ,
roots : roots ,
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
tlsHostname : dns . Domain { ASCII : "mox.example" } ,
need8bitmime : true ,
needsmtputf8 : true ,
needsrequiretls : true ,
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
test ( msg , options { } , nil , nil , nil , nil )
test ( msg , allopts , nil , nil , nil , nil )
test ( msg , options { ehlo : true , eightbitmime : true } , nil , nil , nil , nil )
test ( msg , options { ehlo : true , eightbitmime : false , need8bitmime : true , nodeliver : true } , nil , nil , Err8bitmimeUnsupported , nil )
test ( msg , options { ehlo : true , smtputf8 : false , needsmtputf8 : true , nodeliver : true } , nil , nil , ErrSMTPUTF8Unsupported , nil )
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
test ( msg , options { ehlo : true , starttls : true , tlsMode : TLSRequiredStartTLS , tlsPKIX : true , tlsHostname : dns . Domain { ASCII : "mismatch.example" } , nodeliver : true } , nil , ErrTLS , nil , & net . OpError { } ) // Server TLS handshake is a net.OpError with "remote error" as text.
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
test ( msg , options { ehlo : true , maxSize : len ( msg ) - 1 , nodeliver : true } , nil , nil , ErrSize , nil )
2023-12-24 01:07:21 +03:00
authPlain := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientPlain ( "test" , "test" ) , nil
}
test ( msg , options { ehlo : true , auths : [ ] string { "PLAIN" } } , authPlain , nil , nil , nil )
authCRAMMD5 := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientCRAMMD5 ( "test" , "test" ) , nil
}
test ( msg , options { ehlo : true , auths : [ ] string { "CRAM-MD5" } } , authCRAMMD5 , nil , nil , nil )
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
// todo: add tests for failing authentication, also at various stages in SCRAM
2023-12-24 01:07:21 +03:00
authSCRAMSHA1 := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientSCRAMSHA1 ( "test" , "test" , false ) , nil
}
test ( msg , options { ehlo : true , auths : [ ] string { "SCRAM-SHA-1" } } , authSCRAMSHA1 , nil , nil , nil )
authSCRAMSHA1PLUS := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientSCRAMSHA1PLUS ( "test" , "test" , * cs ) , nil
}
test ( msg , options { ehlo : true , starttls : true , auths : [ ] string { "SCRAM-SHA-1-PLUS" } } , authSCRAMSHA1PLUS , nil , nil , nil )
authSCRAMSHA256 := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientSCRAMSHA256 ( "test" , "test" , false ) , nil
}
test ( msg , options { ehlo : true , auths : [ ] string { "SCRAM-SHA-256" } } , authSCRAMSHA256 , nil , nil , nil )
authSCRAMSHA256PLUS := func ( l [ ] string , cs * tls . ConnectionState ) ( sasl . Client , error ) {
return sasl . NewClientSCRAMSHA256PLUS ( "test" , "test" , * cs ) , nil
}
test ( msg , options { ehlo : true , starttls : true , auths : [ ] string { "SCRAM-SHA-256-PLUS" } } , authSCRAMSHA256PLUS , nil , nil , 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 ( msg , options { ehlo : true , requiretls : false , needsrequiretls : true , nodeliver : true } , nil , nil , ErrRequireTLSUnsupported , nil )
2023-01-30 16:27:06 +03:00
// Set an expired certificate. For non-strict TLS, we should still accept it.
// ../rfc/7435:424
cert = fakeCert ( t , true )
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
roots = x509 . NewCertPool ( )
roots . AddCert ( cert . Leaf )
2023-01-30 16:27:06 +03:00
tlsConfig = tls . Config {
Certificates : [ ] tls . Certificate { cert } ,
}
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
test ( msg , options { ehlo : true , starttls : true , roots : roots } , nil , nil , nil , nil )
2023-01-30 16:27:06 +03:00
// Again with empty cert pool so it isn't trusted in any way.
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
roots = x509 . NewCertPool ( )
2023-01-30 16:27:06 +03:00
tlsConfig = tls . Config {
Certificates : [ ] tls . Certificate { cert } ,
}
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
test ( msg , options { ehlo : true , starttls : true , roots : roots } , nil , nil , nil , nil )
2023-01-30 16:27:06 +03:00
}
func TestErrors ( t * testing . T ) {
ctx := context . Background ( )
2023-12-05 15:35:58 +03:00
log := mlog . New ( "smtpclient" , nil )
2023-01-30 16:27:06 +03:00
// Invalid greeting.
run ( t , func ( s xserver ) {
s . writeline ( "bogus" ) // Invalid, should be "220 <hostname>".
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrProtocol ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrProtocol without Permanent" , err ) )
}
} )
// Server just closes connection.
run ( t , func ( s xserver ) {
s . conn . Close ( )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , io . ErrUnexpectedEOF ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v (%v), expected ErrUnexpectedEOF without Permanent" , err , err ) )
}
} )
// Server does not want to speak SMTP.
run ( t , func ( s xserver ) {
s . writeline ( "521 not accepting connections" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with Permanent" , err ) )
}
} )
// Server has invalid code in greeting.
run ( t , func ( s xserver ) {
s . writeline ( "2200 mox.example" ) // Invalid, too many digits.
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrProtocol ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrProtocol without Permanent" , err ) )
}
} )
// Server sends multiline response, but with different codes.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250-mox.example" )
s . writeline ( "500 different code" ) // Invalid.
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrProtocol ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrProtocol without Permanent" , err ) )
}
} )
// Server permanently refuses MAIL FROM.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250-mox.example" )
s . writeline ( "250 ENHANCEDSTATUSCODES" )
s . readline ( "MAIL FROM:" )
s . writeline ( "550 5.7.0 not allowed" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with Permanent" , err ) )
}
} )
// Server temporarily refuses MAIL FROM.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250 mox.example" )
s . readline ( "MAIL FROM:" )
s . writeline ( "451 bad sender" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with not-Permanent" , err ) )
}
} )
// Server temporarily refuses RCPT TO.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250 mox.example" )
s . readline ( "MAIL FROM:" )
s . writeline ( "250 ok" )
s . readline ( "RCPT TO:" )
s . writeline ( "451" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with not-Permanent" , err ) )
}
} )
// Server permanently refuses DATA.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250 mox.example" )
s . readline ( "MAIL FROM:" )
s . writeline ( "250 ok" )
s . readline ( "RCPT TO:" )
s . writeline ( "250 ok" )
s . readline ( "DATA" )
s . writeline ( "550 no!" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with Permanent" , err ) )
}
} )
// TLS is required, so we attempt it regardless of whether it is advertised.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250 mox.example" )
s . readline ( "STARTTLS" )
s . writeline ( "502 command not implemented" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
_ , err := New ( ctx , log . Logger , conn , TLSRequiredStartTLS , true , localhost , dns . Domain { ASCII : "mox.example" } , Opts { } )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrTLS ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrTLS with Permanent" , err ) )
}
} )
// If TLS is available, but we don't want to use it, client should skip it.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250-mox.example" )
s . writeline ( "250 STARTTLS" )
s . readline ( "MAIL FROM:" )
s . writeline ( "451 enough" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSSkip , false , localhost , dns . Domain { ASCII : "mox.example" } , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with non-Permanent" , err ) )
}
} )
// A transaction is aborted. If we try another one, we should send a RSET.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250 mox.example" )
s . readline ( "MAIL FROM:" )
s . writeline ( "250 ok" )
s . readline ( "RCPT TO:" )
s . writeline ( "451 not now" )
s . readline ( "RSET" )
s . writeline ( "250 ok" )
s . readline ( "MAIL FROM:" )
s . writeline ( "250 ok" )
s . readline ( "RCPT TO:" )
s . writeline ( "250 ok" )
s . readline ( "DATA" )
s . writeline ( "550 not now" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-01-30 16:27:06 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with non-Permanent" , err ) )
}
// Another delivery.
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-01-30 16:27:06 +03:00
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with Permanent" , err ) )
}
} )
2023-04-20 23:29:18 +03:00
// Remote closes connection after 550 response to MAIL FROM in pipelined
// connection. Should result in permanent error, not temporary read error.
// E.g. outlook.com that has your IP blocklisted.
run ( t , func ( s xserver ) {
s . writeline ( "220 mox.example" )
s . readline ( "EHLO" )
s . writeline ( "250-mox.example" )
s . writeline ( "250 PIPELINING" )
s . readline ( "MAIL FROM:" )
s . writeline ( "550 ok" )
} , func ( conn net . Conn ) {
2023-12-05 15:35:58 +03:00
c , err := New ( ctx , log . Logger , conn , TLSOpportunistic , false , localhost , zerohost , Opts { } )
2023-04-20 23:29:18 +03:00
if err != nil {
panic ( err )
}
msg := ""
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 = c . Deliver ( ctx , "postmaster@other.example" , "mjl@mox.example" , int64 ( len ( msg ) ) , strings . NewReader ( msg ) , false , false , false )
2023-04-20 23:29:18 +03:00
var xerr Error
if err == nil || ! errors . Is ( err , ErrStatus ) || ! errors . As ( err , & xerr ) || ! xerr . Permanent {
panic ( fmt . Errorf ( "got %#v, expected ErrStatus with Permanent" , err ) )
}
} )
2023-01-30 16:27:06 +03:00
}
type xserver struct {
conn net . Conn
br * bufio . Reader
}
func ( s xserver ) check ( err error , msg string ) {
if err != nil {
panic ( fmt . Errorf ( "%s: %w" , msg , err ) )
}
}
func ( s xserver ) errorf ( format string , args ... any ) {
panic ( fmt . Errorf ( format , args ... ) )
}
func ( s xserver ) writeline ( line string ) {
_ , err := fmt . Fprintf ( s . conn , "%s\r\n" , line )
s . check ( err , "write" )
}
func ( s xserver ) readline ( prefix string ) {
line , err := s . br . ReadString ( '\n' )
s . check ( err , "reading command" )
if ! strings . HasPrefix ( strings . ToLower ( line ) , strings . ToLower ( prefix ) ) {
s . errorf ( "expected command %q, got: %s" , prefix , line )
}
}
func run ( t * testing . T , server func ( s xserver ) , client func ( conn net . Conn ) ) {
t . Helper ( )
result := make ( chan error , 2 )
clientConn , serverConn := net . Pipe ( )
go func ( ) {
defer func ( ) {
serverConn . Close ( )
x := recover ( )
if x != nil {
result <- fmt . Errorf ( "server: %v" , x )
} else {
result <- nil
}
} ( )
server ( xserver { serverConn , bufio . NewReader ( serverConn ) } )
} ( )
go func ( ) {
defer func ( ) {
clientConn . Close ( )
x := recover ( )
if x != nil {
result <- fmt . Errorf ( "client: %v" , x )
} else {
result <- nil
}
} ( )
client ( clientConn )
} ( )
var errs [ ] error
for i := 0 ; i < 2 ; i ++ {
err := <- result
if err != nil {
errs = append ( errs , err )
}
}
if errs != nil {
t . Fatalf ( "errors: %v" , errs )
}
}
// 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 , expired bool ) tls . Certificate {
notAfter := time . Now ( )
if expired {
notAfter = notAfter . Add ( - time . Hour )
} else {
notAfter = notAfter . Add ( time . Hour )
}
privKey := ed25519 . NewKeyFromSeed ( make ( [ ] byte , ed25519 . SeedSize ) ) // Fake key, don't use this for real!
template := & x509 . Certificate {
SerialNumber : big . NewInt ( 1 ) , // Required field...
DNSNames : [ ] string { "mox.example" } ,
NotBefore : time . Now ( ) . Add ( - time . Hour ) ,
NotAfter : notAfter ,
}
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
}