Facebook
Twitter
atomicturtle
Golden Pleskian
Yes, it just drops right in on a PSA or Project Gamera box. No additional configuration needed.
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
N
netdias
Guest
Has usually ART is fast on an answer 
Thanks again and again
Thanks again and again
F
faris
Guest
For the sake of simplicty I tried Scot's qreylist and although it worked brilliantly and is "compatible" with smtp_auth is does still apply greylisting to smtp_auth which means people using our servers to send email will experience problems.
So now I want to have a go with the more complex version that this thread is mostly about.
But I'm confused (as usual)
I can see the very clear how-to, but I also see that there is an issue in that the original code did not have the Plesk patches related to rejecting email for non-existant mailboxes, which we absolutely need.
I also see that R'twick very kindly applied the necessary patch to the code and this works with Centos 3.3 and possibly others.
Has anyone used the R'twick modified code on RH9 with 7.5.4 by any chance?
Also, what is the third file for? The psa-greylist.patch and qmail-1.03-psa-published-greylist ones are explained in the notes, but I can't see what the qmail-psa-greylist-spf-mailqueue one is for?
Any pointers and advice would be appreciated.
Faris.
So now I want to have a go with the more complex version that this thread is mostly about.
But I'm confused (as usual)
I can see the very clear how-to, but I also see that there is an issue in that the original code did not have the Plesk patches related to rejecting email for non-existant mailboxes, which we absolutely need.
I also see that R'twick very kindly applied the necessary patch to the code and this works with Centos 3.3 and possibly others.
Has anyone used the R'twick modified code on RH9 with 7.5.4 by any chance?
Also, what is the third file for? The psa-greylist.patch and qmail-1.03-psa-published-greylist ones are explained in the notes, but I can't see what the qmail-psa-greylist-spf-mailqueue one is for?
PHP:
psa-greylist.patch 03-Apr-2006 17:45 21K
qmail-1.03-psa-published-greylist.tar.gz 03-Apr-2006 17:44 238K
qmail-psa-greylist-spf-qmailqueue.tar.gz 08-Apr-2006 22:26 1.2MAny pointers and advice would be appreciated.
Faris.
Originally posted by faris
For the sake of simplicty I tried Scot's qreylist and although it worked brilliantly and is "compatible" with smtp_auth is does still apply greylisting to smtp_auth which means people using our servers to send email will experience problems.
So now I want to have a go with the more complex version that this thread is mostly about.
But I'm confused (as usual)
I can see the very clear how-to, but I also see that there is an issue in that the original code did not have the Plesk patches related to rejecting email for non-existant mailboxes, which we absolutely need.
I also see that R'twick very kindly applied the necessary patch to the code and this works with Centos 3.3 and possibly others.
Has anyone used the R'twick modified code on RH9 with 7.5.4 by any chance?
Also, what is the third file for? The psa-greylist.patch and qmail-1.03-psa-published-greylist ones are explained in the notes, but I can't see what the qmail-psa-greylist-spf-mailqueue one is for?
PHP:psa-greylist.patch 03-Apr-2006 17:45 21K qmail-1.03-psa-published-greylist.tar.gz 03-Apr-2006 17:44 238K qmail-psa-greylist-spf-qmailqueue.tar.gz 08-Apr-2006 22:26 1.2M
Any pointers and advice would be appreciated.
Faris.
The last one is with some additional patches, namely
spf - which makes it compatible with plesk 8.0.
qmailqueue - makes it easier to use different mail queues instead of renaming the original qmail-queue. I use this with art's qmail-scanner package.
If you do not need these two patches then use qmail-1.03-psa-published-greylist.tar.gz.
I'm sure this will work on RH9 (you might need to fiddle with the two files I had to change to get it compiled).
HTH
-R'twick
N
netdias
Guest
Is there a way to NOT apply greylisting to smtp_auth?
F
faris
Guest
Thanks hugely for the info R'twick. I'm going to have huge fun playing with this over the weekend I think
Netdias - does this mean that even the mega-patch version still greylists authenticated smtp? That would be annoying - I got the impression that it got around it somehow. There must be a way -- the mere fact that authenticated smtp is being used must surely allow for a simple conditional thingie somewhere in the code? (I don't know when authentication happens in the smtp dialog though, so maybe it comes too late?)
But there are at least three ways I can think of to get around it if it does not...
1) run another instance of qmail, on a different port, and use this for authenticated smtp. Your users would have to change the port number in their email clients, but that's about it. Seems like a nice simple solution. On one of the pages that talks about greylisting I'm reasonably sure I saw some instructions on how to run a second instance. It can't be all that difficult I'm sure.
2) Have a separate mailserver that deals with incoming mail (including greylisting). I'd love to do this but don't have enough machines. When Xen/VMware becomes part and parcel of the OS, which should not be too long now, it would be a doddle just to add a new VM for this very purpose, but for now I'm stuck. In any case it would involve creating a mechanism to copy accross the qmail control files in order to make sure email works as set up in Plesk.
3) The solution I'll probably take it to whitelist the IPs or IP ranges used by those customers who we allow to use authenticated smtp. We are lucky in that we have never offered authenticated smtp as a standard feature to anyone, and only explain how to do it to users who actually need it. We are additionally very lucky in that the majority of our customers use us as their ISP too, so we know the IP ranges they will connect from. Even if we didn't, we could always add the IPs that customers connect from as and when the issue cropped up. So Whitelisting, for us, would be a perfectly acceptable option.
Faris.
Netdias - does this mean that even the mega-patch version still greylists authenticated smtp? That would be annoying - I got the impression that it got around it somehow. There must be a way -- the mere fact that authenticated smtp is being used must surely allow for a simple conditional thingie somewhere in the code? (I don't know when authentication happens in the smtp dialog though, so maybe it comes too late?)
But there are at least three ways I can think of to get around it if it does not...
1) run another instance of qmail, on a different port, and use this for authenticated smtp. Your users would have to change the port number in their email clients, but that's about it. Seems like a nice simple solution. On one of the pages that talks about greylisting I'm reasonably sure I saw some instructions on how to run a second instance. It can't be all that difficult I'm sure.
2) Have a separate mailserver that deals with incoming mail (including greylisting). I'd love to do this but don't have enough machines. When Xen/VMware becomes part and parcel of the OS, which should not be too long now, it would be a doddle just to add a new VM for this very purpose, but for now I'm stuck. In any case it would involve creating a mechanism to copy accross the qmail control files in order to make sure email works as set up in Plesk.
3) The solution I'll probably take it to whitelist the IPs or IP ranges used by those customers who we allow to use authenticated smtp. We are lucky in that we have never offered authenticated smtp as a standard feature to anyone, and only explain how to do it to users who actually need it. We are additionally very lucky in that the majority of our customers use us as their ISP too, so we know the IP ranges they will connect from. Even if we didn't, we could always add the IPs that customers connect from as and when the issue cropped up. So Whitelisting, for us, would be a perfectly acceptable option.
Faris.
N
netdias
Guest
Thank you Faris!
Well I just put the ART patch in it, and it seems it is the same has putting the original qgreylist. I thought it would not greylist the authenticated users. Which is not the case.
I have not yet tried the scots patch but according to Rtwick, it wont stop greylist on the authenticated users. I have been using the greylist for 1 month now, and neither of my users complained about it so... for now I will stay put!
The port change approach might be the best, but it will take a lot of work to teach our users how to change the settings.
Best regards
Well I just put the ART patch in it, and it seems it is the same has putting the original qgreylist. I thought it would not greylist the authenticated users. Which is not the case.
I have not yet tried the scots patch but according to Rtwick, it wont stop greylist on the authenticated users. I have been using the greylist for 1 month now, and neither of my users complained about it so... for now I will stay put!
The port change approach might be the best, but it will take a lot of work to teach our users how to change the settings.
Best regards
F
faris
Guest
Argh!
I'm falling at the first fence with the compile
On RH9, with conf-cc unchanged from R'twick's version, I get this towards the end:
I tried it with the generic conf-cc contents (which just has cc -O2 -DTLS in it) and get the same thing.
I've also tried this in conf-cc:
and
In addition, i've softlinked the kerberos stuff as mentioned in page five of this topic.
The problem is obviously something to do with the ssl libs not being found somehow, but I can't seem to get things sorted.
openssl-devel and mysql-devel are both installed.
I don't know enough about this stuff to progress any further. Hints and tips would be appreciated!
Faris.
I'm falling at the first fence with the compile
On RH9, with conf-cc unchanged from R'twick's version, I get this towards the end:
Code:
./compile qmail-envelope-scanner.c
./compile local_scan.c
./load qmail-envelope-scanner -lz -lm local_scan.o /usr/lib/mysql/libmysqlclient.a
/usr/lib/mysql/libmysqlclient.a(client.o)(.text+0x1601): In function `mysql_ssl_free':
: undefined reference to `SSL_CTX_free'
--- and lots more SSL_xxxx problems ---I tried it with the generic conf-cc contents (which just has cc -O2 -DTLS in it) and get the same thing.
I've also tried this in conf-cc:
Code:
cc -O2 -DTLS -I/usr/lib -I/usr/lib/mysql -I/usr/include/openssl -I/usr/includeand
Code:
cc -O2 -DTLS=20040419 -I/usr/lib -I/usr/lib/mysql -I/usr/include/openssl -I/usr/includeIn addition, i've softlinked the kerberos stuff as mentioned in page five of this topic.
The problem is obviously something to do with the ssl libs not being found somehow, but I can't seem to get things sorted.
openssl-devel and mysql-devel are both installed.
I don't know enough about this stuff to progress any further. Hints and tips would be appreciated!
Faris.
F
faris
Guest
Hmmm..
I googled and experimented a bit and added -lssl to conf-ld
In other words conf-ld now contains
cc -s -lssl
And it compiled!
And it seems to work. It is certainly greylisting, and accepting email from outside the test network correctly.
But I'm having problems testing using telnet, because there is a LONG delay before I get a response. I have -Rt0 in smtp_psa so I don't quite know why this is happening. But that's another story and not important.
What I would like to know is did I do the right thing with the -lssl in conf-ld ?
Thanks,
Faris.
I googled and experimented a bit and added -lssl to conf-ld
In other words conf-ld now contains
cc -s -lssl
And it compiled!
And it seems to work. It is certainly greylisting, and accepting email from outside the test network correctly.
But I'm having problems testing using telnet, because there is a LONG delay before I get a response. I have -Rt0 in smtp_psa so I don't quite know why this is happening. But that's another story and not important.
What I would like to know is did I do the right thing with the -lssl in conf-ld ?
Thanks,
Faris.
N
netdias
Guest
Faris, can you confirm that it applies greylist to the authenticated users ?
F
faris
Guest
I was just going to post about that!
Yes, I can confirm that this super-duper version has no adverse effect whatsoever on authenticated smtp. It works just as it did before - authenticated users do not get affected by the greylisting in any way shape or form. It is perfect!
Faris.
Yes, I can confirm that this super-duper version has no adverse effect whatsoever on authenticated smtp. It works just as it did before - authenticated users do not get affected by the greylisting in any way shape or form. It is perfect!
Faris.
F
faris
Guest
OK, the next step is to have some way to automatically parse:
http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?view=markup
(this is a list of addresses that would possibly be wise to whitelist)
and whitelist them.
There must be an easy way to extract the data from that page - it is in the usual sort of format for code, but I have no idea what tool to use.
Anybody have any suggestions?
Faris.
http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?view=markup
(this is a list of addresses that would possibly be wise to whitelist)
and whitelist them.
There must be an easy way to extract the data from that page - it is in the usual sort of format for code, but I have no idea what tool to use.
Anybody have any suggestions?
Faris.
F
faris
Guest
Just to add soomething to this post, I came accross this:
http://www.datenklause.de/en/software/qgreylistrbl.html
This is a version of the very basic (i.e. the one that causes problems with smtp auth) greylist script in Perl but has a very very significant difference. Essentially it combines RBLs with greylisting, and only applies greylisting if the incoming mail failes the RBL check (dial-up connections are also checked for). This, in itself, will solve most problems authenticated smtp problems anyway, so it sort of takes the incompatibility away.
The instructions say that you basically use it as a replacement for rblsmtpd. However, I have a horrible feeling that the Plesk version of rblsmtpd was customised, so this probably will *not* work as a drop-in replacment.
But I do like the idea of combining RBLs with greylisting as it does two things: 1) Pretty much eliminates the huge number of valid emails that get blocked by most RBLs and 2) Pretty much eliminates the possibility of greylisting accidentally causing problems with valid emails being sent through a faulty mailer.
Anyway, for anyone heavily into the cosding of this kind of thing I thought I'd point it out.
Faris.
http://www.datenklause.de/en/software/qgreylistrbl.html
This is a version of the very basic (i.e. the one that causes problems with smtp auth) greylist script in Perl but has a very very significant difference. Essentially it combines RBLs with greylisting, and only applies greylisting if the incoming mail failes the RBL check (dial-up connections are also checked for). This, in itself, will solve most problems authenticated smtp problems anyway, so it sort of takes the incompatibility away.
The instructions say that you basically use it as a replacement for rblsmtpd. However, I have a horrible feeling that the Plesk version of rblsmtpd was customised, so this probably will *not* work as a drop-in replacment.
But I do like the idea of combining RBLs with greylisting as it does two things: 1) Pretty much eliminates the huge number of valid emails that get blocked by most RBLs and 2) Pretty much eliminates the possibility of greylisting accidentally causing problems with valid emails being sent through a faulty mailer.
Anyway, for anyone heavily into the cosding of this kind of thing I thought I'd point it out.
Faris.
F
faris
Guest
processing order
I've noticed that the greylisting comes into effect before the "reject mail to non-existant addresses" part of the code.
This seems like the wrong order to me since it requires the system to do a database lookup or record insertion even if the mail will never be delivered no matter what.
R'twick/Brenadan - is there any way to change things around?
I wish I was a coder because there are all sorts of things I'd love to do able to do with this if I had the skills. It is very frustrating!
Faris.
I've noticed that the greylisting comes into effect before the "reject mail to non-existant addresses" part of the code.
This seems like the wrong order to me since it requires the system to do a database lookup or record insertion even if the mail will never be delivered no matter what.
R'twick/Brenadan - is there any way to change things around?
I wish I was a coder because there are all sorts of things I'd love to do able to do with this if I had the skills. It is very frustrating!
Faris.
Re: processing order
I'm not sure which should come first. But, "reject to non-existent a/c " feature should also require couple of file reading (or may even be reading the database I'm not sure abt how plesk handles it) which may very well be equally costly.
I also think most of the mails to non-existent users are also from those one time attempt mail scripts/servers and so greylisting will stop them.
For me, I use my own "reject mail to non existent user" code which anyway does couple of database lookups and so both are almost equally costly for me.
I'm not sure which should come first. But, "reject to non-existent a/c " feature should also require couple of file reading (or may even be reading the database I'm not sure abt how plesk handles it) which may very well be equally costly.
I also think most of the mails to non-existent users are also from those one time attempt mail scripts/servers and so greylisting will stop them.
For me, I use my own "reject mail to non existent user" code which anyway does couple of database lookups and so both are almost equally costly for me.
F
faris
Guest
That's interesting R'twick. I'm sure you are right. Thanks
For anybody who is interested:
In testing on a domain that has become both a spam magnet and a domain the spammers are using as a "from" address, out of over 10,000 emails received over a period of 3 days, only 100 spam-related messages passed through the greylist. Out of these, around 50% were bounce messages (to non-existant addresses). Of the other 50%, almost all were sent to non-existant addresses by a marketing company acting on behalf of a load of "slightly more legitimate than the normal spammers" companies and had a proper email system which retried sending until the email got through. So if I didn't have the catchall enabled for the purposes of testing, pretty much no spam would have come through.
gmail and yahoo email had no problem passing through the filter. Emails from Amazon had no problems coming through, even though they use time-based from addresses each time they sent a message.
One legitimate email did not pass through the filter - the sending server (a very very busy mailing list using Mailman) tried once but did not retry. I'm talking to one of the admins, who says he thinks it is deliberately set not to retry due to the massive number of emails that go out - which is fair enough.
Not bad eh? I'd give that a 99.99999% thumbs up, and will be implementing it on a live production server in the not too distant future.
For anybody who is interested:
In testing on a domain that has become both a spam magnet and a domain the spammers are using as a "from" address, out of over 10,000 emails received over a period of 3 days, only 100 spam-related messages passed through the greylist. Out of these, around 50% were bounce messages (to non-existant addresses). Of the other 50%, almost all were sent to non-existant addresses by a marketing company acting on behalf of a load of "slightly more legitimate than the normal spammers" companies and had a proper email system which retried sending until the email got through. So if I didn't have the catchall enabled for the purposes of testing, pretty much no spam would have come through.
gmail and yahoo email had no problem passing through the filter. Emails from Amazon had no problems coming through, even though they use time-based from addresses each time they sent a message.
One legitimate email did not pass through the filter - the sending server (a very very busy mailing list using Mailman) tried once but did not retry. I'm talking to one of the admins, who says he thinks it is deliberately set not to retry due to the massive number of emails that go out - which is fair enough.
Not bad eh? I'd give that a 99.99999% thumbs up, and will be implementing it on a live production server in the not too distant future.
F
funat120mph
Guest
not working after upgrade to Plesk 8
I recently upgraded to Plesk 8 and then reinstalled Greylisting. My install is not working any more.
Any thoughts?
Thank you.
I recently upgraded to Plesk 8 and then reinstalled Greylisting. My install is not working any more.
Any thoughts?
Thank you.
F
faris
Guest
Did you use the Plesk 8 comptible source files?
Also try re-creating the database from scratch -- and make sure you have old-passwords=1 in my.cnf (or is it oldpassword=1 ?)
Faris.
Also try re-creating the database from scratch -- and make sure you have old-passwords=1 in my.cnf (or is it oldpassword=1 ?)
Faris.
F
funat120mph
Guest
Where do I get the Plesk 8 compatible source fiiles?
Did I overlook them in this thread?
Thank you.
F
faris
Guest
Well, I don't think the "normal" version is actually incompatible. But it doesn't have all the new features (e.g. SPF)
If you go back to page 9 of this thread, you'll see a posting by me asking what the difference was between the various files available to download. The one that has all the version 8 goodies in it is:
qmail-psa-greylist-spf-qmailqueue.tar.gz 08-Apr-2006 22:26 1.2M
But I really suspect that you are having a database issue. What does the output file in /tmp have in it? Have a look at the posts right at the start of this thread where people were having problems. Have you changed from MySQL3 to MySQL4? If so then it is almost definitely the problem.
Faris.
If you go back to page 9 of this thread, you'll see a posting by me asking what the difference was between the various files available to download. The one that has all the version 8 goodies in it is:
qmail-psa-greylist-spf-qmailqueue.tar.gz 08-Apr-2006 22:26 1.2M
But I really suspect that you are having a database issue. What does the output file in /tmp have in it? Have a look at the posts right at the start of this thread where people were having problems. Have you changed from MySQL3 to MySQL4? If so then it is almost definitely the problem.
Faris.
