so, I've been quietly feeling bad about using Gmail all day (and Apple
Mail before that, ahum).
If I think about the single most critical feature that makes today's
mail volume manageable for me (other than priority inbox), then it's
conversation view: The ability to page through an entire mail thr
No badge, no gun, but kudos -- and thanks a million to both of you.
Thomas Roessler (@roessler)
On Mon, Apr 4, 2016 at 1:04 PM, Richard Russon wrote:
>
>> It's my pleasure to announce that Kevin McCarthy has agreed to take
>> over as mutt's maintainer.
>
> Th
On 2013-11-07, at 16:48 -0800, Kevin J. McCarthy wrote:
> Thomas Roessler wrote:
>> In fact, pgppubring uses PGPPATH (unlike GNUPGHOME), so if you use
>> Mutt with old-style PGP and pgppubring, then PGPPATH actually needs to
>> be set correctly.
>
> Would it be bet
suggested configuration variable names. They better
> represent the intended meaning of each option. The cost would be a
> surprising behavior change in crypt_autoencrypt that could lead to some
> enraged users.
>
> With your blessing I'd be glad to submit a different
> patch series renaming crypt_autoencrypt => crypt_require_encrypt and
> then changing this patch series to use the option crypt_autoencrypt.
>
> -Kevin
Thomas Roessler (@roessler)
signature.asc
Description: Message signed with OpenPGP using GPGMail
(resending from the subscribed address)
On 2013-10-03, at 01:12 +0200, Thomas Roessler wrote:
> So, who's volunteering to do the release engineering for that?
>
> (I agree that it's time to ship *a* stable version; not sure whether it's
> worthwhile at least
FYI
Begin forwarded message:
> From: Eliot Lear
> Subject: Mark Crispin: 1956 - 2012
> Date: January 8, 2013 10:53:18 +0100
> To: IETF Discussion
>
> It's probably escaped our notice because of the holidays, Mark Crispin
> passed away on the 28th of December. I didn't know Mark too well, bu
FYI -- this is a bit of a change to the data model of E-Mail messages, and - if
deployed - will break existing code in mutt.
If anybody has time to look into this, that'd be great...
Begin forwarded message:
> From: The IESG
> Subject: Protocol Action: 'Update to Internet Message Format to A
On 2012-11-09, at 11:35 +0100, isdtor wrote:
> Hi,
>
> I'm facing a problem with signed emails, introduced by the mail system
> at $workplace.
>
> Receiving two copies of a given, signed, list email, through different
> accounts, the message received in one account has a good signature,
> and t
fyi
Begin forwarded message:
> From: Arvin Moezzi
> Subject: Fwd: urlview: [bug] no declaration for method quote in urlview.c
> Date: June 8, 2012 00:00:59 -0700
> To: Thomas Roessler
>
> Hi Thomas
>
> Sorry I forgot to add you.
>
> Arvin
>
FYI. This is significant in two ways:
1. The downgrade mechanism from the previous e-mail address
internationalization architecture is dropped.
2. We'll start to see utf-8 in addresses and headers across at least POP, IMAP,
and ESMTP.
Regards,
--
Thomas Roessler(@roessler)
LEt's say that this is a longstanding disagreement between mutt and
exim on whose job it is to drop that header. Let's just notice that
exim delivers a poor imitation of sendmail's command line interface
here.
'nuff said.
--
Thomas Roessler
On 21 Sep
Trivial patch, to replace numerical constants by names.
diff -r 6fac57b97bf1 mutt_idna.c
--- a/mutt_idna.c Thu Mar 19 10:36:04 2009 +0100
+++ b/mutt_idna.c Thu Mar 19 12:57:42 2009 +0100
@@ -62,7 +62,7 @@ static int mutt_idna_to_local (const cha
goto notrans;
/* Is this the
Probably worth a review (and maybe an experimental implementation).
Who's got cycles?
Begin forwarded message:
From: The IESG
Date: 23 December 2008 01:18:16 CEST
To: IETF-Announce
Cc: i...@ietf.org
Subject: Last Call: draft-ietf-eai-downgrade (Downgrading mechanism
for Email Address In
external HTTP, XML and Atom libraries. The notion that each message
has a unique HTTP URI should interact very nicely with the way in
which mutt "thinks" about mailboxes and messages.
Any takers?
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
stuff in compare_foo
> is burning?
Nope, didn't do measurements on that part. It did seem (from
looking at gprof outputs) like that code is run a hell of a lot of
times, though.
--
Thomas Roessler <[EMAIL PROTECTED]>
p to date if
> there is some chance that it would be submitted.
Out of curiosity, mind reposting that patch so we can see which
one's better? ;-)
--
Thomas Roessler <[EMAIL PROTECTED]>
ome oft he dynamic memory wastefulness in
compare_from and compare_to; cut off comparison after 128
characters.
Brendan, I haven't pushed this into HG quite yet.
Comments, as always, welcome.
--
Thomas Roessler <[EMAIL PROTECTED]>
diff -r 17adea9cdff6 alias.c
--- a/alias.c
s in an environment that is kind of utf-8,
except for the terminal, and many of the local fils. I'd say
"tough" for that one.
--
Thomas Roessler <[EMAIL PROTECTED]>
well on MacOS now, too.
I frankly wouldn't bother adding code to mutt to work properly in
another inconsistent specification edge case, where the user
actually runs several locales in parallel.
--
Thomas Roessler <[EMAIL PROTECTED]>
onstant zero.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
-free build gives us much
> more in terms of usefulness.
> Defensive programming is all very well, but you can definitely
> take it too far. :-)
I don't think these particular cases are taken too far.
--
Thomas Roessler <[EMAIL PROTECTED]>
ssion is
> inarguably a valid way to construct code...
Indeed, it is -- in particular if (like in this case, I believe) the
code which makes foo constant might change in the future in a way
that would make foo non-constant.
--
Thomas Roessler <[EMAIL PROTECTED]>
> }
>
> -if (isSpool && mbox && *mbox)
> +if (isSpool && *mbox)
> {
>mutt_expand_path (mbox, sizeof (mbox));
>snprintf (buf, sizeof (buf), _("Move read messages to %s?"), mbox);
>
>
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2008-03-03 04:38:43 +0100, Vincent Lefevre wrote:
> But is there a way to automatically remove some headers, such as
> "Delivered-To:"?
If I remember correctly, it does remove some headers. Might be that
some more should be dropped.
--
Thomas Roessler <[EMAIL PROTECTED]>
bug)
- no headers that indicate that the message is a reply
I don't think that this should be yet another function -- rather,
I'd suggest to add a quadoption to reply that controls the various
reply headers.
--
Thomas Roessler <[EMAIL PROTECTED]>
quot;compose to list".
Why isn't list-reply close enough for that?
--
Thomas Roessler <[EMAIL PROTECTED]>
t; could not be sent because of, say, a problem with finding a smarthost to
> send the message.
resend-message
bound to M-e by default, I seem to recall.
--
Thomas Roessler <[EMAIL PROTECTED]>
at:
>
> - if negative wraps to the end of screen,
> - if zero displays as-is (like no f=f support at all, default)
There's more usefulness to be done on narrow screens, i.e., start
flowing the text if you had to break lines.
> - if positive specifies at what column to wrap
&g
only if we had to wrap them before), and make
the new behavior optional.
As an alternative, make the display width of flowed lines
configurable.
Thanks,
--
Thomas Roessler <[EMAIL PROTECTED]>
ould be
> removed from the code. If it is not to be removed, the code
> should certainly be changed to work with version 3.0.
+1
--
Thomas Roessler <[EMAIL PROTECTED]>
a few?
If the former, you could actually fiddle around with the PGP/GPG
command line. If the latter, then I'd recommend adding some UI to
the compose menu to select additional keys.
--
Thomas Roessler <[EMAIL PROTECTED]>
Just stumbling over the include_onlyfirst option. This seems
duplicate functionality that you get more generically by responding
to a specific attachment from the view-attach menu.
While it's little enough code, it strikes me as pure bloat...
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-09-05 11:40:41 -0700, Brendan Cully wrote:
> yes, I agree very much with this. That's why the emacs input
> method seems more suitable - mutt's input line is a lot like the
> emacs minibuffer.
+1
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-09-03 18:02:13 +0200, Vincent Lefevre wrote:
> Yes, except that generates a reply DAG instead of a reply tree,
> and Mutt won't display the DAG.
I might be dense here. What do you mean by "DAG"?
--
Thomas Roessler <[EMAIL PROTECTED]>
anagement by letting go of its ancient design
> philosophy. It need not lose its terminal orientation in order
> to do so, either.
You could keep a terminal mode around, but I would be surprised if
all (or even most) of the benefits of an updated architecture were
to manifest themselves in such a mode.
> the current code base desperately needs to be abandoned, and a
> fresh rewrite started with modularity and modernization in mind.
> But that's a project -- and an argument -- for a different,
> brighter day. :)
Good luck. :)
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-09-02 15:08:10 +0200, Vladimír Marek wrote:
>> Tag the messages you want to reply. Then "; r" and you have
>> them all in your editor ;)
> That's insane :) It would never cross my mind that you can tag-reply.
Nah... tag-replying is a totally essential fe
d/could
> replace the terminal-oriented interface... just that both are
> often quite useful. I'm also aware that mutt can do formatting
> of rtf messages, but that requires that people actually SEND rtf
> mail, which pretty much no one ever does, so it's not a terribly
> useful feature.
From a design perspective, that handler should actually be an
external filter.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
it might be
useful to move the subwindow toward the bottom of the screen, to
basically grow out of the status bar / entry line. I'd suspect that
most long-time mutt users will have their focus down there when they
start dealing with any interaction that they expect will involve a
choice.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-08-30 22:44:10 -0700, Gary Johnson wrote:
> I have attached a patch that fixes this problem by using the same
> file-modification-detection technique used elsewhere in mutt, in the
> mutt_edit_headers() and ci_send_message() functions.
Looks good to me.
--
Thomas Roessler
I'm not sure there's a significant use case in here that can't be
solved with my_hdr.
That said, the way in which two pointers to the same ADDRESS
structure are being used here is a recipe for later memory
corruption. Don't do these kinds of things.
Cheers,
--
Thoma
> and in_encoded_word errorneously is 0.
Actually, I think the logic that deals with the situation after
wrapping is flawed somewhat more deeply. Given how hard this code
is to read, though, something smells like a rewrite here.
Thanks for tracking this down further; I'll have a stab now.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
em. (At least it does for
my test case.)
--
Thomas Roessler <[EMAIL PROTECTED]>
# HG changeset patch
# User Thomas Roessler <[EMAIL PROTECTED]>
# Date 1181342846 -7200
# Node ID 5fba5131a8ad868bc190007fef9a19b19f6d9421
# Parent 9e90789518ad2a6bef64610ce39801c93afca255
Fix he
On 2007-05-31 18:30:37 +0100, Thomas Roessler wrote:
> When replying to the attached message, the subject header gets
> botched, and one of the RFC 2047 encoded-words torn apart. I
> haven't time right now to track that down to a specific version.
A little bit of poking at the
When replying to the attached message, the subject header gets
botched, and one of the RFC 2047 encoded-words torn apart. I
haven't time right now to track that down to a specific version.
Relevant parameters:
send_charset="us-ascii:iso-8859-1:iso-8859-15:iso-8859-2:utf-8"
Che
abase, is there maybe some command
line helper program that returns some structured representation of
that record when confronted with a MIME type?
I guess having a hook of that kind would be most useful. Or maybe
we need to link in yet another library...
Any takers on mutt-dev?
--
Thomas Roessler
ood reason, and it may be better to keep them.
You have to distinguish between quotes as part of the information
that is being transmitted, and quotes as part of the escaping
mechanism that RFC 2822 makes available.
The way things are written above, the quotes are really just part of
a quoting mechanism...
--
Thomas Roessler <[EMAIL PROTECTED]>
This fixes a usability issue when tagging subthreads.
# HG changeset patch
# User Thomas Roessler <[EMAIL PROTECTED]>
# Date 1179255953 -7200
# Node ID 33af2883d52b99ece0a935818a91293b502603aa
# Parent 763bd781d108e17999e4c99f4caf4a76019aca3e
Jump to the next *sub*-thread when tag-subthr
Ignore. This is a local issue.
On 2007-04-26 16:12:30 +0200, Thomas Roessler wrote:
> From: Thomas Roessler <[EMAIL PROTECTED]>
> To: mutt-dev@mutt.org
> Date: Thu, 26 Apr 2007 16:12:30 +0200
> Subject: color-related observation
> X-Spam-Level:
> X-Bogosity: Ham, tes
, that would be
greatly appreciated.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
s been required for
> running smime_keys for a long time.)
I'd dare the guess that asking for perl as a build dependency would
be more reasonable than asking for python.
--
Thomas Roessler <[EMAIL PROTECTED]>
d5ab883ef90a reproducibly leads to segmentation faults in either
line 999 or 1002 of hcache.c. At that point, h->db is a NULL
pointer which is dereferenced.
Backing out d5ab883ef90a cures that.
To reproduce the problem, run tip with the header_cache variable
set.
Regards
--
Thomas Roess
ME mutt.org.
> [???]
kamino knows 194.70.3.63 as the master for mutt.org.
; zone 'mutt.org' last serial 2007022200
; from 194.70.3.63:53 (local 217.160.221.198) using AXFR at Sat Feb 24 18:29:43
2007
Somebody please tell me from where to get the current verison of
that zone...
Confused,
--
Thomas Roessler <[EMAIL PROTECTED]>
So... From what I see in the whois database, this has either been
unrenewed since last August, or Dotster is looking rather stupid
right now.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-28 15:19:09 -0700, William Yardley wrote:
> From: William Yardley <[EMA
I see 4 August 2007 as the expiration date for sigpipe.org.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-28 15:13:23 -0700, William Yardley wrote:
> From: William Yardley <[EMAIL PROTECTED]>
> To: mutt-dev@mutt.org
> Date: Wed, 28 Mar 2007 15:13:23 -0700
>
s also weird that it gets called so many times.
The function is called mutt_addr_is_user, btw, and the debug message
just got fixed.
The only thing that I can think of that would apply
mail_addr_is_user that often would be the scoring code, depending on
what kind of rules you've got in your conf
The following reply was made to PR mutt/2560; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2560: Mutt chokes on invalid charset in UTF environment
Date: Mon, 26 Mar 2007 09:41:52 +0200
On 2007-03-26 09:35:01 +0200, Vlad
27;d guess some people liked the entertainment.
Now, gentlemen, would you please close the door to the rathole after
crawling out of it?
Thanks,
--
Thomas Roessler <[EMAIL PROTECTED]>
Here's a changeset for the patch that I posted yesterday to take
care of some of the problems in update_index().
changeset: 5017:68cfab02b411
tag: tip
user: Thomas Roessler <[EMAIL PROTECTED]>
date:Thu Mar 22 14:36:53 2007 +0100
summary: Fix u
On 2007-03-22 10:12:08 +0100, Thomas Roessler wrote:
> > + s = strdup (AssumedCharset);
> > + /* If it begins with ":", make it empty */
> > + if (s != strtok (s, ":"))
> > +*s = '\0';
> > + return s;
This code is actually rat
char *assumed_charset = mutt_get_default_charset ();
> +if ((charset || *assumed_charset) && Charset)
> + cd = mutt_iconv_open (Charset, charset ? charset : assumed_charset,
> M_ICONV_HOOK_FROM);
> +FREE (&assumed_charset);
>}
... leads to heap coruption.
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
has CONTEXT *ctx in its
> argument, it's not used and the global Context is used instead.
> Is this intended?
Woah. Good catch.
I'm attaching an experimental patch.
--
Thomas Roessler <[EMAIL PROTECTED]>
diff -r b0172175cc89 curs_main.c
--- a/curs_main.c Tue Mar
Rathole?
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-20 21:00:00 -0400, Derek Martin wrote:
> From: Derek Martin <[EMAIL PROTECTED]>
> To: Mutt Developers
> Date: Tue, 20 Mar 2007 21:00:00 -0400
> Subject: Re: [PATCH] Remove absolute paths from gpg.rc
>
I'm totally
confused.
--
Thomas Roessler <[EMAIL PROTECTED]>
ced me that the current behavior
is probably not a bug in the strict sense of the word, but that I'd
still prefer the old handler's behavior.
--
Thomas Roessler <[EMAIL PROTECTED]>
of Technology
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.1.5
>
> Hi,
> * Thomas Roessler [07-03-20 10:46:04 +0100] wrote:
> >On 2007-03-20 10:27:04 +0100, Thomas Roessler wrote:
> >>As an aside, the code used to implement this (in the in
On 2007-03-20 10:27:04 +0100, Thomas Roessler wrote:
> As an aside, the code used to implement this (in the instance around
> line 816 of rfc2047.c) looks like an incredibly convoluted and
> inefficient way of saying something like this:
> if (islwsp (*s))
> {
>
th the old code
taking care of most relevant use cases) would warrant not taking
this patch in.
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
ce at this code, two suggestions:
- Please clean up this code.
- Please throw out the whitespace-skipping option.
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
uot;.
There is no reason why format=flowed can't work with any character
set that's a superset of ASCII.
(Testing äöüß)
--
Thomas Roessler <[EMAIL PROTECTED]>
the right umask to apply.
If you weigh the complexities involved -- a single umask(077) in
main.c vs. a decision about what to do each time a file is opened
--, and the risks that come with screwing up the more complex case,
then it's pretty clear to me that the single umask(077) is the
;
> (The word 'entry' is wrapped around as shown)
Well, some wrapping will inevitably happen when headers exceed the
width of the screen.
--
Thomas Roessler <[EMAIL PROTECTED]>
gt; BODY: Bayesian spam probability is 40 to 60% * [score: 0.5011]
>
>
> which sure is harder to parse...
>
>
> --
> Matthew Fuller (MF4839) | [EMAIL PROTECTED]
> Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
>On the Internet, nobody can hear you scream.
>
>
--
Thomas Roessler <[EMAIL PROTECTED]>
@@ void mutt_canonical_charset (char *dest,
> >
> >strfcpy (dest, scratch, dlen);
> >
> > +found_utf8:
> >/* for cosmetics' sake, transform to lowercase. */
> >for (p = dest; *p; p++)
> > *p = ascii_tolower (*p);
The "goto fou
I think your best bet right now is the hg repository, at
http://dev.mutt.org/hg/mutt
I don't understand what process Brendan is currently using to
generate the ChangeLog, though.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-12 11:37:43 +0100, Vladim�r Marek wrote:
>
ve proper character set handling,
please use PGP/MIME.
Cheers,
--
Thomas Roessler <[EMAIL PROTECTED]>
e a while, but -- for the
record -- it rocks, and it didn't take me a lot of time at all to
get used to it.
So, either way, I'd recommend that you have a look at it.
--
Thomas Roessler <[EMAIL PROTECTED]>
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-03-02 01:25:41 Petr Pisar <[EMAI
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-03-02 01:25:41 Petr Pisar <[EMAI
ere is something in here about a need to express e-mail typical
things in HTML in a way that a client that transforms the stuff to
text can deal with it nicely.
Does anyone feel like raising this here?
http://lists.w3.org/Archives/Public/public-html-mail/
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-02 19:10:25 +0100, Rado S wrote:
> Let them have their way, why do _you_ (or mutt) have to (be able
> to) send HTML?
Tables.
There are actually valid reasons to send HTML stuff.
--
Thomas Roessler <[EMAIL PROTECTED]>
The following reply was made to PR mutt/1116; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/1116: Fails to thread properly without an @ in msg ID
Date: Fri, 2 Mar 2007 12:59:23 +0100
Part of the problem is that there&#x
The current configure script treats --enable-ssl as an error when
there's no POP or IMAP built in. That's not necessary, a warning
will do.
Changeset attached.
--
Thomas Roessler <[EMAIL PROTECTED]>
# HG changeset patch
# User Thomas Roessler <[EMAIL PROTECTED]>
# Date 1
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-03-02 01:25:41 Petr Pisar <[EMAI
ok... We'll need some cygwin-conditional code in the library that
tries to do safer temporary files on Unix.
(And some overall thinking as to whether we're going a step too far
there.)
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-03-01 11:54:54 +, Taleb Hakim wrot
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-28 17:47:13 Brendan Cully <[E
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-27 20:53:13 Brendan Cully <[E
s. This seems to me to address some of the
> problems with both mbox and Maildir (though it might open up some
> other can of worms). Any thoughts?
"Oh no. Yet another folder format."
--
Thomas Roessler <[EMAIL PROTECTED]>
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-27 01:10:57 Brendan Cully <[E
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-25 01:32:31 Brendan Cully <[E
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-25 01:32:31 Brendan Cully <[E
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-23 17:38:25 brendan (brendan)
On 2007-02-23 14:06:33 -0600, Jeremy Blosser wrote:
> I can't, I don't manage the DNS. I think ME still does.
Steve Kennedy does. I've sent mail.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-02-23 18:00:34 +0100, Werner Koch wrote:
> I really would like to see PKA support in Mutt; in particular as
> this is based on an idea Thomas an me developed once.
Err, yes, +1. This is one of the balls I dropped while not meaning
to.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2007-02-22 09:30:33 -0800, Brendan Cully wrote:
> I'll probably apply my ESMTP patch (*dons flame suit*)
*activates flame thrower*
(But up to you.)
--
Thomas Roessler <[EMAIL PROTECTED]>
hat I still prefer to use! ;-)
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
boxes.
I'm not sure, therefore, where precisely you see the problem that
would need to be fixed inside mutt.
--
Thomas Roessler <[EMAIL PROTECTED]>
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-12 00:56:36 Kees Cook <[EMAIL
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-12 00:56:36 Kees Cook <[EMAIL
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
2007-02-12 00:56:36 Kees Cook <[EMAIL
This message was generated and sent automatically. It contains a
summary of the CVS commits over the last 48 hours. These changes
should be propagated to the public repository within at most a day
or two. Most probably, they have already been propagated.
1 - 100 of 110 matches
Mail list logo
