SpamBlocker 4.3.0, BlockCracking, Easy Spam Figther, and new exim.pl

Have you checked the exim logs?
Code: 
/var/log/exim/mainlog
/var/log/exim/rejectlog
/var/log/exim/paniclog
I've just tested a simple pipe to file through php, and it did work for me. (SB 4.3.3, SA, ESF, BC)

Perhaps a path is blocked in your case, using a newer SB feature, which should have something about it in the mainlog.

John
 
I've got a pipe running for my ticket system, which is running now on the newest exim also. Running without any issues on Exim conf 4.3.0 alpha 3.
 
DirectAdmin Support said:
Have you checked the exim logs?
Code: 
/var/log/exim/mainlog
/var/log/exim/rejectlog
/var/log/exim/paniclog
I've just tested a simple pipe to file through php, and it did work for me. (SB 4.3.3, SA, ESF, BC)

Perhaps a path is blocked in your case, using a newer SB feature, which should have something about it in the mainlog.

John
Click to expand...

I have posted the exim mainlog in my previous post. There is nothing in the other logs.

Do you use cloudlinux with cagefs too? Something in 4.3 is blocking cagfefs because 4.2 works just fine.
 
RayManZ, please check if the following solves your problem:
Code: 
mv /etc/exim.cagefs.pipe.conf /etc/exim.cagefs.pipe.conf.moved

If it does, I would recommend contacting CloudLinux support for that.
 
/etc/virtual/blacklist_username
Must contain a DA Username, eg "fred" followed by the unix time it was added, eg:
fred:1409557166

How to find the unix time?

Thank you.
 
This should give you a reliable time that the user was created. You can then convert it to unix time HERE.
Code: 
ls -ld --full-time /home/USERNAME/
 
Today we had a situation that a script was blocked by Directadmin because it was spamming.
For this script, this -was- correct behaviour, so I'm glad DA blocked the script.

But I think there is a bug in there. The user got this mail via the message system:
Some script below the path /home/customer/domains/customerdomain.com/public_html/wp-admin/css/colors/sunrise has just finished sending 100 non-existant emails within a 1h period, and any script in this path is now blocked.
There could be a spammer, the script could be compromised, or just sending more emails than usual.

To unblock this path, go to:
User Level -> E-Mail Accounts -> E-Mail Usage

or manually remove the path from the file:
/var/spool/exim/blocked_script_paths

DirectAdmin has matched the following PHP script:line below the suspect path, with the number of deliveries:
/home/customer/domains/customerdomain.com/public_html/wp-admin/css/colors/sunrise/view.php(1478) : eval()'d code:278 sent 270

This warning was triggered by the BlockCracking monitoring tool in exim.
The script path is managed under the customer User account.

================================
Automated Message Generated by DirectAdmin
Click to expand...

This should be send to the admin email or something. This was just a user account, no reseller account.
So the user has no access to any of the options mentioned in this email or at least not at the /var/spool/exim option.:)

A better way of handling would be the presence of 2 different email templates.
1.) Email to the user, kind of like this, but only stating that (and which) script was stopped and the reason.
2.) Exactly this email, but in that case send to the email address stated in the admin and/or reseller section of the message system.

This way not only the customer, but also admin and/or his reseller knows what is going on and how to fix it.
 
Hi

I understand that if I would like to add some variables then I have to add in exim.variables.conf.

How I could change this
Code: 
#EDIT#23:
# SSL/TLS cert and key
tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key
openssl_options = +no_sslv2 +no_sslv3
tls_require_ciphers = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
tls_advertise_hosts = *
#auth_over_tls_hosts = *
auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

for this

Code: 
#EDIT#23:
# SSL/TLS cert and key
tls_certificate = ${lookup{$received_ip_address}lsearch{/etc/ssl-cert.map}}
tls_privatekey = ${lookup{$received_ip_address}lsearch{/etc/ssl-key.map}}

#tls_certificate = /etc/exim.cert
#tls_privatekey = /etc/exim.key
openssl_options = +no_sslv2 +no_sslv3
tls_require_ciphers = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
tls_advertise_hosts = *
#auth_over_tls_hosts = *
auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

I need comment tls_certificate and use mine.

I understand that if I upgrade via custombuild exim.conf then original exim.conf will be replaced, so feature with separated file variables is great idea.
 
Yes. Some clients want use own certificate to connect e-mail client with server. It will be very useful to manage by Directadmin panel in one place. No I had to modify exim.conf and dovecot.conf
Also before 1.47 version of Directadmin I had to use another variable to use outbound email IP.
So, how I could resolve?
 
