Mail Proxy: interaction option "verify receivers" and "greylisting"

[Teknyske]

Hi,

We are currently evaluating/testing Proxmox.
I must admit I am very impressed with the performance of this product so far !

At the moment, we use greylisting, but not the verify receivers (with error 450: service temporarily not available) option.

As I understand from the documentation, both filtering techniques can result in proxmox returning an error code 450 to the SMTP server trying to deliver a message.

However, it is not quite clear to me how these 2 filtering techniques interact with eachother when both are active at the same time.

My guess is that greylisting filtering is always applied before the verify receiver test,
and that the verify receiver test is only applied when an SMTP server tries to deliver a message again (e.g. an existing triplet is found in the greylisting DB)
Is that correct ?

Teknyske

 

[dietmar]

Yes, thats correct.

 

[Teknyske]

Yes, thats correct.

Thank you very much for the ultra-quick response !

Let's say an SMTP-server would try to deliver a mail or SPAM to a non-existing email-address in the domain that Proxmox is handling and both types of filtering are enabled.

The first time it tries, the sending SMTP would get an error code 450 (try again later) from the greylisting filter of Proxmox.
At the same time, a triplet is created in the greylisting DB.

Let's say a real SMTP-server is used and the sending SMTP would retry the delivery of the mail.
It passes the greylisting filter this time.

So now, proxmox verifies with the SMTP server it is relaying to if the recipient address exists.
- in case error 450 is configured for the verify test:
If the recipient address does not exist, it would again return error code 450 (temporary delivery faillure) to the sending SMTP and would continue doing so from then on upon each delivery attempt until the sending SMTP server gives up ?
- in case error 550 is configured for the verify test:
If the recipient address does not exist, it would return error code 550 (definitive delivery faillure) to the sending SMTP ?

So do I understand correctly that the advantage of enabling the verification test (in case of non-existing recipient addresses) is that less mails have to be processed and less non-delivery reports have to be sent by proxmox since it does never accept them for delivery ?

I am wondering if there is any danger for a spammer to abuse the response of the verification test to harvest existing email -adresses on a specific domain.
If one restricts the connection rate, this would however take quite a while I suppose ?
I guess in that respect, configuring error 450 would be a safer option as it may take a while until the sending SMTP gives up?

 

[martin]

Thank you very much for the ultra-quick response !

Let's say an SMTP-server would try to deliver a mail or SPAM to a non-existing email-address in the domain that Proxmox is handling and both types of filtering are enabled.

The first time it tries, the sending SMTP would get an error code 450 (try again later) from the greylisting filter of Proxmox.
At the same time, a triplet is created in the greylisting DB.

Let's say a real SMTP-server is used and the sending SMTP would retry the delivery of the mail.
It passes the greylisting filter this time.

So now, proxmox verifies with the SMTP server it is relaying to if the recipient address exists.
- in case error 450 is configured for the verify test:
If the recipient address does not exist, it would again return error code 450 (temporary delivery faillure) to the sending SMTP and would continue doing so from then on upon each delivery attempt until the sending SMTP server gives up ?
- in case error 550 is configured for the verify test:
If the recipient address does not exist, it would return error code 550 (definitive delivery faillure) to the sending SMTP ?

So do I understand correctly that the advantage of enabling the verification test (in case of non-existing recipient addresses) is that less mails have to be processed and less non-delivery reports have to be sent by proxmox since it does never accept them for delivery ?

I am wondering if there is any danger for a spammer to abuse the response of the verification test to harvest existing email -adresses on a specific domain.
If one restricts the connection rate, this would however take quite a while I suppose ?
I guess in that respect, configuring error 450 would be a safer option as it may take a while until the sending SMTP gives up?

Hi,
yes, selecting 450 is the recommended setting. At most environments you can reduce the email traffic by using "Verify Receivers" about more than 50 %, some reached 90 % less traffic. but this depends on how much spam you get.

 

[Teknyske]

My guess is that greylisting filtering is always applied before the verify receiver test,
and that the verify receiver test is only applied when an SMTP server tries to deliver a message again (e.g. an existing triplet is found in the greylisting DB)
Is that correct ?

Yes, thats correct.

OK, so I have switched on the recipient verification option in addition to the greylisting filter now !

As you said, indeed, the amount of incoming spam-mails has been reduced even further.

I guess an additional advantage is that now, the system doesn't have to send as much non-delivery faillure reports anymore ?
However, people that tried to send a genuine mail but made a typo in the recipient address won't get a non-delivery report either, will they, at least not until the sending SMTP gives up trying to deliver the mail after some time. I guess selecting option "error 550" for the verification test would indeed reenable those non-delivery faillure reports ?

