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).
Michael Elkins [Fri, 26 Jul 2002 08:23:28 +0000 (08:23 +0000)]
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.
> 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.
David Champion [Tue, 18 Jun 2002 09:52:13 +0000 (09:52 +0000)]
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.
Thomas Roessler [Thu, 30 May 2002 12:15:02 +0000 (12:15 +0000)]
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.
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/.
> 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.
* 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.
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?
The attached patch cleans up some bugs in switching IMAP mailboxes:
* free current flags on mailbox close
* reset reopen state
* don't parse the same untagged SELECT response for multiple options
* call mx_update_context after reading the whole mailbox, not after
each message
* reset new mail flag if mail arrives in the middle of opening the
mailbox. This should close 1139
939 is most likely unaffected. I discovered these problems while
investigating 939.
Thomas Roessler [Sat, 30 Mar 2002 08:24:16 +0000 (08:24 +0000)]
The attached patch allows the user to override the user-agent field
with my_hdr. It also removes the stripping of the x-mailer field
when recalling a postponed message.
Thomas Roessler [Tue, 26 Mar 2002 09:23:54 +0000 (09:23 +0000)]
Please use ascii_strcasecmp() if you want to compare ASCII parameter
strings. mutt_strcasecmp() depends on the locale, and detects "i"
and "I" as _different_ in Turkish locales.
Thomas Roessler [Wed, 13 Mar 2002 23:34:58 +0000 (23:34 +0000)]
Don't fopen mail folders in append mode where we should safe_fopen()
them in write mode. Debian bug #138200, noted by Colin Philipps
<cph@cph.demon.co.uk>.
Thomas Roessler [Sat, 2 Mar 2002 09:17:40 +0000 (09:17 +0000)]
smime.c:
- the getkeys() function was broken and deleted the last char
of the certfilename
- it now lets me use more than one key for the same mailbox
ie select these.
- some display output was garbled when the email didn't match.
i posted some fix to mutt-users, but i don't like that sleep()
so i dropped the first error message, which basically repeated
the from/sender field only. so now there's just the message: they
don't match.
smime_keys:
- i modified the add_chain to continue even if no roo-cert
is present (david collantes received som chain that got
exported from outlook. obiously they don't (always ?)
include the root cert) it will now abort if neither root
nor intermediate certs are present.
- add_cert created index entries with '-' as issuer cert, when
it should have been '?'. thus verify would fail. (obviously
nobody ever used that command (add_cert, that is) :)
the feature above obsoletes the hash_cert and fingerprint_cert commands,
adds import_cert command and ask_cert_label bool. i modified the output
of smime_keys (a little) so it doesn't look too garbled when supplying
the label (it is actually interactive :) furthermore, i do a verify
after the cert was added and modified the verify routine to make the
cerificate trusted in case of success. (we discussed this in another
message) that is ok so far, but perhaps this requires some better root
certificate handling, ie the trust should be somehow connected to the
root certificate, that maybe added (if the user trusts it and its not
present already) to the ca-file. i'll think about that some more ... but
then, there already is the add_root command. hmmm... (btw, you'll now
never get asked to trust a certificate)
i have not yet deleted the email handling from the import key stuff (in
smime.c/crypt.c), for i'm thinking about smime_keys using it as an
additional arg. otoh i don't think users would press ^k if verification
failed...hmmm... but still, smime_keys does extract the email from the
certificate either way and does verify it by itself, so the only thing
that would happen is to have some invalid certificates, that mutt'll
refuse to use anyways, left in the database....