mirror of
https://github.com/foxcpp/maddy.git
synced 2025-04-01 20:27:36 +03:00
Fix typos
This commit is contained in:
parent
13a210f2a4
commit
681976cc7b
22 changed files with 44 additions and 44 deletions
|
@ -9,7 +9,7 @@ load balancer in front of the nodes.
|
|||
|
||||
## Requirement
|
||||
|
||||
In order to run maddy properly, you need to have TLS secret undet name maddy present in the cluster. If you have commercial
|
||||
In order to run maddy properly, you need to have TLS secret under name maddy present in the cluster. If you have commercial
|
||||
certificate, you can create it by the following command:
|
||||
|
||||
```sh
|
||||
|
@ -20,9 +20,9 @@ If you use cert-manager, just create the secret under name maddy.
|
|||
|
||||
## Replication
|
||||
|
||||
Default for this chart is 1 replica of maddy. If you try to increse this, you will probably get an error because of
|
||||
Default for this chart is 1 replica of maddy. If you try to increase this, you will probably get an error because of
|
||||
the busy ports 25, 143, 587, etc. We do not support this feature at the moment, so please use just 1 replica. Like said
|
||||
at the begining of this document, multiple replicas would probably require to switch do DaemonSet which would further require
|
||||
at the beginning of this document, multiple replicas would probably require to switch do DaemonSet which would further require
|
||||
to have TCP load balancer and shared storage between all replicas. This is not supported by this chart, sorry.
|
||||
This chart is used on one node cluster and then installation is straight forward, like described bellow, but if you have
|
||||
multiple node cluster, please use taints and tolerations to select the desired node. This chart supports tolerations to
|
||||
|
|
2
dist/README.md
vendored
2
dist/README.md
vendored
|
@ -22,7 +22,7 @@ Additionally, unit files apply strict sandboxing, limiting maddy permissions on
|
|||
the system to a bare minimum. Subset of these options makes it impossible for
|
||||
privileged authentication helper binaries to gain required permissions, so you
|
||||
may have to disable it when using system account-based authentication with
|
||||
maddy running as a unprivilieged user.
|
||||
maddy running as a unprivileged user.
|
||||
|
||||
## fail2ban configuration
|
||||
|
||||
|
|
|
@ -93,4 +93,4 @@ mentioned above).
|
|||
|
||||
Clients that want to implement proper handling for Unicode strings may assume
|
||||
maddy does not handle them properly in e.g. SEARCH commands and so such clients
|
||||
may download messsages and process them locally.
|
||||
may download messages and process them locally.
|
||||
|
|
|
@ -28,7 +28,7 @@ the [introduction tutorial](tutorials/setting-up.md).
|
|||
|
||||
Also note that you do not really need a separate TLS certificate for each
|
||||
managed domain. You can have one hostname e.g. mail.example.org set as an MX
|
||||
record for mulitple domains.
|
||||
record for multiple domains.
|
||||
|
||||
**If you want multiple domains to share username namespace**, you should change
|
||||
several more options.
|
||||
|
@ -53,7 +53,7 @@ maddy imap-acct create user@example.com
|
|||
"user"**, you can set `storage_map` in IMAP endpoint and `delivery_map` in
|
||||
storage backend to use `email_locapart`:
|
||||
```
|
||||
straoge.imapsql local_mailboxes {
|
||||
storage.imapsql local_mailboxes {
|
||||
...
|
||||
delivery_map email_localpart # deliver "user@*" to "user"
|
||||
}
|
||||
|
|
|
@ -37,7 +37,7 @@ auth.netauth {}
|
|||
|
||||
OPTIONAL.
|
||||
|
||||
Group that entities must posess to be able to use maddy services.
|
||||
Group that entities must possess to be able to use maddy services.
|
||||
This can be used to provide email to just a subset of the entities
|
||||
present in NetAuth.
|
||||
|
||||
|
|
|
@ -127,5 +127,5 @@ the message pipeline action.
|
|||
|
||||
Two codes are defined implicitly, exit code 1 causes the message to be rejected
|
||||
with a permanent error, exit code 2 causes the message to be quarantined. Both
|
||||
action can be overriden using the 'code' directive.
|
||||
action can be overridden using the 'code' directive.
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ check.dkim {
|
|||
**Syntax**: debug _boolean_ <br>
|
||||
**Default**: global directive value
|
||||
|
||||
Log both successfull and unsuccessful check executions instead of just
|
||||
Log both successful and unsuccessful check executions instead of just
|
||||
unsuccessful.
|
||||
|
||||
**Syntax**: required\_fields _string..._ <br>
|
||||
|
|
|
@ -4,7 +4,7 @@ The check.dnsbl module implements checking of source IP and hostnames against a
|
|||
of DNS-based Blackhole lists (DNSBLs).
|
||||
|
||||
Its configuration consists of module configuration directives and a set
|
||||
of blocks specifing lists to use and kind of lookups to perform on them.
|
||||
of blocks specifying lists to use and kind of lookups to perform on them.
|
||||
|
||||
```
|
||||
check.dnsbl {
|
||||
|
|
|
@ -15,8 +15,8 @@ Action to take when check fails. See Check actions for details.
|
|||
**Syntax**: debug _boolean_ <br>
|
||||
**Default**: global directive value
|
||||
|
||||
Log both sucessfull and unsucessfull check executions instead of just
|
||||
unsucessfull.
|
||||
Log both successful and unsuccessful check executions instead of just
|
||||
unsuccessful.
|
||||
|
||||
## require\_mx\_record
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ Enable verbose logging for check.spf.
|
|||
Make policy decision on MAIL FROM stage (before the message body is received).
|
||||
This makes it impossible to apply DMARC override (see above).
|
||||
|
||||
**Syntax**: none\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: none\_action reject|quarantine|ignore <br>
|
||||
**Default**: ignore
|
||||
|
||||
Action to take when SPF policy evaluates to a 'none' result.
|
||||
|
@ -54,7 +54,7 @@ Action to take when SPF policy evaluates to a 'none' result.
|
|||
See [https://tools.ietf.org/html/rfc7208#section-2.6](https://tools.ietf.org/html/rfc7208#section-2.6) for meaning of
|
||||
SPF results.
|
||||
|
||||
**Syntax**: neutral\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: neutral\_action reject|quarantine|ignore <br>
|
||||
**Default**: ignore
|
||||
|
||||
Action to take when SPF policy evaluates to a 'neutral' result.
|
||||
|
@ -62,22 +62,22 @@ Action to take when SPF policy evaluates to a 'neutral' result.
|
|||
See [https://tools.ietf.org/html/rfc7208#section-2.6](https://tools.ietf.org/html/rfc7208#section-2.6) for meaning of
|
||||
SPF results.
|
||||
|
||||
**Syntax**: fail\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: fail\_action reject|quarantine|ignore <br>
|
||||
**Default**: quarantine
|
||||
|
||||
Action to take when SPF policy evaluates to a 'fail' result.
|
||||
|
||||
**Syntax**: softfail\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: softfail\_action reject|quarantine|ignore <br>
|
||||
**Default**: ignore
|
||||
|
||||
Action to take when SPF policy evaluates to a 'softfail' result.
|
||||
|
||||
**Syntax**: permerr\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: permerr\_action reject|quarantine|ignore <br>
|
||||
**Default**: reject
|
||||
|
||||
Action to take when SPF policy evaluates to a 'permerror' result.
|
||||
|
||||
**Syntax**: temperr\_action reject|qurantine|ignore <br>
|
||||
**Syntax**: temperr\_action reject|quarantine|ignore <br>
|
||||
**Default**: reject
|
||||
|
||||
Action to take when SPF policy evaluates to a 'temperror' result.
|
||||
|
|
|
@ -31,7 +31,7 @@ imap tcp://0.0.0.0:143 tls://0.0.0.0:993 {
|
|||
**Default**: global directive value
|
||||
|
||||
TLS certificate & key to use. Fine-tuning of other TLS properties is possible
|
||||
by specifing a configuration block and options inside it:
|
||||
by specifying a configuration block and options inside it:
|
||||
```
|
||||
tls cert.crt key.key {
|
||||
protocols tls1.2 tls1.3
|
||||
|
|
|
@ -49,7 +49,7 @@ Server name to use in SMTP banner.
|
|||
**Default**: global directive value
|
||||
|
||||
TLS certificate & key to use. Fine-tuning of other TLS properties is possible
|
||||
by specifing a configuration block and options inside it:
|
||||
by specifying a configuration block and options inside it:
|
||||
```
|
||||
tls cert.crt key.key {
|
||||
protocols tls1.2 tls1.3
|
||||
|
@ -111,7 +111,7 @@ clients that don't expect an error early in session.
|
|||
**Default**: 5
|
||||
|
||||
Amount of RCPT-time errors that should be logged. Further errors will be
|
||||
handled silently. This is to prevent log flooding during email dictonary
|
||||
handled silently. This is to prevent log flooding during email dictionary
|
||||
attacks (address probing).
|
||||
|
||||
**Syntax**: max\_received _integer_ <br>
|
||||
|
@ -202,7 +202,7 @@ for all messages ("all"), per-sender IP ("ip"), per-sender domain ("source") or
|
|||
per-recipient domain ("destination"). Having a scope other than "all" means
|
||||
that the restriction will be enforced independently for each group determined
|
||||
by scope. E.g. "ip rate 20" means that the same IP cannot send more than 20
|
||||
messages in a scond. "destination concurrency 5" means that no more than 5
|
||||
messages per second. "destination concurrency 5" means that no more than 5
|
||||
messages can be sent in parallel to a single domain.
|
||||
|
||||
**Note**: At the moment, SMTP endpoint on its own does not support per-recipient
|
||||
|
@ -233,7 +233,7 @@ messages can enter the server through both endpoints in one second.
|
|||
# Submission module (submission)
|
||||
|
||||
Module 'submission' implements all functionality of the 'smtp' module and adds
|
||||
certain message preprocessing on top of it, additionaly authentication is
|
||||
certain message preprocessing on top of it, additionally authentication is
|
||||
always required.
|
||||
|
||||
'submission' module checks whether addresses in header fields From, Sender, To,
|
||||
|
|
|
@ -195,5 +195,5 @@ require\_sender\_match checks. Only first address will be checked, however.
|
|||
|
||||
Sign emails from subdomains using a top domain key.
|
||||
|
||||
Allows only one domain to be specified (can be workarounded using modify.dkim
|
||||
Allows only one domain to be specified (can be worked around by using modify.dkim
|
||||
multiple times).
|
||||
|
|
|
@ -6,7 +6,7 @@ modifying IMAP-specific message attributes. In particular, it allows
|
|||
code to change target folder and add IMAP flags (keywords) to the message.
|
||||
|
||||
There is no way to reject message using IMAP filters, this should be done
|
||||
eariler in SMTP pipeline logic. Quarantined messages are not processed
|
||||
earlier in SMTP pipeline logic. Quarantined messages are not processed
|
||||
by IMAP filters and are unconditionally delivered to Junk folder (or other
|
||||
folder with \Junk special-use attribute).
|
||||
|
||||
|
@ -44,7 +44,7 @@ access to the SMTP envelope recipient (before and after any rewrites),
|
|||
|
||||
Note that if you use provided systemd units on Linux, maddy executable is
|
||||
sandboxed - all commands will be executed with heavily restricted filesystem
|
||||
acccess and other privileges. Notably, /tmp is isolated and all directories
|
||||
access and other privileges. Notably, /tmp is isolated and all directories
|
||||
except for /var/lib/maddy and /run/maddy are read-only. You will need to modify
|
||||
systemd unit if your command needs more privileges.
|
||||
|
||||
|
|
|
@ -56,9 +56,9 @@ limits amount of messages tried to be delivered concurrently.
|
|||
**Default**: 20
|
||||
|
||||
Attempt delivery up to _integer_ times. Note that no more attempts will be done
|
||||
is permanent error occured during previous attempt.
|
||||
is permanent error occurred during previous attempt.
|
||||
|
||||
Delay before the next attempt will be increased exponentally using the
|
||||
Delay before the next attempt will be increased exponentially using the
|
||||
following formula: 15mins \* 1.2 ^ (n - 1) where n is the attempt number.
|
||||
This gives you approximately the following sequence of delays:
|
||||
18mins, 21mins, 25mins, 31mins, 37mins, 44mins, 53mins, 64mins, ...
|
||||
|
@ -67,7 +67,7 @@ This gives you approximately the following sequence of delays:
|
|||
**Default**: not specified
|
||||
|
||||
This configuration contains pipeline configuration to be used for generated DSN
|
||||
(Delivery Status Notifiaction) messages.
|
||||
(Delivery Status Notification) messages.
|
||||
|
||||
If this is block is not present in configuration, DSNs will not be generated.
|
||||
Note, however, this is not what you want most of the time.
|
||||
|
|
|
@ -138,7 +138,7 @@ mtasts {
|
|||
```
|
||||
|
||||
If the mx\_auth directive is not specified, no mechanisms are enabled. Note
|
||||
that, however, this makes outbound SMTP vulnerable to a numberous downgrade
|
||||
that, however, this makes outbound SMTP vulnerable to a numerous downgrade
|
||||
attacks and hence not recommended.
|
||||
|
||||
It is possible to share the same set of policies for multiple 'remote' module
|
||||
|
@ -201,9 +201,9 @@ Filesystem directory to use for policies caching if 'cache' is set to 'fs'.
|
|||
|
||||
Checks whether MX records are signed. Sets MX level to "dnssec" is they are.
|
||||
|
||||
maddy does not validate DNSSEC signatures on its own. Instead it reslies on
|
||||
maddy does not validate DNSSEC signatures on its own. Instead it relies on
|
||||
the upstream resolver to do so by causing lookup to fail when verification
|
||||
fails and setting the AD flag for signed and verfified zones. As a safety
|
||||
fails and setting the AD flag for signed and verified zones. As a safety
|
||||
measure, if the resolver is not 127.0.0.1 or ::1, the AD flag is ignored.
|
||||
|
||||
DNSSEC is currently not supported on Windows and other platforms that do not
|
||||
|
|
|
@ -45,7 +45,7 @@ maddy defines two values indicating how "secure" delivery of message will be:
|
|||
- TLS security level
|
||||
|
||||
These values correspond to the problems described above. On delivery, the
|
||||
estabilished connection to the remote server is "ranked" using these values and
|
||||
established connection to the remote server is "ranked" using these values and
|
||||
then they are compared against a number of policies (including local
|
||||
configuration). If the effective value is lower than the required one, the
|
||||
connection is closed and next candidate server is used. If all connections fail
|
||||
|
@ -67,14 +67,14 @@ attacks
|
|||
- MX level: None. MX candidate was returned as a result of DNS lookup for the
|
||||
recipient domain, no additional checks done.
|
||||
- MX level: MTA-STS. Used MX matches the MTA-STS policy published by the
|
||||
recepient domain (even one in testing mode).
|
||||
recipient domain (even one in testing mode).
|
||||
- MX level: DNSSEC. MX record is signed.
|
||||
|
||||
- TLS level: None. Plaintext connection was estabilished, TLS is not available
|
||||
- TLS level: None. Plaintext connection was established, TLS is not available
|
||||
or failed.
|
||||
- TLS level: Encrypted. TLS connection was estabilished, the server certificate
|
||||
- TLS level: Encrypted. TLS connection was established, the server certificate
|
||||
failed X.509 and DANE verification.
|
||||
- TLS level: Authenticated. TLS connection was estabilished, the server
|
||||
- TLS level: Authenticated. TLS connection was established, the server
|
||||
certificate passes X.509 **or** DANE verification.
|
||||
|
||||
**Note 1:** Persistent attacker able to control network connection can
|
||||
|
|
4
docs/third-party/dovecot.md
vendored
4
docs/third-party/dovecot.md
vendored
|
@ -1,7 +1,7 @@
|
|||
# Dovecot
|
||||
|
||||
Builtin maddy IMAP server may not match your requirements in terms of
|
||||
performance, reliabilty or anything. For this reason it is possible to
|
||||
performance, reliability or anything. For this reason it is possible to
|
||||
integrate it with any external IMAP server that implements necessary
|
||||
protocols. Here is how to do it for Dovecot.
|
||||
|
||||
|
@ -69,7 +69,7 @@ smtp tcp://127.0.0.1:587 {
|
|||
deliver_to &remote_queue
|
||||
}
|
||||
```
|
||||
And configure IMAP servers's Submission service to forward outbound messages
|
||||
And configure IMAP server's Submission service to forward outbound messages
|
||||
there.
|
||||
|
||||
Depending on how Submission service is implemented you may also need to route
|
||||
|
|
2
docs/third-party/mailman3.md
vendored
2
docs/third-party/mailman3.md
vendored
|
@ -20,7 +20,7 @@ lmtp_port: 8024
|
|||
|
||||
After that, you will need to configure maddy to send messages to Mailman.
|
||||
|
||||
The preferrable way of doing so is destination_in and table.regexp:
|
||||
The preferable way of doing so is destination_in and table.regexp:
|
||||
```
|
||||
msgpipeline local_routing {
|
||||
destination_in regexp "first-mailinglist(-(bounces\+.*|confirm\+.*|join|leave|owner|request|subscribe|unsubscribe))?@lists.example.org" {
|
||||
|
|
2
docs/third-party/smtp-servers.md
vendored
2
docs/third-party/smtp-servers.md
vendored
|
@ -43,7 +43,7 @@ lmtp unix:/run/maddy/lmtp.sock {
|
|||
Look up documentation for your SMTP server on how to make it
|
||||
send messages using LMTP to /run/maddy/lmtp.sock.
|
||||
|
||||
To handle authentiation for Submission (client-server SMTP) SMTP server
|
||||
To handle authentication for Submission (client-server SMTP) SMTP server
|
||||
needs to access credentials database used by maddy. maddy implements
|
||||
server side of Dovecot authentication protocol so you can use
|
||||
it if SMTP server implements "Dovecot SASL" client.
|
||||
|
|
|
@ -88,7 +88,7 @@ msgpipeline local_routing {
|
|||
## Bounce handling
|
||||
|
||||
Once the message is delivered to `remote_queue`, it will follow the usual path
|
||||
for outbound delivery, including queueing and multiple attempts. This also
|
||||
for outbound delivery, including queuing and multiple attempts. This also
|
||||
means bounce messages will be generated on failures. When accepting messages
|
||||
from arbitrary senders via the 25 port, the DSN recipient will be whatever
|
||||
sender specifies in the MAIL FROM command. This is prone to [collateral spam]
|
||||
|
|
|
@ -4,7 +4,7 @@ maddy source tree
|
|||
Main maddy code base lives here. No packages are intended to be used in
|
||||
third-party software hence API is not stable.
|
||||
|
||||
Subdirectories are organised as follows:
|
||||
Subdirectories are organized as follows:
|
||||
```
|
||||
/
|
||||
auxiliary libraries
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue