headers
Zoong Pham | 1 Jun 2004 05:44
Picon

IMAP login name conversion

Hi all,

Out IMAP client (Outlook and others) use login name like joedirt <at> domainname.com

I need dovecot to convert it to joedirt-domainname_com since that is the local login name.
Can someone give me a hint how to do that?
Is there any simple way to do it or do I have to modify any source code?

Thanks,
Zoong
Permalink | Reply | 1 comment |
headers
Christian Balzer | 1 Jun 2004 06:31

Re: Re: 0.99.10.5 release candidate


Brian wrote:
>On Mon, May 31, 2004 at 07:24:41PM +0300, Timo Sirainen wrote:
>> >   -ERR This message has been deleted by someone else!
>> > 
>> > or something like that. I can live with that.
>> 
>> That's what Dovecot does now.
>> 
>> But that isn't the worst if you have no locks at all. You still want to
>> lock the mailbox while it's being read or written, otherwise there would
>> be either mailbox corruption (two writers at the same time) or user
>> could be sent corrupted mails (one reading while another is writing).
>
>Oh yes, sorry. I now think "Maildir" exclusively, and forget that some
>people still use mbox :-)
>
Converting tens of thousands of users (in a fast and transparent as 
possible fashion) is no easy feat.

>Having seen mailservers where users leave 10-20MB of mail on the server, in
>a single mbox file, where the POP3 server has to read through the whole mbox
>every time they login just to count how many messages are in there... well,
>that's enough for me to give up on mbox.
>
Tell me about it. ;P

Note though that maildir still leaves you vulnerable to some extent 
with large individual mails (we allow for 10MB per message max here). 
The atomic tmp -> new move prevents of course the case of multiple
(Continue reading)

Permalink | Reply | 8 comments |
headers
Brian Candler | 1 Jun 2004 10:00
Picon
Favicon

Re: Re: 0.99.10.5 release candidate

On Tue, Jun 01, 2004 at 01:31:09PM +0900, Christian Balzer wrote:
> >Oh yes, sorry. I now think "Maildir" exclusively, and forget that some
> >people still use mbox :-)
> >
> Converting tens of thousands of users (in a fast and transparent as 
> possible fashion) is no easy feat.

It's not hard in principle.

courier-imap has a feature called "loginexec" (actually something I wrote
and managed to persuade Sam to include).

Whenever you login, if a file called "loginexec" exists within the Maildir
and is executable, it is run. If it terminates with a zero exit code then it
is deleted.

So in your case, within each Maildir you put a small loginexec script which
performs the conversion from mbox to Maildir. The next time this user logs
in, their mail gets converted, and then the loginexec file is deleted.

What I was using loginexec for was to transfer mail from a remote POP3
server; I wrote a small C program which pulled mail from the old server
(given the hostname, username and password) and dropped it into the local
Maildir. I've successfully migrated hundreds of thousands of mailboxes in
this way, where I don't even have shell access to the old POP3 server.

> Note though that maildir still leaves you vulnerable to some extent 
> with large individual mails (we allow for 10MB per message max here). 

Sorry, I don't follow. There's no need for the pop3/imap server to *read*
(Continue reading)

Permalink | Reply | 7 comments |
headers
Brian Candler | 1 Jun 2004 10:12
Picon
Favicon

Re: Re: Small change to make dovecot pop3uw-imapmigrationfriendly

On Tue, Jun 01, 2004 at 12:06:49AM +0200, Matthias Andree wrote:
> > I don't believe they have any permission to assume this. If the server
> > happens to maintain this ordering, well, the client could attempt some sort
> > of dubious binary-chop to work out where new mail has arrived (since some or
> > all messages may have been deleted)
> 
> Yup, given the lack of a range for UIDL, this is necessary.

I wouldn't say "necessary" - I'd say "a possible optimisation not sanctioned
by the RFC"

But anyway, I'm sure you'd agree that clients are not *required* to perform
this optimisation. So, some (many?) clients do ask for a complete UIDL
listing every time they connect. If there are 1000 old messages in the
mailbox, then you definitely don't want to open and read every one to find
its X-POP3-UID header. Equally, clients may ask for a complete LIST of the
maildrop. Again, you don't want to open and read every message file just to
calculate its size.

courier-imap used to do this, and the load was enormous from clients which
left mail on the server. Once it introduced a cache file
(courierpop3dsizelist), this problem went away. (This file also stores the
UID; previously it had used the Maildir filename as UID, but this turned out
to be too long for some clients)

