mmm
I believe that is a great feature. QMAILQUEUE is the real command ~qmail/bin/qmail-queue if the QMAILQUEUE is not set, so i dont know why may fail deliveries for any user.
qmail-ldap, as a pop/IMAP toaster with clustering and compression is a great choose for middle size ISPs and biggers.
For this elecction, qmail-scanner with a great virus protection and spam filtering is needed, but i think that qmail-scanner has the problem i related before, the not per-user filtering.Maybe this feature as part of "original" qmail-ldap patch but of course only active under demand, it will increase qmail-ldap versatility.
you say that this operation complicate debuggin, but i think that not more than when i set QMAILQUEUE by IP connection. Today, this operation cannot be logged, but a line as "Using /var/qmail/bin/qmail-scanner-queue as QMAILQUEUE" in loggin will be enough for debuggin purposes.
any way is only an idea :D
Best Regards.
C�sar Garc�a. Dept. Sistemas, IdecNet S.A. Centro de Gesti�n de Red. Edificio IdecNet. C/Juan XXIII 44. E-35004, Las Palmas de Gran Canaria, Islas Canarias - Espa�a. Tfn: +34 828 111 000 Ext: 340
Ted Zlatanov wrote:
On 14 Jul 2004, [EMAIL PROTECTED] wrote:
And what about QMAILQUEUE enviroment value per-user? it will be usefull for example for filter any users yes and others not, if rcptcheck access LDAP to check destinations, to take QMAILQUEUE from LDAP and modify QMAILQUEUE enviroment VALUE i think not will be so hard, and this implementation will be powerfull.
I think that would make mail fail for certain users in a mysterious way, so maybe it's not a good idea.
The other changes (DATABYTES, etc.) were environmental changes, which don't affect the mail processing pipeline. This would change the pipeline, so it would be much harder to debug. I know QMAILQUEUE can be set even now by IP, but that's intended for other purposes (internal vs. external queueing), not per-user filtering.
I'm pretty sure you can test the environment inside QMAILQUEUE right now. Look at the user name and change the behavior based on that... You can even get the behavior from LDAP if you want, but I repeat that it will probably complicate debugging a lot.
Ted
