how to verify email addresses transport recipients ?

[MiamiJack]

Hello All,

I'm to sure how PMG references this, but in running postfix servers I would have a transport file containing domains ( relay domains ) and then I would create a transport_recipients which would have the allowed users for the domains.

so if we have the following in lets say transport_domains
abc.com
123.com
xyz.com

I would then have a transport_domains_recipeients
@abc.com OK
@123.com OK
mike@xyz.com OK
joe@xyz.com OK

By having this recipients list, we can reject unknown recipient addresses, this reduces the amount of spam going to the mail server.

Does PMG have a way to accomplish this?
If there is no way to accomplish this, I know we can add in to the postfix template as our own functionality, but I'm hoping there is a way from within PMG to keep things clean and consistent.

Also, how can we obtain the valid current user list from Exchange/O365 etc?
I know from cpanel we can write some scripts to build the valid email address list and sync it back to PMG.

Thank you.

 

[Stoiko Ivanov]

Does PMG have a way to accomplish this?

PMG uses recipient verification for this (it asks the downstream-server where the mail for xyz.com gets delivered to, whether it would accept a mail for joe@xyz.com - if it responds with 250 to the RCPT TO command, it caches the result and accepts the mail, if it responds with 5xx it rejects the mail) - see the mail proxy configuration options docs:
https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_mail_proxy_configuration (section 4.6.4)

I hope this helps!

 

[MiamiJack]

Thank you, I saw that feature, but was hoping to do something like an AD sync which is less traffic overall then verifying on each message.

I

 

[Stoiko Ivanov]

Thank you, I saw that feature, but was hoping to do something like an AD sync which is less traffic overall then verifying on each message

the results of the recipient lookup are cached - so the traffic really should not be too much - and it's quite a robust mechanism

 

[MiamiJack]

Seeing that it's cached, I will give that a try.
Thank you.

 

[MiamiJack]

Hello,

Sorry to revisit this, however when checking my configuration which I added verify receivers yes, I see messages still looking like they are being delivered to the destination server, then being rejected from the destination.

This happens with destination servers cpanel & exchange ( I did do some additional settings in cpanel to permit this ).

My issue is that pmgsh get /statistics/receiver will show that a message was delivered to that user, when technically it should have been rejected at PMGW...

Is there possibly something I missed configuration wise?
Or is there a better way for me to block the message at the gateway?

Thanks!

PS Using Verify Receivers option 450

 

[Stoiko Ivanov]

My issue is that pmgsh get /statistics/receiver will show that a message was delivered to that user, when technically it should have been rejected at PMGW...

could you please share the logs of such a mail?

 

[MiamiJack]

Hello,

Here is the actual log content, but with the names & ip's changed to protect the innocent
The rest is verbatim.
The message comes in from outlook, gets delivered, then later on in the log (not shown) the rejection comes back from the exchange server as well as the cpanel server. (2 examples below)
Target email test.henry@respective domain.

This is sent to Exchange Server:

Nov 10 12:19:59 mgw postfix/smtpd[89070]: 7CC338097D: client=localhost.localdomain[127.0.0.1], orig_client=mail-dm6nam11on2048.outbound.protection.outlook.com[40.107.223.48]
Nov 10 12:19:59 mgw postfix/cleanup[88929]: 7CC338097D: message-id=<BN6PR19MB1251B0029A9AC6AF7A522B85B2939@BN6PR19MB1251.namprd19.prod.outlook.com>
Nov 10 12:19:59 mgw postfix/qmgr[1093]: 7CC338097D: from=<Sender@SenderDomain.com>, size=146154, nrcpt=1 (queue active)
Nov 10 12:19:59 mgw pmg-smtp-filter[89375]: A0969618BFF3DD2AE1: accept mail to <test.henry@receivingdomain.com> (7CC338097D) (rule: default-accept)
Nov 10 12:19:59 mgw postfix/smtpd[89070]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5
Nov 10 12:19:59 mgw postfix/smtp[89173]: Trusted TLS connection established to webmail.receivingdomain.com[12.12.12.171]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
Nov 10 12:19:59 mgw pmg-smtp-filter[89375]: A0969618BFF3DD2AE1: processing time: 1.676 seconds (1.159, 0.176, 0)
Nov 10 12:19:59 mgw postfix/lmtp[87216]: 955EE808D7: to=<test.henry@receivingdomain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=2, delays=0.24/0/0.01/1.7, dsn=2.5.0, status=sent (250 2.5.0 OK (A0969618BFF3DD2AE1))
Nov 10 12:19:59 mgw postfix/qmgr[1093]: 955EE808D7: removed
Nov 10 12:19:59 mgw postfix/smtp[89173]: 7CC338097D: to=<test.henry@receivingdomain.com>, relay=webmail.receivingdomain.com[12.12.12.171]:25, delay=0.27, delays=0.07/0/0.06/0.14, dsn=2.6.0, status=sent (250 2.6.0 <BN6PR19MB1251B0029A9AC6AF7A522B85B2939@BN6PR19MB1251.namprd19.prod.outlook.com> [InternalId=10307921511006, Hostname=Comm.receivingdomain.local] Queued mail for delivery)
Nov 10 12:19:59 mgw postfix/qmgr[1093]: 7CC338097D: removed

