2023-01-30 16:27:06 +03:00
{
"Name" : "Admin" ,
2023-03-12 13:52:15 +03:00
"Docs" : "Admin exports web API functions for the admin web interface. All its methods are\nexported under api/. Function calls require valid HTTP Authentication\ncredentials of a user." ,
2023-01-30 16:27:06 +03:00
"Functions" : [
replace http basic auth for web interfaces with session cookie & csrf-based auth
the http basic auth we had was very simple to reason about, and to implement.
but it has a major downside:
there is no way to logout, browsers keep sending credentials. ideally, browsers
themselves would show a button to stop sending credentials.
a related downside: the http auth mechanism doesn't indicate for which server
paths the credentials are.
another downside: the original password is sent to the server with each
request. though sending original passwords to web servers seems to be
considered normal.
our new approach uses session cookies, along with csrf values when we can. the
sessions are server-side managed, automatically extended on each use. this
makes it easy to invalidate sessions and keeps the frontend simpler (than with
long- vs short-term sessions and refreshing). the cookies are httponly,
samesite=strict, scoped to the path of the web interface. cookies are set
"secure" when set over https. the cookie is set by a successful call to Login.
a call to Logout invalidates a session. changing a password invalidates all
sessions for a user, but keeps the session with which the password was changed
alive. the csrf value is also random, and associated with the session cookie.
the csrf must be sent as header for api calls, or as parameter for direct form
posts (where we cannot set a custom header). rest-like calls made directly by
the browser, e.g. for images, don't have a csrf protection. the csrf value is
returned by the Login api call and stored in localstorage.
api calls without credentials return code "user:noAuth", and with bad
credentials return "user:badAuth". the api client recognizes this and triggers
a login. after a login, all auth-failed api calls are automatically retried.
only for "user:badAuth" is an error message displayed in the login form (e.g.
session expired).
in an ideal world, browsers would take care of most session management. a
server would indicate authentication is needed (like http basic auth), and the
browsers uses trusted ui to request credentials for the server & path. the
browser could use safer mechanism than sending original passwords to the
server, such as scram, along with a standard way to create sessions. for now,
web developers have to do authentication themselves: from showing the login
prompt, ensuring the right session/csrf cookies/localstorage/headers/etc are
sent with each request.
webauthn is a newer way to do authentication, perhaps we'll implement it in the
future. though hardware tokens aren't an attractive option for many users, and
it may be overkill as long as we still do old-fashioned authentication in smtp
& imap where passwords can be sent to the server.
for issue #58
2024-01-04 15:10:48 +03:00
{
"Name" : "LoginPrep" ,
"Docs" : "LoginPrep returns a login token, and also sets it as cookie. Both must be\npresent in the call to Login." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "Login" ,
"Docs" : "Login returns a session token for the credentials, or fails with error code\n\"user:badLogin\". Call LoginPrep to get a loginToken." ,
"Params" : [
{
"Name" : "loginToken" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "password" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"CSRFToken"
]
}
]
} ,
{
"Name" : "Logout" ,
"Docs" : "Logout invalidates the session token." ,
"Params" : [ ] ,
"Returns" : [ ]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "CheckDomain" ,
"Docs" : "CheckDomain checks the configuration for the domain, such as MX, SMTP STARTTLS,\nSPF, DKIM, DMARC, TLSRPT, MTASTS, autoconfig, autodiscover." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r" ,
"Typewords" : [
"CheckResult"
]
}
]
} ,
{
"Name" : "Domains" ,
"Docs" : "Domains returns all configured domain names, in UTF-8 for IDNA domains." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"Domain"
]
}
]
} ,
{
"Name" : "Domain" ,
"Docs" : "Domain returns the dns domain for a (potentially unicode as IDNA) domain name." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Domain"
]
}
]
} ,
2023-11-12 16:58:46 +03:00
{
"Name" : "ParseDomain" ,
"Docs" : "ParseDomain parses a domain, possibly an IDNA domain." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Domain"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DomainLocalparts" ,
2023-03-29 22:11:43 +03:00
"Docs" : "DomainLocalparts returns the encoded localparts and accounts configured in domain." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "localpartAccounts" ,
"Typewords" : [
"{}" ,
"string"
]
}
]
} ,
{
"Name" : "Accounts" ,
"Docs" : "Accounts returns the names of all configured accounts." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "Account" ,
"Docs" : "Account returns the parsed configuration of an account." ,
"Params" : [
{
"Name" : "account" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"{}" ,
"any"
]
}
]
} ,
{
"Name" : "ConfigFiles" ,
"Docs" : "ConfigFiles returns the paths and contents of the static and dynamic configuration files." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "staticPath" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "dynamicPath" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "static" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "dynamic" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "MTASTSPolicies" ,
"Docs" : "MTASTSPolicies returns all mtasts policies from the cache." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "records" ,
"Typewords" : [
"[]" ,
"PolicyRecord"
]
}
]
} ,
{
"Name" : "TLSReports" ,
2023-11-12 16:19:12 +03:00
"Docs" : "TLSReports returns TLS reports overlapping with period start/end, for the given\npolicy domain (or all domains if empty). The reports are sorted first by period\nend (most recent first), then by policy domain." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
"Name" : "start" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "end" ,
"Typewords" : [
"timestamp"
]
} ,
{
2023-11-12 16:19:12 +03:00
"Name" : "policyDomain" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "reports" ,
"Typewords" : [
"[]" ,
"TLSReportRecord"
]
}
]
} ,
{
"Name" : "TLSReportID" ,
"Docs" : "TLSReportID returns a single TLS report." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "reportID" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"TLSReportRecord"
]
}
]
} ,
{
"Name" : "TLSRPTSummaries" ,
"Docs" : "TLSRPTSummaries returns a summary of received TLS reports overlapping with\nperiod start/end for one or all domains (when domain is empty).\nThe returned summaries are ordered by domain name." ,
"Params" : [
{
"Name" : "start" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "end" ,
"Typewords" : [
"timestamp"
]
} ,
{
2023-11-12 16:19:12 +03:00
"Name" : "policyDomain" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "domainSummaries" ,
"Typewords" : [
"[]" ,
"TLSRPTSummary"
]
}
]
} ,
{
"Name" : "DMARCReports" ,
"Docs" : "DMARCReports returns DMARC reports overlapping with period start/end, for the\ngiven domain (or all domains if empty). The reports are sorted first by period\nend (most recent first), then by domain." ,
"Params" : [
{
"Name" : "start" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "end" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "reports" ,
"Typewords" : [
"[]" ,
"DomainFeedback"
]
}
]
} ,
{
"Name" : "DMARCReportID" ,
"Docs" : "DMARCReportID returns a single DMARC report." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "reportID" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [
{
"Name" : "report" ,
"Typewords" : [
"DomainFeedback"
]
}
]
} ,
{
"Name" : "DMARCSummaries" ,
"Docs" : "DMARCSummaries returns a summary of received DMARC reports overlapping with\nperiod start/end for one or all domains (when domain is empty).\nThe returned summaries are ordered by domain name." ,
"Params" : [
{
"Name" : "start" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "end" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "domainSummaries" ,
"Typewords" : [
"[]" ,
"DMARCSummary"
]
}
]
} ,
{
"Name" : "LookupIP" ,
"Docs" : "LookupIP does a reverse lookup of ip." ,
"Params" : [
{
"Name" : "ip" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Reverse"
]
}
]
} ,
{
"Name" : "DNSBLStatus" ,
"Docs" : "DNSBLStatus returns the IPs from which outgoing connections may be made and\ntheir current status in DNSBLs that are configured. The IPs are typically the\nconfigured listen IPs, or otherwise IPs on the machines network interfaces, with\ninternal/private IPs removed.\n\nThe returned value maps IPs to per DNSBL statuses, where \"pass\" means not listed and\nanything else is an error string, e.g. \"fail: ...\" or \"temperror: ...\"." ,
"Params" : [ ] ,
"Returns" : [
{
2024-03-05 18:30:38 +03:00
"Name" : "results" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"{}" ,
"{}" ,
"string"
]
2024-03-05 18:30:38 +03:00
} ,
{
"Name" : "using" ,
"Typewords" : [
"[]" ,
"Domain"
]
} ,
{
"Name" : "monitoring" ,
"Typewords" : [
"[]" ,
"Domain"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
2024-03-05 18:30:38 +03:00
{
"Name" : "MonitorDNSBLsSave" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "text" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DomainRecords" ,
"Docs" : "DomainRecords returns lines describing DNS records that should exist for the\nconfigured domain." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DomainAdd" ,
"Docs" : "DomainAdd adds a new domain and reloads the configuration." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "localpart" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainRemove" ,
"Docs" : "DomainRemove removes an existing domain and reloads the configuration." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AccountAdd" ,
2023-09-23 13:05:40 +03:00
"Docs" : "AccountAdd adds existing a new account, with an initial email address, and\nreloads the configuration." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "address" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AccountRemove" ,
"Docs" : "AccountRemove removes an existing account and reloads the configuration." ,
"Params" : [
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AddressAdd" ,
"Docs" : "AddressAdd adds a new address to the account, which must already exist." ,
"Params" : [
{
"Name" : "address" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AddressRemove" ,
"Docs" : "AddressRemove removes an existing address." ,
"Params" : [
{
"Name" : "address" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "SetPassword" ,
"Docs" : "SetPassword saves a new password for an account, invalidating the previous password.\nSessions are not interrupted, and will keep working. New login attempts must use the new password.\nPassword must be at least 8 characters." ,
"Params" : [
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "password" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
2023-03-28 21:50:36 +03:00
{
"Name" : "SetAccountLimits" ,
"Docs" : "SetAccountLimits set new limits on outgoing messages for an account." ,
"Params" : [
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "maxOutgoingMessagesPerDay" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "maxFirstTimeRecipientsPerDay" ,
"Typewords" : [
"int32"
]
2023-12-20 22:54:12 +03:00
} ,
{
"Name" : "maxMsgSize" ,
"Typewords" : [
"int64"
]
2023-03-28 21:50:36 +03:00
}
] ,
"Returns" : [ ]
} ,
2023-01-30 16:27:06 +03:00
{
2023-09-23 13:05:40 +03:00
"Name" : "ClientConfigsDomain" ,
"Docs" : "ClientConfigsDomain returns configurations for email clients, IMAP and\nSubmission (SMTP) for the domain." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
2023-09-23 13:05:40 +03:00
"ClientConfigs"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
"Name" : "QueueList" ,
"Docs" : "QueueList returns the messages currently in the outgoing queue." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"Msg"
]
}
]
} ,
2023-02-08 21:42:21 +03:00
{
"Name" : "QueueSize" ,
"Docs" : "QueueSize returns the number of messages currently in the outgoing queue." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"int32"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "QueueKick" ,
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
"Docs" : "QueueKick initiates delivery of a message from the queue and sets the transport\nto use for delivery." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
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
} ,
{
"Name" : "transport" ,
"Typewords" : [
"string"
]
2023-01-30 16:27:06 +03:00
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "QueueDrop" ,
"Docs" : "QueueDrop removes a message from the queue." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [ ]
2023-02-06 17:17:46 +03:00
} ,
implement "requiretls", rfc 8689
with requiretls, the tls verification mode/rules for email deliveries can be
changed by the sender/submitter. in two ways:
1. "requiretls" smtp extension to always enforce verified tls (with mta-sts or
dnssec+dane), along the entire delivery path until delivery into the final
destination mailbox (so entire transport is verified-tls-protected).
2. "tls-required: no" message header, to ignore any tls and tls verification
errors even if the recipient domain has a policy that requires tls verification
(mta-sts and/or dnssec+dane), allowing delivery of non-sensitive messages in
case of misconfiguration/interoperability issues (at least useful for sending
tls reports).
we enable requiretls by default (only when tls is active), for smtp and
submission. it can be disabled through the config.
for each delivery attempt, we now store (per recipient domain, in the account
of the sender) whether the smtp server supports starttls and requiretls. this
support is shown (after having sent a first message) in the webmail when
sending a message (the previous 3 bars under the address input field are now 5
bars, the first for starttls support, the last for requiretls support). when
all recipient domains for a message are known to implement requiretls,
requiretls is automatically selected for sending (instead of "default" tls
behaviour). users can also select the "fallback to insecure" to add the
"tls-required: no" header.
new metrics are added for insight into requiretls errors and (some, not yet
all) cases where tls-required-no ignored a tls/verification error.
the admin can change the requiretls status for messages in the queue. so with
default delivery attempts, when verified tls is required by failing, an admin
could potentially change the field to "tls-required: no"-behaviour.
messages received (over smtp) with the requiretls option, get a comment added
to their Received header line, just before "id", after "with".
2023-10-24 11:06:16 +03:00
{
"Name" : "QueueSaveRequireTLS" ,
"Docs" : "QueueSaveRequireTLS updates the requiretls field for a message in the queue,\nto be used for the next delivery." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "requireTLS" ,
"Typewords" : [
"nullable" ,
"bool"
]
}
] ,
"Returns" : [ ]
} ,
2023-02-06 17:17:46 +03:00
{
"Name" : "LogLevels" ,
"Docs" : "LogLevels returns the current log levels." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"{}" ,
"string"
]
}
]
} ,
{
"Name" : "LogLevelSet" ,
"Docs" : "LogLevelSet sets a log level for a package." ,
"Params" : [
{
"Name" : "pkg" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "levelStr" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "LogLevelRemove" ,
"Docs" : "LogLevelRemove removes a log level for a package, which cannot be the empty string." ,
"Params" : [
{
"Name" : "pkg" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
2023-02-27 17:03:37 +03:00
} ,
{
"Name" : "CheckUpdatesEnabled" ,
"Docs" : "CheckUpdatesEnabled returns whether checking for updates is enabled." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"bool"
]
}
]
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
} ,
{
"Name" : "WebserverConfig" ,
"Docs" : "WebserverConfig returns the current webserver config" ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "conf" ,
"Typewords" : [
"WebserverConfig"
]
}
]
} ,
{
"Name" : "WebserverConfigSave" ,
"Docs" : "WebserverConfigSave saves a new webserver config. If oldConf is not equal to\nthe current config, an error is returned." ,
"Params" : [
{
"Name" : "oldConf" ,
"Typewords" : [
"WebserverConfig"
]
} ,
{
"Name" : "newConf" ,
"Typewords" : [
"WebserverConfig"
]
}
] ,
"Returns" : [
{
"Name" : "savedConf" ,
"Typewords" : [
"WebserverConfig"
]
}
]
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
} ,
{
"Name" : "Transports" ,
"Docs" : "Transports returns the configured transports, for sending email." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"{}" ,
"Transport"
]
}
]
2023-11-01 19:55:40 +03:00
} ,
{
"Name" : "DMARCEvaluationStats" ,
"Docs" : "DMARCEvaluationStats returns a map of all domains with evaluations to a count of\nthe evaluations and whether those evaluations will cause a report to be sent." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"{}" ,
"EvaluationStat"
]
}
]
} ,
{
"Name" : "DMARCEvaluationsDomain" ,
"Docs" : "DMARCEvaluationsDomain returns all evaluations for aggregate reports for the\ndomain, sorted from oldest to most recent." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "r1" ,
"Typewords" : [
"[]" ,
"Evaluation"
]
}
]
} ,
{
"Name" : "DMARCRemoveEvaluations" ,
"Docs" : "DMARCRemoveEvaluations removes evaluations for a domain." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
} ,
2023-11-13 15:48:52 +03:00
{
"Name" : "DMARCSuppressAdd" ,
"Docs" : "DMARCSuppressAdd adds a reporting address to the suppress list. Outgoing\nreports will be suppressed for a period." ,
"Params" : [
{
"Name" : "reportingAddress" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "until" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "comment" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DMARCSuppressList" ,
"Docs" : "DMARCSuppressList returns all reporting addresses on the suppress list." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"SuppressAddress"
]
}
]
} ,
{
"Name" : "DMARCSuppressRemove" ,
"Docs" : "DMARCSuppressRemove removes a reporting address record from the suppress list." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DMARCSuppressExtend" ,
"Docs" : "DMARCSuppressExtend updates the until field of a suppressed reporting address record." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "until" ,
"Typewords" : [
"timestamp"
]
}
] ,
"Returns" : [ ]
} ,
implement outgoing tls reports
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.
sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.
only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.
config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.
gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
2023-11-09 19:40:46 +03:00
{
"Name" : "TLSRPTResults" ,
"Docs" : "TLSRPTResults returns all TLSRPT results in the database." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"TLSResult"
]
}
]
} ,
{
2023-11-20 13:31:46 +03:00
"Name" : "TLSRPTResultsDomain" ,
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
"Docs" : "TLSRPTResultsPolicyDomain returns the TLS results for a domain." ,
"Params" : [
2023-11-20 13:31:46 +03:00
{
"Name" : "isRcptDom" ,
"Typewords" : [
"bool"
]
} ,
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
{
"Name" : "policyDomain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "r1" ,
"Typewords" : [
"[]" ,
"TLSResult"
]
}
]
} ,
{
"Name" : "LookupTLSRPTRecord" ,
"Docs" : "LookupTLSRPTRecord looks up a TLSRPT record and returns the parsed form, original txt\nform from DNS, and error with the TLSRPT record as a string." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "record" ,
"Typewords" : [
"nullable" ,
"TLSRPTRecord"
]
} ,
{
"Name" : "txt" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "errstr" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "TLSRPTRemoveResults" ,
"Docs" : "TLSRPTRemoveResults removes the TLS results for a domain for the given day. If\nday is empty, all results are removed." ,
"Params" : [
2023-11-20 13:31:46 +03:00
{
"Name" : "isRcptDom" ,
"Typewords" : [
"bool"
]
} ,
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
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "day" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
2023-11-13 15:48:52 +03:00
} ,
{
"Name" : "TLSRPTSuppressAdd" ,
"Docs" : "TLSRPTSuppressAdd adds a reporting address to the suppress list. Outgoing\nreports will be suppressed for a period." ,
"Params" : [
{
"Name" : "reportingAddress" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "until" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "comment" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "TLSRPTSuppressList" ,
"Docs" : "TLSRPTSuppressList returns all reporting addresses on the suppress list." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"TLSRPTSuppressAddress"
]
}
]
} ,
{
"Name" : "TLSRPTSuppressRemove" ,
"Docs" : "TLSRPTSuppressRemove removes a reporting address record from the suppress list." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "TLSRPTSuppressExtend" ,
"Docs" : "TLSRPTSuppressExtend updates the until field of a suppressed reporting address record." ,
"Params" : [
{
"Name" : "id" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "until" ,
"Typewords" : [
"timestamp"
]
}
] ,
"Returns" : [ ]
2024-03-05 12:50:56 +03:00
} ,
{
"Name" : "LookupCid" ,
"Docs" : "LookupCid turns an ID from a Received header into a cid as used in logging." ,
"Params" : [
{
"Name" : "recvID" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "cid" ,
"Typewords" : [
"string"
]
}
]
2023-01-30 16:27:06 +03:00
}
] ,
"Sections" : [ ] ,
"Structs" : [
{
"Name" : "CheckResult" ,
"Docs" : "CheckResult is the analysis of a domain, its actual configuration (DNS, TLS,\nconnectivity) and the mox configuration. It includes configuration instructions\n(e.g. DNS records), and warnings and errors encountered." ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
{
"Name" : "DNSSEC" ,
"Docs" : "" ,
"Typewords" : [
"DNSSECResult"
]
} ,
2023-02-03 17:54:34 +03:00
{
"Name" : "IPRev" ,
"Docs" : "" ,
"Typewords" : [
"IPRevCheckResult"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "MX" ,
"Docs" : "" ,
"Typewords" : [
"MXCheckResult"
]
} ,
{
"Name" : "TLS" ,
"Docs" : "" ,
"Typewords" : [
"TLSCheckResult"
]
} ,
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
{
"Name" : "DANE" ,
"Docs" : "" ,
"Typewords" : [
"DANECheckResult"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "SPF" ,
"Docs" : "" ,
"Typewords" : [
"SPFCheckResult"
]
} ,
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Typewords" : [
"DKIMCheckResult"
]
} ,
{
"Name" : "DMARC" ,
"Docs" : "" ,
"Typewords" : [
"DMARCCheckResult"
]
} ,
{
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
"Name" : "HostTLSRPT" ,
"Docs" : "" ,
"Typewords" : [
"TLSRPTCheckResult"
]
} ,
{
"Name" : "DomainTLSRPT" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"TLSRPTCheckResult"
]
} ,
{
"Name" : "MTASTS" ,
"Docs" : "" ,
"Typewords" : [
"MTASTSCheckResult"
]
} ,
{
"Name" : "SRVConf" ,
"Docs" : "" ,
"Typewords" : [
"SRVConfCheckResult"
]
} ,
{
"Name" : "Autoconf" ,
"Docs" : "" ,
"Typewords" : [
"AutoconfCheckResult"
]
} ,
{
"Name" : "Autodiscover" ,
"Docs" : "" ,
"Typewords" : [
"AutodiscoverCheckResult"
]
}
]
} ,
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
{
"Name" : "DNSSECResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
2023-02-03 17:54:34 +03:00
{
"Name" : "IPRevCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Hostname" ,
"Docs" : "This hostname, IPs must resolve back to this." ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "IPNames" ,
"Docs" : "IP to names." ,
"Typewords" : [
"{}" ,
"[]" ,
"string"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "Domain" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Domain is a domain name, with one or more labels, with at least an ASCII\nrepresentation, and for IDNA non-ASCII domains a unicode representation.\nThe ASCII string must be used for DNS lookups. The strings do not have a\ntrailing dot. When using with StrictResolver, add the trailing dot." ,
2023-02-03 17:54:34 +03:00
"Fields" : [
{
"Name" : "ASCII" ,
2023-12-12 17:47:26 +03:00
"Docs" : "A non-unicode domain, e.g. with A-labels (xn--...) or NR-LDH (non-reserved letters/digits/hyphens) labels. Always in lower case. No trailing dot." ,
2023-02-03 17:54:34 +03:00
"Typewords" : [
"string"
]
} ,
{
"Name" : "Unicode" ,
2024-03-08 23:08:40 +03:00
"Docs" : "Name as U-labels, in Unicode NFC. Empty if this is an ASCII-only domain. No trailing dot." ,
2023-02-03 17:54:34 +03:00
"Typewords" : [
"string"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "MXCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Records" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"MX"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "MX" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Host" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Pref" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "IPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "TLSCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DANECheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
2023-01-30 16:27:06 +03:00
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "SPFCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "DomainTXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DomainRecord" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"SPFRecord"
]
} ,
{
"Name" : "HostTXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "HostRecord" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"SPFRecord"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "SPFRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Version" ,
"Docs" : "Must be \"spf1\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Directives" ,
"Docs" : "An IP is evaluated against each directive until a match is found." ,
"Typewords" : [
"[]" ,
"Directive"
]
} ,
{
"Name" : "Redirect" ,
"Docs" : "Modifier that redirects SPF checks to other domain after directives did not match. Optional. For \"redirect=\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Explanation" ,
"Docs" : "Modifier for creating a user-friendly error message when an IP results in status \"fail\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Other" ,
"Docs" : "Other modifiers." ,
"Typewords" : [
"[]" ,
"Modifier"
]
}
]
} ,
{
"Name" : "Directive" ,
"Docs" : "Directive consists of a mechanism that describes how to check if an IP matches,\nan (optional) qualifier indicating the policy for a match, and optional\nparameters specific to the mechanism." ,
"Fields" : [
{
"Name" : "Qualifier" ,
"Docs" : "Sets the result if this directive matches. \"\" and \"+\" are \"pass\", \"-\" is \"fail\", \"?\" is \"neutral\", \"~\" is \"softfail\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Mechanism" ,
"Docs" : "\"all\", \"include\", \"a\", \"mx\", \"ptr\", \"ip4\", \"ip6\", \"exists\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DomainSpec" ,
"Docs" : "For include, a, mx, ptr, exists. Always in lower-case when parsed using ParseRecord." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "IPstr" ,
"Docs" : "Original string for IP, always with /subnet." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "IP4CIDRLen" ,
"Docs" : "For a, mx, ip4." ,
"Typewords" : [
"nullable" ,
"int32"
]
} ,
{
"Name" : "IP6CIDRLen" ,
"Docs" : "For a, mx, ip6." ,
"Typewords" : [
"nullable" ,
"int32"
]
}
]
} ,
{
"Name" : "Modifier" ,
"Docs" : "Modifier provides additional information for a policy.\n\"redirect\" and \"exp\" are not represented as a Modifier but explicitly in a Record." ,
"Fields" : [
{
"Name" : "Key" ,
"Docs" : "Key is case-insensitive." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Value" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "DKIMCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Records" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"DKIMRecord"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DKIMRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Selector" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "TXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Record" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"Record"
]
}
]
} ,
{
"Name" : "Record" ,
"Docs" : "Record is a DKIM DNS record, served on \u003cselector\u003e._domainkey.\u003cdomain\u003e for a\ngiven selector and domain (s= and d= in the DKIM-Signature).\n\nThe record is a semicolon-separated list of \"=\"-separated field value pairs.\nStrings should be compared case-insensitively, e.g. k=ed25519 is equivalent to k=ED25519.\n\nExample:\n\n\tv=DKIM1;h=sha256;k=ed25519;p=ln5zd/JEX4Jy60WAhUOv33IYm2YZMyTQAdr9stML504=" ,
"Fields" : [
{
"Name" : "Version" ,
"Docs" : "Version, fixed \"DKIM1\" (case sensitive). Field \"v\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Hashes" ,
"Docs" : "Acceptable hash algorithms, e.g. \"sha1\", \"sha256\". Optional, defaults to all algorithms. Field \"h\"." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Key" ,
"Docs" : "Key type, \"rsa\" or \"ed25519\". Optional, default \"rsa\". Field \"k\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Notes" ,
"Docs" : "Debug notes. Field \"n\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Pubkey" ,
"Docs" : "Public key, as base64 in record. If empty, the key has been revoked. Field \"p\"." ,
"Typewords" : [
"[]" ,
"uint8"
]
} ,
{
"Name" : "Services" ,
"Docs" : "Service types. Optional, default \"*\" for all services. Other values: \"email\". Field \"s\"." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Flags" ,
"Docs" : "Flags, colon-separated. Optional, default is no flags. Other values: \"y\" for testing DKIM, \"s\" for \"i=\" must have same domain as \"d\" in signatures. Field \"t\"." ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DMARCCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "TXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Record" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"DMARCRecord"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DMARCRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Version" ,
2023-12-12 17:47:26 +03:00
"Docs" : "\"v=DMARC1\", fixed." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
"Name" : "Policy" ,
"Docs" : "Required, for \"p=\"." ,
"Typewords" : [
"DMARCPolicy"
]
} ,
{
"Name" : "SubdomainPolicy" ,
"Docs" : "Like policy but for subdomains. Optional, for \"sp=\"." ,
"Typewords" : [
"DMARCPolicy"
]
} ,
{
"Name" : "AggregateReportAddresses" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Optional, for \"rua=\". Destination addresses for aggregate reports." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"URI"
]
} ,
{
"Name" : "FailureReportAddresses" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Optional, for \"ruf=\". Destination addresses for failure reports." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"URI"
]
} ,
{
"Name" : "ADKIM" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Alignment: \"r\" (default) for relaxed or \"s\" for simple. For \"adkim=\"." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"Align"
]
} ,
{
"Name" : "ASPF" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Alignment: \"r\" (default) for relaxed or \"s\" for simple. For \"aspf=\"." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"Align"
]
} ,
{
"Name" : "AggregateReportingInterval" ,
2023-12-12 17:47:26 +03:00
"Docs" : "In seconds, default 86400. For \"ri=\"" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"int32"
]
} ,
{
"Name" : "FailureReportingOptions" ,
"Docs" : "\"0\" (default), \"1\", \"d\", \"s\". For \"fo=\"." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "ReportingFormat" ,
2023-12-12 17:47:26 +03:00
"Docs" : "\"afrf\" (default). For \"rf=\"." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Percentage" ,
2023-12-12 17:47:26 +03:00
"Docs" : "Between 0 and 100, default 100. For \"pct=\". Policy applies randomly to this percentage of messages." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "URI" ,
"Docs" : "URI is a destination address for reporting." ,
"Fields" : [
{
"Name" : "Address" ,
"Docs" : "Should start with \"mailto:\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "MaxSize" ,
"Docs" : "Optional maximum message size, subject to Unit." ,
"Typewords" : [
"uint64"
]
} ,
{
"Name" : "Unit" ,
2023-08-23 15:27:21 +03:00
"Docs" : "\"\" (b), \"k\", \"m\", \"g\", \"t\" (case insensitive), unit size, where k is 2^10 etc." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "TLSRPTCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "TXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Record" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TLSRPTRecord"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "TLSRPTRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Version" ,
"Docs" : "\"TLSRPTv1\", for \"v=\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RUAs" ,
2023-11-10 22:25:06 +03:00
"Docs" : "Aggregate reporting URI, for \"rua=\". \"rua=\" can occur multiple times, each can be a list." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"[]" ,
2023-11-10 22:25:06 +03:00
"RUA"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "Extensions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Extension"
]
}
]
} ,
{
"Name" : "Extension" ,
"Docs" : "Extension is an additional key/value pair for a TLSRPT record." ,
"Fields" : [
{
"Name" : "Key" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Value" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "MTASTSCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "TXT" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Record" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"MTASTSRecord"
]
} ,
{
"Name" : "PolicyText" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Policy" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"Policy"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "MTASTSRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Version" ,
"Docs" : "\"STSv1\", for \"v=\". Required." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ID" ,
"Docs" : "Record version, for \"id=\". Required." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Extensions" ,
"Docs" : "Optional extensions." ,
"Typewords" : [
"[]" ,
"Pair"
]
}
]
} ,
{
"Name" : "Pair" ,
"Docs" : "Pair is an extension key/value pair in a MTA-STS DNS record or policy." ,
"Fields" : [
{
"Name" : "Key" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Value" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "Policy" ,
"Docs" : "Policy is an MTA-STS policy as served at \"https://mta-sts.\u003cdomain\u003e/.well-known/mta-sts.txt\"." ,
"Fields" : [
{
"Name" : "Version" ,
"Docs" : "\"STSv1\"" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Mode" ,
"Docs" : "" ,
"Typewords" : [
"Mode"
]
} ,
{
"Name" : "MX" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"STSMX"
]
} ,
{
"Name" : "MaxAgeSeconds" ,
"Docs" : "How long this policy can be cached. Suggested values are in weeks or more." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Extensions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Pair"
]
}
]
} ,
{
"Name" : "STSMX" ,
"Docs" : "STSMX is an allowlisted MX host name/pattern.\ntodo: find a way to name this just STSMX without getting duplicate names for \"MX\" in the sherpa api." ,
"Fields" : [
{
"Name" : "Wildcard" ,
"Docs" : "\"*.\" wildcard, e.g. if a subdomain matches. A wildcard must match exactly one label. *.example.com matches mail.example.com, but not example.com, and not foor.bar.example.com." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
}
]
} ,
{
"Name" : "SRVConfCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "SRVs" ,
"Docs" : "Service (e.g. \"_imaps\") to records." ,
"Typewords" : [
"{}" ,
"[]" ,
"SRV"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "SRV" ,
"Docs" : "An SRV represents a single DNS SRV record." ,
"Fields" : [
{
"Name" : "Target" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Port" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
} ,
{
"Name" : "Priority" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
} ,
{
"Name" : "Weight" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
}
]
} ,
{
"Name" : "AutoconfCheckResult" ,
"Docs" : "" ,
"Fields" : [
assume a dns cname record mail.<domain>, pointing to the hostname of the mail server, for clients to connect to
the autoconfig/autodiscover endpoints, and the printed client settings (in
quickstart, in the admin interface) now all point to the cname record (called
"client settings domain"). it is configurable per domain, and set to
"mail.<domain>" by default. for existing mox installs, the domain can be added
by editing the config file.
this makes it easier for a domain to migrate to another server in the future.
client settings don't have to be updated, the cname can just be changed.
before, the hostname of the mail server was configured in email clients.
migrating away would require changing settings in all clients.
if a client settings domain is configured, a TLS certificate for the name will
be requested through ACME, or must be configured manually.
2023-12-24 13:01:16 +03:00
{
"Name" : "ClientSettingsDomainIPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "IPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "AutodiscoverCheckResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Records" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"AutodiscoverSRV"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Warnings" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "Instructions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "AutodiscoverSRV" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Target" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Port" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
} ,
{
"Name" : "Priority" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
} ,
{
"Name" : "Weight" ,
"Docs" : "" ,
"Typewords" : [
"uint16"
]
} ,
{
"Name" : "IPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "PolicyRecord" ,
"Docs" : "PolicyRecord is a cached policy or absence of a policy." ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "Domain name, with unicode characters." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Inserted" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "ValidEnd" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "LastUpdate" ,
"Docs" : "Policies are refreshed on use and periodically." ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "LastUse" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Backoff" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "RecordID" ,
"Docs" : "As retrieved from DNS." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Version" ,
"Docs" : "\"STSv1\"" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Mode" ,
"Docs" : "" ,
"Typewords" : [
"Mode"
]
} ,
{
"Name" : "MX" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"STSMX"
]
} ,
{
"Name" : "MaxAgeSeconds" ,
"Docs" : "How long this policy can be cached. Suggested values are in weeks or more." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Extensions" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Pair"
]
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
} ,
{
"Name" : "PolicyText" ,
"Docs" : "Text that make up the policy, as retrieved. We didn't store this in the past. If empty, policy can be reconstructed from Policy field. Needed by TLSRPT." ,
"Typewords" : [
"string"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
"Name" : "TLSReportRecord" ,
"Docs" : "TLSReportRecord is a TLS report as a database record, including information\nabout the sender.\n\ntodo: should be named just Record, but it would cause a sherpa type name conflict." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Domain" ,
2023-11-12 16:19:12 +03:00
"Docs" : "Policy domain to which the TLS report applies. Unicode." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
"Name" : "FromDomain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "MailFrom" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
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
{
"Name" : "HostReport" ,
"Docs" : "Report for host TLSRPT record, as opposed to domain TLSRPT record." ,
"Typewords" : [
"bool"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "Report" ,
"Docs" : "" ,
"Typewords" : [
"Report"
]
}
]
} ,
{
"Name" : "Report" ,
2023-12-31 13:55:22 +03:00
"Docs" : "Report is a TLSRPT report." ,
2023-01-30 16:27:06 +03:00
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "OrganizationName" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "DateRange" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"TLSRPTDateRange"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "ContactInfo" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "ReportID" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "Policies" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Result"
]
}
]
} ,
{
"Name" : "TLSRPTDateRange" ,
"Docs" : "note: with TLSRPT prefix to prevent clash in sherpadoc types." ,
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "Start" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "End" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
}
]
} ,
{
"Name" : "Result" ,
"Docs" : "" ,
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "Policy" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"ResultPolicy"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "Summary" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"Summary"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "FailureDetails" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"FailureDetails"
]
}
]
} ,
{
"Name" : "ResultPolicy" ,
"Docs" : "" ,
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "Type" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
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
"PolicyType"
2023-01-30 16:27:06 +03:00
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "String" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "Domain" ,
2024-01-24 12:36:20 +03:00
"Docs" : "ASCII/A-labels, ../rfc/8460:704" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "MXHost" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "Summary" ,
"Docs" : "" ,
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "TotalSuccessfulSessionCount" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "TotalFailureSessionCount" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"int64"
]
}
]
} ,
{
"Name" : "FailureDetails" ,
"Docs" : "" ,
"Fields" : [
{
2023-12-31 13:55:22 +03:00
"Name" : "ResultType" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"ResultType"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "SendingMTAIP" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "ReceivingMXHostname" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "ReceivingMXHelo" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "ReceivingIP" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "FailedSessionCount" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "AdditionalInformation" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2023-12-31 13:55:22 +03:00
"Name" : "FailureReasonCode" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "TLSRPTSummary" ,
"Docs" : "TLSRPTSummary presents TLS reporting statistics for a single domain\nover a period." ,
"Fields" : [
{
2023-11-12 16:19:12 +03:00
"Name" : "PolicyDomain" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2023-11-12 16:19:12 +03:00
"Domain"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "Success" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Failure" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "ResultTypeCounts" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
2023-11-12 16:58:46 +03:00
"int64"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
"Name" : "DomainFeedback" ,
"Docs" : "DomainFeedback is a single report stored in the database." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Domain" ,
"Docs" : "Domain where DMARC DNS record was found, could be organizational domain." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "FromDomain" ,
"Docs" : "Domain in From-header." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Version" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ReportMetadata" ,
"Docs" : "" ,
"Typewords" : [
"ReportMetadata"
]
} ,
{
"Name" : "PolicyPublished" ,
"Docs" : "" ,
"Typewords" : [
"PolicyPublished"
]
} ,
{
"Name" : "Records" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"ReportRecord"
]
}
]
} ,
{
"Name" : "ReportMetadata" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "OrgName" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Email" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ExtraContactInfo" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ReportID" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DateRange" ,
"Docs" : "" ,
"Typewords" : [
"DateRange"
]
} ,
{
"Name" : "Errors" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "DateRange" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Begin" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "End" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
}
]
} ,
{
"Name" : "PolicyPublished" ,
"Docs" : "PolicyPublished is the policy as found in DNS for the domain." ,
"Fields" : [
{
"Name" : "Domain" ,
2023-11-01 19:55:40 +03:00
"Docs" : "Domain is where DMARC record was found, not necessarily message From. Reports we generate use unicode names, incoming reports may have either ASCII-only or Unicode domains." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
"Name" : "ADKIM" ,
"Docs" : "" ,
"Typewords" : [
"Alignment"
]
} ,
{
"Name" : "ASPF" ,
"Docs" : "" ,
"Typewords" : [
"Alignment"
]
} ,
{
"Name" : "Policy" ,
"Docs" : "" ,
"Typewords" : [
"Disposition"
]
} ,
{
"Name" : "SubdomainPolicy" ,
"Docs" : "" ,
"Typewords" : [
"Disposition"
]
} ,
{
"Name" : "Percentage" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "ReportingOptions" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "ReportRecord" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Row" ,
"Docs" : "" ,
"Typewords" : [
"Row"
]
} ,
{
"Name" : "Identifiers" ,
"Docs" : "" ,
"Typewords" : [
"Identifiers"
]
} ,
{
"Name" : "AuthResults" ,
"Docs" : "" ,
"Typewords" : [
"AuthResults"
]
}
]
} ,
{
"Name" : "Row" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "SourceIP" ,
"Docs" : "SourceIP must match the pattern ((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3} (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])| ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Count" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "PolicyEvaluated" ,
"Docs" : "" ,
"Typewords" : [
"PolicyEvaluated"
]
}
]
} ,
{
"Name" : "PolicyEvaluated" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Disposition" ,
"Docs" : "" ,
"Typewords" : [
"Disposition"
]
} ,
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Typewords" : [
"DMARCResult"
]
} ,
{
"Name" : "SPF" ,
"Docs" : "" ,
"Typewords" : [
"DMARCResult"
]
} ,
{
"Name" : "Reasons" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"PolicyOverrideReason"
]
}
]
} ,
{
"Name" : "PolicyOverrideReason" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Type" ,
"Docs" : "" ,
"Typewords" : [
"PolicyOverride"
]
} ,
{
"Name" : "Comment" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "Identifiers" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "EnvelopeTo" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "EnvelopeFrom" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "HeaderFrom" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "AuthResults" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"DKIMAuthResult"
]
} ,
{
"Name" : "SPF" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"SPFAuthResult"
]
}
]
} ,
{
"Name" : "DKIMAuthResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Selector" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Result" ,
"Docs" : "" ,
"Typewords" : [
"DKIMResult"
]
} ,
{
"Name" : "HumanResult" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "SPFAuthResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Scope" ,
"Docs" : "" ,
"Typewords" : [
"SPFDomainScope"
]
} ,
{
"Name" : "Result" ,
"Docs" : "" ,
"Typewords" : [
"SPFResult"
]
}
]
} ,
{
"Name" : "DMARCSummary" ,
"Docs" : "DMARCSummary presents DMARC aggregate reporting statistics for a single domain\nover a period." ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Total" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "DispositionNone" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "DispositionQuarantine" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "DispositionReject" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "DKIMFail" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "SPFFail" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "PolicyOverrides" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"int32"
]
}
]
} ,
{
"Name" : "Reverse" ,
"Docs" : "Reverse is the result of a reverse lookup." ,
"Fields" : [
{
"Name" : "Hostnames" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
2023-09-23 13:05:40 +03:00
"Name" : "ClientConfigs" ,
"Docs" : "ClientConfigs holds the client configuration for IMAP/Submission for a\ndomain." ,
2023-01-30 16:27:06 +03:00
"Fields" : [
{
"Name" : "Entries" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
2023-09-23 13:05:40 +03:00
"ClientConfigsEntry"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
2023-09-23 13:05:40 +03:00
"Name" : "ClientConfigsEntry" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Fields" : [
{
"Name" : "Protocol" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Host" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "Port" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Listener" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Note" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "Msg" ,
2023-11-01 19:55:40 +03:00
"Docs" : "Msg is a message in the queue.\n\nUse MakeMsg to make a message with fields that Add needs. Add will further set\nqueueing related fields." ,
2023-01-30 16:27:06 +03:00
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
2024-03-05 22:10:28 +03:00
{
"Name" : "BaseID" ,
queue: deliver to multiple recipients in a single smtp transaction
transferring the data only once. we only do this when the recipient domains
are the same. when queuing, we now take care to set the same NextAttempt
timestamp, so queued messages are actually eligable for combined delivery.
this adds a DeliverMultiple to the smtp client. for pipelined requests, it will
send all RCPT TO (and MAIL and DATA) in one go, and handles the various
responses and error conditions, returning either an overal error, or per
recipient smtp responses. the results of the smtp LIMITS extension are also
available in the smtp client now.
this also takes the "LIMITS RCPTMAX" smtp extension into account: if the server
only accepts a single recipient, we won't send multiple.
if a server doesn't announce a RCPTMAX limit, but still has one (like mox does
for non-spf-verified transactions), we'll recognize code 452 and 552 (for
historic reasons) as temporary error, and try again in a separate transaction
immediately after. we don't yet implement "LIMITS MAILMAX", doesn't seem likely
in practice.
2024-03-07 12:07:53 +03:00
"Docs" : "A message for multiple recipients will get a BaseID that is identical to the first Msg.ID queued. The message contents will be identical for each recipient, including MsgPrefix. If other properties are identical too, including recipient domain, multiple Msgs may be delivered in a single SMTP transaction. For messages with a single recipient, this field will be 0." ,
2024-03-05 22:10:28 +03:00
"Typewords" : [
"int64"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "Queued" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "SenderAccount" ,
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
"Docs" : "Failures are delivered back to this local account. Also used for routing." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"string"
]
} ,
{
"Name" : "SenderLocalpart" ,
"Docs" : "Should be a local user and domain." ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "SenderDomain" ,
"Docs" : "" ,
"Typewords" : [
"IPDomain"
]
} ,
{
"Name" : "RecipientLocalpart" ,
"Docs" : "Typically a remote user and domain." ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "RecipientDomain" ,
"Docs" : "" ,
"Typewords" : [
"IPDomain"
]
} ,
{
"Name" : "RecipientDomainStr" ,
"Docs" : "For filtering." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Attempts" ,
"Docs" : "Next attempt is based on last attempt and exponential back off based on attempts." ,
"Typewords" : [
"int32"
]
} ,
2023-11-01 19:55:40 +03:00
{
"Name" : "MaxAttempts" ,
"Docs" : "Max number of attempts before giving up. If 0, then the default of 8 attempts is used instead." ,
"Typewords" : [
"int32"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DialedIPs" ,
"Docs" : "For each host, the IPs that were dialed. Used for IP selection for later attempts." ,
"Typewords" : [
"{}" ,
"[]" ,
"IP"
]
} ,
{
"Name" : "NextAttempt" ,
"Docs" : "For scheduling." ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "LastAttempt" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"timestamp"
]
} ,
{
"Name" : "LastError" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Has8bit" ,
"Docs" : "Whether message contains bytes with high bit set, determines whether 8BITMIME SMTP extension is needed." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "SMTPUTF8" ,
"Docs" : "Whether message requires use of SMTPUTF8." ,
"Typewords" : [
"bool"
]
} ,
2023-11-01 19:55:40 +03:00
{
"Name" : "IsDMARCReport" ,
"Docs" : "Delivery failures for DMARC reports are handled differently." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "IsTLSReport" ,
"Docs" : "Delivery failures for TLS reports are handled differently." ,
"Typewords" : [
"bool"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "Size" ,
"Docs" : "Full size of message, combined MsgPrefix with contents of message file." ,
"Typewords" : [
"int64"
]
} ,
2023-07-23 18:56:39 +03:00
{
"Name" : "MessageID" ,
"Docs" : "Used when composing a DSN, in its References header." ,
"Typewords" : [
"string"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "MsgPrefix" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"uint8"
]
} ,
{
"Name" : "DSNUTF8" ,
"Docs" : "If set, this message is a DSN and this is a version using utf-8, for the case the remote MTA supports smtputf8. In this case, Size and MsgPrefix are not relevant." ,
"Typewords" : [
"[]" ,
"uint8"
]
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
} ,
{
"Name" : "Transport" ,
"Docs" : "If non-empty, the transport to use for this message. Can be set through cli or admin interface. If empty (the default for a submitted message), regular routing rules apply." ,
"Typewords" : [
"string"
]
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
} ,
{
"Name" : "RequireTLS" ,
"Docs" : "RequireTLS influences TLS verification during delivery. If nil, the recipient domain policy is followed (MTA-STS and/or DANE), falling back to optional opportunistic non-verified STARTTLS. If RequireTLS is true (through SMTP REQUIRETLS extension or webmail submit), MTA-STS or DANE is required, as well as REQUIRETLS support by the next hop server. If RequireTLS is false (through messag header \"TLS-Required: No\"), the recipient domain's policy is ignored if it does not lead to a successful TLS connection, i.e. falling back to SMTP delivery with unverified STARTTLS or plain text." ,
"Typewords" : [
"nullable" ,
"bool"
]
2024-02-10 19:55:56 +03:00
} ,
{
"Name" : "FutureReleaseRequest" ,
"Docs" : "For DSNs, where the original FUTURERELEASE value must be included as per-message field. This field should be of the form \"for;\" plus interval, or \"until;\" plus utc date-time." ,
"Typewords" : [
"string"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
"Name" : "IPDomain" ,
"Docs" : "IPDomain is an ip address, a domain, or empty." ,
"Fields" : [
{
"Name" : "IP" ,
"Docs" : "" ,
"Typewords" : [
"IP"
]
} ,
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
}
]
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
} ,
{
"Name" : "WebserverConfig" ,
"Docs" : "WebserverConfig is the combination of WebDomainRedirects and WebHandlers\nfrom the domains.conf configuration file." ,
"Fields" : [
{
"Name" : "WebDNSDomainRedirects" ,
"Docs" : "From server to frontend." ,
"Typewords" : [
"[]" ,
"[]" ,
"Domain"
]
} ,
{
"Name" : "WebDomainRedirects" ,
"Docs" : "From frontend to server, it's not convenient to create dns.Domain in the frontend." ,
"Typewords" : [
"[]" ,
"[]" ,
"string"
]
} ,
{
"Name" : "WebHandlers" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"WebHandler"
]
}
]
} ,
{
"Name" : "WebHandler" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "LogName" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "PathRegexp" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DontRedirectPlainHTTP" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
2023-08-21 22:52:35 +03:00
{
"Name" : "Compress" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
improve webserver, add domain redirects (aliases), add tests and admin page ui to manage the config
- make builtin http handlers serve on specific domains, such as for mta-sts, so
e.g. /.well-known/mta-sts.txt isn't served on all domains.
- add logging of a few more fields in access logging.
- small tweaks/bug fixes in webserver request handling.
- add config option for redirecting entire domains to another (common enough).
- split httpserver metric into two: one for duration until writing header (i.e.
performance of server), another for duration until full response is sent to
client (i.e. performance as perceived by users).
- add admin ui, a new page for managing the configs. after making changes
and hitting "save", the changes take effect immediately. the page itself
doesn't look very well-designed (many input fields, makes it look messy). i
have an idea to improve it (explained in admin.html as todo) by making the
layout look just like the config file. not urgent though.
i've already changed my websites/webapps over.
the idea of adding a webserver is to take away a (the) reason for folks to want
to complicate their mox setup by running an other webserver on the same machine.
i think the current webserver implementation can already serve most common use
cases. with a few more tweaks (feedback needed!) we should be able to get to 95%
of the use cases. the reverse proxy can take care of the remaining 5%.
nevertheless, a next step is still to change the quickstart to make it easier
for folks to run with an existing webserver, with existing tls certs/keys.
that's how this relates to issue #5.
2023-03-02 20:15:54 +03:00
{
"Name" : "WebStatic" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"WebStatic"
]
} ,
{
"Name" : "WebRedirect" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"WebRedirect"
]
} ,
{
"Name" : "WebForward" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"WebForward"
]
} ,
{
"Name" : "Name" ,
"Docs" : "Either LogName, or numeric index if LogName was empty. Used instead of LogName in logging/metrics." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DNSDomain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
}
]
} ,
{
"Name" : "WebStatic" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "StripPrefix" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Root" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ListFiles" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "ContinueNotFound" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "ResponseHeaders" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"string"
]
}
]
} ,
{
"Name" : "WebRedirect" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "BaseURL" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "OrigPathRegexp" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ReplacePath" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "StatusCode" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "WebForward" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "StripPath" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "URL" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ResponseHeaders" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"string"
]
}
]
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
} ,
{
"Name" : "Transport" ,
"Docs" : "Transport is a method to delivery a message. At most one of the fields can\nbe non-nil. The non-nil field represents the type of transport. For a\ntransport with all fields nil, regular email delivery is done." ,
"Fields" : [
{
"Name" : "Submissions" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TransportSMTP"
]
} ,
{
"Name" : "Submission" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TransportSMTP"
]
} ,
{
"Name" : "SMTP" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TransportSMTP"
]
} ,
{
"Name" : "Socks" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TransportSocks"
]
}
]
} ,
{
"Name" : "TransportSMTP" ,
"Docs" : "TransportSMTP delivers messages by \"submission\" (SMTP, typically\nauthenticated) to the queue of a remote host (smarthost), or by relaying\n(SMTP, typically unauthenticated)." ,
"Fields" : [
{
"Name" : "Host" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Port" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "STARTTLSInsecureSkipVerify" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "NoSTARTTLS" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Auth" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"SMTPAuth"
]
}
]
} ,
{
"Name" : "SMTPAuth" ,
"Docs" : "SMTPAuth hold authentication credentials used when delivering messages\nthrough a smarthost." ,
"Fields" : [
{
"Name" : "Username" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Password" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Mechanisms" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "TransportSocks" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Address" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RemoteIPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "RemoteHostname" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
2023-11-01 19:55:40 +03:00
} ,
{
"Name" : "EvaluationStat" ,
"Docs" : "EvaluationStat summarizes stored evaluations, for inclusion in an upcoming\naggregate report, for a domain." ,
"Fields" : [
{
2023-11-13 16:44:40 +03:00
"Name" : "Domain" ,
2023-11-01 19:55:40 +03:00
"Docs" : "" ,
"Typewords" : [
2023-11-13 16:44:40 +03:00
"Domain"
2023-11-01 19:55:40 +03:00
]
} ,
{
2023-11-13 16:44:40 +03:00
"Name" : "Dispositions" ,
2023-11-01 19:55:40 +03:00
"Docs" : "" ,
"Typewords" : [
2023-11-13 16:44:40 +03:00
"[]" ,
"string"
2023-11-01 19:55:40 +03:00
]
} ,
{
2023-11-13 16:44:40 +03:00
"Name" : "Count" ,
2023-11-01 19:55:40 +03:00
"Docs" : "" ,
"Typewords" : [
2023-11-13 16:44:40 +03:00
"int32"
]
} ,
{
"Name" : "SendReport" ,
"Docs" : "" ,
"Typewords" : [
"bool"
2023-11-01 19:55:40 +03:00
]
}
]
} ,
{
"Name" : "Evaluation" ,
"Docs" : "Evaluation is the result of an evaluation of a DMARC policy, to be included\nin a DMARC report." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "PolicyDomain" ,
"Docs" : "Domain where DMARC policy was found, could be the organizational domain while evaluation was for a subdomain. Unicode. Same as domain found in PolicyPublished. A separate field for its index." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Evaluated" ,
"Docs" : "Time of evaluation, determines which report (covering whole hours) this evaluation will be included in." ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Optional" ,
"Docs" : "If optional, this evaluation is not a reason to send a DMARC report, but it will be included when a report is sent due to other non-optional evaluations. Set for evaluations of incoming DMARC reports. We don't want such deliveries causing us to send a report, or we would keep exchanging reporting messages forever. Also set for when evaluation is a DMARC reject for domains we haven't positively interacted with, to prevent being used to flood an unsuspecting domain with reports." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "IntervalHours" ,
"Docs" : "Effective aggregate reporting interval in hours. Between 1 and 24, rounded up from seconds from policy to first number that can divide 24." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Addresses" ,
"Docs" : "\"rua\" in DMARC record, we only store evaluations for records with aggregate reporting addresses, so always non-empty." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "PolicyPublished" ,
"Docs" : "Policy used for evaluation. We don't store the \"fo\" field for failure reporting options, since we don't send failure reports for individual messages." ,
"Typewords" : [
"PolicyPublished"
]
} ,
{
"Name" : "SourceIP" ,
"Docs" : "For \"row\" in a report record." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Disposition" ,
"Docs" : "" ,
"Typewords" : [
"Disposition"
]
} ,
{
"Name" : "AlignedDKIMPass" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "AlignedSPFPass" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "OverrideReasons" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"PolicyOverrideReason"
]
} ,
{
"Name" : "EnvelopeTo" ,
"Docs" : "For \"identifiers\" in a report record." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "EnvelopeFrom" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "HeaderFrom" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "DKIMResults" ,
"Docs" : "For \"auth_results\" in a report record." ,
"Typewords" : [
"[]" ,
"DKIMAuthResult"
]
} ,
{
"Name" : "SPFResults" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"SPFAuthResult"
]
}
]
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
} ,
2023-11-13 15:48:52 +03:00
{
"Name" : "SuppressAddress" ,
"Docs" : "SuppressAddress is a reporting address for which outgoing DMARC reports\nwill be suppressed for a period." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Inserted" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "ReportingAddress" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Until" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Comment" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
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
{
"Name" : "TLSResult" ,
"Docs" : "TLSResult is stored in the database to track TLS results per policy domain, day\nand recipient domain. These records will be included in TLS reports." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "PolicyDomain" ,
2023-11-20 13:31:46 +03:00
"Docs" : "Domain potentially with TLSRPT DNS record, with addresses that will receive reports. Either a recipient domain (for MTA-STS policies) or an (MX) host (for DANE policies). Unicode." ,
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
"Typewords" : [
"string"
]
} ,
{
"Name" : "DayUTC" ,
"Docs" : "DayUTC is of the form yyyymmdd." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RecipientDomain" ,
2023-11-20 13:31:46 +03:00
"Docs" : "Reports are sent per recipient domain and per MX host. For reports to a recipient domain, we type send a result for MTA-STS and one or more MX host (DANE) results. Unicode." ,
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
"Typewords" : [
"string"
]
} ,
{
"Name" : "Created" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Updated" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "IsHost" ,
2023-11-20 13:31:46 +03:00
"Docs" : "Result is for MX host (DANE), not recipient domain (MTA-STS)." ,
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
"Typewords" : [
"bool"
]
} ,
{
"Name" : "SendReport" ,
"Docs" : "Whether to send a report. TLS results for delivering messages with TLS reports will be recorded, but will not cause a report to be sent." ,
"Typewords" : [
"bool"
]
} ,
2023-11-20 13:31:46 +03:00
{
"Name" : "SentToRecipientDomain" ,
"Docs" : "Set after sending to recipient domain, before sending results to policy domain (after which the record is removed)." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "RecipientDomainReportingAddresses" ,
"Docs" : "Reporting addresses from the recipient domain TLSRPT record, not necessarily those we sent to (e.g. due to failure). Used to leave results to MX target (DANE) policy domains out that were already sent in the report to the recipient domain, so we don't report twice." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "SentToPolicyDomain" ,
"Docs" : "Set after sending report to policy domain." ,
"Typewords" : [
"bool"
]
} ,
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
{
"Name" : "Results" ,
"Docs" : "Results is updated for each TLS attempt." ,
"Typewords" : [
"[]" ,
"Result"
]
}
]
2023-11-13 15:48:52 +03:00
} ,
{
"Name" : "TLSRPTSuppressAddress" ,
"Docs" : "TLSRPTSuppressAddress is a reporting address for which outgoing TLS reports\nwill be suppressed for a period." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Inserted" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "ReportingAddress" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Until" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Comment" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
2023-01-30 16:27:06 +03:00
}
] ,
"Ints" : [ ] ,
"Strings" : [
replace http basic auth for web interfaces with session cookie & csrf-based auth
the http basic auth we had was very simple to reason about, and to implement.
but it has a major downside:
there is no way to logout, browsers keep sending credentials. ideally, browsers
themselves would show a button to stop sending credentials.
a related downside: the http auth mechanism doesn't indicate for which server
paths the credentials are.
another downside: the original password is sent to the server with each
request. though sending original passwords to web servers seems to be
considered normal.
our new approach uses session cookies, along with csrf values when we can. the
sessions are server-side managed, automatically extended on each use. this
makes it easy to invalidate sessions and keeps the frontend simpler (than with
long- vs short-term sessions and refreshing). the cookies are httponly,
samesite=strict, scoped to the path of the web interface. cookies are set
"secure" when set over https. the cookie is set by a successful call to Login.
a call to Logout invalidates a session. changing a password invalidates all
sessions for a user, but keeps the session with which the password was changed
alive. the csrf value is also random, and associated with the session cookie.
the csrf must be sent as header for api calls, or as parameter for direct form
posts (where we cannot set a custom header). rest-like calls made directly by
the browser, e.g. for images, don't have a csrf protection. the csrf value is
returned by the Login api call and stored in localstorage.
api calls without credentials return code "user:noAuth", and with bad
credentials return "user:badAuth". the api client recognizes this and triggers
a login. after a login, all auth-failed api calls are automatically retried.
only for "user:badAuth" is an error message displayed in the login form (e.g.
session expired).
in an ideal world, browsers would take care of most session management. a
server would indicate authentication is needed (like http basic auth), and the
browsers uses trusted ui to request credentials for the server & path. the
browser could use safer mechanism than sending original passwords to the
server, such as scram, along with a standard way to create sessions. for now,
web developers have to do authentication themselves: from showing the login
prompt, ensuring the right session/csrf cookies/localstorage/headers/etc are
sent with each request.
webauthn is a newer way to do authentication, perhaps we'll implement it in the
future. though hardware tokens aren't an attractive option for many users, and
it may be overkill as long as we still do old-fashioned authentication in smtp
& imap where passwords can be sent to the server.
for issue #58
2024-01-04 15:10:48 +03:00
{
"Name" : "CSRFToken" ,
"Docs" : "" ,
"Values" : null
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DMARCPolicy" ,
"Docs" : "Policy as used in DMARC DNS record for \"p=\" or \"sp=\"." ,
"Values" : [
{
"Name" : "PolicyEmpty" ,
"Value" : "" ,
"Docs" : "Only for the optional Record.SubdomainPolicy."
} ,
{
"Name" : "PolicyNone" ,
"Value" : "none" ,
"Docs" : ""
} ,
{
"Name" : "PolicyQuarantine" ,
"Value" : "quarantine" ,
"Docs" : ""
} ,
{
"Name" : "PolicyReject" ,
"Value" : "reject" ,
"Docs" : ""
}
]
} ,
{
"Name" : "Align" ,
"Docs" : "Align specifies the required alignment of a domain name." ,
"Values" : [
{
"Name" : "AlignStrict" ,
"Value" : "s" ,
"Docs" : "Strict requires an exact domain name match."
} ,
{
"Name" : "AlignRelaxed" ,
"Value" : "r" ,
"Docs" : "Relaxed requires either an exact or subdomain name match."
}
]
} ,
2023-11-10 22:25:06 +03:00
{
"Name" : "RUA" ,
"Docs" : "RUA is a reporting address with scheme and special characters \",\", \"!\" and\n\";\" not encoded." ,
"Values" : null
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "Mode" ,
"Docs" : "Mode indicates how the policy should be interpreted." ,
"Values" : [
{
"Name" : "ModeEnforce" ,
"Value" : "enforce" ,
"Docs" : "Policy must be followed, i.e. deliveries must fail if a TLS connection cannot be made."
} ,
{
"Name" : "ModeTesting" ,
"Value" : "testing" ,
2023-12-12 17:47:26 +03:00
"Docs" : "In case TLS cannot be negotiated, plain SMTP can be used, but failures must be reported, e.g. with TLSRPT."
2023-01-30 16:27:06 +03:00
} ,
{
"Name" : "ModeNone" ,
"Value" : "none" ,
"Docs" : "In case MTA-STS is not or no longer implemented."
}
]
} ,
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
{
"Name" : "PolicyType" ,
"Docs" : "PolicyType indicates the policy success/failure results are for." ,
"Values" : [
{
"Name" : "TLSA" ,
"Value" : "tlsa" ,
"Docs" : "For DANE, against a mail host (not recipient domain)."
} ,
{
"Name" : "STS" ,
"Value" : "sts" ,
"Docs" : "For MTA-STS, against a recipient domain (not a mail host)."
} ,
{
"Name" : "NoPolicyFound" ,
"Value" : "no-policy-found" ,
"Docs" : "Recipient domain did not have MTA-STS policy, or mail host (TSLA base domain)\ndid not have DANE TLSA records."
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "ResultType" ,
"Docs" : "ResultType represents a TLS error." ,
"Values" : [
{
"Name" : "ResultSTARTTLSNotSupported" ,
"Value" : "starttls-not-supported" ,
"Docs" : ""
} ,
{
"Name" : "ResultCertificateHostMismatch" ,
"Value" : "certificate-host-mismatch" ,
"Docs" : ""
} ,
{
"Name" : "ResultCertificateExpired" ,
"Value" : "certificate-expired" ,
"Docs" : ""
} ,
{
"Name" : "ResultTLSAInvalid" ,
"Value" : "tlsa-invalid" ,
"Docs" : ""
} ,
{
"Name" : "ResultDNSSECInvalid" ,
"Value" : "dnssec-invalid" ,
"Docs" : ""
} ,
{
"Name" : "ResultDANERequired" ,
"Value" : "dane-required" ,
"Docs" : ""
} ,
{
"Name" : "ResultCertificateNotTrusted" ,
"Value" : "certificate-not-trusted" ,
"Docs" : ""
} ,
{
"Name" : "ResultSTSPolicyInvalid" ,
"Value" : "sts-policy-invalid" ,
"Docs" : ""
} ,
{
"Name" : "ResultSTSWebPKIInvalid" ,
"Value" : "sts-webpki-invalid" ,
"Docs" : ""
} ,
{
"Name" : "ResultValidationFailure" ,
"Value" : "validation-failure" ,
"Docs" : "Other error."
} ,
{
"Name" : "ResultSTSPolicyFetch" ,
"Value" : "sts-policy-fetch-error" ,
"Docs" : ""
}
]
} ,
{
"Name" : "Alignment" ,
"Docs" : "Alignment is the identifier alignment." ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "AlignmentAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "AlignmentRelaxed" ,
"Value" : "r" ,
"Docs" : "Subdomains match the DMARC from-domain."
} ,
{
"Name" : "AlignmentStrict" ,
"Value" : "s" ,
"Docs" : "Only exact from-domain match."
}
]
} ,
{
"Name" : "Disposition" ,
"Docs" : "Disposition is the requested action for a DMARC fail as specified in the\nDMARC policy in DNS." ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "DispositionAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DispositionNone" ,
"Value" : "none" ,
"Docs" : ""
} ,
{
"Name" : "DispositionQuarantine" ,
"Value" : "quarantine" ,
"Docs" : ""
} ,
{
"Name" : "DispositionReject" ,
"Value" : "reject" ,
"Docs" : ""
}
]
} ,
{
"Name" : "DMARCResult" ,
"Docs" : "DMARCResult is the final validation and alignment verdict for SPF and DKIM." ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "DMARCAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DMARCPass" ,
"Value" : "pass" ,
"Docs" : ""
} ,
{
"Name" : "DMARCFail" ,
"Value" : "fail" ,
"Docs" : ""
}
]
} ,
{
"Name" : "PolicyOverride" ,
"Docs" : "PolicyOverride is a reason the requested DMARC policy from the DNS record\nwas not applied." ,
"Values" : [
2024-03-09 17:43:49 +03:00
{
"Name" : "PolicyOverrideAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "PolicyOverrideForwarded" ,
"Value" : "forwarded" ,
"Docs" : ""
} ,
{
"Name" : "PolicyOverrideSampledOut" ,
"Value" : "sampled_out" ,
"Docs" : ""
} ,
{
"Name" : "PolicyOverrideTrustedForwarder" ,
"Value" : "trusted_forwarder" ,
"Docs" : ""
} ,
{
"Name" : "PolicyOverrideMailingList" ,
"Value" : "mailing_list" ,
"Docs" : ""
} ,
{
"Name" : "PolicyOverrideLocalPolicy" ,
"Value" : "local_policy" ,
"Docs" : ""
} ,
{
"Name" : "PolicyOverrideOther" ,
"Value" : "other" ,
"Docs" : ""
}
]
} ,
{
"Name" : "DKIMResult" ,
"Docs" : "" ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "DKIMAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "DKIMNone" ,
"Value" : "none" ,
"Docs" : ""
} ,
{
"Name" : "DKIMPass" ,
"Value" : "pass" ,
"Docs" : ""
} ,
{
"Name" : "DKIMFail" ,
"Value" : "fail" ,
"Docs" : ""
} ,
{
"Name" : "DKIMPolicy" ,
"Value" : "policy" ,
"Docs" : ""
} ,
{
"Name" : "DKIMNeutral" ,
"Value" : "neutral" ,
"Docs" : ""
} ,
{
"Name" : "DKIMTemperror" ,
"Value" : "temperror" ,
"Docs" : ""
} ,
{
"Name" : "DKIMPermerror" ,
"Value" : "permerror" ,
"Docs" : ""
}
]
} ,
{
"Name" : "SPFDomainScope" ,
"Docs" : "" ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "SPFDomainScopeAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "SPFDomainScopeHelo" ,
"Value" : "helo" ,
"Docs" : "SMTP EHLO"
} ,
{
"Name" : "SPFDomainScopeMailFrom" ,
"Value" : "mfrom" ,
"Docs" : "SMTP \"MAIL FROM\"."
}
]
} ,
{
"Name" : "SPFResult" ,
"Docs" : "" ,
"Values" : [
2024-01-23 18:36:49 +03:00
{
"Name" : "SPFAbsent" ,
"Value" : "" ,
"Docs" : ""
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "SPFNone" ,
"Value" : "none" ,
"Docs" : ""
} ,
{
"Name" : "SPFNeutral" ,
"Value" : "neutral" ,
"Docs" : ""
} ,
{
"Name" : "SPFPass" ,
"Value" : "pass" ,
"Docs" : ""
} ,
{
"Name" : "SPFFail" ,
"Value" : "fail" ,
"Docs" : ""
} ,
{
"Name" : "SPFSoftfail" ,
"Value" : "softfail" ,
"Docs" : ""
} ,
{
"Name" : "SPFTemperror" ,
"Value" : "temperror" ,
"Docs" : ""
} ,
{
"Name" : "SPFPermerror" ,
"Value" : "permerror" ,
"Docs" : ""
}
]
} ,
2023-03-29 22:11:43 +03:00
{
"Name" : "Localpart" ,
2024-03-08 23:08:40 +03:00
"Docs" : "Localpart is a decoded local part of an email address, before the \"@\".\nFor quoted strings, values do not hold the double quote or escaping backslashes.\nAn empty string can be a valid localpart.\nLocalparts are in Unicode NFC." ,
2023-03-29 22:11:43 +03:00
"Values" : null
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "IP" ,
"Docs" : "An IP is a single IP address, a slice of bytes.\nFunctions in this package accept either 4-byte (IPv4)\nor 16-byte (IPv6) slices as input.\n\nNote that in this documentation, referring to an\nIP address as an IPv4 address or an IPv6 address\nis a semantic property of the address, not just the\nlength of the byte slice: a 16-byte slice can still\nbe an IPv4 address." ,
"Values" : [ ]
}
] ,
"SherpaVersion" : 0 ,
"SherpadocVersion" : 1
}