Mail relay to customer server

[ispcomm]

I have attached the ispcp-dmn-mngr to

http://www.isp-control.net/ispcp/ticket/1332

Pls.check it.

ADDED: You missed this piece, line 2129, ispcp-dmn-mngr:

Code:

    $working =~ s/^$dmn_name[\s]+[^\n]+\n//gim;
    
+    if ( $dmn_relay ne "_no_" ) {
+        $working .= "$dmn_name\t\t\tsmtp:[$dmn_relay]\n";
+    }

ispcomm.

[ispcomm]

Attached to the ticket for this feature is a cleaned up patch (tested to apply cleanly to r1204, without fuzz). Sorry, but the forum will not let me attach new files (is this only me?)

I modified the admin templates so that MX relay can be set from the Admin interface (in addition to the reseller).

To use it add this to /etc/postfix/main.cf

relay_domains = $mydestination,hash:/etc/postfix/ispcp/transport

Still Missing, quoting from kilburn (optional):

kilburn Wrote:-) Just don't allow to set relaying if there are any mail accounts and/or aliases for this domain (this is a gui-only check that shouldn't take much effort).

-) Shouldn't we add "reject_unverified_recipients" to the smtpd_recipient_restrictions in the default postfix config?

Hope you like the mod and can push it mainstream.

ispcomm.

[kilburn]

I've tested your last patch. Adding and removing the relay host works flawlessly (both in admin/edit_domain and reseller/edit_domain), so great work ispcomm.

The patch is clean and I really like this functionality, so I'll do what I can to push it mainstream (that's why I'm so annyoing hehe), but as it is relatively big I'd like that {malte,rats,raphael,zothos} also approve it before commiting. Let us polish the remaining rough edges and then we'll annoy them until they approve it

More comments:

-) (Debian Lenny) Relayed mails are not counted on this system as SMTP Traffic as I would expect. Can you check if this is the case for you too?

-) Adding mail accounts to a relayed domain has no effect: mails are always relayed. This is ok for me, but then we need to implement the "don't allow to set relaying...." thing for usability reasons (or my idea down here).

-) Mail for subdomains of a relayed domain are still delivered locally. This effectively means that we can't relay subdomains as of now (I think this is not required to go mainstream, but should be properly documented). Proof:

Code:

Jun 12 08:45:56 v2 postfix/trivial-rewrite[10914]: warning: do not list domain sub.dmn.tld in BOTH virtual_mailbox_domains and relay_domains
Jun 12 08:45:56 v2 postfix/virtual[10916]: 9BEE86501AF: to=<user@sub.dmn.tld>, relay=virtual, delay=14, delays=14/0/0/0.06, dsn=2.0.0, status=sent (delivered to maildir)

-) What about adding MX relays (no brackets)?

Further ideas:

-) Maybe the engine could be further modified to write the mail accounts to (a new) "relay_recipients" table when the domain is relayed, instead of the "mailboxes" table. This way we could add "relay_recipients_map hash:/etc/postfix/ispcp/relay_recipients" so every recipient address is locally verified (the customer will have to create the mailboxes as if it wasn't relayed, but I think it's not a major drawback). What do you think?

[ispcomm]

I must have this functionality in my panel because more and more customers are using their local servers, so for me there's no coming back.

Regarding the other issues:

SMTP Traffic: I haven't looked into this, but I think the traffic script will need some tweaks. It's a priority for me too, as it's very important to account for traffic precisely.

Mail accounts - aliasing: Did you try to see if aliases are respected? I don't remember the postfix flow (whether transport comes before aliasing).

Mail account functionality:I can gray out the input boxes in the templates when there are accounts in the domain and show a warning text like "Please delete all pop3 accounts before enabling the MX relay feature". This will require an extra query at max and is easy. However, this could be a problem when one domain has pop3 accounts and then decides to go with MX relay. Unless timing is very precise, there will be a risk for loosing mail between the moment accounts are deleted and the moment the MX relay gets live.

A different solution would be to put a nice RED warning next to the MX relay field with something like "WARNING: MX Relay is active. The pop3 mailboxes for this domain will not receive new mail.". How do you like this idea?

Subdomains: I could add the same functionality to subdomains. Not a priority for me as normally subdomains are used for SEO stuff and mini sites.

MX Relays - no brackets: This one is easy. Just remove the brackets in ispcp-dmn-mngr and remember to put brackets whenever needed in the MX relay field. I have no customer with this requirement. If you need it this way, I have no objections (but it must be documented that [] are required for no mx lookup).

Quote:-) Maybe the engine could be further modified to write the mail accounts to (a new) "relay_recipients" table when the domain is relayed, instead of the "mailboxes" table. This way we could add "relay_recipients_map hash:/etc/postfix/ispcp/relay_recipients" so every recipient address is locally verified (the customer will have to create the mailboxes as if it wasn't relayed, but I think it's not a major drawback). What do you think?

This one could be nice to have. It's more work for the customers. For small domains it would be better with reject_unverified_sender. For bigger domains it's better to have maps on the server. However, without proper pages to load the maps it will look more like a hack than a feature. I could implement a dedicated page for uploading a text field with a list of the accounts (either space or newline separated). This will require an extra table but is a cleaner solution.

ispcomm.

[ispcomm]

Kilburn,

I'm working on the issue of mail logs, and found a problem that causes some traffic to be unaccounted in specific conditions (http://www.isp-control.net/ispcp/ticket/1345)

There are many issues with this script (It basically works only under special circumstances).

Depending on postfix configuration, localhost could be written "127.0.0.1" in the logs instead of "localhost". And depending on /etc/hosts there could be other variations.

To help me fix this issue (I don't see your problem on my test server), pls send me some <anonymyzed> output from this command:

Code:

#grep postfix /var/log/mail.log|/usr/sbin/maillogconvert.pl standard|grep <relayed_domain.ext>

Also attach an "anonymyzed /etc/hosts".

The solution would be to rewrite the AWK script to:
1. Skip everything with ? bytes (or perhaps account a fixed amount of traffic).
2. Skip anything with virtual delivery (that has been already accounted via SMTP).
3. Account all others (i.e. smtp etc), but take care of antivirus etc properly.

However, once again, I'm running a modified mail flow (not using amavis here) and my logs migh be a little different than yours.

Thank you,
ispcomm.

[ispcomm]

I started a new thread for mail accounting here: http://www.isp-control.net/forum/mail-tr...-3511.html

as it's not directly connected to the mx patch.

ispcomm.