hundreds of NDRs

ron

Member
Oct 31, 2006
38
0
6
Hi all,
it seems someone decided to use one of our corporate info Email addresses for sending SPAM. as a result, this mailbox receives hundreds of NDRs every single day. is there a way to stop this flood of unwanted mail?
 

Attachments

  • Capture.jpg
    Capture.jpg
    104.6 KB · Views: 38
Backscatter detection

To detect misdirected bounces Proxmox needs a list of MTA relays that your outbound mail is delivered through. The parameter is called:

whitelist_bounce_relays hostname [hostname2 ...]

This is used to 'rescue' legitimate bounce messages that were generated in response to mail you really *did* send. List the MTA relays that your outbound mail is delivered through. If a bounce message is found, and it contains one of these hostnames in a 'Received' header, it will not be marked as a blowback virus-bounce.

The hostnames can be file-glob-style patterns, so "relay*.isp.com" will work. Specifically, "*" and "?" are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons.

Multiple addresses per line, separated by spaces, is OK.
Multiple "whitelist_bounce_relays" lines are also OK.

Please set that parameter in /etc/mail/spamassassin/custom.cf

Proxmox/SA cassifies bounces into the following classes:

BOUNCE_MESSAGE: an MTA-generated bounce from a non-whitelisted relay, "message was undeliverable" etc.

CRBOUNCE_MESSAGE: Challenge-response bounce message from a non-whitelisted relay, eg. "please confirm your message was not spam"

VBOUNCE_MESSAGE: a virus-scanner-generated bounce from a non-whitelisted relay, e.g. "You sent a virus"

ANY_BOUNCE_MESSAGE: any of the *BOUNCE_MESSAGE types above will also trigger this

You can set a score for each class (default is 0.1, which is very low).

So for example, you custom.cf file can look like:

Code:
whitelist_bounce_relays proxmox.yourdomain.com mail1.yourisp.com
score ANY_BOUNCE_MESSAGE 5

Plese tell me if that works for you. Just ask if you need further information.

- Dietmar
 
Hi Dietmar, thank you for your reply

Let me see if I get it right: in my case, I have only one MTA (my Proxmox) which delivers mail directly to recipients' servers using DNS (I don't use my ISP's relay). so I just need to add the lines:

whitelist_bounce_relays mail.my-domain.com
score ANY_BOUNCE_MESSAGE 5

to my /etc/mail/spamassassin/custom.cf? (this file does not exist, do I need to create it so it will contain only the two lines above?)

:cool:



 
yes, you are right. Just create the file if it does not exists.

I guess you also need to restart the filter after that:

> /etc/init.d/proxprox restart

- Dietmar
 
I just tested it, and it works like a charm!

Is there a way to delete these NDRs altogether instead of quarantining them?
 
Yes, I do

I don't use greylisting though, because of user complaints about long delivery time.

I just took a look at the quarantine of this specific mailbox and there are thousands of NDRs quarantined. I wonder how a few hundreds still managed to find their way to the inbox.
 
I don't use greylisting though, because of user complaints about long delivery time.

The question was if you are using SPF? If you publish an SFP Record other MTAs can check if somebody else forges your email address.

I just took a look at the quarantine of this specific mailbox and there are thousands of NDRs quarantined. I wonder how a few hundreds still managed to find their way to the inbox.

Don't understand your question? Does the previous suggestions works? Please can you give me more info.

- Dietmar
 
Hi,

We have the same problem, but less luck finding the right configuration to solve it.

We receive thousands of backscatter bounces everyday from spam forged as if it was sent from one of our few domains. It would be very desirable to dump or block these messages before they are forwarded to an email server hosting our user accounts that must archive everything. The settings for Spam Detector Configuration, Backscatter, Bounce message score is set to 5 and the valid whitelist bounce relays are entered. For good measure the /etc/mail/spamassassin/custom.cf also has the lines:

whitelist_bounce_relays our_relays_separated_by_a_space
score ANY_BOUNCE_MESSAGE 5

The setting were saved and the server rebooted. There seems to be no effect on the amount of these backscatter bounces. We also use SPF. Perhaps I missed a step or concept.

Our mail gateway filters out the spam and then relays to another email server hosting all of the users. If a Proxmox mail gateway rule could be created to block all email for users who are "not" listed in a Who Object filled with our users/aliases, perhaps this would solve the problem. Does this sound right? If yes, is there a way create a rule using a "not" condition to block email for anyone not in a Who Object?

Thanks,
Jeff
 
Using verify receivers sounds good. My internal email server is qmail on FreeBSD. Perhaps qmail is configured to reject unknown users by default as seems to be required as discussed in the Deployment Guide for Exchange. Before I test, hopefully you might have a suggestion how I might fix another small problem I must've created while attempting to address this issue. My internal email server is all of the sudden saying the postmaster account on my Proxmox mail gateway is not there or not available.

log entry from internal qmail/FreeBSD server:
Jul 21 16:14:11 mailgate qmail: 1248218051.462422 delivery 11055679: deferral: 205.155.240.3_does_not_like_recipient./Remote_host_said:_450_4.7.1_<postmaster@vegas.bb.slv.k12.ca.us>:_Recipient_address_rej
ected:_Service_is_unavailable_(try_later)/Giving_up_on_205.155.240.3./

Here's the current aliases file:

vegas:/etc# more /etc/aliases
postmaster: root
mailer-daemon: postmaster
nobody: root
hostmaster: root
webmaster: root
www: root
security: root
clamav: root
noc: root

Thanks,
Jeff
 
log entry from internal qmail/FreeBSD server:
Jul 21 16:14:11 mailgate qmail: 1248218051.462422 delivery 11055679: deferral: 205.155.240.3_does_not_like_recipient./Remote_host_said:_450_4.7.1_<postmaster@vegas.bb.slv.k12.ca.us>:_Recipient_address_rej
ected:_Service_is_unavailable_(try_later)/Giving_up_on_205.155.240.3./

The "(try_later) indicated that the message is 'greylisted'. I assume you are connecting on the wrong (external) port. You need to connect on the internal port (default is port 26) instead.

- Dietmar
 

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!