Re: [Mutt 1.5.18] /usr/local/share/doc/mutt/manual.txt is XML!

2008-05-28 Thread Rocco Rutte

Hi,

* Wilkinson, Alex wrote:


 head -3 /usr/local/share/doc/mutt/manual.txt
 ?xml version=1.0?
 !DOCTYPE html PUBLIC //W3C//DTD XHTML 1.0 Transitional//EN 
ttp://www.w3.org/
 TR/xhtml1/DTD/xhtml1-transitional.dtd


Did you compile mutt yourself? If yes, from what source (e.g. tarball or 
mercurial)? Do you have any of these installed: lynx, links, w3m?


Rocco


Re: [Mutt 1.5.18] /usr/local/share/doc/mutt/manual.txt is XML!

2008-05-28 Thread Wilkinson, Alex
0n Wed, May 28, 2008 at 10:11:08AM +0200, Rocco Rutte wrote: 

Did you compile mutt yourself? If yes, from what source (e.g. tarball or 
mercurial)? Do you have any of these installed: lynx, links, w3m?

From FreeBSD ports [/usr/ports/mail/mutt-devel].

Yes, I have all 3 lynx, links, w3m.

 -aW

IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.




Email addresses with spaces

2008-05-28 Thread Clayton Scott Kern
I'm not sure if this is the right place to address this.

I use fetchmail - sendmail - procmail - mutt.

I have problem with emails that have spaces in the user name.
For example  joe [EMAIL PROTECTED]

Mutt doesn't display them in the index page.  For now, I've been editing
the mbox file and putting an underline in the email address.

I've looked through the manual and if there's a setting to handle this,
I'mm missing it.  Or should I be handling this with either procmail or
sendmail?

I'm using mutt version 1.4.2.3 on a FreeBSD 6.3 system.

Thank you in advance.

Scott


Re: Email addresses with spaces

2008-05-28 Thread Michelle Konzack
Am 2008-05-28 10:43:41, schrieb Clayton Scott Kern:
 I'm not sure if this is the right place to address this.
 
 I use fetchmail - sendmail - procmail - mutt.

First of all:  Why do you use sendmail between
   fetchmail and procmail?

 I have problem with emails that have spaces in the user name.
 For example  joe [EMAIL PROTECTED]

Such messages should be rejected by your ISP on SMTP-Level since they
are invalid.

 Mutt doesn't display them in the index page.  For now, I've been editing
 the mbox file and putting an underline in the email address.
 
 I've looked through the manual and if there's a setting to handle this,
 I'mm missing it.  Or should I be handling this with either procmail or
 sendmail?

Better ask you ISP to REJECT them.

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature


Re: Email addresses with spaces

2008-05-28 Thread Charles Cazabon
Michelle Konzack [EMAIL PROTECTED] wrote:
 Am 2008-05-28 10:43:41, schrieb Clayton Scott Kern:
  I'm not sure if this is the right place to address this.
  
  I use fetchmail - sendmail - procmail - mutt.
 
 First of all:  Why do you use sendmail between
fetchmail and procmail?
 
  I have problem with emails that have spaces in the user name.
  For example  joe [EMAIL PROTECTED]
 
 Such messages should be rejected by your ISP on SMTP-Level since they
 are invalid.

They're only invalid if they're not encoded correctly.  RFC822/2822 allows
spaces to be included if they're part of a quoted string.

i.e., this is an rfc822-valid header field:

  To: joe doe@mymail.com

Mutt handles this case correctly.

Either the message you're retrieving with fetchmail has the header encoded
incorrectly by the server it's retrieving from, or one of the programs you're
passing it through (including fetchmail) is munging the message header and
leaving it invalid.

You can check whether the message is already invalid on your mail server by
capturing the POP/IMAP conversation off the wire when you run fetchmail.  If
it's clean there, you need to figure out which of your mail-processing
programs is breaking it.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---


Re: set time_inc= ?

2008-05-28 Thread Wilkinson, Alex

Pure gold kyle! Thanks stacks for such a detailed explanation.

