On Tue, Jan 23, 2001 at 11:30:57AM +0100, Heinrich Langos wrote:
> On Mon, Jan 22, 2001 at 03:53:44PM +0000, Dave Pearson wrote:
>
> > 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.
I think I see the problem and the source of the misunderstanding. I wasn't
saying that the documentation was correct, I was saying that the "new mail"
detection *was* reliable within the limits of it's reported abilities. While
I don't have a problem with those limits (I've configured my backup utility,
for example, to preserve time stamps) it doesn't follow that I think that
development should stop right there.
> 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.
That would seem like an obvious solution. However, I suspect you're starting
to get into design problems that have caused the mutt developers to dismiss
extending this before. The point being that you still end up with a "it
sometimes works, but not always" solution.
In other words you still get something that is "unreliable" for certain
values of "unreliable".
> > I don't use fetchmail but the above still isn't true. email does arrive
> > in large batches for me.
>
> How comes?
I'm on a dialup connection. Mail only flows into my box when I dial into my
ISP <URL:http://www.demon.net/>.
> 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?
They affect all mailboxes.
> > ,----
> > | 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 think it's more likely you've got a mutt configuration problem.
> 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.
This seems to be your problem. The mutt list should be in your `subscribe'
list, not your `list' list. If the `index_format' isn't what you'd like it
to be that's what you should change.
Here's the index format I use for mailing lists:
,----
| # This is the index format for mailing lists.
| set index_format="%4C %Z %{%b %d} %-15.15n (%4l) %s"
`----
You can see the whole of my ~/.muttrc setup on my web site. I'm not
suggesting it's actually useful but the list/non-list handling that I have
might give you some ideas.
--
Dave Pearson: | mutt.octet.filter - autoview octet-streams
http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards
Mutt: | muttrc2html - muttrc -> HTML utility
http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
