• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

SPAM: How can I switch off email-messages by MAILER-DAEMON?

E

editor

Guest
hi,

spam is a big problem in the internet. Spamers are very often
used just to guess an emailadress. Most time, they only know
the domainname and they just try it with the "info"-mailalias
to send spam to this email-adress.

[email protected]

But if a user does not have this email-alias [email protected],
which means, that there is a job for MAILER-DAEMON to report
the sender (the spamer) about the failure mail-delivery, because
the

[email protected]

does not exist. The MAILER-DAEMON will begin to send
following email to the sender:

-------------cut--------------
From: [email protected]
To: [email protected]
Subject: failure notice

Hi. This is the qmail-send program at domainname.tld.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[email protected]>:
This address no longer accepts mail.
-------------cut--------------

Until to this point, it would be ok. Not only the spamers are
informed by such an email of the MAILER-DAEMON, there are
also normal users who will get this email.

The problem is following (see the cut-cut-example before):
If the MAILER-DAEMON will send the email to the sender

[email protected]

which does not exist (because the spamer faked his email-
adress with a non-existing [email protected]),
then the MAILER-DAEMON of Plesk 7.5.x does following:

-------------cut--------------
Subject: failure notice
Date: 24 May 2005 21:03:20 -0000
From: [email protected]
To: [email protected]

Hi. This is the qmail-send program at domainname.tld.
I tried to deliver a bounce message to this address, but the bounce bounced!

<[email protected]>:
65.54.167.5 does not like recipient.
Remote host said: 550 Requested action not taken: mailbox unavailable
Giving up on 65.54.167.5.

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 24571 invoked for bounce); 24 May 2005 21:03:20 -0000
Date: 24 May 2005 21:03:19 -0000
From: [email protected]
To: [email protected]
Subject: failure notice

Hi. This is the qmail-send program at domainname.tld.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[email protected]>:
This address no longer accepts mail.
-------------cut--------------

Or with other words:

The trick with non-existing <[email protected]> to let have
the spamers a easy guessing for sending spams to the

[email protected]

this trick does not work - especially if the spamer will fake
his email-adress with also a non-existing

[email protected]

The final effect is: The <[email protected]> will
then get the spam, namely: The <[email protected]>
will get the email of MAILER-DAEMON.

So, my question is: How can I switch this off within Plesk 7.5.x,
that the MAILER-DAEMON will _not_inform_ the
<[email protected]>? I am not able to kill the
emailadress <[email protected]>.

thank you
 
No answer ?

I would say that prefer that qmail don't accept mails destinated to local users that noneexistent.
 
I thought the latest version of Qmail was supposed to drop connections addressed to nonexistant email users?
 
You can set it to 'drop' by creating a new mail user such as 'blackhole', do not select Mailbox, Redirect, Forward, or anything.

Then set your domain's default action to 'Forward to' this email address (instead of bounce or reject).

In effect this does a 'catchall' to 'blackhole' which does not have a mail repository and therefore emails addressed to non-existent users are sent to 'blackhole' and they end up in a bit bucket.
 
I have been meaning to inform the forum of the following for a few days, but keep forgetting.

I recently moved from a VPS running Plesk 6.0.2 (Linux) to a dedicated server running 7.5.3. I have successfully used the black hole trick (mailbox off and no redirect, mail group, or autoresponder) for years. Every once in a while, I turn the mailbox back on just to see what is flowing into the black hole. To my surprise, I found a ton of redirected mail in there. It appears that on 7.5.3, the mail is not dropped into the bit bucket, but is actually saved on the server. This trick definitely worked in 6.0.2. I jumped right to 7.5.3, so I don't know what happens with interim releases.

Could someone please confirm this behavior in 7.5.3 (Linux).

Thanks.

John
 
Verified working ok on RH9/Plesk 7.5.3

I just turned my blackhole mailbox on and it does not show any old messages, but I know from the logs that there are many many 100's - 1000's - 10K's? sent into it.

Also just noticed that I did not mention that I also (just because I'm anal) set the mailbox quota limit to 0Kb instead of unlimited (even though it's not checkmarked as a mailbox).
(Just verified another server, that blackhole has unlimited quota, but still does not show any emails when I turn it's mailbox to on.)

You may want to verify the contents of your

/var/qmail/mailnames/domain.com/blackhole/.qmail

It should show:

[root@ns2 blackhole]# cat .qmail
| true
 
Maybe missing something obvious here, but why do people simply not use the new "Reject" option in the mail preferences on Plesk 7.5.3?

Surely rejecting it prior to reaching the mailname is a better option.
 
Mikk, the only answer I have for myself is that 'old habits die hard', but you are correct, the Reject option is *supposed* to do rejection at the SMTP level, with all the other problems reported, I personally never even tested to see if that feature worked or not since I had a tried and true method for doing it.
 
Fair enuf - i actually use the other method as at this time running mainly 7.1.x based servers which sadly doesnt have it.

This method however can still cause issues with huge mailqueues at times and huge maillogs, my understanding is that the reject option will stop this from happening, so queues wont be clogged with mails simply being sent to null
 
True about the logs and performance hit, on very busy servers it would make a difference, but with the blackhole option, at least you can run a stats script and get some counts of how many were blackholed (for those admins who just have to know those things). I don't believe you can get any stats from using the Reject option.
 
You can do either of the methods discussed here. Either turn on the Reject option (Domains - Mail - Preferences), or setup the blackhole mail user as described above.

I am assuming your problem is related to bounced messages causing MAILER-DAEMON delivery failure emails.

The above methods will prevent spam bounces from going out of your server and coming back due to forged From or Reply-to addresses used by spammers.
 
The problem we seem to have with simply bouncing all these messages is that we have some customers who reply to the over quota messages sent to them which go to this default address also. So we would be missing all these emails.

Can we send the email bounces to a different address to the overquota messages from Plesk. Or have we possibly got things misconfigured here?
 
You can create the file:
/var/qmail/control/bounceto
put a single line with a valid email address. This will tell Qmail where to send bounces.

Also in the Plesk CP, Domains, Mail, Preferences, if you don't want to Bounce or Reject, you can specify a forwarding email address (this will affect email to non-existent users).

Note: I almost didn't remember this topic, I only briefly skimmed it as a refresher.
 
wow, am I getting senile? You are correct. 'bounceto' is not a defined standard qmail control file. Of course, that may be from some add-on script in the past.

Thanks for catching that!
 
Also the first line of the doublebounceto file should be a blank line followed by the email address, so I have read.
 
Back
Top