Hi Scott -

The qgreylist did wonders to the server load ! The problem we are facing now is the lack of integration to pop-before-smtp, which is used by a bunch of clients who run local Linux servers on DSL connections without static IPs, and use Plesk server for outgoing mails and fetchmail for mail downloads.

Is there any quick way to integrate pop-before-smtp into qgreylist. I saw one that uses swatch, but the latency is too much. I can try a patch, but I am not sure how courier and qmail are exchanging the list of valid logins. Did not dig in too deep yet, so I am not sure where the handover of valid client IPs is done from Courier to Qmail. If there is some file that stores the list of valid pop-before-smtp client IPs, I can try to patch qgreylist to parse it and exclude them from greylisting.

Regards,
Anwar.

Never tried it, all my users use smtp_auth over submission so it hasn't been an issue. If you develop a patch for it, I'd be happy to include it with the package in the next update.

Cool.

Does any one know off-hand where the list of valid pop-before-smtp mails is maintained on a Plesk system (either on the qmail side or on the courier side) ? Basically I am looking for that file or folder where this is maintained, so that I can incorporate it into qgreylist.

I'm the guy that created the pop-before-smtp thingie, and I'd be interested to hear what you mean by latency. I've been runnning it here, with the minor nit of IMAP not being included in the swatch script.

The location using my method where the files are stored is in /var/qmail/clientlist, and they are in the same format as the regular qgrelist files. Just an empty file with the first three octets of the IP addy.

Having said that, I'd recommend just remove qgreylist from the smtps chain in the xinetd file. You'll still get qgreylisting on port 25. Far, far less painful and invasive, and you get the bonus of encrypting the passwords of your clients. All my subscribers responded positively to the added security part.

By latency, I meant the delay in getting the clients added to the clientlist via swatch.

And the idea of not using qgreylist on SMTPS submission was not enticing either, since we have a bunch of small businesses who use local Linux servers on ADSL lines, and their submission is coming from their Postfix servers with dynamic IP addresses (instead of just enabling SMTPS submission with auth in their email clients). But the following link makes it manageable.

http://wiki.redwall-firewall.com/index.php/Implementing_Upstream_SMTP_Authentication_for_Postfix

I am planning to play with this on the client side (Postfix). For regular (human!) users, they can all use SMTPS with auth.