Verify Receivers settings and meanings

creeble

New Member
Sep 18, 2023
17
0
1
Hi, new to Proxmox (Mail Gateway), setting up my first instance.

I'm having trouble understanding the "Verify Receivers" setting. This thread:

https://forum.proxmox.com/threads/how-to-verify-email-addresses-transport-recipients.77519/

Seems to indicate that when it is set to "No", PMG still queries the destination server (with RCPT TO) when receiving RCPT TO: on the input side (i.e., without queuing the message).

So is the only reason to use this setting to set a different return value (say 450) than what the destination server returns (say, 550)? Otherwise, setting to "No" still does verification, returning... something; in my case it seems to always return "550 Protocol Error" on any error from the server?

I would expect that when the setting is "No", PMG would return what the destination server returns, which in my case would be:

"550 5.1.1 <aslkdfjas@domain.com>: Recipient address rejected: User unknown in virtual alias table"

Also, when PMG processes the bounce, it doesn't seem to have a "From: " address when sending it back to the email address of the sender. Can this be set somewhere?
 
Last edited:
Seems to indicate that when it is set to "No", PMG still queries the destination server (with RCPT TO) when receiving RCPT TO: on the input side (i.e., without queuing the message).
no - if you've disabled it - PMG will accept the mail - and, if the address does not exist downstream will send out a bounce

Otherwise, setting to "No" still does verification, returning... something; in my case it seems to always return "550 Protocol Error" on any error from the server?
the protocol error sounds odd - please share the logs for such a transaction...
I would expect that when the setting is "No", PMG would return what the destination server returns, which in my case would be:
no - for this you need to set it to 550 - if PMG gets a 550 from downstream - it caches this
see
https://www.postfix.org/ADDRESS_VERIFICATION_README.html
for more details
 
Well, at the moment I'm unable to make a session work from telnet at all, so having trouble duplicating the issue.
Here are my settings:
1695138754654.png
But here are the results from a valid SMTP session:


Code:
telnet pmg.domain.com 25
Trying 1.2.3.4...
Connected to pmg.domain.com.
Escape character is '^]'.
220-pmg.domain.com ESMTP Proxmox
helo foo.com
250 pmg.domain.com
mail from: <valid.address@somwhere.com>
250 2.1.0 Ok
rcpt to: <address@domain.configured.in.proxmox.com>
550 5.5.1 Protocol error
quit
221 2.0.0 Bye

That's a perfectly valid SMTP session, so I'm not sure why it's not accepting that mail.

I removed the DNSBL entries, but got the same thing.
 
Last edited:
Code:
telnet pmg.domain.com 25
Trying 1.2.3.4...
Connected to pmg.domain.com.
Escape character is '^]'.
220-pmg.domain.com ESMTP Proxmox
helo foo.com
250 pmg.domain.com
mail from: <valid.address@somwhere.com>
250 2.1.0 Ok
rcpt to: <address@domain.configured.in.proxmox.com>
550 5.5.1 Protocol error
quit
221 2.0.0 Bye
That's a perfectly valid SMTP session, so I'm not sure why it's not accepting that mail.
no it's not - this is what postscreen does to catch bots:
https://www.postfix.org/POSTSCREEN_README.html

one of the things is writing:
220-pmg.domain.com ESMTP Proxmox
which is not
220 pmg.domain.com ESMTP Proxmox

I hope this helps to clear this up!
also keep an eye on the journal of PMG - as it might have given you some hints
also consider using a dedicated smtp-tool - like swaks instead of telnet
 
Okay, wait, sorry, I think the DNSBL was cached for a bit.
Actually, I think both of those issues were maybe cache or restarting-postfix related. I can do a session now with an unknown address on the PMG and it will accept the RCPT TO:

However, the bounce handling is an issue (from PMG mail.log):