Also, I noticed in the Logs / Greylist section that now, the system only creates triplets for existing recipient addresses ?
So, to me it seems then that the system does not sequentually perform the greylisting (first) and recipient verification test (next).
It seems as though these two tests really interact, as new greylisting triplets are created only for existing addresses ?

Anyway, I hereby want to re-affirm that I am very pleased with the stability and performance of Proxmox and will certainly suggest buying it so we can use all of it's features.

 

[dietmar]

I guess an additional advantage is that now, the system doesn't have to send as much non-delivery faillure reports anymore ?

yes

However, people that tried to send a genuine mail but made a typo in the recipient address won't get a non-delivery report either, will they, at least not until the sending SMTP gives up trying to deliver the mail after some time. I guess selecting option "error 550" for the verification test would indeed reenable those non-delivery faillure reports ?

yes, 550 would give them an immediate response. But a reasonable MTA also gives a delay warning if you select the 450 response (after some time)

Also, I noticed in the Logs / Greylist section that now, the system only creates triplets for existing recipient addresses ?
So, to me it seems then that the system does not sequentually perform the greylisting (first) and recipient verification test (next).
It seems as though these two tests really interact, as new greylisting triplets are created only for existing addresses ?

You are right. We first apply RBL checks (if enabled), then recipient verification, and finally greylisting.

- Dietmar

 

[alex-schaefer]

Q: Recipient verification + AD non-existent e-mail address policy

And how do interact these both policies: non-existent e-mail address, which we have activated, using the Active Directory connector as described in the deployment guide and the Recipient verification (with Exchange server)?
Is there some logical difference? Is it resonable to activate both policies? Will non-existent e-mail address become something to do with the activated Recipient verification?

 

[dietmar]

And how do interact these both policies: non-existent e-mail address, which we have activated, using the Active Directory connector as described in the deployment guide and the Recipient verification (with Exchange server)?

There is no iteraction at all.

Is there some logical difference? Is it resonable to activate both policies? Will non-existent e-mail address become something to do with the activated Recipient verification?

Recipient verification work at SMTP protocol level.

LDAP/AD is used inside the rule system - It is quite reasonable to use both LDAP and reciepient verification. Although it make no sense to use the LDAP object 'non-existent address' if you already block at SMTP level.

- Dietmar

 

[tom]

And how do interact these both policies: non-existent e-mail address, which we have activated, using the Active Directory connector as described in the deployment guide and the Recipient verification (with Exchange server)?
Is there some logical difference? Is it resonable to activate both policies? Will non-existent e-mail address become something to do with the activated Recipient verification?

Hi Alex,

the main difference is that
"RBL checks (if enabled), then recipient verification, and finally greylisting"
acts on smtp level (internet/proxmox).

By using the LDAP connection and the rule described in the deployment guide works after proxmox already acepted the message from the internet. It depends what you prefer. By using the LDAP, you have the email on your proxmox and you can do whatever you want using the rulesystem.

By using the SMTP level, you rejects unwanted email before reaching the rule sytem, which leads to much lower traffic.

 

[alex-schaefer]

Of course, fighting SPAM on SMTP dialog level is the best method and should be used whenever possible to make the gateways as fast as possible.

 

[alex-schaefer]

Verify receivers with multiple receivers in single e-mail

How works "verify receivers" with multiple receivers in the single e-mail:
Does it accept the e-mail with one ore more non-existent recipient, when other recipients from the envelop does even exist in the organisation?

 

[tom]

How works "verify receivers" with multiple receivers in the single e-mail:
Does it accept the e-mail with one ore more non-existent recipient, when other recipients from the envelop does even exist in the organisation?

Hi Alex,
yes, if you get an email to 2 recipients (eg. lksdjfs@domain.com and valid@domain.com) the valid receiver gets the email and the other receiver is rejected as specified (450 or 550).

 

[thiagotgc]

Sorry to return to this subject after so long.

But checking the http://www.postfix.org/ADDRESS_VERIFICATION_README.html documentation, if I understand correctly, after analyzing that the postfix judgment is correct, I should change from 450 to 550.

After several years of use, still recommend 450 or should I really change to 550?

I want to make Proxmox the "lightest" and spam-free, to spare resources for valid emails!

 

[Stoiko Ivanov]

Please don't respond to 12 year old threads - create a new one instead the next time.

If you're content with the workings of recipient verification I would switch to 550 - otherwise you will get multiple requests per rejected mail
(The sending mailserver will try for a few days if it gets a 450 as response)
However such requests should not cause too much load on PMG

I hope this helps!

 

[ittk]

@Stoiko Ivanov
@tom

