Backscatter issue with domain aliases (failure notice) workaround.

[huck]

This may be elsewhere on the forums,and I know it was discussed when people were patching qmail in earlier plesk versions. But here is a synopsis of an issue we've been looking to resolve and a temporary workaround.

Plesk 8 does implement recipient checking via chkrcptto. However, domain aliases are not added to the rejectnonexist file.

As a result, dictionary attacks and spoof reply-to's sent to unknown users will generate a bounce.

Spamcop now treats backscatter as spam, and we've seen several people listed after either a dictionary attacks or large volumes of spam with spoofed header information.



Workaround
=========================================
You can add the aliased domain to the rejectnonexist file in /var/qmail/control but this will fail because the virtual domain does not exist in the mailnames directory.

Right now, we've created a symlink from the virtual domain name to the real domain name within the /var/qmail/mailnames folder.

This allows the chkrcptto to verify the user.

The chkrcptto plugin will have to be re-coded to allow checking of domain aliases.




I knew there was a hole in this somewhere after setting all domains to reject email and still seeing 1000's of failure notices in the mail queue.

Locals Issue
------
I've seen a few post where people add something like drop or devnull to the doublebounceto control file. In some limited testing, we found that this will fail unless you add the server's hostname to the locals control file.

 

[Who-m3]

The problem you're outlining is a bit confusing. Let me clarify a bit.

When creating a Domain Alias, you have the option of Aliasing e-mail. When doing this, the domain is added to rcpthosts and to the virtualdomains list. (Note, if you cat your /var/qmail/control/virtualdomains, you'll see a number referencing each specific domain group.). The domain alias should have the same number as the domain it's aliasing.. I.e. domain1.com:1 domainalias1.com:1... This would handle the chkrcptto properly.

The problem you're describing seems as though you're wanting the option to reject nonexistant users on the domain. If this is the case, referencing a previous post I made at http://forum.plesk.com/showthread.php?s=&threadid=35197, which describes similar issues with Domain Aliasing, you'll notice a fix for this..

Ref: http://forum.plesk.com/showthread.php?s=&threadid=35197

Second, you give us options on the primary domain to "Bounce", "Reject", or use a "Catch-All" address for e-mail to the domain. Yet with Domain Aliases, we don't have this option. We have no options. With a domain that's previously been used by a client (frequently, or if at all), but suddenly they move to a new domain, that leaves some issues. Example: One client switches to Domain2.Com, Domain1.Com is a Domain Alias. They don't want to receive e-mail from certain accounts on that domain, but want other e-mail to come through. They create the accounts on Domain2.Com that they want, set up Mail and Domain aliases. All of the rest...bounce to the originator (or in this case, no where, since it was a majority of spam, meaning it comes right back to my inbox..)
...
2. Give us the option to modify, or mirror the settings from the primary domain for the Domain Alias's Mail Config. If "Bounce" is selected, let it bounce. If "Reject" is selected, add the domain to the list in /var/qmail/control/rejectnonexist so that it'll reject instead of bounce. If Catch-All, set up the Catch-All address on it. But please give us a way to manage it properly.

Adding the domain to the /var/qmail/control/rejectnonexist will secure qmail against the dictionary attacks you're concerned about.

Hope this helps,

-John

 

[huck]

I will re-phrase to make this clearer:

Plesk 8 does not add email domain aliases to the Qmail control file rejectnonexist.

If a domain is not in rejectnonexist, the chkrcptto plugin does not get invoked. As a result, email sent to unknown users will generate a NDR.

If you simply add the email domain alias to the rejectnonexist, you will get an error when sending email to that domain.

For example, a mail session in which you try to send an email to an unknown user at a main and aliased domain:

220 mail.domain.com ESMTP
helo senderdomain.com
250 mail.domain.com
mail
250 ok
RCPT TO: [email][email protected][/email]
550 sorry, no mailbox here by that name. (#5.7.17)
RCPT TO: [email][email protected][/email]
250 ok

The email to the aliased domain gets accepted, and a NDR will be sent.


If you simply add the aliased domain to the rejectnonexist control file, you will get an error:

MAIL
250 ok
RCPT TO: [email][email protected][/email]       
421 opendir() failed (#5.7.15) No such file or directory
Connection closed by foreign host.

So if you simply add the domain to the control file, you will not be able to send email to a real user at the aliased domain. This is because the chkrcptto uses entries in the mailnames directory for verfication. By creating a symlink from the aliased domain to the real domain with the mailnames directory, you can then have this function as it should.

 

[Kevin Troendle]

Fowarded email to nonexistent user flaw or bug causes backscatter

If an email is fowarded ot nonexistent user the email is NOT rejected
as it should see below, this must a bug or overlooked case

The email address [email protected] is set up to REJECT email.
I have tested this and it does not matter whether the email being fowared to is an alias
or has physical hosting.

Hi. This is the qmail-send program at firedrumhosting.com.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. --- Below this line is a copy of the message. Return-Path: <[email protected]>Received: (qmail 14280 invoked by uid 110); 31 Aug 2009 13:35:15 -0700Delivered-To: [email protected]eived: (qmail 14273 invoked from network); 31 Aug 2009 13:35:15 -0700Received-SPF: pass (firedrumhosting.com: domain of hotmail.com designates 65.55.90.223 as permitted sender) client-ip=65.55.90.223; [email protected]; helo=snt0-omc4-s20.snt0.hotmail.com;Received: from snt0-omc4-s20.snt0.hotmail.com (65.55.90.223)by firedrum.com with SMTP; 31 Aug 2009 13:35:15 -0700Received: from SNT105-W4 ([65.55.90.199]) by snt0-omc4-s20.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);Mon, 31 Aug 2009 13:30:14 -0700Message-ID: <[email protected]>Return-Path: [email protected]tent-Type: multipart/alternative;boundary="_f4317213-ab31-4780-b941-d7a0f6e0c2bf_"X-Originating-IP: [24.249.173.13]From: Kevin Troendle <[email protected]>To: <[email protected]>Subject: teestDate: Mon, 31 Aug 2009 13:30:14 -0700Importance: NormalMIME-Version: 1.0X-OriginalArrivalTime: 31 Aug 2009 20:30:14.0167 (UTC) FILETIME=[D84ACA70:01CA2A79] --_f4317213-ab31-4780-b941-d7a0f6e0c2bf_Content-Type: text/plain; charset="Windows-1252"Content-Transfer-Encoding: quoted-printable