cp932 should be treated like shift_jis.

Hi - this is a patch against mutt-1.4 to use version 2 of the Cyrus
SASL library; all changes are ifdef'd so as not to break SASLv1
support. This includes a patch to configure.in to allow the choice
between v1 and v2, but someone with a better understanding of
autoconf should double-check it.

Actually commit patch-1.5.1.me.long_qp.2.

The maildir_time patch.

You shall not use CVS to distribute test versions.

more fixes.

Add some rpm-related intelligence to flea.

Fix flea's interaction with bug(1) on Debian systems.

Clean up the patch list.

Fix #485: Make %z work like %Z inside of %{} in $index_format.

Fix #1379 - update the total mailbox size when an attachment is
deleted.

Fix #1310; redraw problems.

Fix #1306.

Fix #1364.

Fix memory leak in the PGP code.

Fix #718.

Fix #1366.

Fix IMAP moving; #1367.

Another S/MIME ifdef misses and causes compilation problems.

patch-1.5.1-me.status_doc.2

patch-1.5-tlr.alias-parse.1 - extension of patch-1.5.1-me.aliascheck.1

This patch catches the same kind of bad alias names caught by
Michael's patch.  There are some extensions:

1. Mutt makes sure that it doesn't _suggest_ bad names to the user.
2. If a name is bad, the user is informed, and may elect to fix the
   name.  In this case, mutt will automatically suggest a fixed
   version.
3. If the user insists in the bad name, it's written into the
   aliases file with proper quoting.
4. When mutt parses the aliases file, it now uses the normal
   tokenizer routines in order to properly handle quoted alias names.

