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"
]
}
]
} ,
2024-04-18 12:14:24 +03:00
{
"Name" : "DomainConfig" ,
"Docs" : "DomainConfig returns the configuration for a domain." ,
"Params" : [
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"ConfigDomain"
]
}
]
} ,
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"
]
2024-04-24 20:15:30 +03:00
} ,
{
"Name" : "localpartAliases" ,
"Typewords" : [
"{}" ,
"Alias"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
"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" : [
{
2024-03-11 16:02:35 +03:00
"Name" : "accountConfig" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
2024-04-14 18:18:20 +03:00
"Account"
2023-01-30 16:27:06 +03:00
]
2024-03-11 16:02:35 +03:00
} ,
{
"Name" : "diskUsage" ,
"Typewords" : [
"int64"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
"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
{
2024-03-16 22:24:07 +03:00
"Name" : "AccountSettingsSave" ,
"Docs" : "AccountSettingsSave set new settings for an account that only an admin can set." ,
2023-03-28 21:50:36 +03:00
"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"
]
2024-03-16 22:24:07 +03:00
} ,
{
"Name" : "firstTimeSenderDelay" ,
"Typewords" : [
"bool"
]
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
]
}
]
} ,
2024-03-18 10:50:42 +03:00
{
"Name" : "QueueSize" ,
"Docs" : "QueueSize returns the number of messages currently in the outgoing queue." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "QueueHoldRuleList" ,
"Docs" : "QueueHoldRuleList lists the hold rules." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"HoldRule"
]
}
]
} ,
{
"Name" : "QueueHoldRuleAdd" ,
"Docs" : "QueueHoldRuleAdd adds a hold rule. Newly submitted and existing messages\nmatching the hold rule will be marked \"on hold\"." ,
"Params" : [
{
"Name" : "hr" ,
"Typewords" : [
"HoldRule"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"HoldRule"
]
}
]
} ,
{
"Name" : "QueueHoldRuleRemove" ,
"Docs" : "QueueHoldRuleRemove removes a hold rule. The Hold field of messages in\nthe queue are not changed." ,
"Params" : [
{
"Name" : "holdRuleID" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [ ]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "QueueList" ,
"Docs" : "QueueList returns the messages currently in the outgoing queue." ,
2024-03-18 10:50:42 +03:00
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"Filter"
]
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
} ,
{
"Name" : "sort" ,
"Typewords" : [
"Sort"
]
2024-03-18 10:50:42 +03:00
}
] ,
2023-01-30 16:27:06 +03:00
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"Msg"
]
}
]
} ,
2023-02-08 21:42:21 +03:00
{
2024-03-18 10:50:42 +03:00
"Name" : "QueueNextAttemptSet" ,
"Docs" : "QueueNextAttemptSet sets a new time for next delivery attempt of matching\nmessages from the queue." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"Filter"
]
} ,
{
"Name" : "minutes" ,
"Typewords" : [
"int32"
]
}
] ,
2023-02-08 21:42:21 +03:00
"Returns" : [
{
2024-03-18 10:50:42 +03:00
"Name" : "affected" ,
2023-02-08 21:42:21 +03:00
"Typewords" : [
"int32"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
2024-03-18 10:50:42 +03:00
"Name" : "QueueNextAttemptAdd" ,
"Docs" : "QueueNextAttemptAdd adds a duration to the time of next delivery attempt of\nmatching messages from the queue." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
2024-03-18 10:50:42 +03:00
"Name" : "filter" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
2024-03-18 10:50:42 +03:00
"Filter"
2023-01-30 16:27:06 +03:00
]
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
} ,
{
2024-03-18 10:50:42 +03:00
"Name" : "minutes" ,
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
"Typewords" : [
2024-03-18 10:50:42 +03:00
"int32"
new feature: when delivering messages from the queue, make it possible to use a "transport"
the default transport is still just "direct delivery", where we connect to the
destination domain's MX servers.
other transports are:
- regular smtp without authentication, this is relaying to a smarthost.
- submission with authentication, e.g. to a third party email sending service.
- direct delivery, but with with connections going through a socks proxy. this
can be helpful if your ip is blocked, you need to get email out, and you have
another IP that isn't blocked.
keep in mind that for all of the above, appropriate SPF/DKIM settings have to
be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the
SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM
requirements cannot really be checked.
which transport is used can be configured through routes. routes can be set on
an account, a domain, or globally. the routes are evaluated in that order, with
the first match selecting the transport. these routes are evaluated for each
delivery attempt. common selection criteria are recipient domain and sender
domain, but also which delivery attempt this is. you could configured mox to
attempt sending through a 3rd party from the 4th attempt onwards.
routes and transports are optional. if no route matches, or an empty/zero
transport is selected, normal direct delivery is done.
we could already "submit" emails with 3rd party accounts with "sendmail". but
we now support more SASL authentication mechanisms with SMTP (not only PLAIN,
but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also
supports. sendmail will use the most secure mechanism supported by the server,
or the explicitly configured mechanism.
for issue #36 by dmikushin. also based on earlier discussion on hackernews.
2023-06-16 19:38:28 +03:00
]
2023-01-30 16:27:06 +03:00
}
] ,
2024-03-18 10:50:42 +03:00
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "QueueHoldSet" ,
"Docs" : "QueueHoldSet sets the Hold field of matching messages in the queue." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"Filter"
]
} ,
{
"Name" : "onHold" ,
"Typewords" : [
"bool"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "QueueFail" ,
"Docs" : "QueueFail fails delivery for matching messages, causing DSNs to be sent." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"Filter"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
2023-01-30 16:27:06 +03:00
} ,
{
"Name" : "QueueDrop" ,
2024-03-18 10:50:42 +03:00
"Docs" : "QueueDrop removes matching messages from the queue." ,
2023-01-30 16:27:06 +03:00
"Params" : [
{
2024-03-18 10:50:42 +03:00
"Name" : "filter" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
2024-03-18 10:50:42 +03:00
"Filter"
2023-01-30 16:27:06 +03:00
]
}
] ,
2024-03-18 10:50:42 +03:00
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
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
{
2024-03-18 10:50:42 +03:00
"Name" : "QueueRequireTLSSet" ,
"Docs" : "QueueRequireTLSSet updates the requiretls field for matching messages in the\nqueue, to be used for the next delivery." ,
implement "requiretls", rfc 8689
with requiretls, the tls verification mode/rules for email deliveries can be
changed by the sender/submitter. in two ways:
1. "requiretls" smtp extension to always enforce verified tls (with mta-sts or
dnssec+dane), along the entire delivery path until delivery into the final
destination mailbox (so entire transport is verified-tls-protected).
2. "tls-required: no" message header, to ignore any tls and tls verification
errors even if the recipient domain has a policy that requires tls verification
(mta-sts and/or dnssec+dane), allowing delivery of non-sensitive messages in
case of misconfiguration/interoperability issues (at least useful for sending
tls reports).
we enable requiretls by default (only when tls is active), for smtp and
submission. it can be disabled through the config.
for each delivery attempt, we now store (per recipient domain, in the account
of the sender) whether the smtp server supports starttls and requiretls. this
support is shown (after having sent a first message) in the webmail when
sending a message (the previous 3 bars under the address input field are now 5
bars, the first for starttls support, the last for requiretls support). when
all recipient domains for a message are known to implement requiretls,
requiretls is automatically selected for sending (instead of "default" tls
behaviour). users can also select the "fallback to insecure" to add the
"tls-required: no" header.
new metrics are added for insight into requiretls errors and (some, not yet
all) cases where tls-required-no ignored a tls/verification error.
the admin can change the requiretls status for messages in the queue. so with
default delivery attempts, when verified tls is required by failing, an admin
could potentially change the field to "tls-required: no"-behaviour.
messages received (over smtp) with the requiretls option, get a comment added
to their Received header line, just before "id", after "with".
2023-10-24 11:06:16 +03:00
"Params" : [
{
2024-03-18 10:50:42 +03:00
"Name" : "filter" ,
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
"Typewords" : [
2024-03-18 10:50:42 +03:00
"Filter"
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" ,
"Typewords" : [
"nullable" ,
"bool"
]
}
] ,
2024-03-18 10:50:42 +03:00
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "QueueTransportSet" ,
"Docs" : "QueueTransportSet initiates delivery of a message from the queue and sets the transport\nto use for delivery." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"Filter"
]
} ,
{
"Name" : "transport" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
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
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
"Name" : "RetiredList" ,
"Docs" : "RetiredList returns messages retired from the queue (delivery could\nhave succeeded or failed)." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"RetiredFilter"
]
} ,
{
"Name" : "sort" ,
"Typewords" : [
"RetiredSort"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"MsgRetired"
]
}
]
} ,
{
"Name" : "HookQueueSize" ,
"Docs" : "HookQueueSize returns the number of webhooks still to be delivered." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "HookList" ,
"Docs" : "HookList lists webhooks still to be delivered." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"HookFilter"
]
} ,
{
"Name" : "sort" ,
"Typewords" : [
"HookSort"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"Hook"
]
}
]
} ,
{
"Name" : "HookNextAttemptSet" ,
"Docs" : "HookNextAttemptSet sets a new time for next delivery attempt of matching\nhooks from the queue." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"HookFilter"
]
} ,
{
"Name" : "minutes" ,
"Typewords" : [
"int32"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "HookNextAttemptAdd" ,
"Docs" : "HookNextAttemptAdd adds a duration to the time of next delivery attempt of\nmatching hooks from the queue." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"HookFilter"
]
} ,
{
"Name" : "minutes" ,
"Typewords" : [
"int32"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
{
"Name" : "HookRetiredList" ,
"Docs" : "HookRetiredList lists retired webhooks." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"HookRetiredFilter"
]
} ,
{
"Name" : "sort" ,
"Typewords" : [
"HookRetiredSort"
]
}
] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"[]" ,
"HookRetired"
]
}
]
} ,
{
"Name" : "HookCancel" ,
"Docs" : "HookCancel prevents further delivery attempts of matching webhooks." ,
"Params" : [
{
"Name" : "filter" ,
"Typewords" : [
"HookFilter"
]
}
] ,
"Returns" : [
{
"Name" : "affected" ,
"Typewords" : [
"int32"
]
}
]
} ,
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"
]
}
]
2024-04-18 12:14:24 +03:00
} ,
{
"Name" : "Config" ,
"Docs" : "Config returns the dynamic config." ,
"Params" : [ ] ,
"Returns" : [
{
"Name" : "r0" ,
"Typewords" : [
"Dynamic"
]
}
]
} ,
{
"Name" : "AccountRoutesSave" ,
"Docs" : "AccountRoutesSave saves routes for an account." ,
"Params" : [
{
"Name" : "accountName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "routes" ,
"Typewords" : [
"[]" ,
"Route"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainRoutesSave" ,
"Docs" : "DomainRoutesSave saves routes for a domain." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "routes" ,
"Typewords" : [
"[]" ,
"Route"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "RoutesSave" ,
"Docs" : "RoutesSave saves global routes." ,
"Params" : [
{
"Name" : "routes" ,
"Typewords" : [
"[]" ,
"Route"
]
}
] ,
"Returns" : [ ]
2024-04-19 11:23:53 +03:00
} ,
{
"Name" : "DomainDescriptionSave" ,
"Docs" : "DomainDescriptionSave saves the description for a domain." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "descr" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainClientSettingsDomainSave" ,
"Docs" : "DomainClientSettingsDomainSave saves the client settings domain for a domain." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "clientSettingsDomain" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainLocalpartConfigSave" ,
"Docs" : "DomainLocalpartConfigSave saves the localpart catchall and case-sensitive\nsettings for a domain." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "localpartCatchallSeparator" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "localpartCaseSensitive" ,
"Typewords" : [
"bool"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainDMARCAddressSave" ,
"Docs" : "DomainDMARCAddressSave saves the DMARC reporting address/processing\nconfiguration for a domain. If localpart is empty, processing reports is\ndisabled." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "localpart" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "account" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "mailbox" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainTLSRPTAddressSave" ,
"Docs" : "DomainTLSRPTAddressSave saves the TLS reporting address/processing\nconfiguration for a domain. If localpart is empty, processing reports is\ndisabled." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "localpart" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domain" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "account" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "mailbox" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainMTASTSSave" ,
"Docs" : "DomainMTASTSSave saves the MTASTS policy for a domain. If policyID is empty,\nno MTASTS policy is served." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "policyID" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "mode" ,
"Typewords" : [
"Mode"
]
} ,
{
"Name" : "maxAge" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "mx" ,
"Typewords" : [
"[]" ,
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainDKIMAdd" ,
"Docs" : "DomainDKIMAdd adds a DKIM selector for a domain, generating a new private\nkey. The selector is not enabled for signing." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "selector" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "algorithm" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "hash" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "headerRelaxed" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "bodyRelaxed" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "seal" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "headers" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "lifetime" ,
"Typewords" : [
"int64"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainDKIMRemove" ,
"Docs" : "DomainDKIMRemove removes a DKIM selector for a domain." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "selector" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "DomainDKIMSave" ,
"Docs" : "DomainDKIMSave saves the settings of selectors, and which to enable for\nsigning, for a domain. All currently configured selectors must be present,\nselectors cannot be added/removed with this function." ,
"Params" : [
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "selectors" ,
"Typewords" : [
"{}" ,
"Selector"
]
} ,
{
"Name" : "sign" ,
"Typewords" : [
"[]" ,
"string"
]
}
] ,
"Returns" : [ ]
2024-04-24 20:15:30 +03:00
} ,
{
"Name" : "AliasAdd" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "aliaslp" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "alias" ,
"Typewords" : [
"Alias"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AliasUpdate" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "aliaslp" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "postPublic" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "listMembers" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "allowMsgFrom" ,
"Typewords" : [
"bool"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AliasRemove" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "aliaslp" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AliasAddressesAdd" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "aliaslp" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "addresses" ,
"Typewords" : [
"[]" ,
"string"
]
}
] ,
"Returns" : [ ]
} ,
{
"Name" : "AliasAddressesRemove" ,
"Docs" : "" ,
"Params" : [
{
"Name" : "aliaslp" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "domainName" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "addresses" ,
"Typewords" : [
"[]" ,
"string"
]
}
] ,
"Returns" : [ ]
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"
]
} ,
{
2024-04-18 12:14:24 +03:00
"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" ,
2024-04-19 11:51:24 +03:00
"Docs" : "MX is an allowlisted MX host name/pattern." ,
2024-04-18 12:14:24 +03:00
"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" : [
{
"Name" : "ClientSettingsDomainIPs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"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" : "ConfigDomain" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Description" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "ClientSettingsDomain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LocalpartCatchallSeparator" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LocalpartCaseSensitive" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Typewords" : [
"DKIM"
]
} ,
{
"Name" : "DMARC" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"DMARC"
]
} ,
{
"Name" : "MTASTS" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"MTASTS"
]
} ,
{
"Name" : "TLSRPT" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TLSRPT"
]
} ,
{
"Name" : "Routes" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Route"
]
2024-04-24 20:15:30 +03:00
} ,
{
"Name" : "Aliases" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"Alias"
]
} ,
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
2024-04-18 12:14:24 +03:00
}
]
} ,
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Selectors" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"Selector"
]
} ,
{
"Name" : "Sign" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "Selector" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Hash" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "HashEffective" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Canonicalization" ,
"Docs" : "" ,
"Typewords" : [
"Canonicalization"
]
} ,
{
"Name" : "Headers" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "HeadersEffective" ,
"Docs" : "Used when signing. Based on Headers from config, or the reasonable default." ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "DontSealHeaders" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"bool"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Expiration" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
2024-04-18 12:14:24 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "PrivateKeyFile" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
2024-04-19 11:23:53 +03:00
} ,
{
"Name" : "Algorithm" ,
"Docs" : "\"ed25519\", \"rsa-*\", based on private key." ,
"Typewords" : [
"string"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Canonicalization" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Fields" : [
{
2024-04-18 12:14:24 +03:00
"Name" : "HeaderRelaxed" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"bool"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "BodyRelaxed" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"bool"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "DMARC" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Fields" : [
{
2024-04-18 12:14:24 +03:00
"Name" : "Localpart" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
2024-04-18 12:14:24 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Domain" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Account" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Mailbox" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
2024-04-18 12:14:24 +03:00
} ,
{
"Name" : "ParsedLocalpart" ,
"Docs" : "" ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "DNSDomain" ,
"Docs" : "Effective domain, always set based on Domain field or Domain where this is configured." ,
"Typewords" : [
"Domain"
]
2023-01-30 16:27:06 +03:00
}
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "MTASTS" ,
"Docs" : "" ,
2023-01-30 16:27:06 +03:00
"Fields" : [
{
2024-04-18 12:14:24 +03:00
"Name" : "PolicyID" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Mode" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"Mode"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "MaxAge" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"int64"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "MX" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"[]" ,
"string"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "TLSRPT" ,
2023-01-30 16:27:06 +03:00
"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
{
2024-04-18 12:14:24 +03:00
"Name" : "Localpart" ,
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
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
2023-01-30 16:27:06 +03:00
{
2024-04-18 12:14:24 +03:00
"Name" : "Domain" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Account" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Mailbox" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "ParsedLocalpart" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"Localpart"
]
} ,
{
"Name" : "DNSDomain" ,
"Docs" : "Effective domain, always set based on Domain field or Domain where this is configured." ,
"Typewords" : [
"Domain"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Route" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Fields" : [
{
2024-04-18 12:14:24 +03:00
"Name" : "FromDomain" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "ToDomain" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "MinimumAttempts" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"int32"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "Transport" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "FromDomainASCII" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-18 12:14:24 +03:00
"[]" ,
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
2024-04-18 12:14:24 +03:00
"Name" : "ToDomainASCII" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Alias" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Fields" : [
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Addresses" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"[]" ,
"string"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "PostPublic" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"bool"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "ListMembers" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"bool"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "AllowMsgFrom" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"bool"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "LocalpartStr" ,
"Docs" : "In encoded form." ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
2024-04-14 18:18:20 +03:00
{
"Name" : "Domain" ,
"Docs" : "" ,
2024-04-24 20:15:30 +03:00
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "ParsedAddresses" ,
"Docs" : "Matches addresses." ,
"Typewords" : [
"[]" ,
"AliasAddress"
]
}
]
} ,
{
"Name" : "AliasAddress" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Address" ,
"Docs" : "Parsed address." ,
"Typewords" : [
"Address"
]
} ,
{
"Name" : "AccountName" ,
"Docs" : "Looked up." ,
2024-04-14 18:18:20 +03:00
"Typewords" : [
"string"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Destination" ,
"Docs" : "Belonging to address." ,
"Typewords" : [
"Destination"
]
}
]
} ,
{
"Name" : "Address" ,
"Docs" : "Address is a parsed email address." ,
"Fields" : [
{
"Name" : "Localpart" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"Localpart"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Domain" ,
"Docs" : "todo: shouldn't we accept an ip address here too? and merge this type into smtp.Path." ,
"Typewords" : [
"Domain"
]
}
]
} ,
{
"Name" : "Destination" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Mailbox" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Rulesets" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"[]" ,
"Ruleset"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "FullName" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
2024-04-24 20:15:30 +03:00
}
]
} ,
{
"Name" : "Ruleset" ,
"Docs" : "" ,
"Fields" : [
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "SMTPMailFromRegexp" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "MsgFromRegexp" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "VerifiedDomain" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "HeadersRegexp" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"{}" ,
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "IsForward" ,
"Docs" : "todo: once we implement ARC, we can use dkim domains that we cannot verify but that the arc-verified forwarding mail server was able to verify." ,
2024-04-14 18:18:20 +03:00
"Typewords" : [
2024-04-24 20:15:30 +03:00
"bool"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "ListAllowDomain" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "AcceptRejectsToMailbox" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Mailbox" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Comment" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "VerifiedDNSDomain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "ListAllowDNSDomain" ,
"Docs" : "" ,
2024-04-14 18:18:20 +03:00
"Typewords" : [
"Domain"
]
}
]
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Account" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Fields" : [
{
2024-04-24 20:15:30 +03:00
"Name" : "OutgoingWebhook" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"nullable" ,
"OutgoingWebhook"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "IncomingWebhook" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"nullable" ,
"IncomingWebhook"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "FromIDLoginAddresses" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
2024-04-24 20:15:30 +03:00
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "KeepRetiredMessagePeriod" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"int64"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "KeepRetiredWebhookPeriod" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"int64"
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
]
2024-04-24 20:15:30 +03:00
} ,
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Domain" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Description" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
"Name" : "FullName" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
2024-04-24 20:15:30 +03:00
} ,
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Destinations" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"{}" ,
"Destination"
2024-04-14 18:18:20 +03:00
]
} ,
webmail: when moving a single message out of/to the inbox, ask if user wants to create a rule to automatically do that server-side for future deliveries
if the message has a list-id header, we assume this is a (mailing) list
message, and we require a dkim/spf-verified domain (we prefer the shortest that
is a suffix of the list-id value). the rule we would add will mark such
messages as from a mailing list, changing filtering rules on incoming messages
(not enforcing dmarc policies). messages will be matched on list-id header and
will only match if they have the same dkim/spf-verified domain.
if the message doesn't have a list-id header, we'll ask to match based on
"message from" address.
we don't ask the user in several cases:
- if the destination/source mailbox is a special-use mailbox (e.g.
trash,archive,sent,junk; inbox isn't included)
- if the rule already exist (no point in adding it again).
- if the user said "no, not for this list-id/from-address" in the past.
- if the user said "no, not for messages moved to this mailbox" in the past.
we'll add the rule if the message was moved out of the inbox.
if the message was moved to the inbox, we check if there is a matching rule
that we can remove.
we now remember the "no" answers (for list-id, msg-from-addr and mailbox) in
the account database.
to implement the msgfrom rules, this adds support to rulesets for matching on
message "from" address. before, we could match on smtp from address (and other
fields). rulesets now also have a field for comments. webmail adds a note that
it created the rule, with the date.
manual editing of the rulesets is still in the webaccount page. this webmail
functionality is just a convenient way to add/remove common rules.
2024-04-21 18:01:50 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "SubjectPass" ,
webmail: when moving a single message out of/to the inbox, ask if user wants to create a rule to automatically do that server-side for future deliveries
if the message has a list-id header, we assume this is a (mailing) list
message, and we require a dkim/spf-verified domain (we prefer the shortest that
is a suffix of the list-id value). the rule we would add will mark such
messages as from a mailing list, changing filtering rules on incoming messages
(not enforcing dmarc policies). messages will be matched on list-id header and
will only match if they have the same dkim/spf-verified domain.
if the message doesn't have a list-id header, we'll ask to match based on
"message from" address.
we don't ask the user in several cases:
- if the destination/source mailbox is a special-use mailbox (e.g.
trash,archive,sent,junk; inbox isn't included)
- if the rule already exist (no point in adding it again).
- if the user said "no, not for this list-id/from-address" in the past.
- if the user said "no, not for messages moved to this mailbox" in the past.
we'll add the rule if the message was moved out of the inbox.
if the message was moved to the inbox, we check if there is a matching rule
that we can remove.
we now remember the "no" answers (for list-id, msg-from-addr and mailbox) in
the account database.
to implement the msgfrom rules, this adds support to rulesets for matching on
message "from" address. before, we could match on smtp from address (and other
fields). rulesets now also have a field for comments. webmail adds a note that
it created the rule, with the date.
manual editing of the rulesets is still in the webaccount page. this webmail
functionality is just a convenient way to add/remove common rules.
2024-04-21 18:01:50 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"SubjectPass"
webmail: when moving a single message out of/to the inbox, ask if user wants to create a rule to automatically do that server-side for future deliveries
if the message has a list-id header, we assume this is a (mailing) list
message, and we require a dkim/spf-verified domain (we prefer the shortest that
is a suffix of the list-id value). the rule we would add will mark such
messages as from a mailing list, changing filtering rules on incoming messages
(not enforcing dmarc policies). messages will be matched on list-id header and
will only match if they have the same dkim/spf-verified domain.
if the message doesn't have a list-id header, we'll ask to match based on
"message from" address.
we don't ask the user in several cases:
- if the destination/source mailbox is a special-use mailbox (e.g.
trash,archive,sent,junk; inbox isn't included)
- if the rule already exist (no point in adding it again).
- if the user said "no, not for this list-id/from-address" in the past.
- if the user said "no, not for messages moved to this mailbox" in the past.
we'll add the rule if the message was moved out of the inbox.
if the message was moved to the inbox, we check if there is a matching rule
that we can remove.
we now remember the "no" answers (for list-id, msg-from-addr and mailbox) in
the account database.
to implement the msgfrom rules, this adds support to rulesets for matching on
message "from" address. before, we could match on smtp from address (and other
fields). rulesets now also have a field for comments. webmail adds a note that
it created the rule, with the date.
manual editing of the rulesets is still in the webaccount page. this webmail
functionality is just a convenient way to add/remove common rules.
2024-04-21 18:01:50 +03:00
]
} ,
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "QuotaMessageSize" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"int64"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "RejectsMailbox" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "KeepRejects" ,
"Docs" : "" ,
2024-04-14 18:18:20 +03:00
"Typewords" : [
"bool"
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "AutomaticJunkFlags" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"AutomaticJunkFlags"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "JunkFilter" ,
"Docs" : "todo: sane defaults for junkfilter" ,
"Typewords" : [
"nullable" ,
"JunkFilter"
]
} ,
{
"Name" : "MaxOutgoingMessagesPerDay" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"int32"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "MaxFirstTimeRecipientsPerDay" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "NoFirstTimeSenderDelay" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Routes" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Route"
]
} ,
{
"Name" : "DNSDomain" ,
"Docs" : "Parsed form of Domain." ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "Aliases" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"AddressAlias"
]
}
]
} ,
{
"Name" : "OutgoingWebhook" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "URL" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
webmail: when moving a single message out of/to the inbox, ask if user wants to create a rule to automatically do that server-side for future deliveries
if the message has a list-id header, we assume this is a (mailing) list
message, and we require a dkim/spf-verified domain (we prefer the shortest that
is a suffix of the list-id value). the rule we would add will mark such
messages as from a mailing list, changing filtering rules on incoming messages
(not enforcing dmarc policies). messages will be matched on list-id header and
will only match if they have the same dkim/spf-verified domain.
if the message doesn't have a list-id header, we'll ask to match based on
"message from" address.
we don't ask the user in several cases:
- if the destination/source mailbox is a special-use mailbox (e.g.
trash,archive,sent,junk; inbox isn't included)
- if the rule already exist (no point in adding it again).
- if the user said "no, not for this list-id/from-address" in the past.
- if the user said "no, not for messages moved to this mailbox" in the past.
we'll add the rule if the message was moved out of the inbox.
if the message was moved to the inbox, we check if there is a matching rule
that we can remove.
we now remember the "no" answers (for list-id, msg-from-addr and mailbox) in
the account database.
to implement the msgfrom rules, this adds support to rulesets for matching on
message "from" address. before, we could match on smtp from address (and other
fields). rulesets now also have a field for comments. webmail adds a note that
it created the rule, with the date.
manual editing of the rulesets is still in the webaccount page. this webmail
functionality is just a convenient way to add/remove common rules.
2024-04-21 18:01:50 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Authorization" ,
webmail: when moving a single message out of/to the inbox, ask if user wants to create a rule to automatically do that server-side for future deliveries
if the message has a list-id header, we assume this is a (mailing) list
message, and we require a dkim/spf-verified domain (we prefer the shortest that
is a suffix of the list-id value). the rule we would add will mark such
messages as from a mailing list, changing filtering rules on incoming messages
(not enforcing dmarc policies). messages will be matched on list-id header and
will only match if they have the same dkim/spf-verified domain.
if the message doesn't have a list-id header, we'll ask to match based on
"message from" address.
we don't ask the user in several cases:
- if the destination/source mailbox is a special-use mailbox (e.g.
trash,archive,sent,junk; inbox isn't included)
- if the rule already exist (no point in adding it again).
- if the user said "no, not for this list-id/from-address" in the past.
- if the user said "no, not for messages moved to this mailbox" in the past.
we'll add the rule if the message was moved out of the inbox.
if the message was moved to the inbox, we check if there is a matching rule
that we can remove.
we now remember the "no" answers (for list-id, msg-from-addr and mailbox) in
the account database.
to implement the msgfrom rules, this adds support to rulesets for matching on
message "from" address. before, we could match on smtp from address (and other
fields). rulesets now also have a field for comments. webmail adds a note that
it created the rule, with the date.
manual editing of the rulesets is still in the webaccount page. this webmail
functionality is just a convenient way to add/remove common rules.
2024-04-21 18:01:50 +03:00
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
2024-04-14 18:18:20 +03:00
{
2024-04-24 20:15:30 +03:00
"Name" : "Events" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"[]" ,
"string"
]
}
]
} ,
{
"Name" : "IncomingWebhook" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "URL" ,
"Docs" : "" ,
"Typewords" : [
"string"
2024-04-14 18:18:20 +03:00
]
} ,
{
2024-04-24 20:15:30 +03:00
"Name" : "Authorization" ,
2024-04-14 18:18:20 +03:00
"Docs" : "" ,
"Typewords" : [
2024-04-24 20:15:30 +03:00
"string"
2024-04-14 18:18:20 +03:00
]
}
]
} ,
{
"Name" : "SubjectPass" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Period" ,
"Docs" : "todo: have a reasonable default for this?" ,
"Typewords" : [
"int64"
]
}
]
} ,
{
"Name" : "AutomaticJunkFlags" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Enabled" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "JunkMailboxRegexp" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "NeutralMailboxRegexp" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "NotJunkMailboxRegexp" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "JunkFilter" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Threshold" ,
"Docs" : "" ,
"Typewords" : [
"float64"
]
} ,
{
"Name" : "Onegrams" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Twograms" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Threegrams" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "MaxPower" ,
"Docs" : "" ,
"Typewords" : [
"float64"
]
} ,
{
"Name" : "TopWords" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "IgnoreWords" ,
"Docs" : "" ,
"Typewords" : [
"float64"
]
} ,
{
"Name" : "RareWords" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
}
]
} ,
2024-04-24 20:15:30 +03:00
{
"Name" : "AddressAlias" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "SubscriptionAddress" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Alias" ,
"Docs" : "Without members." ,
"Typewords" : [
"Alias"
]
} ,
{
"Name" : "MemberAddresses" ,
"Docs" : "Only if allowed to see." ,
"Typewords" : [
"[]" ,
"string"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"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" ,
2024-04-19 11:51:24 +03:00
"Docs" : "Record is a TLS report as a database record, including information\nabout the sender." ,
2023-01-30 16:27:06 +03:00
"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" : [
2024-05-09 16:58:14 +03:00
"string"
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" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
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" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "ASPF" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "Policy" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "SubdomainPolicy" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"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" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "DKIM" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "SPF" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "Reasons" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"PolicyOverrideReason"
]
}
]
} ,
{
"Name" : "PolicyOverrideReason" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Type" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"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" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "HumanResult" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "SPFAuthResult" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Domain" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Scope" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
} ,
{
"Name" : "Result" ,
"Docs" : "" ,
"Typewords" : [
2024-05-09 16:58:14 +03:00
"string"
2023-01-30 16:27:06 +03:00
]
}
]
} ,
{
"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"
]
}
]
} ,
2024-03-18 10:50:42 +03:00
{
"Name" : "HoldRule" ,
"Docs" : "HoldRule is a set of conditions that cause a matching message to be marked as on\nhold when it is queued. All-empty conditions matches all messages, effectively\npausing the entire queue." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "SenderDomain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "RecipientDomain" ,
"Docs" : "" ,
"Typewords" : [
"Domain"
]
} ,
{
"Name" : "SenderDomainStr" ,
"Docs" : "Unicode." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RecipientDomainStr" ,
"Docs" : "Unicode." ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "Filter" ,
"Docs" : "Filter filters messages to list or operate on. Used by admin web interface\nand cli.\n\nOnly non-empty/non-zero values are applied to the filter. Leaving all fields\nempty/zero matches all messages." ,
"Fields" : [
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
"Name" : "Max" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
2024-03-18 10:50:42 +03:00
{
"Name" : "IDs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"int64"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "From" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "To" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Hold" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"bool"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "Whether submitted before/after a time relative to now. \"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "NextAttempt" ,
"Docs" : "\"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Transport" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"string"
]
}
]
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
"Name" : "Sort" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Field" ,
"Docs" : "\"Queued\" or \"NextAttempt\"/\"\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastID" ,
"Docs" : "If \u003e 0, we return objects beyond this, less/greater depending on Asc." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Last" ,
"Docs" : "Value of Field for last object. Must be set iff LastID is set." ,
"Typewords" : [
"any"
]
} ,
{
"Name" : "Asc" ,
"Docs" : "Ascending, or descending." ,
"Typewords" : [
"bool"
]
}
]
} ,
2023-01-30 16:27:06 +03:00
{
"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"
]
} ,
2024-03-18 10:50:42 +03:00
{
"Name" : "Hold" ,
"Docs" : "If set, delivery won't be attempted." ,
"Typewords" : [
"bool"
]
} ,
2023-01-30 16:27:06 +03:00
{
"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"
]
} ,
2024-03-18 10:50:42 +03:00
{
"Name" : "SenderDomainStr" ,
"Docs" : "For filtering, unicode." ,
"Typewords" : [
"string"
]
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
"Name" : "FromID" ,
"Docs" : "For transactional messages, used to match later DSNs." ,
"Typewords" : [
"string"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "RecipientLocalpart" ,
"Docs" : "Typically a remote user and domain." ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "RecipientDomain" ,
"Docs" : "" ,
"Typewords" : [
"IPDomain"
]
} ,
{
"Name" : "RecipientDomainStr" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "For filtering, unicode domain. Can also contain ip enclosed in []." ,
2023-01-30 16:27:06 +03:00
"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"
]
} ,
{
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Name" : "Results" ,
2023-01-30 16:27:06 +03:00
"Docs" : "" ,
"Typewords" : [
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"[]" ,
"MsgResult"
2023-01-30 16:27:06 +03:00
]
} ,
{
"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" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "Message-ID header, including \u003c\u003e. Used when composing a DSN, in its References header." ,
2023-07-23 18:56:39 +03:00
"Typewords" : [
"string"
]
} ,
2023-01-30 16:27:06 +03:00
{
"Name" : "MsgPrefix" ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Docs" : "Data to send before the contents from the file, typically with headers like DKIM-Signature." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
"[]" ,
"uint8"
]
} ,
{
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"Name" : "Subject" ,
"Docs" : "For context about delivery." ,
2023-01-30 16:27:06 +03:00
"Typewords" : [
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
"string"
]
} ,
{
"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" : [
"[]" ,
2023-01-30 16:27:06 +03:00
"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"
]
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
} ,
{
"Name" : "Extra" ,
"Docs" : "Extra information, for transactional email." ,
"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
} ,
add a webapi and webhooks for a simple http/json-based api
for applications to compose/send messages, receive delivery feedback, and
maintain suppression lists.
this is an alternative to applications using a library to compose messages,
submitting those messages using smtp, and monitoring a mailbox with imap for
DSNs, which can be processed into the equivalent of suppression lists. but you
need to know about all these standards/protocols and find libraries. by using
the webapi & webhooks, you just need a http & json library.
unfortunately, there is no standard for these kinds of api, so mox has made up
yet another one...
matching incoming DSNs about deliveries to original outgoing messages requires
keeping history of "retired" messages (delivered from the queue, either
successfully or failed). this can be enabled per account. history is also
useful for debugging deliveries. we now also keep history of each delivery
attempt, accessible while still in the queue, and kept when a message is
retired. the queue webadmin pages now also have pagination, to show potentially
large history.
a queue of webhook calls is now managed too. failures are retried similar to
message deliveries. webhooks can also be saved to the retired list after
completing. also configurable per account.
messages can be sent with a "unique smtp mail from" address. this can only be
used if the domain is configured with a localpart catchall separator such as
"+". when enabled, a queued message gets assigned a random "fromid", which is
added after the separator when sending. when DSNs are returned, they can be
related to previously sent messages based on this fromid. in the future, we can
implement matching on the "envid" used in the smtp dsn extension, or on the
"message-id" of the message. using a fromid can be triggered by authenticating
with a login email address that is configured as enabling fromid.
suppression lists are automatically managed per account. if a delivery attempt
results in certain smtp errors, the destination address is added to the
suppression list. future messages queued for that recipient will immediately
fail without a delivery attempt. suppression lists protect your mail server
reputation.
submitted messages can carry "extra" data through the queue and webhooks for
outgoing deliveries. through webapi as a json object, through smtp submission
as message headers of the form "x-mox-extra-<key>: value".
to make it easy to test webapi/webhooks locally, the "localserve" mode actually
puts messages in the queue. when it's time to deliver, it still won't do a full
delivery attempt, but just delivers to the sender account. unless the recipient
address has a special form, simulating a failure to deliver.
admins now have more control over the queue. "hold rules" can be added to mark
newly queued messages as "on hold", pausing delivery. rules can be about
certain sender or recipient domains/addresses, or apply to all messages pausing
the entire queue. also useful for (local) testing.
new config options have been introduced. they are editable through the admin
and/or account web interfaces.
the webapi http endpoints are enabled for newly generated configs with the
quickstart, and in localserve. existing configurations must explicitly enable
the webapi in mox.conf.
gopherwatch.org was created to dogfood this code. it initially used just the
compose/smtpclient/imapclient mox packages to send messages and process
delivery feedback. it will get a config option to use the mox webapi/webhooks
instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and
developing that shaped development of the mox webapi/webhooks.
for issue #31 by cuu508
2024-04-15 22:49:02 +03:00
{
"Name" : "MsgResult" ,
"Docs" : "MsgResult is the result (or work in progress) of a delivery attempt." ,
"Fields" : [
{
"Name" : "Start" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Duration" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Success" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Code" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Secode" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Error" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "RetiredFilter" ,
"Docs" : "RetiredFilter filters messages to list or operate on. Used by admin web interface\nand cli.\n\nOnly non-empty/non-zero values are applied to the filter. Leaving all fields\nempty/zero matches all messages." ,
"Fields" : [
{
"Name" : "Max" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "IDs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"int64"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "From" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "To" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "Whether submitted before/after a time relative to now. \"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastActivity" ,
"Docs" : "\"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Transport" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"string"
]
} ,
{
"Name" : "Success" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"bool"
]
}
]
} ,
{
"Name" : "RetiredSort" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Field" ,
"Docs" : "\"Queued\" or \"LastActivity\"/\"\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastID" ,
"Docs" : "If \u003e 0, we return objects beyond this, less/greater depending on Asc." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Last" ,
"Docs" : "Value of Field for last object. Must be set iff LastID is set." ,
"Typewords" : [
"any"
]
} ,
{
"Name" : "Asc" ,
"Docs" : "Ascending, or descending." ,
"Typewords" : [
"bool"
]
}
]
} ,
{
"Name" : "MsgRetired" ,
"Docs" : "MsgRetired is a message for which delivery completed, either successful,\nfailed/canceled. Retired messages are only stored if so configured, and will be\ncleaned up after the configured period." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "Same ID as it was as Msg.ID." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "BaseID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Queued" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "SenderAccount" ,
"Docs" : "Failures are delivered back to this local account. Also used for routing." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "SenderLocalpart" ,
"Docs" : "Should be a local user and domain." ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "SenderDomainStr" ,
"Docs" : "For filtering, unicode." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "FromID" ,
"Docs" : "Used to match DSNs." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RecipientLocalpart" ,
"Docs" : "Typically a remote user and domain." ,
"Typewords" : [
"Localpart"
]
} ,
{
"Name" : "RecipientDomain" ,
"Docs" : "" ,
"Typewords" : [
"IPDomain"
]
} ,
{
"Name" : "RecipientDomainStr" ,
"Docs" : "For filtering, unicode." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Attempts" ,
"Docs" : "Next attempt is based on last attempt and exponential back off based on attempts." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "MaxAttempts" ,
"Docs" : "Max number of attempts before giving up. If 0, then the default of 8 attempts is used instead." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "DialedIPs" ,
"Docs" : "For each host, the IPs that were dialed. Used for IP selection for later attempts." ,
"Typewords" : [
"{}" ,
"[]" ,
"IP"
]
} ,
{
"Name" : "LastAttempt" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"timestamp"
]
} ,
{
"Name" : "Results" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"MsgResult"
]
} ,
{
"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"
]
} ,
{
"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"
]
} ,
{
"Name" : "Size" ,
"Docs" : "Full size of message, combined MsgPrefix with contents of message file." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "MessageID" ,
"Docs" : "Used when composing a DSN, in its References header." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Subject" ,
"Docs" : "For context about delivery." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Transport" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "RequireTLS" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"bool"
]
} ,
{
"Name" : "FutureReleaseRequest" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Extra" ,
"Docs" : "Extra information, for transactional email." ,
"Typewords" : [
"{}" ,
"string"
]
} ,
{
"Name" : "LastActivity" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "RecipientAddress" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Success" ,
"Docs" : "Whether delivery to next hop succeeded." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "KeepUntil" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
}
]
} ,
{
"Name" : "HookFilter" ,
"Docs" : "HookFilter filters messages to list or operate on. Used by admin web interface\nand cli.\n\nOnly non-empty/non-zero values are applied to the filter. Leaving all fields\nempty/zero matches all hooks." ,
"Fields" : [
{
"Name" : "Max" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "IDs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"int64"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "Whether submitted before/after a time relative to now. \"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "NextAttempt" ,
"Docs" : "\"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Event" ,
"Docs" : "Including \"incoming\"." ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "HookSort" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Field" ,
"Docs" : "\"Queued\" or \"NextAttempt\"/\"\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastID" ,
"Docs" : "If \u003e 0, we return objects beyond this, less/greater depending on Asc." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Last" ,
"Docs" : "Value of Field for last object. Must be set iff LastID is set." ,
"Typewords" : [
"any"
]
} ,
{
"Name" : "Asc" ,
"Docs" : "Ascending, or descending." ,
"Typewords" : [
"bool"
]
}
]
} ,
{
"Name" : "Hook" ,
"Docs" : "Hook is a webhook call about a delivery. We'll try delivering with backoff until we succeed or fail." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "QueueMsgID" ,
"Docs" : "Original queue Msg/MsgRetired ID. Zero for hooks for incoming messages." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "FromID" ,
"Docs" : "As generated by us and returned in webapi call. Can be empty, for incoming messages to our base address." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "MessageID" ,
"Docs" : "Of outgoing or incoming messages. Includes \u003c\u003e." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Subject" ,
"Docs" : "Subject of original outgoing message, or of incoming message." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Extra" ,
"Docs" : "From submitted message." ,
"Typewords" : [
"{}" ,
"string"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "URL" ,
"Docs" : "Taken from config when webhook is scheduled." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Authorization" ,
"Docs" : "Optional value for authorization header to include in HTTP request." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "IsIncoming" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "OutgoingEvent" ,
"Docs" : "Empty string if not outgoing." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Payload" ,
"Docs" : "JSON data to be submitted." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Attempts" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "NextAttempt" ,
"Docs" : "Index for fast scheduling." ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Results" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"HookResult"
]
}
]
} ,
{
"Name" : "HookResult" ,
"Docs" : "HookResult is the result of a single attempt to deliver a webhook." ,
"Fields" : [
{
"Name" : "Start" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "Duration" ,
"Docs" : "" ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "URL" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Success" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "Code" ,
"Docs" : "eg 200, 404, 500. 2xx implies success." ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Error" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Response" ,
"Docs" : "Max 512 bytes of HTTP response body." ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "HookRetiredFilter" ,
"Docs" : "HookRetiredFilter filters messages to list or operate on. Used by admin web interface\nand cli.\n\nOnly non-empty/non-zero values are applied to the filter. Leaving all fields\nempty/zero matches all hooks." ,
"Fields" : [
{
"Name" : "Max" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "IDs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"int64"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "Whether submitted before/after a time relative to now. \"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastActivity" ,
"Docs" : "\"\u003e$duration\" or \"\u003c$duration\", also with \"now\" for duration." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Event" ,
"Docs" : "Including \"incoming\"." ,
"Typewords" : [
"string"
]
}
]
} ,
{
"Name" : "HookRetiredSort" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "Field" ,
"Docs" : "\"Queued\" or \"LastActivity\"/\"\"." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "LastID" ,
"Docs" : "If \u003e 0, we return objects beyond this, less/greater depending on Asc." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Last" ,
"Docs" : "Value of Field for last object. Must be set iff LastID is set." ,
"Typewords" : [
"any"
]
} ,
{
"Name" : "Asc" ,
"Docs" : "Ascending, or descending." ,
"Typewords" : [
"bool"
]
}
]
} ,
{
"Name" : "HookRetired" ,
"Docs" : "HookRetired is a Hook that was delivered/failed/canceled and kept according\nto the configuration." ,
"Fields" : [
{
"Name" : "ID" ,
"Docs" : "Same as original Hook.ID." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "QueueMsgID" ,
"Docs" : "Original queue Msg or MsgRetired ID. Zero for hooks for incoming messages." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "FromID" ,
"Docs" : "As generated by us and returned in webapi call. Can be empty, for incoming messages to our base address." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "MessageID" ,
"Docs" : "Of outgoing or incoming messages. Includes \u003c\u003e." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Subject" ,
"Docs" : "Subject of original outgoing message, or of incoming message." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Extra" ,
"Docs" : "From submitted message." ,
"Typewords" : [
"{}" ,
"string"
]
} ,
{
"Name" : "Account" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "URL" ,
"Docs" : "Taken from config at start of each attempt." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Authorization" ,
"Docs" : "Whether request had authorization without keeping it around." ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "IsIncoming" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "OutgoingEvent" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Payload" ,
"Docs" : "JSON data submitted." ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Submitted" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "SupersededByID" ,
"Docs" : "If not 0, a Hook.ID that superseded this one and Done will be true." ,
"Typewords" : [
"int64"
]
} ,
{
"Name" : "Attempts" ,
"Docs" : "" ,
"Typewords" : [
"int32"
]
} ,
{
"Name" : "Results" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"HookResult"
]
} ,
{
"Name" : "Success" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "LastActivity" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
} ,
{
"Name" : "KeepUntil" ,
"Docs" : "" ,
"Typewords" : [
"timestamp"
]
}
]
} ,
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"
]
} ,
improve http request handling for internal services and multiple domains
per listener, you could enable the admin/account/webmail/webapi handlers. but
that would serve those services on their configured paths (/admin/, /,
/webmail/, /webapi/) on all domains mox would be webserving, including any
non-mail domains. so your www.example/admin/ would be serving the admin web
interface, with no way to disabled that.
with this change, the admin interface is only served on requests to (based on
Host header):
- ip addresses
- the listener host name (explicitly configured in the listener, with fallback
to global hostname)
- "localhost" (for ssh tunnel/forwarding scenario's)
the account/webmail/webapi interfaces are served on the same domains as the
admin interface, and additionally:
- the client settings domains, as optionally configured in each Domain in
domains.conf. typically "mail.<yourdomain>".
this means the internal services are no longer served on other domains
configured in the webserver, e.g. www.example.org/admin/ will not be handled
specially.
the order of evaluation of routes/services is also changed:
before this change, the internal handlers would always be evaluated first.
with this change, only the system handlers for
MTA-STS/autoconfig/ACME-validation will be evaluated first. then the webserver
handlers. and finally the internal services (admin/account/webmail/webapi).
this allows an admin to configure overrides for some of the domains (per
hostname-matching rules explained above) that would normally serve these
services.
webserver handlers can now be configured that pass the request to an internal
service: in addition to the existing static/redirect/forward config options,
there is now an "internal" config option, naming the service
(admin/account/webmail/webapi) for handling the request. this allows enabling
the internal services on custom domains.
for issue #160 by TragicLifeHu, thanks for reporting!
2024-05-11 12:13:14 +03:00
{
"Name" : "WebInternal" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"WebInternal"
]
} ,
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" : "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
} ,
improve http request handling for internal services and multiple domains
per listener, you could enable the admin/account/webmail/webapi handlers. but
that would serve those services on their configured paths (/admin/, /,
/webmail/, /webapi/) on all domains mox would be webserving, including any
non-mail domains. so your www.example/admin/ would be serving the admin web
interface, with no way to disabled that.
with this change, the admin interface is only served on requests to (based on
Host header):
- ip addresses
- the listener host name (explicitly configured in the listener, with fallback
to global hostname)
- "localhost" (for ssh tunnel/forwarding scenario's)
the account/webmail/webapi interfaces are served on the same domains as the
admin interface, and additionally:
- the client settings domains, as optionally configured in each Domain in
domains.conf. typically "mail.<yourdomain>".
this means the internal services are no longer served on other domains
configured in the webserver, e.g. www.example.org/admin/ will not be handled
specially.
the order of evaluation of routes/services is also changed:
before this change, the internal handlers would always be evaluated first.
with this change, only the system handlers for
MTA-STS/autoconfig/ACME-validation will be evaluated first. then the webserver
handlers. and finally the internal services (admin/account/webmail/webapi).
this allows an admin to configure overrides for some of the domains (per
hostname-matching rules explained above) that would normally serve these
services.
webserver handlers can now be configured that pass the request to an internal
service: in addition to the existing static/redirect/forward config options,
there is now an "internal" config option, naming the service
(admin/account/webmail/webapi) for handling the request. this allows enabling
the internal services on custom domains.
for issue #160 by TragicLifeHu, thanks for reporting!
2024-05-11 12:13:14 +03:00
{
"Name" : "WebInternal" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "BasePath" ,
"Docs" : "" ,
"Typewords" : [
"string"
]
} ,
{
"Name" : "Service" ,
"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"
]
2024-04-08 22:50:30 +03:00
} ,
{
"Name" : "Direct" ,
"Docs" : "" ,
"Typewords" : [
"nullable" ,
"TransportDirect"
]
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" : "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
} ,
2024-04-08 22:50:30 +03:00
{
"Name" : "TransportDirect" ,
"Docs" : "" ,
"Fields" : [
{
"Name" : "DisableIPv4" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
} ,
{
"Name" : "DisableIPv6" ,
"Docs" : "" ,
"Typewords" : [
"bool"
]
}
]
} ,
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" : [
2024-05-09 16:58:14 +03:00
"string"
2023-11-01 19:55:40 +03:00
]
} ,
{
"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" ,
2024-04-19 11:51:24 +03:00
"Docs" : "SuppressAddress is a reporting address for which outgoing TLS reports\nwill be suppressed for a period." ,
2023-11-13 15:48:52 +03:00
"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"
]
}
]
2024-04-18 12:14:24 +03:00
} ,
{
"Name" : "Dynamic" ,
"Docs" : "Dynamic is the parsed form of domains.conf, and is automatically reloaded when changed." ,
"Fields" : [
{
"Name" : "Domains" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"ConfigDomain"
]
} ,
{
"Name" : "Accounts" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"Account"
]
} ,
{
"Name" : "WebDomainRedirects" ,
"Docs" : "" ,
"Typewords" : [
"{}" ,
"string"
]
} ,
{
"Name" : "WebHandlers" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"WebHandler"
]
} ,
{
"Name" : "Routes" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Route"
]
} ,
{
"Name" : "MonitorDNSBLs" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"string"
]
} ,
{
"Name" : "MonitorDNSBLZones" ,
"Docs" : "" ,
"Typewords" : [
"[]" ,
"Domain"
]
}
]
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."
}
]
} ,
2024-04-18 12:14:24 +03:00
{
"Name" : "Localpart" ,
"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." ,
"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
}