Last edited:
remikk said:
Yes. Some clients want use own certificate to connect e-mail client with server. It will be very useful to manage by Directadmin panel in one place. No I had to modify exim.conf and dovecot.conf
Also before 1.47 version of Directadmin I had to use another variable to use outbound email IP.
So, how I could resolve?
Click to expand...

To use per-domain SSL certs in dovecot, you can customize the files and add them to /usr/local/directadmin/custombuild/custom/dovecot/conf. It should look something like:
Code: 
local_name mail.example.org {
  ssl_cert = </etc/ssl/certs/mail.example.org.crt
  ssl_key = </etc/ssl/private/mail.example.org.key
}


local_name mail.example2.org {
  ssl_cert = </etc/ssl/certs/mail.example2.org.crt
  ssl_key = </etc/ssl/private/mail.example2.org.key
}

For exim, something like the following would do the trick:
Code: 
tls_privatekey = ${if exists{/etc/exim.key.${tls_sni}}{/etc/exim.key.${tls_sni}}{/etc/exim.key}}
tls_certificate = ${if exists{/etc/exim.cert.${tls_sni}}{/etc/exim.cert.${tls_sni}}{/etc/exim.cert}}

That way it would take /etc/exim.key.domain.com and /etc/exim.cert.domain.com if they exist, and if they do not, /etc/exim.key & /etc/exim.cert would be used.

That sounds like a great feature request for DA :)
 
The $(tls_sni) variable woulndt work somehow in dovecot too (maybe on dovecot is different) to automatize it?

I do agree that would be a pretty nice feature

Regards
 
Actually I get a lot of requests for this from my clients. It would be awesome if this would be integrated in DA.
 
For dovecot I use in /etc/dovecot/dovecot.conf
I didn't know that I can use in another path custom dovecot. I will try modify.
So can I add custom exim.conf in /usr/local/directadmin/custom and then /etc/exim.conf settings will be overwrite? Now my settings are in /etc/exim.conf but I understand if I upgrade to new version exim.conf then will be ovewrite.

Yes it will be great feature. Then I will not must create manually for each user. I use it from about 3 years.
 
Last edited:
Richard G said:
Today we had a situation that a script was blocked by Directadmin because it was spamming.
For this script, this -was- correct behaviour, so I'm glad DA blocked the script.

But I think there is a bug in there. The user got this mail via the message system:


This should be send to the admin email or something. This was just a user account, no reseller account.
So the user has no access to any of the options mentioned in this email or at least not at the /var/spool/exim option.:)

A better way of handling would be the presence of 2 different email templates.
1.) Email to the user, kind of like this, but only stating that (and which) script was stopped and the reason.
2.) Exactly this email, but in that case send to the email address stated in the admin and/or reseller section of the message system.

This way not only the customer, but also admin and/or his reseller knows what is going on and how to fix it.
Click to expand...

Thanks for the report.
I've confirmed the Admin notice was based on the per-email limit, rather than just the normal limit.
Added this fix:
https://www.directadmin.com/features.php?id=1744

As for the Reseller, they should have been notified (aka, "admin" in this case), based on this option:
notify_reseller_on_mass_emailing=1

and then the User gets the notice too, if this is set:
notify_user_on_mass_emailing=1

and all 3 require:
notify_on_mass_emailing=1

So double check that the reseller setting is enabled.

I'm uploading the changed pre-release binaries now, in anyone wants the id=1744 fix.

John
 
Thank you for fixing it!
But I can't find these settings in directadmin.conf, exim.conf or any of the /etc/exim.blockcracking configuration files.
Where can I check these settings?
 
Those settings are for directadmin.conf , if they are missing there, the default value will be used by DA itself, if you add them, you can manage them :)

Regards
 
Correct, that's the global on/off switch for all of them, and is what decides if notification parsing should even be started.

On an unrelated note, I believe I've found an important variable that may be causing issues.
The exim.variables.conf variable queue_only_load may be bypassing the ACLs if the load is high enough.
I've changed the default to a much higher value, aka 100, but if needed, we'll completely remove it if we can confirm it as being the cause of the "queue filling up" issue.
I did just finish up on server where this was a complaint, and the load average regularly spiking above 10 (due to disk I/O), but that was a side-issue, but above the queue_only_load limit.

John
 
You must log in or register to reply here.
Back
Top