patch-1.5-me.long_qp.2 (#1371) - fix truncation with overly long Q-P
encoded lines.

Add some missing #ifdefs.

Documentation fix; #1326

Another crypt_reply fix.

#1357

Make sure that crypt_reply replies with the same type, despite a
possible S/MIME default.

Document escaping rules for regular expressions (#1351).

Fix header coloring, so there is no difference between ncurses and
slang.

PGP documentation glitch.

Fix #1340 (documentation)

Jeremy Lin wrote:
> When I search with / and get a match, doing '/\r' doesn't move to the next
> match. This behavior is unlike the less pager, and is rather useless, IMHO.

Try the attached patch.

A variant of buffy notification.  Note:  If you folks don't like
this, we can return to the old version.

Add a buffy-list function, and display more information when new
mail arrives.  With some modifications from tlr.

Fix #1321.

Tru64 Unix portability patch.

Fixing a typo.

Fixing #1300.  Noted by David Shaw <dshaw@jabberwocky.com>.

Fix #1299; noted by David Shaw <dshaw@jabberwocky.com>.

Introducing $forward_edit.

#265:

> Suppose a user wants to fcc to a file (e.g., /a/b/c) but accidentally
> typed a = before the path name. Mutt will fail to find the =/a/b/c
> folder, display the error message and beep, but immediately erase the
> error message; the mail will be sent even though the fcc failed. (The
> same can be accomplished by accidentally mistyping other parts of the
> path name.) On local systems where screen update is quick, the user
> might not notice the error message at all.
>
> The problem with this behaviour is that the user might have no chance
> to read the error message if the screen update is quick enough; as a
> result (s)he might not notice that the fcc failed.
>
> A related thing (probably can't be classified as a problem) is that if
> fcc fails, the user probably don't want to send the mail out because
> if fcc is requested (s)he probably very much want to keep a copy of
> the sent mail.

Try the following patch.  We keep track of whether or not the fcc
failed with a local var `fcc_error' and perform the same behavior as
if the actual send of the message failed (without really sending)
when the FCC fails, thus giving the user a chance to correct the
error.

Introduce $content_type.  There's one change against Michael's
patch, in how the "format=flowed" parameter is used.

Fixing history classes.

when doing the second parsing pass on a maildir, mutt doesn't delete
the fake HEADER struct if the file is unreadable. With this fix
unreadable files get silently ignored (like in the MH case).

Update.

Fixing #1149:  Truncate files used for editing messages.

An unmailboxes command.  #1311.

Fixing #1330.

Document unalternative_order in the manual page.

The following patch adds the `unalternative_order' command.  It also
allows using "*" more generically in un-commands which use
parse_unlists().

Error handling fixes.

Documentation for reply-hook.  Another patch (for the manual page)
would be most welcome. ;-))

The attached patch fixes mutt_yesorno() so that the question will be
truncated enough to always fit in the default answer string.  The
size is calculated on the fly so that there is no artificial
truncation.

The attached patch sets MB_LEN_MAX to 16, which is MB_LEN_MAX value
on glibc-2.2. It works only with --without-wc-funcs switch. It may
be applied to mutt-1.4 and mutt-1.5.1.

Fix a quoting sloppiness.  Noted by Vincent Lefevre.

Fixing #1282.  An off-by-one error. :-/

reply-hook.  Documentation still needed.

update.

Fix $editor and $visual.  Based on an earlier patch from Edmund
Grimley Evans.

Another documentation patch.

* Thomas Roessler [02-07-08 10:14:53 +0200] wrote:
>  * sendlib.c, 3.12 -> 3.13
>    From: Rocco Rutte <s1118644@mail.inf.tu-dresden.de>

>    Make encode_from a bit more aggressive, by also catching a 'f' in
>    the beginning of a line.

'Catch' is good but also to encode it is better. It may have
been too late (sorry for that) so I fixed it. I don't know
why the current source only escapes lines that actually
begin with 'from' or 'From' followed by some text. I think
that escaping 'from' or 'From' on a single line should be
done, too.

Not a big deal, anyways.

Update copyright notices.

Documentation fixes.

Dcumentation fixes.

Make encode_from a bit more aggressive, by also catching a 'f' in
the beginning of a line.

Documentation fix (#271).

The string used to store the commmand for a backtic expansion in the
muttrc was not free'd if the command failed for some reason.

Okay, two bugs here. One's an oversight of mine in my previous patch,
where I tried to use "[hH]" as Bourne code while m4 had quoting set to
([, ]) -- this probably makes mutt mis-detect Heimdal after all.

The other is not mine (i.e., it's in cvs now) and it makes mutt
overstrike $LIBS if Heimdal or MIT Kerberos is detected. This is a
problem for anyone who needs -lnsl -lsocket, in particular. I was
fixing
this by hand during late 1.3.x releases, as I didn't have time to
track
it down....

Here's a patch against the current (unpatched) 1.5 cvs copy of
m4/gssapi.m4. It probably should go into both branches. Sorry for the
repeats.

Fix #1230.

Fix a couple of compile-time warnings.

Fix charset-hook.

Properly handle empty addresses (<>) when they show up in mail
headers.  The approach taken is to store this address as <@>, and to
check this special case when printing an address.

Fix some warnings noted by Vincent Lefevre.

Fix #1175.  Noticed by Alain Bench.

Attached patch for mutt 1.3.X/1.4 and 1.5.X removes gcc warning in
pop_lib.c.

update.

update.

Triple-DES, not Tripple-DES.

update

update

update

#1190, from Tim Alexeevsky <tim@zhuchka.gbnet.net>

Include smime.h with EXRA_DIST.

update tags

automatic post-release commit for mutt-1.5.1

Shut up check_sec.sh.  No security holes, but some ugly code.

Give all the warnings at once.

- This is a development branch.
- Add a -nodiff option to suppress generating a patch.

Fix #1171.

update.

update.

There is a possible buffer overflow due an off-by-one error in
imap/util.c, line 125. The error is in the maximum field width
indication in the sscanf() call. You must have room in the
receiving buffer for this number of characters /plus a
terminating NULL character/.

Attached patch fixes the problem described below. It should be
applied to both mutt 1.3/1.4 and 1.5 branches.

> Date: Thu, 11 Apr 2002 16:24:00 -0500
> Subject: mutt 1.3.x / pop
> From: "Ryan O'Hara" <rohara@isis.visi.com>
> To: bcully@users.sourceforge.net
> User-Agent: Mutt/1.3.27i

> Hi. My apologies if this has nothing to do with you. If it does not,
> maybe you could forward it on to someone.

> In mutt 1.3.x I have noticed that if I uses POP to retrieve mail, and
> I enter an incorrect password whem prompted, it will *save* that
> password and keep trying to use it. However, in the 1.2.x versions it
> worked like this: type in wrong POP password, try to connect to POP
> server again and it will ask you (again) for the password. mutt 1.3.x
> does not, it just tries to connect with the wrongs password (which
> just failed).

> This is kinda annoying. Just thought I'd point out this regression.

> Thanks.
> R

Someone in news:comp.mail.mutt noted that the list of command-line
options in the manual is not up-to-date.

Included a small patch that includes all options that 'mutt -h' shows.

attached are fixes for some little mistakes :

* history-down -> scroll _down_, not up
* functions decode-(save|copy) do not exist in the attach menu.
* gettext oversight in pattern.c
* inconsistency between "printf-like sequences" used all over the
  place and "escape sequences" for the description of $attribution.

Also fix this for the S/MIME case.

Fiy handling of multiparts which have encrypted sub-parts, at least
for PGP.

Force 7bit encoding for application/pgp-keys.

Generate the resent-message-id ourselves, and add it in the top of
the header.

Bug #571 "mutt should not replicate ">From " headers while bounding",
has a patch attached.
Will that patch get in?

Although these lines are not generated by mutt, I would strongly
suggest
to prevent it, because by boucing a mail the MUA should ensure
that the message header is according to the specification.
A ">From " line is not, because of the spaces before a colon.

Because this has such serious consequences (totally unreadable mail)
when a MTA interpretes this line as the beginning of the body (not
unreasonable), I think Mutt should prevent sending this invalid
headerline.

Because the other patch to the bugreport is not really correct IMHO
(because the fieldnames are not limited to alphanumeric chars, RFC2822
3.6.8), I propose another one.

This patch also appends Resent-* to the header, instead of
prepending it. The Resent-Message-Id is however still appended,
because I could not find it; is it added by the MTA instead of by
Mutt?