postfix mail domains

[sseitz]

Due to customer needs, I've found one strange behaviour of ispcp (compared to other control panels).
If e.g. a customer holds two domains, both with regular webspace and mysql, but only one of them with email adresses and postboxes, the other one with MX delegated to a thirdparty mail appliance, he will be unable to mail from one of his regular email adresses to his mail accounts handled by thirdparty.

It looks like the postfix configuration /etc/postfix/ispcp/domains (and subsequent also domains.db) holds every domain, regardless if this domain holds addresses (reflected in aliases/aliases.db and mailboxes/mailboxes.db)
I suggest that a domain should only be added to domains/domains.db if there is an address assigned. If the last address of a domain has been removed, the domain should get removed for mail purposes at all.

As I'm going to do the needed work for this (well, by now learning and understanding the ispcp way of configuration) I'ld really like to see pro's and con's.

Cheers,
Stephan

[kilburn]

In fact, it would be great if there was a "Mail handling" setting that you could set up for each domain as either:

1. Local mail (default)
Mails are handled locally, just as it is now.

2. Relay to xxxx (IP or MX fqdn)
Mails for this domains are accepted, scanned (if needed), and relayed to another server(s). This would be the setting as a mail filering gateway or backup system, for example, when the server should act as mail filter for a customer's exchange server.

3. Handled externally (list of IP's/priorities)
Mails for this domains are not accepted by the server, yet MX records for the given IP's are created. This is what you want here.

4. Disabled
Just don't accept mails neither create any mail-related settings such as MX records.

Each of this modes has his own hiccups, but it could be done and would be fantastic for all ispcp users! Don't hesitate to contact me if you want some more details on how the implementation could be done (I have a good knowledge of ispcp's interals)

[rbtux]

for the second point we would need some sort of recipient validation...

[kilburn]

There are two approaches to address verification for relayed domains:

1. Use postfix address verification
2. (my preferred one) Implement an interface to allow the domain owner (client) to specify it's valid addresses. IMHO it would be enough if we create a "php rpc" that accepts user credentials + list of emails and processes the list (probably sanitizing + inserting it to the db), in combination with a backend perl script that writes the actual config.

[sseitz]

Regarding your second way (relaying) I never thought about adding the functionality of a filtering / backup relay gateway into a controlled shared host. In fact some kind of remote controlling a dedicated relay gateway in front of one ore more ispCP's would be really nice.
We're currently do similar with some heavily patched confixx hosts using xml-rpc to update a mail-relay cluster. This also allows us to do some handcrafted xml for special purposes (fallback MX, delivery to inhouse exchange, authenticate bangpath targets, etc.)
But by now, I'ld like to focus on your third topic. I assume this can be done without any caveats and customers can be told to remove all email addresses for a domain after they pointed MX to another host. This would be really transparent for the customers. If they cancel thirdpart service they could revert to normal behaviour by themselves just by moving MX back to their respective ispCP host and adding their email addresses again.
Another idea is to ignore the customers settings and regulary check for MX delegations to remove domains from the MTA if the MX doesn't point to it. This way the domains should also get added again if the MX points back to the MTA again. After a second thought, I do not prefer this, because customers will get confused if the reality differs from their shown settings. Alternatively the settings could be modified as well (removing email addresses), but this would be a oneway ticket.

cheeers,
Stephan