Hello, > I have tested dbmail.(MTA postfix) on Suse 9.1 (for test on vmware) > > If using myisam tables check should be added like > SELECT * > FROM dbmail_messages > LEFT JOIN dbmail_physmessage ON dbmail_messages.physmessage_id = > dbmail_physmessage.id > WHERE dbmail_physmessage.id IS NULL > if there any records, imap will fail to deliver, or will cache everything > into memory! tested on 600mb mailbox and imap eat all memory!! > It cannot happen on innodb tables, but a check would be usefull if somebody > using myisam.
Maybe that could be added to dbmail-util (file a bug in the bug tracker on it?). > Imapd does cache the last message into memory and do not relase until next > message delivery or logout, for example 6 Mb message by fetching goes up to > 14Mb memory and then back to 10Mb memory usage but I think it should free up > it.(staying on a message in a client, but message is downloaded and viewed, > it use still 10 mb). > The email messages will go bigger and bigger so I have made a test database > of 6 Mb mails. > > The message in the database is splitted into half Mb parts, so it should > relase the delivered message part of the message, and do not hold in the > memory. > (I think the memory use is caused by the mysqlclient part because normaly it > will not relase memory sended true it, but possibly I'm wrong. I programming > in delphi, and when I made mass insert of big blobs to a mysql database with > ODBC and ADOTable and not limited the MaxRecords to 1 , all inserted rows > remained in memory and have eaten all memory. ). If you/someone can track this down to either a mysql client library problem or a dbmail issue, a bug could be filed against it in the appropriate place. > Is header is not used as I seem, is > SELECT min( `messageblk_idnr` ) , `physmessage_id` > FROM `dbmail_messageblks` > WHERE messagecheck.etc.... > GROUP BY `physmessage_id` > used to determine the header Correct, is_header isn't used anywhere yet. See mailing list archives for recent discussions (dbmail-dev). > Quota: > If over qouta the smtp returns with temporary database error, but it should > be return with some other error, because messages will be remain in postfix > queue. So if somebody flood a mailbox, he floods the postfix queuen. Or if > the mail is returned it does not contain that it is over qouta. > No overqouta and qoutawarn message present (for the user). > I can write a script doing it, but I can do it in two way: > put in the database and move summailsize over qouta or put message with null > indicated mailsize. > But it should implemented someway....(it could be made by Imapd or pop3d > give an extra message (not to database) to the client) > I do not understand why qoutacheck performed only at the end, because it is > cached . It should check at first remaining qouta, then check the size and > next delivery or not when getting the message and messagesize counted by a > counter on the fly. And when the memory cache is not used (why used now? > bug?) then it not needed to store, discard the remaining part (devnull :)) > and give back error. Ditto - known issue, see dbmail-dev archives for recent discussion. > !!!! The shared mailbox works if have same aliases, but when one of the > users quote exceed , it will be delivered to the other user(s) every time > postfix try to deliver!!! (get the same message more times). Not sure on the right way to handle this case in general. For this case in particular (quota exceeded), returning a 5xx response like you just mentioned would do it. > I think one way is, the smtp does not give error messages and "accepts" not > exist user and over qouta messages and generate the error messages returned > to sender self.. The code of autoreply could do this... But must be checked > if the sender address is in the user list, domian in the domain(it is a > little harder to do see suggestion, but if only error messageges generated > by overqouta and hard error is given by not exist users, the domain check it > can be left out),and when yes, this is not over qouta (disable bounce)... > (lmpt qive 550 by not existent user error but by overquota it gives 415 > Recipient <[EMAIL PROTECTED]> Permanent Failure Address Status Destination > mailbox address valid (in reply to end of DATA command) but it should be > give over qouta limit message or 5xx over qouta message (second would be > better, because if it would be the smtp service it ok, but mail would be > queuened by sender's emailserver, but now all is queuened by postfix > locally.. ) > Not existent user smtp: the same like Quota, It should be give harder error, > so > the queue cannot be flooded.(I do not know if possible to give 5xx like > errors by using smtp transport, or any error return codes equivalent to > 5xx ). > > my main.cf > #home_mailbox = Maildir/ > #mail_spool_directory = /var/mail > #canonical_maps = hash:/etc/postfix/canonical > #virtual_maps = hash:/etc/postfix/virtual > #relocated_maps = hash:/etc/postfix/relocated > #transport_maps = hash:/etc/postfix/transport > #sender_canonical_maps = hash:/etc/postfix/sender_canonical > local_recipient_maps = > luser_relay = $name > mydestination = /etc/postfix/localdest > mailbox_transport = dbmail-smtp: > > (I use luser_relay > (localdest is a plain text file with domain list per line, and will be later > generated by a script, and no local_recipient_maps used.) A permanent error is generated, but it's re-injected back into your mail queue, which fills it up, as you've noticed. This is handled well by using local_recipient_maps to point to your dbmail aliases table. See dbmail list archives for numerous examples of doing so. > No documentation about auto notification and auto replies > does auto replies support for example $Subject? Correct, no documentation... also recent discussions in the archives for this. :) No, it doesn't support any variable expansion, and is generally fairly broken right now, it sounds like (never used it myself). > Suggesions: > It would be usefull if the aliases alias splitt into 2 parts name and > domain, so a domain table could be made and the client_idnr could be used to > determine the domain, or something like that, because when want to manage > users, it would be easier when can be done per domain(s). You can of course put your own table in the database with a map of client_idnr's to domain names to track that. Since aliases generally are the full email address anyways, there's not much of a reason for dbmail to have it seperate itsself. In fact, it would generally take even more configuration in your mta to handle delivery for such a mechanism via direct inject (and via lmtp you'd just be parsing the addr out into 2 parts and joining back together on a lookup... it's more efficient the way it is, likely). > Best Regards, > Udo Attila Fischer Thanks for your comments, suggestions, etc... -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
