One of the worst problems in qmail is that it accepts messages for non existent users and then sends back a bounce to the sender. This is the perfect setup to be exploited by a spammer. I'm using the qmail-tls port configured with vpopmail on FreeBSD.
There might be some patches that make qmail use the vpopmail command line tools directly to check if a user exists before accepting messages but I either didn't find them or thought that using the SMTP Plugins patch is more elegant and gives me more flexibility (It might be slower but this was not a high traffic server so I didn't care).
The SMTP plugins patch adds hooks at all STMP stages and the plugins can use those hooks to accept or reject a message based on the data in the smtp statements sent by the sender.
I used the Qmail-SPP - Vpopmail check user Script written by Werner Maier.
The only problem was that I had to patch the source code for qmail-tls with the qmail-spp patch and there were quite a few rejects because of the other patches applied by freebsd ports system.
I managed to adapt the code to make this patch work and here is how I did it...
First I built the original freebsd port:
This will also install the files and then after we apply the spp plugin we just copy the modified file ( qmail-smtpd )
Next step if to download the qmail-spp plugin into /usr/ports/mail/qmail-tls/work and apply it.
This will give you some rejects but don't worry because you'll fix them with my next patch : [download id="10"]
At this point qmail-smtpd should have smtp plugins working and we can set up the vpopmail user verifier script.
Now edit vpopmail_check_recipient.sh and make sure the correct paths to vpopmail directory ( /home/vpopmail on freebsd ) are set in the script.
To test it, connect to smtp and try to send a message to an nonexistent account, you should see a reject message instead of the usual "ok".
I had to learn this the hard way. It seems in php 27.64 is just not quite 27.64 , but something close to it ( that's what some people say here anyway: http://www.php.net/ternary ) .
And that's why the following code wouldn't echo the text "dude" as you might think it should:
span style="color: #ff0000;">"amountdue: $amountdue, amount: $amount\n""dude\n""but still no match\n"
Run this script and you should see:
amountdue: 27.64, amount: 27.64
but still no match
That's the dumbest thing I've ever seen. A similar code written in C gives the good results. Isn't php written in C? They should have copied C's good behavior.
If conversion from float to string gives the right results, why not use the same results when comparing float values?
So if you're having this problem it seems this will work:
The fact that php can't compare float values reliably and that you have to resort to this to make it work just makes php look bad.