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

[Sam Roberts]

I can give some background on some of these.

Quoteing address@hidden, on Thu, Jan 22, 2004 at 03:56:06PM +0200:
> ** 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.

Errors occaisonally are written to stdout/stderr now, which is nice for
mh, but isn't such a great idea for the pop and imap daemons, they get
mixed into the protocol stream. Others have noticed this recently.

The debug objects are arguably misnamed, they are ways of handling and
directing human-readable output, maybe they should be called log_t?

Essentially there are two ways interesting things are reported right
now, I think one would be better, and that the debug_t mechanism is more
flexible, so mu_error() could be made to use a debug_t object.

> ** 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).

My understanding was that select and examine are identical, but examine
is readonly, I guess I was mistaken.

CMU has a read-only IMAP archive, its address is on this page:

  http://asg.web.cmu.edu/cyrus/imapd/

My memory is that mailutils couldn't connect to this read-only archive,
but that I thought we could if we did an examine, and supported
anonymous authentication.

>    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. 

If you have a really simple workstation with a basic mail system, you
may want mail.local to deliver all email addressed to "root" and
"postmaster", etc., to a particular user, like yourself. 

> ** 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?

My recollection is that when you give a buffer to output APIs, you give
the total size. But the size_t* that returns the required size, returns
the required size, minus the NUL. The units are different, in a sense.

> ** run as daemon, sieving mail on arrival 
> 
> I'm not quite sure whether we need it, since mail.local already
> provides this functionality.

What if you can't convince the IT department to run GNU mail.local? :-)

There is no way to filter mail on unix systems right now that works well
in a corporate environment where you want to use IMAP for mail storage.

For example, all the people (like me) who work in companies with
Exchange or Lotus Domino mail servers but who read mail using IMAP on
their Linux boxes. How can I filter mail? The standard answer is always
the same: run fetchmail, make it deliver using GNU mail.local or
procmail, do your filtering there.

But, I want to leave my mail on the IMAP server, it allows me to read my
email from anywhere inside or outside work! Technically, the company
security policy requires me to do so, as well, but I'm ignoring that.  ;-)

So: I want to filter, but I want to leave my mail on the IMAP server,
and I can't use the Notes filter facilities because they a) suck, and b)
aren't accessible from non-windows boxes, and c) even with windows, only
work when you actually have the Notes client running and hit "refresh
mailbox".

If sieve ran as a daemon, it could poll my IMAP inbox periodically, and
apply my filter rules.

Also, if sieve supported the proposed sieve extensions to check whether
email was spam, I could discard spam, too. That would be bliss, because
the company's level of tolerance for spam is way higher than mine (I'd
like to reject all html-only email, for example). I took a quick check
to see how hard it would be to extend GNU sieve to support spamcheck a
half-year ago, but it wasn't obvious how to do so. CMU's sieve was much
simpler, and even with that I could barely make progress in the few
hours a week I have.

Too bad, there is a fairly large body of people of people who've posted to
mailing lists like mutt-users wanting to do this.

IMO, its the killer app for GNU mailutils - the rest (imap server, pop
server, mh, etc.) looks to me like a clone of existing software that
mainly differs by its licence. I could be totally wrong on that, maybe
I don't see the cool things when I serve one mailbox from a local
workstation!

Btw, I also used to use sieve as a simple fetchmail: I added a loop to
it's main(), and it pulled my mail down to my box every few minutes,
after discarding email that looked like it might be spam (anything with
viagra in the header, for example).


** One extra todo: the bug reported lately where mail.remote sends mail
to all addresses in the message, not just the addresses explicitly
listed on the command line. This isn't sendmail compatible, and the
effect is that when I "bounce" mail from inside mutt, it comes back to
me!

This is new behaviour, it didn't used to do this, and makes mail.remote
unusable to anybody wanting to bounce mail. Last fall this change made
it into Debian unstable, and caused me a fair amount of debugging pain,
since I was convinced that it was the Notes mail server screwing up,
again. I'd updated my debian at about the same time they'd updated the
servers. I shouldn't have done that.

Anyhow, congratulations Sergey, it looks like mailutils is becoming
quite solid and popular. Nobody puts as much energy into patches as
they've been doing unless they really like something!

Happy New Year, all of you.
Sam