Disabling catch-all add for current accounts on a Cpanel server

[Pollie]

Hello

Recent WHM versions have a very nice tweak settings item which permits us to disable the catch-all address on localuser for every *new* account; a handy tool against spam which saves a lot of /home room too as it washes stuck, forgotten and stuffed /home/localuser/mail/inboxes which otherwise would stay put.

However :blackhole: turned on on localusers through WHM tweak settings will not affect *current* accounts. Too bad.

Do some of you happen to know a way to mass-disabling this feature on an entire server? Notice please that when catch-all is enabled for a server, Cpanel assigns localuser as catch-all not only to the main domain but also to every subdomain on the server: namely, this feature will multiply the number of catch-all localusers per the number of localdomains, not per the number of localusers. It means that there should be plenty of occurrences of something like $localuser to be replaced by :blackhole: if we try to write some script to run over the server instead of -- this chills my back -- asking clients to kindly disable this themselves (no way, no use, most of them will not even know what we're talking about) or have it *manually* disabled for each localdomain for each cpanel, over some thousands of users... that would be a real killer.

Any hint will be highly appreciated.

Thank you in advance,

Paula

[lloyd_tennison]

See Cjirpy's script at this thread:

http://forums.cpanel.net/showthread.php?t=30987&highlight=Converting+domain+Default+Accounts+%3Afail

That will do the trick.

[Pollie]

Hello,

Interesting thread, thank you so much for helping.

For me, surrendering :blackhole: to :fail: is a brand new concept. I always thought :fail: increases SMTP traffic as flowing the bounced messages. I actually receive plenty of NDR when I have :fail: turned on. Did I miss something in his explanation?

Thank you again,

Paula

[lloyd_tennison]

As I understand it, and see for myself, a properly configured mail server does not attempt to resend the message if yoiu have it set to fail. Blackhole accepts the messsage, processess it, etc - all more overhead.

[chirpy]

That's about right. Here it is

It's been accepted now that since the use of verify = recipient in exim.conf that it is definitely best to use :fail: now.

The reasons are:

1. :blackhole: accepts the email and receives it, then sends it to /dev/null. This wastes your bandwidth and actually breaks the SMTP RFC because you're not notifying the sender that the email is undelivered.

2. :fail: stops the email from being received, because verify = recipient occurs at the RCPT phase of the SMTP exchange before any data has been received. No bounce is sent, the exchange simply termintates with an SMTP error code. This means much less processing resources on your SMTP server, much less bandwidth (you don't actually receive the email) and you maintain RFC compliance by notifying the senders SMTP server that the delivery failed (which spammers ignore and real people appreciate if they've made an addressing mistake).

Then just add my free exim dictionary attack ACL and you'll stop a whole bunch of spam:
http://www.configserver.com/free/eximdeny.html

[maxbia]

Chirpy just reading cpanel docs there and in "Setting your default e-mail address" it says..

Note: You can enter :blackhole: to throw away all incoming mail, or :fail: no such address here to bounce the e-mail back to the sender.

Is that not the complete opposite of what you say above ?

Which one will delete email and save resources and the mail queue from filling up ?

[PWSowner]

I think the cpanel docs are a little behind. They usually are. It's hard to keep docs up to date for something that is always changing.

[chirpy]

That are out of date, though they are saying a similar thing. :blackhole: accepts incoming email, processes it through all your filters, egts to the end and then throws it into /dev/null - a waste of resources. The bit that is our of date is that :fail: does not "bounce" email, it rejects the SMTP connection at the RCPT stage informing the sending MTA that the SMTP transaction has failed - the sending MTA will then usually send a bounce back to the originator, but your server does not send a bounce message itself.

[joehark]

you maintain RFC compliance by notifying the senders SMTP server that the delivery failed (which spammers ignore and real people appreciate if they've made an addressing mistake).

Hmmm - very interesting and a bit of a mind strecther for us less knowledgeables - but the issue I'm still concerned about is that notification to the "sender's SMTP."

Spammers don't use real return addresses. In that case, wouldn't sending a notice to the orininal but phony source create a message back to me saying "undeliverable?' Multiply this times a few thousand an hour and, to re-apply a commment from the late Senator Dirkeson of Illinois regarding "giveornment" budgets, "A million here; a million there. Pretty soon, you are talking about real money."

That's undeliverable notification is the worst part of spam flood attacks. The original flood is bad enough but sending a notice back to a phony address only generates a second wave of the attack, right?

Or am I (as usual) missing something?


Oh, and after reading the footnote about the dictionary attack script, I think I'm gonna be learning (and having a headache again) over soenthing I really must master. Much appreciated. I experienced those attacks and welcome tools to resist them.

Regards, Joe

[chirpy]

Hi Joe. You would be perfectly correct, but...

This is what happens during the SMTP conversation:

1. Some other SMTP server (MTA) connects to your server on port 25 and initiates an SMTP connection (EHLO command)

2. Other server then sends a message saying who they're delivering a message for (MAIL FROM command)

3. Other server then sends who the message is for on your server (RCPT command)

At this point your server then checks whether the email address in the RCPT command can actually be delivered on your server. If you do not have a catchall alias configured to point to an email address (Default Address) and you have it set to :fail: the following happens:

4. Your server sends back along the same connection to the sending server "Go away, no-one here" (the DENY command)

5. The sender server would then normally tell their user that the attempt to email your server failed. Your server does not send a "bounce" message. So far as your server is concerned, all that has happened is a little SMTP chatter and no email has been received and no bounce sent.

With the dictionary attack ACL, the following also happens:

6. If the sender server tries 4 email addresses that don't exist on my server I'm going to disconnect you (DROP the connection) and put your nasty IP address in a file.

7. Senders SMTP server connects again, your server says "Oi! I've already told you to piss off!" and instantly drops the connection, foiling the potential spammer.

OK, I got a little carried away at the end - but that is what happens.

[joehark]

With the dictionary attack ACL, the following also happens:

6. If the sender server tries 4 email addresses that don't exist on my server I'm going to disconnect you (DROP the connection) and put your nasty IP address in a file.

7. Senders SMTP server connects again, your server says "Oi! I've already told you to piss off!" and instantly drops the connection, foiling the potential spammer.

OK, I got a little carried away at the end - but that is what happens.

Oh, I like that. I LIKE that.

Now could we also send a small package, for next day delivery, via FedEx, to the real source computer? If so, as soon as those famously elusive WMDs are found, I'd like to put them to good use.

[chirpy]

I'll see if I can get that into v2

[Website Rob]

Chirpy, my compliments on an excellent method for cutting down on Spam and waste of Server resources, and well written documentation.

May I suggest something to really make this a kick-ass potent script?

Those of us using RBL will find that eMails are first checked against the RBLs and then, checked for setup on the Server. For this reason there are some dictionary attack IPs not being listed.

Is it possible to incorporate your preventive dictionary attack method so that it runs "before" the RBL checking?

[lloyd_tennison]

I have mine setup that way and it works fine.

#!!# ACL that is used after the RCPT command
check_recipient:

  # Exim 3 had no checking on -bs messages, so for compatibility
  # we accept if the source is local SMTP (i.e. not over TCP/IP).
  # We do this by testing for an empty sending host field.
  # colon added to next line from new config
  accept  hosts = :

# Added Lft per http://www.webumake.com/free/eximdeny.htm
    drop hosts = /etc/exim_deny
        message = Connection denied after dictionary attack
        log_message = Connection denied from $sender_host_address after dictionary attack


    drop message = Appears to be a dictionary attack
        log_message = Dictionary attack (after $rcpt_fail_count failures)
        condition = ${if > {${eval:$rcpt_fail_count}}{3}{yes}{no}}
        condition = ${run{/etc/exim_deny.pl $sender_host_address }{yes}{no}}
        !verify = recipient
# End Add

#*# Added by LFT
#**# DNSBL List Begin
#**#
#
# Always accept mail to postmaster & abuse for any local domain
#
accept domains = +local_domains
local_parts = postmaster:abuse



# Check sending hosts against DNS black lists.
# Reject message if address listed in blacklist.
deny message = Message rejected because $sender_fullhost \
is blacklisted at $dnslist_domain see $dnslist_text
!hosts = +relay_hosts
!authenticated = *
dnslists = combined.njabl.org : \ , etc.