Convert Default Addresses to :fail:

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
I just posted this to a thread and thought I'd make it available to anyone who wants to run it on their servers. It changes all Default Addresses (i.e. catchall aliases) for all domains on the server to :fail:

Code:
#!/usr/bin/perl
print "Converting all domain Default Accounts to :fail: ...";
opendir (DIR, "/etc/valiases/") or die;
while (my $file = readdir (DIR)) {
	if ($file =~ /^\./) {next}
	open (IN, "</etc/valiases/$file") or die;
	my @data = <IN>;
	close (IN);
	open (OUT, ">/etc/valiases/$file") or die;
	foreach my $line (@data) {
		if ($line =~ /^\*\:/) {
			print OUT "*: :fail:\n";
		} else {
			print OUT $line;
		}
	}
	close (OUT);
}
print "Done!\n";
Use at your own risk. That means, backup /etc/valiases before running it ;)
 

nickn

Well-Known Member
PartnerNOC
Jun 15, 2003
616
1
168
Why would you want :fail:? :fail:'s just a bad idea IMO. :blackhole: is the answer. :)
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Nope, :fail: is definitely the way to go. Here comes my usual answer ;)

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).
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Btw, just to back that up - I did extensive research on the use of :blackhole: and :fail: when I wrote the exim Dictionary Attack ACL over here:
http://www.webumake.com/free/eximdeny.htm

I also used to think that :blackhole: was best until it was pointed out to me that several months ago the ACL's were changed to use verify = recipient at the RCPT stage. So cynical me went and checked it out and found it to be perfectly true ;)
 

dezignguy

Well-Known Member
Sep 26, 2004
533
0
166
Heh, chirpy, this seems to come up about once a week... I see why you have your usual answer saved and handy. heh.
 

mr.wonderful

BANNED
Feb 1, 2004
344
1
166
chirpy said:
Btw, just to back that up - I did extensive research on the use of :blackhole: and :fail: when I wrote the exim Dictionary Attack ACL over here:
http://www.webumake.com/free/eximdeny.htm

I also used to think that :blackhole: was best until it was pointed out to me that several months ago the ACL's were changed to use verify = recipient at the RCPT stage. So cynical me went and checked it out and found it to be perfectly true ;)
I looked at your dictionary attack rules, that you recommended, for exim.conf, and found it quite flawed. Your script however is another story. It works well to ban the ip however it needs to be used properly in exim.conf.

I will email you later, off this site and let you know the much better way to use your perl script with exim.conf
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
mr.wonderful said:
I looked at your dictionary attack rules, that you recommended, for exim.conf, and found it quite flawed. Your script however is another story. It works well to ban the ip however it needs to be used properly in exim.conf.

I will email you later, off this site and let you know the much better way to use your perl script with exim.conf
I wait with baited breath. It works perfectly well for me and all the people I've installed it for and those that have used it themselves. I did do extensive testing with it, using examples provided by the exim developers.

Since you're so highly critical of it, I do hope you will have the decency to post the problems with the implementation here as a matter of urgency, since it is so "flawed".
 
Last edited:

picoyak

Well-Known Member
Jun 10, 2004
72
0
156
FWIW, the dictionary rules are working very well for me. I've noticed that among the bogus recipients there are often some valid ones, so along with reducing load, it's helped ditch a bit of spam.

mr.wonderful said:
I will email you later, off this site and let you know the much better way to use your perl script with exim.conf
Why? Chirpy has been generous enough to share his work with everyone here. If you have some addition, then for cryin' out loud, spit it out! :D
 

Valetia

Well-Known Member
Jun 20, 2002
216
10
168
cPanel Access Level
Root Administrator
chirpy said:
Btw, just to back that up - I did extensive research on the use of :blackhole: and :fail: when I wrote the exim Dictionary Attack ACL over here:
http://www.webumake.com/free/eximdeny.htm
How do you implement this on a secondary (backup MX) mail server?

The current version of the ACL doesn't work on such servers, since they don't even have the valias files on them. Help!
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
You cannot implement it for email being queued on a secondary MX server because the email has not reached its final destination. This can only happen on the primary MX server. It's a limitation you have by imposing an additional hop in the mail delivery route by interrupting the direct SMTP delivery from the source.
 

[email protected]

Well-Known Member
Mar 5, 2002
487
0
316
Los Angeles California
I think you have to add extra detection to the script.

From what I know, this script will also switch the pipings that are required by helpdesk softwares to :fail:
You have to use pregmatch regex to check that the destination is not a php,cgi or a binary.
Hope that helps. :D
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Hi Roy,

I completely agree. It was just thrown togther for those that wanted to splat all their domains, as someone asked for it. So they got it ;)
 

XPerties

Well-Known Member
Apr 10, 2003
401
0
166
New Jersey, USA
You just take this script, place it in a new file on your server and access it to run the script? :confused: :confused: :confused:
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Yes, bascially do this as root on the server:

pico -w defrep.pl
(paste in the script from the thread and exit)

perl defrep.pl

That should be it.
 

chican0

Well-Known Member
Mar 26, 2003
59
0
156
Los Angeles
I would love to use this script but I have been finding that accounts with multiple email accounts (pop3 accounts), start having problems.

The primary problem is that the Main Account, the primary email address which is automaticaly created when the account is created (account username) will no longer accept emails. The system instead returns the following error:

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 10): 550 "The recipient cannot be verified. no such address here"
The only work around I have found is to create a second pop3 mail account and add a forwarder to route mails from the Main Account(username) to the new pop3 account.

This can be unacceptable for a few customers as some of their preferred email address is that of the Main Account which is automatically created by the system during initial account setup.

Does anyone know of a way to fix this problem? To set the Default address to :fail: and still receive emails to the Main email Account?
 

chican0

Well-Known Member
Mar 26, 2003
59
0
156
Los Angeles
That is just freekin awsome!

Thanks Chirpy. Your a definite help.

I do have a couple questions.... I have been searching thie board for that answer for the past hour. Was that little bit of info mentioned in other threads that you know of or is it hardly mentioned at all. I would feel quite helpless if it is in other threads and I just could not manage to find it.

Also, After running your small script... what would be the easiest way to add the required forwarder for the Default Account email address to work on all domains? Or do I need to go into each cPanel and manually add them?

And finally, is this a cPanel or Exim bug? If so, any word or information about it being fixed/patched? I do know it has been an issue for a while as I remember running into this issue sometime back but only used the workaround mentioned in my previous post.

Thanks again for your assistance!
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
1. It's only something that has come to light recently and was posted by rs-freddo hidden in some other threads, so it's easily missed.

2. You will need to add it manually without more scripting. You could also do it directly in the /etc/valiases/*

3. It's a feature ;) Basically, it's an artefact of the way that cPanel has created virtual POP3 accounts together with the exim delivery system works.