Thanks :)
> I'm no programmer but was wondering if it may be possible to add
> Maildir delivery capability?
Hmm, I've never messed with Maildir.
Some questions I need to answer:
-What file/directory structure does Maildir create?
-Can multiple mailboxes be stored in the same Maildir location?
-And will the single location maintain a separate folder for each mailbox?
-Or will we need to set up different mail directories for each mailbox?
Let me know if you know the answers to any of these questions.
Avast!
Daniel Roesler
dia...@gmail.com
>
> On Wed, Jan 7, 2009 at 11:16 AM, My <mybsd+i...@postpro.net> wrote:
> >
> > ... <snip> ...
>
> > I'm no programmer but was wondering if it may be possible to add
> > Maildir delivery capability?
>
> Hmm, I've never messed with Maildir.
>
> Some questions I need to answer:
> -What file/directory structure does Maildir create?
Maildir/{cur,new,tmp}
> -Can multiple mailboxes be stored in the same Maildir location?
Yes. Also, Getmail will deliver to nested Maildirs (as long as the Maildir
exists before the delivery attempt.
> -And will the single location maintain a separate folder for each mailbox?
> -Or will we need to set up different mail directories for each mailbox?
>
You should be able to do either with parallel Maildir folder sets in a single
directory (as you now do for MBoxes) or by nesting the Maildir folder sets to
ape the IMAP account folder layout.
> Let me know if you know the answers to any of these questions.
>
Hope I have given you the requested answers.
... <snip> ...
Thank for your prompt reply and please let me know if I can be of any
further help if you decide to implement Maildir support.
My best regards.
--
My
>
> Ok, I played around with the maildir option for getmail, and you will
> need separate maildir folders for each IMAP mailbox selected.
>
> When getmail downloads new mail, it just dumps it into the new (or
> Inbox) of the selected Maildir folder. So downloading multiple
> mailboxes, either through multiple rc files or a tuple in on one rc
> file, will cause them to get lumped together in the Maildir folder.
> Therefore, separate folders must be created to keep mailboxes
> separate.
>
> So you end up with:
> /Maildir/cur/
> /Maildir/new/
> /Maildir/tmp/
> /Maildir/box1/
> /Maildir/box2/
> /Maildir/box3/
>
I Believe I mentioned this before, but just to reiterate, if you do implement
Maildir support, it would be nice (when the whole IMAP account is being
fetched) to be able to create nested Maildirs matching the folder layout
on the IMAP server, as follows:
/Maildir/cur/
/Maildir/new/
/Maildir/tmp/
/Maildir/Maildir/cur/
/Maildir/Maildir/new/
/Maildir/Maildir/tmp/
/Maildir/Maildir/Maildir/cur/
/Maildir/Maildir/Maildir/new/
/Maildir/Maildir/Maildir/tmp/
And also:
/Maildir/cur/
/Maildir/new/
/Maildir/tmp/
/Maildir/Maildir1/cur/
/Maildir/Maildir1/new/
/Maildir/Maildir1/tmp/
/Maildir/Maildir2/cur/
/Maildir/Maildir2/new/
/Maildir/Maildir2/tmp/
> The root level /cur/, /new/, and /tmp/ folders are just there to
> ensure correct importing to Evolution, Thunderbird, etc. Nothing will
> be downloaded to them. Each mailbox folder will have their own set of
> /cur/, /new/, and /tmp/ folders. This is where getmail will download
> them.
>
(Not wanting to sound pedantic but just to clarify concepts as I understand
them) the {cur,new,tmp} sub-folder structure is part of the Maildir standard
as it was developed by Dr. Bernstein of QMail fame and has more to do with
how some MTAs and LDAs deliver mail locally and how some IMAP/POP
servers manipulate delivered messages than with importing messages by
MUAs.
Not sure about evolution but Thunderbird cannot handle Maildirs.
Pine, Mutt and KMail (my current favorite) among others, can actually
read from and write to Maildirs without importing the messages.
> Here's another question. Getmail has the ability to send messages to
> multiple destinations. Do we want the option to download both to mbox
> and maildir, or just one of them at a time? I'm a fan of the
> one-at-a-time (I don't see a backup program needing a
> multi-destination feature).
>
I would agree with you that it should be either or (you can always do
separate runs if you want both types of storage for the same account).
... <snip> ...
Please keep up the good work Daniel.
Okay, so in addition to making a Maildir folder, it needs to be able
to create mailboxes several layers deep. For example, [Gmail]/Trash
would cause this to create:
/Maildir/cur/
/Maildir/new/
/Maildir/tmp/
/Maildir/[Gmail]/Trash/cur/
/Maildir/[Gmail]/Trash/new/
/Maildir/[Gmail]/Trash/tmp/
Does this example need a [Gmail] maildir setup even though you don't
have the [Gmail] mailbox selected?
/Maildir/[Gmail]/cur/
/Maildir/[Gmail]/new/
/Maildir/[Gmail]/tmp/
In the current version (0.1), it simply changes directories to
underscores (i.e. [Gmail]/Trash becomes [Gmail]_Trash), so nesting
directories would require a fundamental change in how mailboxes are
stored. That might be a good idea. I'll put it on the Roadmap for
version 2.
> (Not wanting to sound pedantic but just to clarify concepts as I understand
> them) the {cur,new,tmp} sub-folder structure is part of the Maildir standard
> as it was developed by Dr. Bernstein of QMail fame and has more to do with
> how some MTAs and LDAs deliver mail locally and how some IMAP/POP
> servers manipulate delivered messages than with importing messages by
> MUAs.
>
> Not sure about evolution but Thunderbird cannot handle Maildirs.
> Pine, Mutt and KMail (my current favorite) among others, can actually
> read from and write to Maildirs without importing the messages.
Ya, you have to set up a new account with Evolution and set the
directory of that account to your Maildir, so it's not really
"importing". I didn't know what to call that. I'm just thinking about
how I would go about checking to see that the mail actually got
delivered.
In other news, it will probably be a few weeks before I get around to
working on version 0.2, so you are welcome to play around with
patching before I get around to it.
Avast!
Daniel Roesler
dia...@gmail.com
... <snip> ...
>
> Okay, so in addition to making a Maildir folder, it needs to be able
> to create mailboxes several layers deep. For example, [Gmail]/Trash
> would cause this to create:
> /Maildir/cur/
> /Maildir/new/
> /Maildir/tmp/
> /Maildir/[Gmail]/Trash/cur/
> /Maildir/[Gmail]/Trash/new/
> /Maildir/[Gmail]/Trash/tmp/
>
That would appear to be the case. Although depending on the MUA, you
may or may not have to include the {cur,new,tmp} sub-folders that contain
other folders but no messages.
By the way, the "new" Maildir++ layout used by Courier, Dovecot, etc.
is basically flat. Sub-folders are not nested (except for {cur,new,tmp}).
A dot "." separator is used Instead of a forward slash "/" separator.
Your above example would appear something like the following:
/Maildir/cur/
/Maildir/new/
/Maildir/tmp/
/Maildir/.[Gmail]/cur/
/Maildir/.[Gmail]/new/
/Maildir/.[Gmail]/tmp/
/Maildir/.[Gmail].Trash/cur/
/Maildir/.[Gmail].Trash/new/
/Maildir/.[Gmail].Trash/tmp/
> Does this example need a [Gmail] maildir setup even though you don't
> have the [Gmail] mailbox selected?
> /Maildir/[Gmail]/cur/
> /Maildir/[Gmail]/new/
> /Maildir/[Gmail]/tmp/
>
I imagine that it would depend on the purpose of the fetch. For a full local
replica of the IMAP account, yes. If all that is desired is one or more folder
sub-trees, probably not.
> In the current version (0.1), it simply changes directories to
> underscores (i.e. [Gmail]/Trash becomes [Gmail]_Trash), so nesting
> directories would require a fundamental change in how mailboxes are
> stored. That might be a good idea. I'll put it on the Roadmap for
> version 2.
>
Good to hear. Would that actually be version "2." or version "0.2"?
... <snip> ...
> In other news, it will probably be a few weeks before I get around to
> working on version 0.2, so you are welcome to play around with
> patching before I get around to it.
>
As you are developing this is as a voluntary open source project , there is
no particular rush.
I'm not versed in Python but, if and when I have time, I'll see how I can break it. :)
... <snip> ...