Blocking a TO address

Submitted by rjrsinc on Wed, 06/06/2012 - 11:05 Pro Licensee

Is there a way to reject any email sent to a specific email address? It is not an email address in our system.

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Wed, 06/06/2012 - 13:34

Just to verify what you're asking -- it sounds like you're saying that you would like to block access to a particular email address at a remote server?

So anyone on your server who sends an email to that address would receive some sort of rejection message?

Submitted by rjrsinc on Wed, 06/06/2012 - 13:42 Pro Licensee

Correct. For some reason, the mailq gets a backlog of email rejections sent from a spammer that is trying to deliver the email to a yahoo account.

Here is one of them:

info@shrogspide.com elizabethpeck@yahoo.com 9.22 kB host mta7.am0.yahoodns.net[98.139.175.224] said: 451 mta1023.mail.bf1.yahoo.com Resources temporarily unavailable. Please try again later [#4.16.1]. (in reply to end of DATA command)

Submitted by andreychek on Wed, 06/06/2012 - 14:13

Well, Postfix provides a somewhat complex rule system that would allow you to do that. You can't do it via Virtualmin, but you could do it manually. You would need to make a "smtpd_recipient_restrictions" section within your Postfix config in /etc/postfix/main.cf, and then setup a restrictions file using "check_recipient_access". I don't have an example of that, though they're out there on Google.

However, that's not really what I'd recommend.

The issue you're seeing is likely because a malicious user is sending spam via your server -- and it'd be more ideal to close down the hole that's allowing someone to use your server for spamming.

If they can spam that one address, there's no reason that they couldn't be sending spam to a number of other addresses right now.

The key is to review the email headers for the spam in your mail queue, and to use those headers to determine how the email is getting there.

You should be able to determine what account the email is being generated from. Usually, spam is sent via a vulnerable web application. So once you determine the account responsible for the spam, you'd need to review the web apps running within their account, and determine the source of the breakin.

It's also possible that that user's password was compromised, meaning that they're sending the spam remotely using an email client, rather than from a web app on your server.

But the email headers can assist you in determining that.