Re: [Dovecot] adding users to passwd-file
On Mon, April 26, 2010 1:46 pm, Phil Howard wrote:
On Mon, Apr 26, 2010 at 4:38 PM, Heiko Schlittermann
h...@schlittermann.dewrote:
Some people use htpasswd, but there not password scheme is coded into
the password hash.
It's not clear what you're seeking - some tool for generating the hashed
string (e.g. openssl passwd -1 $cleartext) or some tool for managing
the
entries in the (dovecot) password file.
I left it vague to handle some variety. Something to add/delete users is
nice. Something to change password in place is nice. Something that
given
a user and plain text password and everything else Dovecot needs when
using
it as userdb, and would output to stdout the line contents that would go
into the file, would do the job.
I want to avoid re-inventing the wheel. If there are no wheels, I guess
I'll just look up the salted-MD5 format details and do it.
Here's a little perl script you can start with for creating the MD5 salted
password (slightly modified from something I found on the net a couple of
years ago):
=
#!/usr/bin/perl -wl
use strict;
use Crypt::PasswdMD5 qw(unix_md5_crypt);
my @salt = ( '.', '/', 0 .. 9, 'A' .. 'Z', 'a' .. 'z' );
# take clear-text password as argument:
my $password = shift || die usage: $0 password;
my %encrypted;
# generate md5 password
$encrypted{md5} = unix_md5_crypt( $password, gensalt(8) );
print $_ $encrypted{$_} for sort keys %encrypted;
# uses global @salt to construct salt string of requested length
sub gensalt {
my $count = shift;
my $salt;
for (1..$count) {
$salt .= (@salt)[rand @salt];
}
return $salt;
}
=
You will need to have the Crypt::PasswdMD5 perl module installed to use this.
Bill
Re: [Dovecot] Fail2Ban and the Dovecot log
Timo Sirainen wrote: On Mon, 2009-05-11 at 14:48 -0700, Bill Landry wrote: If you log via syslog, the timestamp will be at the beginning of line. Well, then that would explain it. Maybe it would be a good idea then to remove the dovecot: from the beginning of each log line when not using syslog for logging, since I'm pretty sure that anyone checking the dovecot.log would know that it was the dovecot log they were looking at (no need to remind then at the beginning of each and every line). ;-) Yeah. I don't know what I was thinking when I made it work like that. v1.2 has more sensible logging now, but I don't want to break anyone's setup by doing the change to v1.1. These patches probably apply to v1.1 too though: http://hg.dovecot.org/dovecot-1.2/rev/0669bc561763 http://hg.dovecot.org/dovecot-1.2/rev/194b80691980 Thanks Timo, your responsiveness to requests (no matter how mundane at times) is always very much appreciated! Bill
Re: [Dovecot] Fail2Ban and the Dovecot log
Lou Duchez wrote: Is there any way to disable the dovecot: at the beginning of each line of the log? Fail2Ban responds poorly to it. I know there are a number of sites with failregex strings for Fail2Ban and Dovecot, but I've tried them all, and they don't work, at least with the latest Fail2ban and the latest Dovecot. The Fail2Ban wiki is pretty clear about why there will be a problem: In order for a log line to match your failregex, it actually has to match in two parts: the beginning of the line has to match a timestamp pattern or regex, and the remainder of the line has to match your failregex.. So in other words, Fail2Ban expects that each line of the log will start with a timestamp. Hmmm, I'm using: dovecot --version 1.2.rc3 rpm -q fail2ban fail2ban-0.8.3-18.fc10.noarch and this seems to work just fine for me: failregex = auth.*passwd.*,HOST\).*(unknown user|Password mismatch) in my /etc/fail2ban/filter.d/dovecot.conf. Bill
Re: [Dovecot] Fail2Ban and the Dovecot log
Timo Sirainen wrote: On Mon, 2009-05-11 at 17:15 -0400, Lou Duchez wrote: Re: the dovecot: at the beginning of the line in the log. I should mention that other applications encounter a similar issue with Fail2Ban -- for example, if you're running Asterisk, you have to alter the log format such that the timestamp is at the beginning of the line: If you log via syslog, the timestamp will be at the beginning of line. Well, then that would explain it. Maybe it would be a good idea then to remove the dovecot: from the beginning of each log line when not using syslog for logging, since I'm pretty sure that anyone checking the dovecot.log would know that it was the dovecot log they were looking at (no need to remind then at the beginning of each and every line). ;-) Bill
Re: [Dovecot] Account lockout option?
Ed W wrote: failregex = : warning: [-._\w]+\[HOST\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed$ failregex = dovecot: auth.*\(.*,HOST\): (unknown user|password mismatch)$ Ed, have you found that both failregex lines are actually being used here, as in my experience, only the first failregex line is used? Maybe this has changed in the most recent version of fail2ban, but I have found that I had to create a separate filter file if I wanted to used a second failregex against the same log file and also add a second jail.conf entry. Bill
Re: [Dovecot] Account lockout option?
Ed W wrote: Bill Landry wrote: Ed W wrote: failregex = : warning: [-._\w]+\[HOST\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed$ failregex = dovecot: auth.*\(.*,HOST\): (unknown user|password mismatch)$ Ed, have you found that both failregex lines are actually being used here, as in my experience, only the first failregex line is used? Oh! You mean did I actually test this stuff before assuming it was all working perfectly (shuffling of feet...) Well, ok, perhaps it doesn't... Looking at the config files it would appear that proftpd.conf and sshd.conf set use a single failregex= line and then put multiple regexps on each following line. I guess this is the correct way to do it... The benefit of only using one .conf file is that if some cheeky scammer is alternately trying your smtp, pop, imap for a breakin then it takes more attempts to snag them The current attacks against my server are very slow attacks from a distributed botnet and fail2ban is hardly touching them. I see dozens of IPs trying at no more than one per minute and it would appear they swap between smtp and pop ports (I see the same from any given IP). Some IPs seem much more common and fail2ban is occasionally snagging an IP which spews a bit faster, but sometimes each IP will try only once or twice a day. Bit of a bugger to stop really... What is your maxretry = set to for your dovecot jail.conf entry, as you did not show it if your initial email? If they are trying once per minute (as you stated above), and you have, for example, your maxretry = 5, then after 5 failed attempts (in your scenario, 5 minutes), they will be locked out for 3600 seconds (1 hour). And if they keep trying, they will stay blocked until there is at least 1 hour between attempts. Fail2ban is awesome, I have it set to monitor all of my running services. Bill
Re: [Dovecot] login processes from attacks staying for hours
Kai Schaetzl wrote: Charles Marcus wrote on Wed, 23 Jul 2008 10:30:30 -0400: The best answer is to use a tool made for this kind of job, like fail2ban. I found a few fail2ban definitions on the web, but all seem to be either very outdated or plain wrong for RHEL/CentOS. I've come so far as to this with the regex for dovecot on CentOS 5 (scanning /var/log/secure). Do you think that's correct? failregex = dovecot-auth: pam_unix(dovecot:auth): authentication failure; .* rhost=HOST$ log line to be matched: Jul 23 16:42:26 chacha dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=:::127.0.0.1 Kai, you can test your regex using fail2ban-regex. For example: fail2ban-regex /var/log/secure dovecot-auth: pam_unix(dovecot:auth): authentication failure; .* rhost=HOST$ However, that does not detect the log-line above. Try something simpler like: fail2ban-regex /var/log/secure dovecot-auth.*pam_unix.*authentication failure.*rhost=HOST$ Bill
Re: [Dovecot] 1.1Beta5 Issue
Timo Sirainen wrote: On Mon, 2007-10-29 at 08:08 -0700, Jeff Grossman wrote: I installed 1.1Beta 5 this weekend. I had no problems at all yesterday using Thunderbird. I started reading my mail with Squirrelmail this morning and everything was going pretty smooth. I tried to delete a daily e-mail I receive from careerbuilder.com and the IMAP process shot up to 99.9% and I was not able to do anything in Squirrelmail. I killed that process and tried it again just to be sure what it was. And it did it again. I can delete any other message with no problems, just that one causes me issues. I am not sure if Thunderbird is the same, I will have to wait until I get home tonight. By deleting I suppose you mean Move to trash, so the problematic part is probably copying the message to another mailbox. So I guess it gets to infinite loop somehow. Would be nice if you could get gdb backtrace from the running process: gdb /usr/local/libexec/dovecot/imap pid of imap process bt full Also if that's not a sensitive email, could you send it to me? I have a question about using gdb, as I too had a message that I could not move between folders (however, that was prior to 1.1b5). When you say to gdb the pid of imap process, how do you determine which pid to trace when the output of ps axf is?: 2252 ?Ss 0:00 dovecot 2256 ?S 0:00 \_ dovecot-auth 2265 ?S 0:00 \_ imap-login 2266 ?S 0:00 \_ imap-login 2267 ?S 0:00 \_ imap-login 3048 ?S 0:00 \_ imap 3054 ?S 0:00 \_ imap 3061 ?S 0:00 \_ imap 3063 ?S 0:00 \_ imap 3064 ?S 0:00 \_ imap 3065 ?S 0:00 \_ imap 3066 ?S 0:00 \_ imap 3404 ?S 0:00 \_ imap Thanks for any feedback! Bill
Re: [Dovecot] 1.1Beta5 Issue
Timo Sirainen wrote: On Mon, 2007-10-29 at 13:04 -0700, Bill Landry wrote: I have a question about using gdb, as I too had a message that I could not move between folders (however, that was prior to 1.1b5). When you say to gdb the pid of imap process, how do you determine which pid to trace when the output of ps axf is?: 2252 ?Ss 0:00 dovecot 2256 ?S 0:00 \_ dovecot-auth 2265 ?S 0:00 \_ imap-login 2266 ?S 0:00 \_ imap-login 2267 ?S 0:00 \_ imap-login 3048 ?S 0:00 \_ imap 3054 ?S 0:00 \_ imap 3061 ?S 0:00 \_ imap 3063 ?S 0:00 \_ imap 3064 ?S 0:00 \_ imap 3065 ?S 0:00 \_ imap 3066 ?S 0:00 \_ imap 3404 ?S 0:00 \_ imap Well, ps aux at least shows the user (if you use different UIDs). Also if you have an imap process eating 100% CPU that'd be a good clue as well. :) I had already tried the ps u flag, but the user in my configuration is always vuser. Setting verbose_proctitle=yes is also helpful. Ah yes, setting verbose_proctitle=yes helped indeed: vuser [...] imap [EMAIL PROTECTED] xxx.xxx.xxx.xxx] Is there any reason not to keep verbose_proctitle=yes set (like performance issues or something)? Thanks! Bill
Re: [Dovecot] Squirrelmail Problem with 1.1 Beta 3
Jeff Grossman wrote: I just installed 1.1 beta 3 and noticed a problem when sending an e-mail with Squirrelmail. When I hit send, I get the following error in my log: Oct 16 11:35:54 apple dovecot: IMAP(jeff): Disconnected: EOF while appending bytes=1851/5926 Oct 16 11:35:54 apple imapproxyd[9132]: Raw_Proxy(): IMAP server unexpectedly closed the connection on sd 9 I am also using imapproxy. I wasn't sure if that line would help also. In Squirrelmail I get a LOGOUT message when it tries to redisplay the INBOX listing. The message does get sent correctly, but it does not get copied to my Sent Items folder. I went and deleted all of the dovecot.index* files and now I don't get that error anymore, but I now get the following error. The message is now copied to the Sent Items folder. Oct 16 11:44:45 apple dovecot: IMAP(jeff): Cache file /home/jeff/.maildir/.Sent Items/dovecot.index.cache: Newly added field got lost unexpectedly Same here, using Dovecot 1.1 Beta 3 and SquirrelMail 1.4.10a-1.fc7. SquirrelMail with either Firefox 2.0.0.7 or IE 6.0.2900.2180 browser sessions: ERROR: Connection dropped by IMAP server. Query: LOGOUT Log shows: Oct 16 12:08:12 mail dovecot: imap-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Oct 16 12:08:12 mail dovecot: IMAP([EMAIL PROTECTED]): Effective uid=1000, gid=1000, home=/var/spool/vmail/inetmsg.com/ Oct 16 12:08:12 mail dovecot: IMAP([EMAIL PROTECTED]): maildir: data=/var/spool/vmail/inetmsg.com/bill Oct 16 12:08:12 mail dovecot: IMAP([EMAIL PROTECTED]): maildir++: root=/var/spool/vmail/inetmsg.com/bill, index=, control=, inbox=/var/spool/vmail/inetmsg.com/bill Oct 16 12:08:12 mail dovecot: IMAP([EMAIL PROTECTED]): Disconnected: EOF while appending bytes=619/67 Mail gets delivered, but does not show up in the sent folder. Bill
Re: [Dovecot] Auto create folder(s)
mouss wrote: Mouss, your post got me thinking, and after a bit of struggle and testing, I was finally able to come up with a working maildroprc configuration that would first attempt message delivery and then fall-back to creating the maildir as an exception if the maildir did not exist. you could have just asked. I didn't want to post mine since this is not a maildrop list ;-p Yes, of course, but then I would have missed out on all of the fun and frustration of trying to figure this out... ;-) Actually, it was a good exercise, as I had not reviewed my maildroprc configuration file since I originally created it almost 1.5 years ago, and learned some new stuff in the process. Bill
[Dovecot] Problem with manually moving maildir files between folders
dovecot --version 1.1.beta1 With previous versions of Dovecot I could manually move maildir files between folders and the index would automatically update when entering the folder with Thunderbird. However, with 1.1.beta1, I am seeing the following when entering the folder, when attempting to rebuild the indexes via Thunderbird, or when attempting to force the download of all messages in the folder (this is with mail_debug = yes): Sep 30 09:05:55 mail dovecot: imap-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.1.100, lip=192.168.1.37, TLS Sep 30 09:05:55 mail dovecot: IMAP([EMAIL PROTECTED]): Effective uid=1000, gid=1000, home=/var/spool/vmail/inetmsg.com/ Sep 30 09:05:55 mail dovecot: IMAP([EMAIL PROTECTED]): maildir: data=/var/spool/vmail/inetmsg.com/bill Sep 30 09:05:55 mail dovecot: IMAP([EMAIL PROTECTED]): maildir++: root=/var/spool/vmail/inetmsg.com/bill, index=, control=, inbox=/var/spool/vmail/inetmsg.com/bill Sep 30 09:05:58 mail dovecot: imap-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.1.100, lip=192.168.1.37, TLS Sep 30 09:05:58 mail dovecot: IMAP([EMAIL PROTECTED]): Effective uid=1000, gid=1000, home=/var/spool/vmail/inetmsg.com/ Sep 30 09:05:58 mail dovecot: IMAP([EMAIL PROTECTED]): maildir: data=/var/spool/vmail/inetmsg.com/bill Sep 30 09:05:58 mail dovecot: IMAP([EMAIL PROTECTED]): maildir++: root=/var/spool/vmail/inetmsg.com/bill, index=, control=, inbox=/var/spool/vmail/inetmsg.com/bill Sep 30 09:05:58 mail dovecot: IMAP([EMAIL PROTECTED]): open(/var/spool/vmail/inetmsg.com/bill/.SURBL/cur/1190901367.M206487P27879VFD00I006D150C_0.mail.inetmsg.com,S=6648:2,S) failed: Permission denied Sep 30 09:05:58 mail dovecot: IMAP([EMAIL PROTECTED]): Disconnected: Internal error occurred. Refer to server log for more information. [2007-09-30 09:05:58] bytes=210/2225 I'm not sure where the server log is that the last line above is referring to. Here is my running config: dovecot -n # 1.1.beta1: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ syslog_facility: local1 listen: 127.0.0.1 ssl_listen: 192.168.1.37 ssl_ca_file: /etc/ssl/certs/ca-cert.pem ssl_cert_file: /etc/ssl/certs/public-cert.pem ssl_key_file: /etc/ssl/certs/private-key.pem login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_greeting: IMAP Ready login_process_per_connection: no login_greeting_capability: yes login_process_size: 64 login_max_processes_count: 56 mail_location: maildir:/var/spool/vmail/%d/%n mail_debug: yes maildir_stat_dirs: yes auth default: mechanisms: plain login verbose: yes passdb: driver: passwd-file args: /etc/dovecot/users userdb: driver: passwd-file args: /etc/dovecot/users socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix Let me know if there is additional info that is needed. Bill
Re: [Dovecot] Problem with manually moving maildir files between folders
Please disregard, I found the error of my ways... :-\ Bill Bill Landry wrote the following on 9/30/2007 9:23 AM -0800: dovecot --version 1.1.beta1 With previous versions of Dovecot I could manually move maildir files between folders and the index would automatically update when entering the folder with Thunderbird. However, with 1.1.beta1, I am seeing the following when entering the folder, when attempting to rebuild the indexes via Thunderbird, or when attempting to force the download of all messages in the folder (this is with mail_debug = yes):
Re: [Dovecot] Auto create folder(s)
mouss wrote the following on 9/30/2007 3:45 PM -0800:
Fábio M. Catunda wrote:
Charles Marcus escreveu:
On 9/26/2007, Bill Landry ([EMAIL PROTECTED]) wrote:
But with maildrop you still run the process of creating/checking on
every delivery, same thing as dovecot, right?
Correct. If the folder does not exist, maildrop will create it on
first delivery. If the end user deletes the folder, maildrop will
recreate the folder on the next message delivery to that account.
Could it could be written to simply create the folder if the target
folder doesn't exist (ie, if the initial save fails due to
non-existent folder)? Then there would be no performance hit...
There will be a performance hit couse you have to check if the folder
exists or not.
Charles did not say you need to check if the folder exists or not.
With maildrop its pretty easy to do that, but you will have an extra
access to your HD on every message delivery.
Maildrop can run shell commands it the user that runs it have a valid
shell (Debian-exim do NOT have a valid shell, I created another user
just to make the delivery), so, you can run something like
/^Envelope-to:.*/
getaddr($MATCH) =~ /^.*/;
DEST = $MATCH
USER = `/bin/echo $DEST | /usr/bin/cut -f1 -d'@'`
DOMAIN = `/bin/echo $DEST | /usr/bin/cut -f2 -d'@'`
DOEXIST=`[ -d /var/mail/$DOMAIN/$USER/Maildir ]; echo $?`
if ($DOEXIST == 1){
RUN SOMETHING HERE TO CREATE MAILDIRS
}
Thats it!
There's a pattern here. instead of
if (file|dir) (exists|is writable) ... write to ...
use
write to ...
if (error) handle it
This has multiple benefits:
- optimized for the common case
- less vulnerable to race conditions (things happen between the time you
check and the time you do).
- if the file/dir exists/writable, no check to do.
with maildrop, this is done with exceptions (otherwise trying to deliver
would result in an error reported to the MTA).
# try writing
exception {
TO $folder
}
# failed. maybe folder doesn't exist. try creating it
# add whatever checks or actins inside this...
`$maildirmake $folder`
# try writing again
TO $folder
you can adapat this to delivering spam to the Inbox if the user has
deleted his Junk folder (a method to opt-out).
Mouss, your post got me thinking, and after a bit of struggle and
testing, I was finally able to come up with a working maildroprc
configuration that would first attempt message delivery and then
fall-back to creating the maildir as an exception if the maildir did not
exist. The issue I was having was that maildrop was creating mbox files
if the maildir directory structure was not already existing before
sending a message to a new account. I finally found a hint in an e-mail
exchange on the Courier maildrop list:
http://osdir.com/ml/mail.maildrop/2004-10/msg00031.html
The trick was to terminate the path with a forward slash /. I know
this trailing / is a maildir standard, but even a follow up review of
the maildrop maildropfilter documentation didn't reveal this little
tidbit. There was just one reference to maildir format vs. file
(mbox) format in the official maildrop documentation:
http://www.courier-mta.org/maildrop/maildropfilter.html
If /|expression|/ is a directory, *maildrop* assumes that the directory
is a maildir directory. Otherwise, *maildrop* will deliver the message
to a file, formatted in traditional mailbox format. *maildrop* will use
either dot-locking, or flock()-locking when delivering the message to
the file.
However, is the maildir directory structure does not exist, then
maildrop creates an mbox file. With the trailing forward slash,
maildrop will then assume maildir, and if the directory does not exist,
the error condition will trigger and the exception to create the maildir
will be followed.
Hope this help someone else who has been trying to figure this out. And
thanks for the hint, Mouss!
Bill
Re: [Dovecot] Auto create folder(s)
Lars Stavholm wrote: Charles Marcus wrote: On 9/26/2007, Lars Stavholm ([EMAIL PROTECTED]) wrote: if not - maybe this is for you:http://wiki.dovecot.org/PostLoginScripting Even better. But then this would happen for every user, at every login, when all you need is to do it once, when the new user is created... Very true. Postfixadmin does this automatically when the account is created, and this is the ideal time to do such things, no? It is the ideal time, you're right about that. However, to my understanding, Postfixadmin is a web interface for managing postfix config and users in a mysql db. Not very automated. Our users are normal unix users (we do use LDAP) and are not stored in mysql. We use webmin/LDAP for user maintenance. These folders could easily be create dynamically by maildrop, if used as your MDA. I use it as my MDA between Postfix and Dovecot to automatically create spam folders for new accounts and also for delivering mail that exceeds our spam thresholds into the spam folder for end user review. Bill
Re: [Dovecot] Auto create folder(s)
Fábio M. Catunda wrote: Bill Landry escreveu: Lars Stavholm wrote: Charles Marcus wrote: On 9/26/2007, Lars Stavholm ([EMAIL PROTECTED]) wrote: if not - maybe this is for you:http://wiki.dovecot.org/PostLoginScripting Even better. But then this would happen for every user, at every login, when all you need is to do it once, when the new user is created... Very true. Postfixadmin does this automatically when the account is created, and this is the ideal time to do such things, no? It is the ideal time, you're right about that. However, to my understanding, Postfixadmin is a web interface for managing postfix config and users in a mysql db. Not very automated. Our users are normal unix users (we do use LDAP) and are not stored in mysql. We use webmin/LDAP for user maintenance. These folders could easily be create dynamically by maildrop, if used as your MDA. I use it as my MDA between Postfix and Dovecot to automatically create spam folders for new accounts and also for delivering mail that exceeds our spam thresholds into the spam folder for end user review. Bill But with maildrop you still run the process of creating/checking on every delivery, same thing as dovecot, right? Correct. If the folder does not exist, maildrop will create it on first delivery. If the end user deletes the folder, maildrop will recreate the folder on the next message delivery to that account. Bill
Re: [Dovecot] v1.1.beta1 released
Timo Sirainen wrote the following on 9/23/2007 6:55 AM -0800: http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta1.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta1.tar.gz.sig Alpha6 seemed to finally work quite well, so I think it's time for a feature freeze (except for dbox changes). I started a new wiki page to list incompatibilities between v1.0 and v1.1: http://wiki.dovecot.org/Upgrading/1.1 Fixes since alpha6: - deliver + maildir caused UID 0 in transaction log errors - deliver + maildir no longer blocks if dovecot-uidlist.lock file exists. The mail is simply delivered without updating uidlist or indexes. - Quota handling fixes, especially dict quota - etc. Timo, I reviewed the wiki link above, but there was no mention of the following config options no longer being recognized/supported: Starting Dovecot Daemon: Error: Error in configuration file /usr/local/etc/dovecot.conf line 275: Unknown setting: mail_read_mmaped Fatal: Invalid configuration in /usr/local/etc/dovecot.conf [FAILED] Starting Dovecot Daemon: Error: Error in configuration file /usr/local/etc/dovecot.conf line 283: Unknown setting: mmap_no_write Fatal: Invalid configuration in /usr/local/etc/dovecot.conf I commented out mail_read_mmaped and mmap_no_write in my dovecot.conf and Dovecot started without issue. Bill
Re: [Dovecot] Quota handling - v2 - updated FR
Charles Marcus wrote the following on 5/23/2007 4:30 AM -0800: This revised proposal for a Feature Request is the result of my desire to implement quotas, but not have the attendant headaches that inevitably accompany its implementation. Ralf Hildebrandt wrote: I have to face it, my users are retards: Is there any other kind of user? ;) snip Thus I need a feature in dovecot that will tell them via email: Level1: You ALMOST exceeded your quota, you're at 90% now Level2: You're very close to exceededin your quota, you're at 95% now Level3: Would you please clean up now? You're at 99% now What I'd *really* like to see implemented is something along the lines outlined below - but of course, this will depend entirely on whether or not Timo thinks it is doable - or desirable... I'm thinking this would be best handled by the Quota plug-in - either as part of the current one, or as a separate/different one... *** 1. Have a 'special' user-specific folder (by special, I mean like the Drafts, Sent, Templates folders) that dovecot controls. For purposes of this FR, call it the 'over-quota' folder. Question: could the .tmp folder be used for this? No sense in reinventing the wheel if necessary... and then if someone migrated from dovecot to something else, and messages were left in there from an over-quota condition, that other solution would most likely just move these to .new the first time it ran, right? Or, possibly, could dovecot create a new one maybe, .oqt (for over-quota), and store the queued messages there until the over-quota condition was rectified? Anyway, the main thing is, this folder should be essentially hidden from the user so they do *not* have access to it, and should temporarily hold messages that come in that are unable to be delivered due to an over-quota condition. Would seem to me that this would then require quota management over the .oqt folder. What happens if someone is on an extended vacation/leave-of-absence, or leaves the company or ISP and the account is not removed? The .oqt would continue to grow indefinitely. I guess one could implement a max .oqt folder size, but then that would duplicate what quota is already doing anyway. *** 2. Make dovecot aware of and use a special 'Quota Status' message that it uses to inform a user that they are over quota. This message should be able to be customized, with variables (like, for example, it should list the messages that are currently being prevented from being moved to the Inbox - including, optionally, the Subject, the sender, date/time, attachments, size, etc - as well as provide general quota information (ie, how close to or over quota they are, and how much they'd need to delete or move to Local Folders to allow delivery of all of the messages being held), and lastly, any custom information the System Admin wanted to provide - like, maybe, specific instructions for how to move messages to Local Folders, how to request additional storage allowance, etc. *** 3. When user is over quota, have LDA deliver to the folder referenced above (# 1) - (yes, accept the message for final delivery from the sending mta), and then update the Quota Status message and move it to the Inbox. Optionally, a bounce/notification could be generated to the sender, informing them that their message is being 'held in queue' or something to that effect, due to the recipient being over-quota. *** 4. Once the user deletes enough mail to come back under quota, dovecot would then move messages from the 'over-quota' folder to his Inbox. Ok, again, am willing to hear *valid* reasons how/why this is a terrible idea... :) I think a system that simply warns a user like Ralf outlined above seems a better solution to me, and is more resilient and less likely to cause admin headaches due to account maintenance oversights. Just my 2 cents... Bill
Re: [Dovecot] dovecot.org moves to a new server
Timo Sirainen wrote the following on 5/20/2007 1:45 PM -0800: On Sun, 2007-05-20 at 22:53 +0300, Timo Sirainen wrote: So, beginning the move by shutting down Postfix and Mailman.. Wonder if it's working. Wonder what all I forgot.. If things seem broken, please tell me. :) Well, got that posting - so far so good... ;-) Bill