Code:
2023-09-19T09:08:53.373200-07:00 pmg postfix/smtp[40012]: 94539C122A: to=<nonuser@domain.com>, relay=1.2.3.4[1.2.3.4]:25, delay=0.77, delays=0.04/0.03/0.6/0.08, dsn=5.1.1, status=bounced (host 1.2.3.4[1.2.3.4] said: 550 5.1.1 <nonuser@domain.com>: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command))
2023-09-19T09:08:53.451204-07:00 pmg postfix/cleanup[40006]: 6E07DC1227: message-id=<20230919160853.6E07DC1227@pmg.pmg-domain.com>
2023-09-19T09:08:53.451813-07:00 pmg postfix/bounce[40013]: 94539C122A: sender non-delivery notification: 6E07DC1227
2023-09-19T09:08:53.451940-07:00 pmg postfix/qmgr[39875]: 6E07DC1227: from=<>, size=5086, nrcpt=1 (queue active)
2023-09-19T09:08:53.451997-07:00 pmg postfix/qmgr[39875]: 94539C122A: removed
2023-09-19T09:08:53.681627-07:00 pmg postfix/smtp[40012]: 6E07DC1227: to=<sender@gmail.com>, relay=aspmx.l.google.com[64.233.177.26]:25, delay=0.23, delays=0/0/0.04/0.18, dsn=5.7.26, status=bounced (host aspmx.l.google.com[64.233.177.26] said: 550-5.7.26 Unauthenticated email from pmg-domain.com is not accepted due to domain's 550-5.7.26 DMARC policy. Please contact the administrator of pmg-domain.com domain if 550-5.7.26 this was a legitimate mail. Please visit 550-5.7.26  https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.26 DMARC initiative. d67-20020a254f46000000b00d84c19c398dsi4915289ybb.527 - gsmtp (in reply to end of DATA command))
2023-09-19T09:08:53.682623-07:00 pmg postfix/qmgr[39875]: 6E07DC1227: removed

My DMARC policy for "pmg-domain.com" is set to ACCEPT, but I don't think it likes the from=<> message?
 
Okay, I think I have this all sorted -- my DMARC/SPF were not what I thought, and setting them correctly (or at least to something google accepts) seems to be working now.

One detail, just to be clear:
no - if you've disabled it - PMG will accept the mail - and, if the address does not exist downstream will send out a bounce

Downstream sends the bounce back to PMG (550), and PMG then sends a bounce to sender. So PMG had better comply with SPF and other (sometimes recipient-specific) sender policies or bounces won't be received!
 
Downstream sends the bounce back to PMG (550), and PMG then sends a bounce to sender. So PMG had better comply with SPF and other (sometimes recipient-specific) sender policies or bounces won't be received!
Yes - you should include your PMG in your SPF record, if you use it for outbound relaying - however - bounces are sent with an empty envelope-sender - so SPF is usually not checked
 
however - bounces are sent with an empty envelope-sender - so SPF is usually not checked
Well, Gmail checks. So if you want your bounces to be received by Gmail users, you'll need the right SPF (and I can't seem to get 'alignment' with DMARC p=reject no matter how I try).

I'd love a feature that silently accepts non-existent addresses to reduce bounces, as some 50% of our traffic (by messages, not size) are bounces from messages sent to nonsense addresses. I'd rather risk misspellings than have all that backspray!
 
I'd love a feature that silently accepts non-existent addresses to reduce bounces, as some 50% of our traffic (by messages, not size) are bounces from messages sent to nonsense addresses. I'd rather risk misspellings than have all that backspray!
just enable verify recieivers - this will make sure that non-existing inbound addresses are not accepted during the SMTP dialogue

Well, Gmail checks. So if you want your bounces to be received by Gmail users, you'll need the right SPF (and I can't seem to get 'alignment' with DMARC p=reject no matter how I try).
this could be the result of: https://bugzilla.proxmox.com/show_bug.cgi?id=2971
 
just enable verify recieivers - this will make sure that non-existing inbound addresses are not accepted during the SMTP dialogue
I have verify receivers set now -- but it sends 550, which results in a bounce at the client end (and potentially information about what names exist @thedomain). I would like a feature to send 250 to the client, and if it didn't find a user, send all data to /dev/null. I could potentially do it at the receiving end by having a catch-all for domains and throw out non-existent addresses, but then it has to queue the mail in PMG and deliver it to my mail server.

I'm pretty sure it's my fault -- I've been trying to use "p=reject" without DKIM, which I think is just a fail. Signing bounces seems like a lot of trouble (including the problems pointed out in the bugzilla), so I think I'm stuck with "p=none" for now.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!