John Peacock wrote:
Though a couple of self-inflicted Denial of Service attacks on my mail servers, I've discovered that qpsmtpd doesn't implement any mailing loop detection internally. Now that I have fixed my misconfiguration (alias domains not completely set up), I thought I'd add this to qpsmtpd so it *can't* happen again.
The only question I have is whether this should be a plugin (since it might be computationally significant) or if it should be part of the core code...
Thoughts???
John
Right now I think for qmail-queue people that qpsmtpd core is not responsible for de-aliasing or validating addresses, though self-defense against ddossing is needed for self-preservation. qmail has a level limit to prevent alias looping. Could anybody expect more than three levels?
I'm building off of a rcpt_ok plugin I wrote which initially used ./config/rcptusers if available. Then to use cyrus for local delivery, I have to write an ldap lookup of uid to de-alias rcptusers so at that point I've outgrown rcptusers--it's redundant if I have ldap. Somebody else reconciled the dspam and mda's sql by aliasing the two(dspam and mda) alias record names to point to one uid record. That's two layers of aliasing, the de-alias to uid and the de-alias from dspam name for record to mda's name for the same de-alias method or uid.
Somebody else will use bdb, mldbm, you can't anticipate, but specialized plugins that work for dspam and different mda's would be nice to accumulate.
The way I form uid's for cyrus is different than somebody else. For virtual domains, some use the whole email name as uid, but I change all the dots and the @ to underlines. You can't anticipate those alternatives.
I think it was Felix Leitner who said that the best way to do ldap would probably be a file-directory tree on a flash or ram disk or maybe djb said it because his maildir non-locking safe write would be such a help there.
./uid/unique_dn/uid [file contains mda mailbox uid] ./uid/unique_dn/userPassword [file contains password] ./uid/unique_dn/mail [file contains all [EMAIL PROTECTED] for uid] ./uid/unique_dn/objectClass [schema obclasses to write ldif]
./mail/[EMAIL PROTECTED] [ln -s ./uid/unique_dn/uid [EMAIL PROTECTED] ./mail/[EMAIL PROTECTED] [ln -s ./uid/unique_dn/uid [EMAIL PROTECTED]
./cn/admins/[files: (cn|member|objectClass|member)] ./cn/[domain]_admins/[files: (cn|member|objectClass|member)] ./cn/[domain]_users/[files: (cn|member|objectClass|member)]
There, file-locking on attribute files would equal column-level locking! Better, use maildir writes instead of locking.
That shines a light on how stupid it is to put write code in the ldap lookup server like openldap does. tinyldap doesn't do writes because it's a frontend not a jack of all trades master of none, not a frontend bulked up with backend code, not that kind of failure kludging instead of solving the update, collision, contention, locking issues at the design level. tinyldap scales in terms of speed, but it needs that file tree on flash or ramdisk with maildir-style safe writes from a different entity to be scalable as far as updating data, writes without collisions, contention, or locking problems.
Some ACL functionality would be hard, by way of directory and file ownership and permissions. The rest would be soft, in the read and write backends as usual.
Currently there would be an extra layer, writing an ldif based on the tree, and tinyldap not standalone would offer read-only access for imap/pop3 auth's and qpsmtpd de-aliasing of addresses to mda's mailbox uid for queueing.
-Bob Dodds
