[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-mailutils] Request for comments on our TODO.

From: Sergey Poznyakoff
Subject: [bug-mailutils] Request for comments on our TODO.
Date: Thu, 22 Jan 2004 15:56:06 +0200

Hello everybody,

While revising out TODO list I have found several items that appear
to me unnecessary and/or unclear. I would like to invite all mailutils
developers to express their opinions on these. Of course, regular
subscribers are quite welcome to participate in the discussion.

   I. The list of items I would like to delete from the TODO:
[* mailbox section] 

** write a fnmatch() that doesn't respect []

What should this serve for? One can always escape [] anyway. 

** print errors to a debug object, by default

That would be a very dangerous thing to do, since disabling debugging
mode would turn off error messages as well.

** does IMAP do an EXAMINE instead of a select if the mailbox is being
opened readonly? Does list return whether a mailbox is readonly?
Check against CMUs anon server, it is a read-only mailbox.

There's no reason to do EXAMINE, since it would effectively disable most
of the IMAP functionality (e.g. FETCH will not work).

** support POP3S and IMAPS mailers (ports 995/993).

I don't believe this is necessary. Both pop3d and imap4d already
support TLS in accordance with RFC 2595. If one wishes to
use them over an initially encrypted channel, one can easily
achieve this by using ssh tunnel. Besides, RFC explicitly discourages
using dedicated ports for this purpose in favor of the STLS/STARTTLS

[* utilities section]

** utility to move all mail from one mailbox to another, like mbox to
IMAP, preserving all flags that are possible. can sieve do this, or do
I need a mbox-copy() utility?

The following sieve script will do the job:

include "fileinto";
fileinto "another/mailbox";

   II. The list of the suspicious items

** need to be able to map some addresses (like mail to "root") to a
user for the box, a la nullmailer, perhaps

Not quite sure what this means. 

** mu_cpystr - the size_t* size outputs only give strlen(), not the
actual length?

mu_cpystr (mailbox/mutil.c:237) does the same work as the usual strcpy,
but it also respects the size of the destination buffer. It returns the
number of bytes actually written to the destination *not counting
the terminating zero*. If the destination is NULL, the function 
returns the number of bytes that should have been written, again
not counting the terminating zero. In both cases, its return is
consistent. Besides, mailutils heavily relies on it and changing
it will require a considerable amount of work. So, what should we
change and do we really need it?

[* sieve section]

** run as daemon, sieving mail on arrival 

I'm not quite sure whether we need it, since mail.local already
provides this functionality.

Your opinions, please.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]