[Dovecot] Disable imap proxy access

[Dominique Feyer]

Scott Silva a écrit :
> on 10/3/2007 3:25 PM Bazy spake the following:
>> Ed W wrote:
>>>> How to disable pop3 and imap access during the data migration process
>>>> (duration 5 minutes to 10 minutes). Can i send a custom error
>>>> message to
>>>> our users ?
>>>>   
>>>
>>> I don't recall the exact details, but I think both options are possible
>>> if you check the dovecot wiki.  There is a good study regarding the
>>> proxy stuff, and some notes on sending custom errors back (along with a
>>> note that it's not supported on many clients)
>>>
>>> If you use SQL then you could simply change the query temporarily
>>>
>>> Also when I do my migration I change the permissions on the home
>>> folders
>>> first (root:root say) - this way if I muck something up they don't get
>>> logged into the old mailbox.  Then I reset the permissions back on the
>>> new server and update the proxy settings.  This also gives a random
>>> error back to the client in the meantime if they try and log in.
>>>
>>> I should think that the above could even be scripted and run per
>>> mailbox
>>> for a very subtle downtime period... I use rsync once while the mailbox
>>> is online, then change perms so that the user can't login, then do a
>>> final rsync to get any changes across.  I didn't check whether there is
>>> a problem with an existing connection still accessing the data after
>>> the
>>> perms were changed though...
>>>
>>> Good luck
>>>
>>> Ed W
>>
>> I'm not an perl expert, but... you could create a script that listens on
>> port 143, and one for 110, that acts as a server. So right after ".login
>> <username> <password>" the perl script will print an error, telling the
>> client that the server is down for maintenance or something like that.
>>
>> Like when you get the 550 error in smtp and it says "die spammer" :).
>>
>> I think you can use IO::Socket::Telnet.
>> Take a look over these scripts:
>> http://www-user.tu-chemnitz.de/~uro/perlgoodies/server/
>>
>> It's just an idea...
>>
> Or just stop the dovecot running on the proxy and the connections will
> just die.
>
Thanks for your answer, finaly the best solution is a simple chmod 0 on
the /var/mail/domain.com ... migration, chmod 700 on the new disk,
update the DB ... and wait about the cache TTL of the dovecot deliver ;-)

One bash script and 80% of my 10'000 domains can be migrated to the new
disk in less than 5 minutes.

Thanks you

Dom