mailway-app / mailout Goto Github PK

Short description:

It is not tested how mailout will react when redirecting to same domain name as the incoming domain. For example we want the rule: *@example.com -> *@example.com, and we have setup the DNS records as:

@ 300 IN MX 10 mail.example.com.
@ 300 IN MX 20 server1.mailout.
@ 300 IN MX 30 server2.mailout.

If the original sender only supports sending through port 25, but port 25 is blocked on mail.example.com, then it will redirect to mailout. The intended result is that mailout will retry the original configuration, but try additional ports.

Usecase:

Simplifying the required DNS records for users, and allow mailout to act as a fail-safe redirecter to the same domain name.

Minimal implementation:

The minimum implementation to get this setting to work would be to detect if the incoming mail is from the same mailout server or not. If there are multiple mailout servers in the DNS record, it can either be that it is a fail-safe mail-server with the same configuration or 3rd party server with different configurations.

• case1: mailout can keep track of the servers that share the same configuration, or add an array of mailout servers belonging to the same cluster. When mailout will try to redirect the mail, it should filter out the DNS records belonging to the cluster
• case2: This is a bit trickier to configure because there can be the same recursive configuration on the 3rd party server as well. Either allow for additional filters to be added depending on the domain-name and have them configured in the mailway front-end, or keep track of the jumps and filter accordingly.

Currently when mailout receives a mail to redirect, the sending server will consider it successful. There are two ways mailout can be configured to resolve this issue.

1. mailout will read the header before accepting the mail, try to connect to the rule receiver, and test with the same header. If it succeeds simply pass it through as usual. If the receiver denies it pass the same error to the original sender.
2. mailout will fully receive the mail and attempt to send the mail a few times. If it fails due to instant errors: MX record is not set, receiver denies the connection, then have mailout send the errors to the sender. If the receiver cannot be contacted it should try again for the standard 24h before sending an error to the sender that it cannot be contacted. (Or even better after a few attempts send a warning email, that the receiver is not able to receive the email at the moment, and mailout will try again for some time before it declares the message failed. Maybe allow the sender to be notified when the mail was successfully relayed)

I can see merit to both configuration, and I think the user should decide which error handling to go for.

Short description:

Currently TLS connection is only tested on port 465, and it continues with failover to insecure connection. The latter can be a MIM attack risk.

Features to implement:

• Allow for user settings on a per-domain basis whether the TLS test has to pass or not.
• Perform a TLS test on the custom port (2525) as well with the same failover settings as above

Bonus:

• Allow users to add self-signed certificates for specific domains.

• TLS connection on port 465.
• What order does/should mailout try to send mails (e.g. IPv6 port 25 -> IPv6 port 587 ... or IPv6 port 25 -> IPv4 port 25 ...)
• How does mailout react to self-signed certificates on ports 587 and port 465.
• Does mailout reject unsecured connection on port 465
• Can mailout detect MIM attacks when using STARTTLS and/or regular TLS?

I have just found out about this project from reddit, and would like to know if this project will support this feature either free or paid. For context I am currently using mxguarddog to forward my emails to my local mail-server on a different SMTP port due to isp block. Problem there is that it has an aggressive spam filter which I actually do not wish for and it is not open-source. Could this project accommodate these needs?

At the minimum it should be able to redirect incoming emails to the provided port(s) in at least three configurations:

• Transparent: emails are simply forwarded without mailway reading any metadata except the destination domain name.
• Holding: emails are temporarily received on the mailway server, then redirected to the first destination port which accepts it. It should retry for at least 24h and inform the domain owner if there are issues.
• Managed: similar to the current method but with ability to redirect to smtp port as well.