I'm not trying to be pro-courier-imap here, by the way. I'd be happy to have
a path to bail out; but there are some key features that I need to have
first. One is Maildir++ quotas, and another is efficient POP3 operation in
the presence of clients who leave mail on server, and issue a full maildrop
UIDL and/or LIST each time they connect. A mechanism for transparent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Jaekel | 1 Jun 2004 12:13
Picon

1.0-test14: no sendfile() in Solaris 8

Aloha.

The current CVS snapshot and 1.0-test14 will not build on Solaris 8
because it does not provide a sendfile() funtion.  It just has sendfilev().
Solaris 9 has sendfile(), though.

Using the old sendfile-util.c from 1.0-test1 and setting HAVE_SOLARIS_SENDFILEV
instead of HAVE_LINUX_SENDFILE in config.h works.

Greetings,
      Andy.
Permalink | Reply | 2 comments |
headers
David Champion | 1 Jun 2004 13:08
Favicon

Re: 1.0-test14: no sendfile() in Solaris 8

* On 2004.06.01, in <5.2.1.1.0.20040601115849.02e8ae28 <at> fredda.webgods.de>,
*	"Andreas Jaekel" <jaekel <at> webgods.de> wrote:
> Aloha.
> 
> The current CVS snapshot and 1.0-test14 will not build on Solaris 8
> because it does not provide a sendfile() funtion.  It just has sendfilev().

It's available via patch -- perhaps 111297-01.

http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=111297&rev=01

I have not tried building 1.0-test14 with it, though.

--

-- 
 -D.    dgc <at> uchicago.edu                                  NSIT::ENSS
        No money,  no book.  No book,  no study.  No study, no pass.
        No pass, no graduate. No graduate, no job. No job, no money.
             T h e   U n i v e r s i t y   o f   C h i c a g o
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 1 Jun 2004 13:35
Picon
Picon
Favicon

Re: 1.0-test14: no sendfile() in Solaris 8

On 1.6.2004, at 13:13, Andreas Jaekel wrote:

> The current CVS snapshot and 1.0-test14 will not build on Solaris 8
> because it does not provide a sendfile() funtion.  It just has 
> sendfilev().
> Solaris 9 has sendfile(), though.

Doesn't the configure detect that you don't have it? It shouldn't 
define HAVE_SOLARIS_SENDFILE if it isn't there (if sendfile library 
doesn't have sendfile() function).
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 1 Jun 2004 13:38
Picon
Picon
Favicon

Re: IMAP login name conversion

On 1.6.2004, at 06:44, Zoong Pham wrote:

> Out IMAP client (Outlook and others) use login name like 
> joedirt <at> domainname.com
>
> I need dovecot to convert it to joedirt-domainname_com since that is 
> the local login name.
> Can someone give me a hint how to do that?
> Is there any simple way to do it or do I have to modify any source 
> code?

What passdb and userdb do you use? Unless you're authenticating from 
SQL you probably have to modify the source.
Permalink | Reply | 0 comments |
headers
Olivier Tharan | 1 Jun 2004 14:11
Picon
Picon
Favicon

Re: 0.99.10.5 release candidate

* Timo Sirainen <tss <at> iki.fi> (20040527 19:01):
> >Oh yes it is. I have never taken the trouble to examine the
> >figures closer. Is it a problem or is it normal?
> 
> Would attached patch help? Wasn't a real problem if it does, but then I 
> have to keep in mind that NFS implementations can do this too to avoid 
> real problems elsewhere..

With 0.99.10.5 and this patch, things seem to have settled to
normal and I do not have spurious log messages anymore.

I think I will soon put this server into production. Thanks!

--

-- 
olive
Permalink | Reply | 0 comments |
headers
Timo Sirainen | 1 Jun 2004 14:15
Picon
Picon
Favicon

Re: Re: 0.99.10.5 release candidate

On Tue, 2004-06-01 at 11:00, Brian Candler wrote:
> > The atomic tmp -> new move prevents of course the case of multiple 
> > (inbound, SMTP) writers. Alas following a recent conversation in this
> > ML with Timo all that saves your butt and mail integrity in the case
> > when a large message being read by slow client gets deleted by another
> > client (dovecot instance) is Saint BufferCache. ;)
> 
> I don't understand that comment either. If process A has a file open, and
> process B deletes it, the file remains (in its entirety) on the filesystem
> until process A closes it. That's not buffer caching; that's the semantics
> of unlink().

I think Christian was talking about NFS, it doesn't follow the
"semantics of unlink()". Rather if a file is deleted and it's tried to
be read later you'll get ESTALE.
Permalink | Reply | 6 comments |

Gmane