450 3.7.1 Client host rejected: cannot find you hostname, [...] (in reply to RCPT to command)

[Zamana]

Hi!

We successfully installed Proxmox Mail Gateway with SPF, DKIM and the whole shebang, and it is working fine. Sort of...

For a dozen domains or so (a minority), our e-mails are getting queued, because "450 3.7.1 Client host rejected: cannot find you hostname, [...] (in reply to RCPT to command)"

The PMG has a local domain, and it is hosted in a datacenter. I created an entry in our DNS pointing the IP address of the datacenter to a FQDN in our domain, but of course this does not resolve the issue, for 2 reasons (I guess...):

1) The local host/domain of our mail server does not match the FQDN that I created in our DNS, and

2) The IP address of the datacenter shows another resolution when queried, bypassing our entry (which seems perfectly understandable).

The question is: is there a way to solve this from our part, once the receivers won't change their side in order to change their behavior (i.e.: they will keep trying to do the reverse lookup)?

Thanks.
Best regards.

 

[Stoiko Ivanov]

If the mail is getting queued on PMG (and should be sent so some remote domain in the internet) then the receiving server is denying to accept the mail

what's the (public) IP of pmg? - it needs to resolve to a DNS-name which has an A record pointing to that IP.

Your datacenter provider should be able to help you in resolving this issue.


I hope this helps!

 

[Zamana]

(...)

what's the (public) IP of pmg? - it needs to resolve to a DNS-name which has an A record pointing to that IP.

Your datacenter provider should be able to help you in resolving this issue.


I hope this helps!

Hi!

Thanks for reply.

I configured an A entry in our DNS manager for our domain. But it seems that the configuration of the datacenter's resolution is getting precedence...

The IP is 177.154.135.250.

But how the datacenter could help if they does not have any relationship with our domain? I'm confused...

Regards.

 

[Stoiko Ivanov]

The entries do not match:

 dig -x 177.154.135.250 +noall +answer

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -x 177.154.135.250 +noall +answer
;; global options: +cmd
250.135.154.177.in-addr.arpa. 3426 IN    PTR    bodysystems.net.
siv@rosa:~ $ dig bodysystems.net. +noall +answer

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> bodysystems.net. +noall +answer
;; global options: +cmd
bodysystems.net.    3426    IN    A    91.195.240.101

the PTR record for 177.154.135.250 points to bodysystems.net
but bodysystems.net points to 91.195.240.101

your datacenter provider is (usually) the entity that can set PTR records for their public IP, therefore you need to ask them to set one pointing to your PMG's hostname

 

[Zamana]

Hi!

Yesterday we opened a ticket at our datacenter's support and it was solved. Now the IP resolves to a host at our domain.

So the new questions are:

1) What we need to do so the new messages get delivered?

2) What we need to do so the old, queued messages, be delivered?

Of course the hostname@domain returned by the query on the public IP is different from the hostname@domain inside our environment. What need to be done to translate the internal to the external at the moment when the messages are sent?

Thanks!
Regards.

 

[Stoiko Ivanov]

Now the IP resolves to a host at our domain.

does:

dig -x 177.154.135.250

now resolve to a fqdn, which points to 177.154.135.250?

if yes:

1) What we need to do so the new messages get delivered?

try whether mails already get delivered to external server successfully - if that does not work - post the logs of such a mail from your PMG's mail.log

2) What we need to do so the old, queued messages, be delivered?

this should happen automatically - postfix tries to deliver queued mail periodically
(else you can also try `postqueue -f` - see `man postqueue`)

if there are still problems - post the logs from PMG

 

[Zamana]

Hi!

Thanks for the help. It seems we are fixing the problems with your suggestions.

Just another issue: when we send test e-mails via command line from another system (using ssmtp), the messages seems to get the "authentication layer' that PMG provides (SPF and DKIM), and are delivered just fine.

But when we do the same from the PMG host itself, it seems that the messages don't use the PMG features, and are sent by using the postfix service only. In this case the message arrives at the destination with alignment problems between SPF and DKIM (although they are configured fine).

Is this a feature or a bug? Or, in other words, how can we send test messages from the PMG host itself? Preferably by using command line tools?

Thanks!
Best regards.

 

[Stoiko Ivanov]

Messages sent directly on PMG (the one's that get input to the mailsystem via `postdrop` or `/usr/sbin/sendmail`) don't get passed through the mail-proxy (postscreen, smtpd) and through the rule-system (pmg-smtp-filter)

you could try submitting mail via TCP to 127.0.0.1:25 (or 127.0.0.1:26 for outbound mail) - using e.g. `swaks (1)` - this passes the mail through the rule-system - although 127.0.0.1 is considered local by postfix - so the rbl-checks+spf (in the mailproxy)+greylisting won't probably apply:

swaks --server 127.0.0.1:26 --to some@external.address --data testmailbody.txt

I hope this helps!