Notify Sender/Admin: postmaster@myhostname.mydomain.tld

[i1h9lu]

Hi,

i have the problem, that notifications from our PROXMOX are send from "postmaster@myhostname.mydomain.tld".

From some external MTAs (tested from GMX) i get the message "550 5.1.8 {mx027} Cannot resolve your domain (in reply to MAIL FROM command)".

Yesterday i added "myorigin=$mydomain" to the "/etc/postfix/main.cf" to fix the problem. After a restart of postfix, it seems to work.

Today, the "/etc/postfix/main.cf" seems to be overwritten and the problem emerges again.

How can i make permanent changes to the "/etc/postfix/main.cf" or is there an other way to fix this?

Thanks
Tobias

[dietmar]

Just add the right address on the web interface:

System/Reports/Administrator EMail

Best Regards,

Dietmar

[i1h9lu]

Hi,

on the web interface i have the eMail address "support@mydomain.tld".

If i click on "send report now" the report is send correctly to "support@mydomain.tld".

Notifications are send from "postmaster@myhostname.mydomain.tld" and not from "support@mydomain.tld".

best regards
Tobias

[dietmar]

You should already have a DNS address record for your mail proxy, and you also need a PTR record (reverse lookup). If not, add them to the DNS.

- Dietmar

[i1h9lu]

I have just looked at our DNS-Server. The forward and reverse entries are set correctly for our PROXMOX mail proxy.

I have still the same Problem.

best regard
Tobias

[dietmar]

If the DNS is OK, why doe GMX say:

"Cannot resolve your domain (in reply to MAIL FROM command)". "

This is usually because DNS is worng.

- Dietmar

[i1h9lu]

Hm, maybe it bekomes a little bit clearer if i don't use the "myhostname.mydomain" stuff in my explanations.

Our primary domain is "ahlers-ag.com".
The hostname of our PROXMOX mail router is "mgw".
We have an external and an internal DNS-Server for "ahlers-ag.com".

External Mails are send to our MX "mail.ahlers-ag.com".
It pionts to our firewall with the public IP: 62.159.134.66.
The firewall is doing SMTP-NAT and gives the mails to the PROXMOX (mgw.ahlers-ag.com), which is in our DMZ and has a private IP (192.168.99.75).

The hostname of our PROXMOX (mgw.ahlers-ag.com) is only known by our internal DNS-Server.

Now, PROXMOX is sending notifications and status reports under the address "postmaster@mgw.ahlers-ag.com".

For GMX, "mgw" is a subdomain from "ahlers-ag.com" (which doesn't exist).

To avoid this, PROXMOX should send mails as "postmaster@ahlers-ag.com".
We have saverel internal MTAs (mta1.ahlers-ag.com, mta2.ahlers-ag.com...) which are sending their mails like anybody@ahlers-ag.com. (not like anybody@mta1.ahlers-ag.com etc...).

One way to fix this, is to add "myorigin = $mydomain" to the "/etc/postfix/main.cf".
If i do that (after a "/etc/init.d/postfix reload") PROXMOX sends notifications as "postmaster@ahlers-ag.com" (didn't work for Status Reports :?: : not so nice, but not a real problem - i get the reports) .

The mails from "postmaster@ahlers-ag.com" are accepted by GMX and the mail-header contains the following: "Received: from mail.ahlers-ag.com (EHLO mgw.ahlers-ag.com) [62.159.134.66]"

After some time, the "/etc/postfix/main.cf" seems to be overwritten and my changes are lost.

I hope, this explains our configuration and our problem more exactly.

[dietmar]

Adding an exernal DNS entry for mgw.ahlers-ag.com pointing to 62.159.134.66 (with reverse lookup) would solve the problem too?

That way bounces go back to the right host.

- Dietmar

[i1h9lu]

Hm, i need some time to test it.
Our external DNS is hosted at the German Telekom.
They have a very stupid webinterface and changes are not applied immediately. :(

As a workaround, i added "myorigin=$mydomain" to the "main.cf.in"-template in "/var/lib/proxmox/templates".
Now the sender of the notifications is "postmaster@ahlers-ag.com".
(But the sender of the "Status Report" is always still "postmaster@mgw.ahlers-ag.com" :?: !!)

If the changes on our external DNS are applied, i will remove the entry from the template and test again.

Afterwards, i will inform you, whether it funktions.

[dietmar]

Hm, i need some time to test it.
Now the sender of the notifications is "postmaster@ahlers-ag.com".
(But the sender of the "Status Report" is always still "postmaster@mgw.ahlers-ag.com" :?: !!)


What adress do you suggest instead?

[i1h9lu]

The sender of the "Status Reports" is not so important for us, because we sends them only to internal MTAs and they accepts it.

I would expect "postmaster@ahlers-ag.com" as the sender of the "Status Report", because i have added the "myorigin = $mydomain" to the postfix "main.cf".
That entry tells postfix to send every mail from the host under "ahlers-ag.com" (not mgw.ahlers-ag.com), doesn't it?!

But as i mention above, it's not so important.

[jlar310]

Adding an exernal DNS entry for mgw.ahlers-ag.com pointing to 62.159.134.66 (with reverse lookup) would solve the problem too?

That way bounces go back to the right host.

- Dietmar

I know this is an old thread, but I just wanted to add my 2 cents...

The sender address for notifications really should be configurable by Proxmox users. Why on earth would we want to expose our internal hostnames on public DNS? Bad, bad, bad.... That's why we all use a CNAME mail.domain.tld for our mail servers, right?

Please consider this for a future release. In the meantime, I too have added myorigin = $mydomain to /var/lib/proxmox/templates/main.cf.in.

While I'm on the topic of hacking the templates in order to mask the local hostname, I have found it useful to add

-o smtp_helo_name=mail.mydomain.tld

after the "smtp" line in master.cf.in as well. This is because some receiving mail servers use reverse DNS to validate the name your mail server reports. Again, I did not want to expose or maintain a specific hostname in public DNS. So that would be another "value added" configuration enhancement to the Proxmox system.

These enhancements do not appear that they should be all that complicated to implement. Just a couple more fields on the config page, and plug these values into the templates. Easy, right?

We still love your product despite these shortcomings. At least it can be hacked via the templates!

Thanks.