English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
Relay all subdomains to another relay
-
I would like to route everything *@*.example.com (including *@example.com) to an external relay (or to a different relay than the default one, if a default is configured).
As far as I was told there is no possibility of using a wildcard at that point. (gateway domain, MXCACHE, ...)
That is a problem since not all subdomains are known to us in advance.
-
Arron Staff
Do you want the messages to be routed to a specific domain? For example, is *@*.example.com being routed to *@example.com ok?
Do you know the sending IP address of these messages and is it consistent?
Can the sender authenticate with the server when delivering the messages or will the messages come from outside of your control?
-
Essentially, I want to route *@*.example.com to some IP address or domain name (i.e. 192.168.1.1 or mx.example2.com).
The messages would be coming from inside. We would not be relaying those messages, we would be at the origin.
-
Arron Staff
Is the email address the message is from, local to MDaemon? If it is, then you can skip steps 1 and 2 below and just add a wildcard MX record in your DNS server.
1. Add the IP of the sending server as a trusted IP in MDaemon. Security / Security Manager / Security Settings / Trusted IPs
2. Go to Security / Security Manager / Security Settings / Relay Control and check the box to allow Trusted IP addresses to relay mail.
3. Add a wildcard MX record in your DNS for *.example.com, that points to the FQDN of the server you want the mail passed to. I've done minimal testing and it seems to be working for me, but I've read that not all DNS servers support adding a wildcard MX record.
Another option would be to use an alias such as *@*.example.com = *@example.com. The problem with this is that all mail will end up addressed to @example.com. If that is not ok, then this is not a good option.
The final option I came up with would be to setup a gateway for example.com, and configure the gateway to be dequeued by another server. Then create a content filter rule to copy all mail that has an X-MDaemon-Deliver-To header that ends with .example.com to the gateway directory and then delete the original message. Configure the gateway so that it accepts ETRN requests and when the request is received it sends mail to a specific IP or host name. Then configure MDaemon to send a dequeue request to itself. This can be configured by going to Setup / Domain Manager / Select the Domain / Dequeueing.
If you'd like more specific instructions on the last method, let me know.
-
Phew, thanks for all those ideas...
So the setup is FROM our internal domain TO some external domain.
Concerning 1) and 2): We cannot set any trusted senders because anyone can potentially be a sender for those mails.3) That might work if we didn't use a global external relay to send all our outgoing mail to. (in which case it no longer considers DNS I guess)
The most straightforward solution would be to allow wilcards, regexes or the like in MXCACHE.DAT.
Just like in postfix where you can for example write ".example.com" (note the leading dot) meaning it is supposed to match all subdomains.
-
Arron Staff
If the senders are all local and are authenticating then you don't need to trust anything. MDaemon will accept mail from any local user to any external domain and then route it based on DNS.
I'm not sure what you mean by this, "a global external relay to send all our outgoing mail to" Are you saying that you have MDaemon configured to send all mail to a smart host and you don't want this mail sent to that smart host?
If that is the case, then use a gateway and a content filter rule as described in my last post.
The most straightforward solution would be to allow wilcards, regexes or the like in MXCACHE.DAT.
Just like in postfix where you can for example write ".example.com" (note the leading dot) meaning it is supposed to match all subdomains.That is not how the MXCache.dat file works. Even if MDaemon could accept a wildcard in the mxcache.dat file, if you are sending all mail to a smart host, the MXCache.dat file would not come into play.
If you'd like further details on setting up a gateway with the content filter rule and configuring the dequeueing, let me know.