Sorry for that. But don't find any other more fitting thread, therefore i post it in here

Having PMG doing the SMTP Verification directly on SMTP Level would be very good feature (other products on the markt have these feature). Because the Problem is that e. g. well-known Microsoft Exchange Server above Version 2010 with Recipient Verification activiated will REJECT ALL E-Mails (not just the wrong address one!), when an E-Mail is send to multiple Recipients, but when only ONE recipient address i wrong or having a typo. so this i a big issue and sending out separately generated NDRs (from internally used Mailsystem or PMG generated) will lead to backscatter problems.

Here comes the problem described with Exchange recent version:

Although the Recipient Filter agent is available on Mailbox servers, you shouldn't configure it. When recipient filtering on a Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is rejected.
Quelle: https://technet.microsoft.com/en-us/library/bb125187(v=exchg.150).aspx

Das Problem bei diesem Verhalten ist natürlich, dass der sendende Mailserver nicht erkennen kann, welcher Empfänger aus der Liste nun ungültig ist und dass die komplette Mail "unzustellbar" ist. Der absendende Mailserver versucht es also nicht mehr erneut und der Absender bekommt die Information, dass alle Empfänger unerreichbar sind.

other sources, but in german: https://www.msxfaq.de/exchange/e2013/e2013recipientfilter.htm
https://www.mcseboard.de/topic/2112...-ab-wenn-eine-e-mail-adresse-ungültig/page/2/
https://www.heinlein-support.de/blo...3-dynamische-empfaengerpruefung-fuer-postfix/


As we have all infos (about valid recipient addresses) there on the PMG side, when using LDAP user adress sync. So why can't PMG handle the Recipient Address Verification also on SMTP level itself - with the data it can gain from the LDAP user sync (database files)?

 

[Stoiko Ivanov]

Sorry for that. But don't find any other more fitting thread, therefore i post it in here

you could also just open a fresh new thread

Having PMG doing the SMTP Verification directly on SMTP Level would be very good feature

this is what pmg (in that case postfix) is doing - it takes the response on SMTP level from the downstream server and caches that.
if the downstream server replies with 5XX for an existing address than I'd consider that a misconfiguration of the downstream server!

would you have a link to where this behaviour of exchange is explained? (I don't have experience with Exchange and it seems rather odd to me)

The elegance of the verification via SMTP is that it does work on the same channel where the mail is also delivered

As for using LDAP as reciepient verification database - probably doable - you'd need to adapt the postfix config templates and add the ldap queries to that - the following should be a good start:

http://www.postfix.org/ADDRESS_VERIFICATION_README.html
http://www.postfix.org/LDAP_README.html
https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine (for integration into PMG)

I hope this helps!

 

[ittk]

would you have a link to where this behaviour of exchange is explained? (I don't have experience with Exchange and it seems rather odd to me)

Thanks for fast response, have edited my previous posting, with many links, pointing to the exchange problem starting with exchange 2013 version. Leading to this problem: When recipient filtering on a Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is rejected.

Would be nice, to have any PMG integrated solution (other products do it), without the need, to manually editing postfix and other conf files...

 

[hata_ph]

Thanks for fast response, have edited my previous posting, with many links, pointing to the exchange problem starting with exchange 2013 version. Leading to this problem: When recipient filtering on a Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is rejected.

Would be nice, to have any PMG integrated solution (other products do it), without the need, to manually editing postfix and other conf files...

https://dhenandi.com/prevent-spam-email-using-ldap-verification-on-proxmox-mail-gateway/

 

[ittk]

https://dhenandi.com/prevent-spam-email-using-ldap-verification-on-proxmox-mail-gateway/

Using this weblink you supplied, this is exactly NOT what is intended, as this is AFTER SMTP-Level --> SMTP Connection, so PMG already accepted the mails and MUST generate the separate NDR! --> Leading to backscatter problem.
PMG itself should directly reject such invalid recipient on SMTP-Level (on SMTP-Protocol-Communication base). and all would be fine, when its reject on SMTP-Level the Source Mailsystem must generate the NDR, no backscatter problem...
PMG using LDAP user sync have already all infos there, but cannot use this data to reject DIRECTLY and by ITSELF on SMTP-Level.

 

[Stoiko Ivanov]

thanks for the links - as far as i understand - they do describe how to configure a transport on exchange which behaves sanely (i.e. not replying with 5xx to an existing mail-address in rcpt to) - in that case you would only need to configure a separate verification transport - that does sound quite elegant

OTOH - if you enable before queue filtering (check https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_before_after_queue) you should get the desired behavior (haven't tested it since the recipient verification works for me as is)

I hope this helps