[PATCH] sync-mailbox: Syncing an empty mailbox is no error

Hello,
the question popped up: Why the following macro[1] fails on an empty
mailbox.

[1] macro to access the folder browser:
	macro index i "<sync-mailbox><change-folder>?<toggle-mailboxes>"

The problem here is that sync-mailbox fails on empty mailboxes and abort
the macro.

You want that sync before the folder browser in - because syncing is
only done, if you enter a *new* folder and so closing the the current
implicit.  But when you browse that folder list you have outdated data
in the folder list until you synced it before.

Attached is a little patch to fix the issue - as usual against current
CVS head.

	Thomas

diff -Nru a/curs_main.c b/curs_main.c
--- a/curs_main.c	2004-07-24 12:27:19 +02:00
+++ b/curs_main.c	2004-12-02 23:03:02 +01:00
 <at>  <at>  -984,6 +984,10  <at>  <at> 

       case OP_MAIN_SYNC_FOLDER:

+	/* syncing an non empty mailbox isn't error */
+	if (Context && !Context->msgcount)

Thoughts on an OpenPGP header?

Hi.  We are preparing a document that aims to merge all X-PGP,
X-PGP-Fingerprint etc headers into one well defined header, for use in
mail and news.  The document is available from:

http://josefsson.org/openpgp-header/

I'm writing to see if there is any interest in supporting this in
Mutt.  General thoughts on the concept or the document would be
appreciated, too, of course.

Like Gnus, I suppose Mutt is configurable, so that users can add the
OpenPGP header manually, but one thing that could be implemented is
this: when the user click on a URL in the OpenPGP: header, the URL
could be retrieved, and 'gpg --import' is invoked on it.  Another is a
"Secure reply" button, that uses the Key ID information in the header,
to make a signed/encrypted reply to a message.

Thanks,
Simon

[PATCH] send2-hook

(Resending.)

The attached patch adds a command named "send2-hook".  send2-hook is
executed even when recalling or resending messages, and is triggered
by any change to the message that can be done from the compose menu.

Use case: Set the $sendmail or $envelope_from variables according to
the sender of the message, even when that sender is changed from the
compose screen.

I would welcome suggestions for a better name; other comments are,
of course, also welcome.

Greetings from the mid-Atlantic,
--

-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

Binary files /tmp/mutt-dev/account.o and mutt-dev/account.o differ
Binary files /tmp/mutt-dev/addrbook.o and mutt-dev/addrbook.o differ
Binary files /tmp/mutt-dev/alias.o and mutt-dev/alias.o differ
Binary files /tmp/mutt-dev/attach.o and mutt-dev/attach.o differ
Binary files /tmp/mutt-dev/base64.o and mutt-dev/base64.o differ
Binary files /tmp/mutt-dev/browser.o and mutt-dev/browser.o differ
Binary files /tmp/mutt-dev/buffy.o and mutt-dev/buffy.o differ
Binary files /tmp/mutt-dev/charset.o and mutt-dev/charset.o differ
Binary files /tmp/mutt-dev/color.o and mutt-dev/color.o differ
Binary files /tmp/mutt-dev/commands.o and mutt-dev/commands.o differ
Binary files /tmp/mutt-dev/complete.o and mutt-dev/complete.o differ
diff -ur /tmp/mutt-dev/compose.c mutt-dev/compose.c

[PATCH] alternates handling

(Resending)

The $alternates variable triggered some special handling which was
lost when it was replaced by an alternates command.  The attached
patch is intended to restore this behavior.

Comments welcome.
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

diff -ur /tmp/mutt-dev/init.c mutt-dev/init.c
--- /tmp/mutt-dev/init.c	2004-08-30 16:07:08.000000000 -0400
+++ mutt-dev/init.c	2004-11-29 09:33:54.852821143 -0500
 <at>  <at>  -611,6 +611,28  <at>  <at> 
   return 0;
 }