forgive my top-posting

 -aW

0n Tue, May 27, 2008 at 10:49:29PM -0500, Kyle Wheeler wrote: 

On Wednesday, May 28 at 09:56 AM, quoth Wilkinson, Alex:
 Ok so in the manual time_inc says:

  this variable controls the frequency with which progress updates 
  are displayed. It suppresses updates less than ``time_inc'' 
  milliseconds apart. This can improve throughput on systems with 
  slow terminals, or when running mutt on a remote system.

 Ok so what is meant by progress updates ?

Whenever mutt does something that can take a while (such as download a 
large message, open a very large mailbox, send a large message, etc.), 
it displays status information about that task at the bottom of the 
terminal. That status information is a progress update.

 I'm still trying to work out what time_inc gives me :(

time_inc is a solution to a problem that some people have had. Here's 
how things used to work:

Progress updates used to be on a once every N things basis (this is 
the $read_inc setting). For example, when opening a large mailbox, you 
could tell mutt to post a new progress update every 10 messages (ten 
is the default, but it could be any number). Thus, after parsing ten 
messages, mutt would change the message at the bottom of the terminal 
(update it) to tell you that another ten messages had been parsed. 
Now, generally speaking, mutt can read messages out of a mailbox 
pretty darn fast. Let's say, just for discussion purposes, that on you 
computer, mutt can read 1000 messages every second. With a $read_inc 
setting of 10, that means mutt will attempt to update the terminal's 
contents 100 times per second, or once every 1/100th of a second. 
That's pretty darn fast---you can't even read that fast---and some 
terminals just aren't that fast. If your terminal is slow and can't 
change it's display that quickly, you're spending a lot of time 
(comparatively speaking) updating your terminal and you aren't even 
getting anything useful out of it because the terminal can't display 
updates that quickly. It can even slow down how quickly mutt opens a 
mailbox, because mutt can't change the display until the previous 
display has finished. If your terminal has a reaction time of 1/25th 
of a second, that means updating the terminal 100 times takes 4 
seconds! That's no good, because that forces mutt to take four times 
as long to open a 1000 message mailbox (which it could have opened in 
1 second, if it didn't have to wait for the terminal). With me so far?

Previously, to compensate, you would do something like increase the 
read_inc setting to, say, 100. Thus, mutt would attempt to update the 
terminal's contents only 10 times per second. That's still plenty 
fast, on your 1/25th second terminal, it only takes 0.4 seconds, which 
means mutt can easily meet its deadline of opening the 1000 message 
mailbox in 1 second.

But now imagine that in addition to opening a local mailbox, which 
mutt can open quickly, you also want to open a remote IMAP mailbox, 
which mutt can only pull down much more slowly. Let's say, just for 
argument's sake, that mutt can only read 20 IMAP messages every 
second. If your $read_inc setting is 100, that means mutt has to read 
100 messages before it tells you how far along it is, which means that 
in the IMAP situation, it'll only tell you what it's doing every five 
seconds. That's annoying! It's also very imprecise! You don't know if 
mutt is just chugging along, or if there's one really big message 
that's causing a problem, or quite what's going on. What you'd really 
like mutt to do is to tell you what it's up to every so often, so that 
you know it's still alive, but at a pace that doesn't slow down its 
operation. That's where $time_inc comes in. You can set $read_inc to 
something absurdly small, like 1, and then set $time_inc to something 
reasonable, like 250. That means that it'll update the terminal to 
tell you what it's up to 4 times per second, NO MATTER how quickly or 
slowly it's doing its job. That way you can ensure that mutt keeps you 
informed (even if the task is really slow) without slowing itself down 
(even if the task is really fast).

Does that make sense?

 AFAICT with time_inc=10 included in my $HOME/.mutt/settings I see no 
 change, yet I see people on this list raving about it ? What am I 
 missing ?

A $time_inc=10 setting is absurdly low. That's telling mutt that you 
need updates every 1/100th of a second. You can't read that fast, and 
your terminal can't update that fast. The real joy of $time_inc is 
that you can make your increments (read_inc and