This is sent to cPanel Server:

Nov 10 12:25:58 mgw postfix/smtpd[89161]: 4D161808F6: client=localhost.localdomain[127.0.0.1], orig_client=mail-dm6nam10on2049.outbound.protection.outlook.com[40.107.93.49]
Nov 10 12:25:58 mgw postfix/cleanup[89579]: 4D161808F6: message-id=<BN6PR19MB12516ED0D72B8166496750BEB2939@BN6PR19MB1251.namprd19.prod.outlook.com>
Nov 10 12:25:58 mgw postfix/qmgr[1093]: 4D161808F6: from=<Jack@senderdomain.com>, size=146071, nrcpt=1 (queue active)
Nov 10 12:25:58 mgw pmg-smtp-filter[89681]: A0969618C00A56CD46: accept mail to <test.henry@receivingcpanel.net> (4D161808F6) (rule: default-accept)
Nov 10 12:25:58 mgw postfix/smtpd[89161]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5
Nov 10 12:25:58 mgw pmg-smtp-filter[89681]: A0969618C00A56CD46: processing time: 0.936 seconds (0.685, 0.096, 0)
Nov 10 12:25:58 mgw postfix/lmtp[89164]: 33F21808D7: to=<test.henry@receivingcpanel.net>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.2, delays=0.23/0/0/0.95, dsn=2.5.0, status=sent (250 2.5.0 OK (A0969618C00A56CD46))
Nov 10 12:25:58 mgw postfix/qmgr[1093]: 33F21808D7: removed

 

[MiamiJack]

@Stoiko Ivanov
Sorry to bump but I hadn't hear back on the above...

 

[Stoiko Ivanov]

relay=webmail.receivingdomain.com[12.12.12.171]:25, delay=0.27, delays=0.07/0/0.06/0.14, dsn=2.6.0, status=sent (250 2.6.0 <BN6PR19MB1251B0029A9AC6AF7A522B85B2939@BN6PR19MB1251.namprd19.prod.outlook.com> [InternalId=10307921511006, Hostname=Comm.receivingdomain.local] Queued mail for delivery

here the downstream server (12.12.12.171) accepted the mail for test.henry@receivingdomain.com - meaning that on smtp-protocol level there it is not possible to see that the recipient does not exist/or will reject the mail later on - this needs to be configured (by the admin) on 12.12.12.171

This is sent to cPanel Server:

for this mail the relaying to the downstream server is missing (lines from postfix/smtp for 4D161808F6)

 

[MiamiJack]

Thank you for your quick response!!

First I would like to review the process so I can insure I understand what I should expect.

Mail received by gateway, is in the relay domains, and accepts it.
Then it should query the receiving server to ask if its accepting email for bob@x.com
receiving server should reply with a yes or no..
if no, reject, if yes, accept and run through the rest of the checks

Does that sound somewhat accurate?

-----

Also, if the server did the verify would it even have been attempted to be delivered or rejected immediately if it received the proper response back?
Is there a way for me to manually query the server to ask if it can verify an address?

One of the concerns I have is it also shows the message to the invalid user as someone that got mail delivered within the pmgsh get /statistics/receiver report.

Thanks

 

[hata_ph]

Before setup Verify Receivers, can you confirm your downstream email servers support error 450/550 code for unknown email address?

 

[Stoiko Ivanov]

First I would like to review the process so I can insure I understand what I should expect.

Mail received by gateway, is in the relay domains, and accepts it.
Then it should query the receiving server to ask if its accepting email for bob@x.com
receiving server should reply with a yes or no..
if no, reject, if yes, accept and run through the rest of the checks

Does that sound somewhat accurate?

roughly speaking yes - however PMG does not accept the mail - it asks the downstream server if the mailbox exists before processing the mail in the rule system. Additionally it caches the response (both for yes answers and no answers)

with a bit more detail:
The sending server opens a connection to PMG, and starts the SMTP dialog:
EHLO <server name>
MAIL FROM <sender address>
RCPT TO <bob@x.com>
here PMG (actually postfix) does the check:
* if the answer is cached (and the caching time has not expired) - it answers according to the cached answer
* if there is nothing in the cache - PMG connects to the downstream server (where it would send the mail for bob@x.com ) - and does the SMTP dialog until the RCPT TO: - if the downstream server answers with 200 (OK) then it caches this and answers 200
if the downstream server answers 4xx (temporary failure) it answers with 450 (temporary failure - try again later)
if the downstream server answers 5xx (permanent failure) it answers with whatever you have configured in the GUI as response (and caches the answer)

so @hata_ph is correct - check what your downstream server answers.

PMG uses postfix recipient verification for this - this are the docs on the topic:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

I hope this helps!

 

[MiamiJack]

Thank you both, will try to follow up with your points and report back!

 

[MiamiJack]

I was hoping there was some functionality within PMG to accomplish this.
I know I could potentially do it within 3rd party scripts and such to modify postfix files, but wanted to do it in a more integrated way within PMG.