+static void _alternates_clean (void)
+{
+  int i;
+  if (Context && Context->msgcount) 
+  {
+    for (i = 0; i < Context->msgcount; i++)
+      Context->hdrs[i]->recip_valid = 0;
+  }
+}
+
+static int parse_alternates (BUFFER *buf, BUFFER *s, unsigned long data, BUFFER *err)
+{

delays

Sorry about the delays to the list, we once again got spammed bombed.

Unfortunately the new mj2 seemed to do strange things and clamav went
into overdrive and went into a weird state and sucked up all the swap on
the system.

Anyway things have been restarted and mail seems to be moving again.

Steve

--

-- 
NetTek Ltd Phone/Fax +44-(0)20 7483 2455
SMS steve-epage (at) gbnet.net [body] gpg 1024D/468952DB 2001-09-19

Re: [PATCH] send2-hook

* Thomas Roessler <roessler <at> does-not-exist.org> [05-12-2004 06:48]:

> The attached patch adds a command named "send2-hook".  send2-hook is
> executed even when recalling or resending messages, and is triggered
> by any change to the message that can be done from the compose menu.

[...]

> I would welcome suggestions for a better name; other comments are,
> of course, also welcome.

"resend-hook"?

--

-- 
René Clerc                      - (rene <at> clerc.nl) - PGP: 0x9ACE0AC7

CAT, n.  A soft, indestructible automaton provided by nature to be
kicked when things go wrong in the domestic circle.
-Ambrose Bierce, "The Devil's Dictionary"

Re: Thoughts on an OpenPGP header?

On 2004-12-03 18:16:03 +0100, Simon Josefsson wrote:
> Hi.  We are preparing a document that aims to merge all X-PGP,
> X-PGP-Fingerprint etc headers into one well defined header, for use in
> mail and news.  The document is available from:
> 
> http://josefsson.org/openpgp-header/
> 
> I'm writing to see if there is any interest in supporting this in
> Mutt.  General thoughts on the concept or the document would be
> appreciated, too, of course.

[First off, I am not a mutt developer, just a user (who submits a patch
every few years ]

While I won't debate that some users are adding such a header, I fail to
see the need for it.

Either a mail is PGP-signed, or it isn't.

If it is signed, it already contains the key id, algorithm, etc., so
this doesn't have to be added to the header. There is also already an
infrastructure for looking up keys, so including an URL where the key
can be obtained seems to be mostly pointless to me - why not just upload
the key to a keyserver? 

If the mail is not signed, including information about a key which may
or may not be used on other mails seems to be of rather dubious value.

So I can see only two scenarios where such a header would be useful:

Re: Thoughts on an OpenPGP header?

"Peter J. Holzer" <hjp+mutt <at> wsr.ac.at> writes:

> On 2004-12-03 18:16:03 +0100, Simon Josefsson wrote:
>> Hi.  We are preparing a document that aims to merge all X-PGP,
>> X-PGP-Fingerprint etc headers into one well defined header, for use in
>> mail and news.  The document is available from:
>> 
>> http://josefsson.org/openpgp-header/
>> 
>> I'm writing to see if there is any interest in supporting this in
>> Mutt.  General thoughts on the concept or the document would be
>> appreciated, too, of course.
>
> [First off, I am not a mutt developer, just a user (who submits a patch
> every few years ]
>
> While I won't debate that some users are adding such a header, I fail to
> see the need for it.

Yes, we should work on clarifying the motivation in the document.

> Either a mail is PGP-signed, or it isn't.
>
> If it is signed, it already contains the key id, algorithm, etc., so
> this doesn't have to be added to the header. There is also already an
> infrastructure for looking up keys, so including an URL where the key
> can be obtained seems to be mostly pointless to me - why not just upload
> the key to a keyserver? 

Right.

Re: Thoughts on an OpenPGP header?

On Fri, 03 Dec 2004 18:16:03 +0100, Simon Josefsson said:

> could be retrieved, and 'gpg --import' is invoked on it.  Another is a
> "Secure reply" button, that uses the Key ID information in the header,
> to make a signed/encrypted reply to a message.

I don't think that this is a good idea.  Mutt should default to an
encrypted reply if a encrypted message is replied to.  The keyID to
encrypt to may then be taken either from the signature of the message
(most messages are encrypted and signed) or from the list of
recipients the orginal mssage has been encrypted too.  The latter
poses a security problem because an attacker might have added an
additional recipient with a random session ID.

The PGP header is still useful as a hint on where to get an updated
key for non-signed messages in case of keyserver problems.  That is
useful if you want to reply encrypted on a non-encrypted message.

Salam-Shalom,

   Werner

Re: Thoughts on an OpenPGP header?

On 2004-12-05 21:05:21 +0100, Simon Josefsson wrote:
> "Peter J. Holzer" <hjp+mutt <at> wsr.ac.at> writes:
> 
> > On 2004-12-03 18:16:03 +0100, Simon Josefsson wrote:
> >> Another is a "Secure reply" button, that uses the Key ID information
> >> in the header, to make a signed/encrypted reply to a message.
> >
> > The way mutt chooses the key(s) to encrypt a message with could surely
> > be improved (in mutt 1.4.x at least, I don't know the current status in
> > 1.5.x). Taking the key id from the OpenPGP header might be a good idea.
> 
> Presumably it uses the To: e-mail address, and let GnuGP select the
> correct key id.

No, it searches the key ring itself and presents a list of matching Ids
to the user if it finds more than one matching key for an address (or
asks directly if it finds none).

What I was thinking about - sorry for not spelling it out in the first
place - was something like this:

For each recipient:

    search for a key with a matching uid.

    If there is exactly one, use it. 

    If there is more than one:

	If one was used to sign the message, use this key