maddy

Fork https://github.com/foxcpp/maddy

git clone git://git.lin.moe/go/maddy.git

  1# Forward messages to a remote MX
  2
  3Default maddy configuration is done in a way that does not result in any
  4outbound messages being sent as a result of port 25 traffic.
  5
  6In particular, this means that if you handle messages for example.org but not
  7example.com and have the following in your aliases file (e.g. /etc/maddy/aliases):
  8
  9```
 10foxcpp@example.org: foxcpp@example.com
 11```
 12
 13You will get "User does not exist" error when attempting to send a message to
 14foxcpp@example.org because foxcpp@example.com does not exist on as a local
 15user.
 16
 17Some users may want to make it work, but it is important to understand the
 18consequences of such configuration:
 19
 20- Flooding your server will also flood the remote server.
 21- If your spam filtering is not good enough, you will send spam to the remote
 22  server.
 23
 24In both cases, you might harm the reputation of your server (e.g. get your IP
 25listed in a DNSBL).
 26
 27**So, this is a bad practice. Do so only if you clearly understand the
 28consequences (including the Bounce handling section below).**
 29
 30If you want to do it anyway, here is the part of the configuration that needs
 31tweaking:
 32
 33```
 34msgpipeline local_routing {
 35    destination postmaster $(local_domains) {
 36        modify {
 37            replace_rcpt regexp "(.+)\+(.+)@(.+)" "$1@$3"
 38            replace_rcpt file /etc/maddy/aliases
 39        }
 40
 41        deliver_to &local_mailboxes
 42    }
 43
 44    default_destination {
 45        reject 550 5.1.1 "User doesn't exist"
 46    }
 47}
 48```
 49
 50In default configuration, `local_routing` block is responsible for handling
 51messages that are received via SMTP or Submission and have the initial
 52destination address at a local domain.
 53
 54Note the `modify { }` block being nested inside `destination` and then followed
 55by unconditional `deliver_to &local_mailboxes`. This means: if address is
 56on `$(local_domains)`, apply aliases and deliver to mailboxes from
 57`&local_mailboxes`.
 58
 59The problem here is that recipients are matched before aliases are resolved so
 60in the end, maddy attempts to look up foxcpp@example.com locally. The solution
 61is to insert another step into the pipeline configuration to rerun matching
 62*after* aliases are resolved. This can be done using the 'reroute' directive:
 63
 64```
 65msgpipeline local_routing {
 66    destination postmaster $(local_domains) {
 67        modify {
 68            replace_rcpt file /etc/maddy/aliases
 69			...
 70        }
 71
 72		reroute {
 73			destination postmaster $(local_domains) {
 74				deliver_to &local_mailboxes
 75			}
 76			default_destination {
 77				deliver_to &remote_queue
 78			}
 79		}
 80    }
 81
 82    default_destination {
 83        reject 550 5.1.1 "User doesn't exist"
 84    }
 85}
 86```
 87
 88## Bounce handling
 89
 90Once the message is delivered to `remote_queue`, it will follow the usual path
 91for outbound delivery, including queuing and multiple attempts. This also
 92means bounce messages will be generated on failures. When accepting messages
 93from arbitrary senders via the 25 port, the DSN recipient will be whatever
 94sender specifies in the MAIL FROM command. This is prone to [collateral spam]
 95when an automatically generated bounce message gets sent to a spoofed address.
 96
 97However, the default maddy configuration ensures that in this case, the NDN
 98will be delivered only if the original sender is a local user. Backscatter can
 99not happen if the sender spoofed a local address since such messages will not
100be accepted in the first place.
101
102You can also configure maddy to send bounce messages to remote
103addresses, but in this case, you should configure a really strict local policy
104to make sure the sender address is not spoofed. There is no detailed
105explanation of how to do this since this is a terrible idea in general.
106
107[collateral spam]: https://en.wikipedia.org/wiki/Backscatter_(e-mail)
108
109## Transparent forwarding
110
111As an alternative to silently dropping messages on remote delivery failures,
112you might want to use transparent forwarding and reject the message without
113accepting it first ("connection-stage rejection").
114
115To do so, simply do not use the queue, replace
116```
117deliver_to &remote_queue
118```
119with
120```
121deliver_to &outbound_delivery
122```
123(assuming outbound_delivery refers to target.remote block)