On Mon, Jan 22, 2001 at 03:53:44PM +0000, Dave Pearson wrote:
> On Mon, Jan 22, 2001 at 04:16:25PM +0100, Heinrich Langos wrote:
>
> > Dave, you may stop reading. The rest will only bother you and further
> > waste your time.
>
> With an attitude like that it's not surprising that you're confused about
> what I've been saying. Read what I've actually said, look for the reasonable
> reason this time, then you might find that I've said nothing against the
> idea of providing the feature you'd like to see.
Well, then I'm sorry. I guess I took your repating of "the docs are
right" the wrong way. I was not trying to convince you that the docs
are wrong and I took your insiting on the thier correctnes as conviction
that there is nothing to improve.
That really upset me. Sorry, once again.
> > ok ok .. just wanted to make sure we talk about the same thing. i guess
> > most users don't have huge mailboxes since mbox-hooks are a such a nice
> > way to move older mail out of mailboxes after some time. anyway...
>
> But we can't actually make such a guess can we? You also seem to be under
> the impression that I don't archive older mail. I do. Arguing that "most
> users" do what you'd like them to do doesn't detract from the point that
> there can and will be large mailboxes defined by the mailbox command. When
> designing new features it makes sense to work to the extreme case, not the
> average case (especially when you can't really know what the average is).
>
I was just under the impression that incoming mailboxes usually are
small. Though my choice of words may have been inappropriate and insulting.
I admit that arguing for "most users" in the absents of statistic data
is, well, arguable. :-)
In order to deal with extremly big mailboxes I proposed that "jump to
the previously know end" strategy. But dealing with large amounts of
incoming mail could be a problem.
Any ideas? I mean other than limiting the amount to scan like
"max_growth_to_scan_for_new_mail=200k"
If a mailbox had grown more than 200k since the last scan you would
only mark the previously known amount of new mail with a "+" and
postpone exact scanning and updating of numbers till the user entered
that folder and you had to scan it anyway.
> > jump to the previously know end of the file and scan how may new mails
> > arrived. that shouldn't be too much of a burden for a system. since mails
> > usually don't arrive in large batches. (i know, fetchmail users will hate
> > me.)
>
> I don't use fetchmail but the above still isn't true. email does arrive in
> large batches for me.
How comes? Are these large batches usually source initiated (like
moderated mailinglists) or are they collected at another MX host
before they get transfered to your mail server? In other words: Will
they affect all/many of your mailboxes or usually just one ore two?
> > to prevent errors due to other programms, maliciously changing your
> > mailboxes and increasing its size, you could check for that.
> > depending on your level of paranoia you could do anything.
> > from
> > A) checking if a new mail starts exactly where it is supposed to start
> > (at the previously know file-end, which you do anyway by starting
> > parsingthere)
>
> That sounds like a good solution for the problem I highlight above.
I hope it is. It would save a lot of trouble.
>
> PS: You still appear to have a configuration problem with your copy of mutt:
>
> ,----
> | Mail-Followup-To: heinrich, [EMAIL PROTECTED]
> `----
yeap .. unfortunatly i don't know how to review the headers before
sending an email.
could it be a problem with the local sendmail configuration?
i've got these in my muttrc but it doesnt realy help.
-----------------
set edit_hdrs
ignore *
unignore from: subject to cc mail-followup-to \
date x-mailer x-url
-----------------
furthermore i've got "[EMAIL PROTECTED]" on my "lists". but not on
"subscribe" since i like to see the sender instead of the list address
in the index. if putting it on "subscribe" will solve the
"Mail-Followup-To:"-problem i will do that and change index_format
accordingly.
TIA
-heinrich
