headers
Mutt | 1 May 2010 15:31

[Mutt] #3409: IMAP-folder added to "mailboxes" per "imap_check_subscribed" won't report new mail on start but only later

#3409: IMAP-folder added to "mailboxes" per "imap_check_subscribed" won't report
new mail on start but only later
--------------------+-------------------------------------------------------
 Reporter:  rado    |       Owner:  brendan
     Type:  defect  |      Status:  new    
 Priority:  major   |   Milestone:         
Component:  IMAP    |     Version:  1.5.20 
 Keywords:          |  
--------------------+-------------------------------------------------------
 The "new messages" count in "mailboxes-view" of the browser show there are
 new mails when I initially connect to the server, but mutt won't report
 them in buffy-list nor suggest them as default for change-folder dialog.

 Only when after the initial connect new mail arrives, then both buffy-list
 and change-folder notice the IMAP folders with new mail in them.

 How to debug this?

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3409>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 4 comments |
headers
David Champion | 5 May 2010 05:55
Favicon

[PATCH] Adequately read mailboxes with s/ <at> / at / obfuscations

 from.c   |  28 ++++++++++++++++++++--------
 rfc822.c |   6 ++++++
 2 files changed, 26 insertions(+), 8 deletions(-)

# HG changeset patch
# User David Champion <dgc <at> uchicago.edu>
# Date 1273031552 18000
# Branch HEAD
# Node ID 850072857e7c86e29a73efc3478b2feabbe01394
# Parent  4cd2daafd03bfe9d8af1fa543baf873cd94e144f
Adequately read mailboxes with s/ <at> / at / obfuscations.

This handles mbox From_ separators and rfc822 address parsing.

diff -r 4cd2daafd03b -r 850072857e7c from.c
--- a/from.c	Sat Apr 24 16:10:43 2010 -0700
+++ b/from.c	Tue May 04 22:52:32 2010 -0500
 <at>  <at>  -83,20 +83,32  <at>  <at> 
     const char *p;
     size_t len;
     short q = 0;
+    short at = 0;

-    for (p = s; *p && (q || !ISSPACE (*p)); p++)
+    p = s;
+    do
     {
-      if (*p == '\\')
+      for ( ; *p && (q || !ISSPACE (*p)); p++)
       {
(Continue reading)

Permalink | Reply | 4 comments |
headers
Moritz Barsnick | 6 May 2010 14:59
Picon

Re: [PATCH] Adequately read mailboxes with s/ <at> / at / obfuscations

On Tue, May 04, 2010 at 22:55:46 -0500, David Champion wrote:
> Adequately read mailboxes with s/ <at> / at / obfuscations.
> 
> This handles mbox From_ separators and rfc822 address parsing.

Ah, nice! Just when I had dug up the "un-at-" script for being able to
read some mailing lists archives.

Yes, I would like this feature! :-)

Moritz
Permalink | Reply | 0 comments |
headers
Bertrand Yvain | 6 May 2010 17:15

Re: [PATCH] Adequately read mailboxes with s/ <at> / at / obfuscations

Hi,

On Tue, May 04, 2010 at 10:55:46PM -0500, David Champion wrote:
> Adequately read mailboxes with s/ <at> / at / obfuscations.

This kind of substitution is not reversible in the general case.
Consider for instance this e-mail address: "works at home" <at> some.dom.ain

Address obfuscation/mangling cause much more problems that they solve
(if any).  The actual problem is the mangling and I don't think mutt
should jump through hoops in order to handle them.

Cheers,
--

-- 
Bertrand Yvain
http://www.IELO.net/
Permalink | Reply | 2 comments |
headers
David Champion | 6 May 2010 18:53
Favicon

Re: [PATCH] Adequately read mailboxes with s/ <at> / at / obfuscations

* On 06 May 2010, Bertrand Yvain wrote: 
> On Tue, May 04, 2010 at 10:55:46PM -0500, David Champion wrote:
> > Adequately read mailboxes with s/ <at> / at / obfuscations.
> 
> This kind of substitution is not reversible in the general case.
> Consider for instance this e-mail address: "works at home" <at> some.dom.ain

Of course.  That is one of the reasons (digital signature invalidation
is another[1]) for only handling rfc822 parsing in headers, and not messing
with bodies.  If you look at the code or try the patch, you see that it
handles your example in exactly the same way as unpatched mutt does.

This patch does not disrupt any signature system that relies on rfc822
address headers, because it does not modify the source text of the
message.  It only changes what is parsed into the in-memory header
structure: what you can interact with in mutt.  The point is to be able
to read a mangled mailbox -- currently mutt fails miserably -- without
changing it on disk.

> Address obfuscation/mangling cause much more problems that they solve
> (if any).  The actual problem is the mangling

I agree completely, but I can't stop people from mangling.  I can undo
their damage.

> and I don't think mutt
> should jump through hoops in order to handle them.

I just want to be able to read the mailboxes that manglers have created.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Cameron Simpson | 7 May 2010 04:11
Picon
Picon
Gravatar

Re: Adequately read mailboxes with s/ <at> / at / obfuscations

On 06May2010 11:53, David Champion <dgc <at> uchicago.edu> wrote:
| * On 06 May 2010, Bertrand Yvain wrote: 
| > On Tue, May 04, 2010 at 10:55:46PM -0500, David Champion wrote:
| > > Adequately read mailboxes with s/ <at> / at / obfuscations.
| > 
| > This kind of substitution is not reversible in the general case.
| > Consider for instance this e-mail address: "works at home" <at> some.dom.ain
| 
| Of course.  [...]
| This patch does not disrupt any signature system that relies on rfc822
| address headers, because it does not modify the source text of the
| message.  It only changes what is parsed into the in-memory header
| structure: what you can interact with in mutt.  The point is to be able
| to read a mangled mailbox -- currently mutt fails miserably -- without
| changing it on disk.
[...]
| > and I don't think mutt
| > should jump through hoops in order to handle them.
| 
| I just want to be able to read the mailboxes that manglers have created.

Personally, I unmangle mailman archives when I collect them (eg: join
list, suck down old archives). Then I file the de-mangled archives into
legitimate mutt mail folders. Thus:

  get-mailman-archive archive-page-url... >mlist.mbox

Then "mutt -f mlist.mbox" and save them all into the target folder where
I'll be reading this stuff in the future, and where mairix will index
it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oswald Buddenhagen | 9 May 2010 20:07
Picon
Favicon
Gravatar

Re: [PATCH] allow octal codes with more than three digits

On Thu, Apr 22, 2010 at 11:11:15AM -0700, Michael Elkins wrote:
> allow octal codes with more than three digits
> 
little surprisingly, this patch actually works. ;)

i modified it as discussed when you created it weeks ago. take it or
leav it. :)
Attachment (reject-keycode-whitespace.diff): text/x-diff, 1025 bytes
Permalink | Reply | 0 comments |
headers
Mutt | 11 May 2010 01:46

Re: [Mutt] #3246: Please make the internal viewer open diffs and/or text/*

#3246: Please make the internal viewer open diffs and/or text/*
-------------------------------+--------------------------------------------
  Reporter:  antonio <at> …         |       Owner:  mutt-dev
      Type:  enhancement       |      Status:  new     
  Priority:  trivial           |   Milestone:          
 Component:  display           |     Version:  1.5.19  
Resolution:                    |    Keywords:          
-------------------------------+--------------------------------------------

Comment(by ghelleks):

 I believe projekt21's regression also effects the ability to handle
 text/calendar in a useful way.

 .mailcap is only honored via autoview with this patch, which means that my
 clever calendar attachment processing happens automatically when I open
 the message. If I disable autoview, the text/calendar attachment is only
 handled by the internal editor.

 The preferred behavior is to be able to not use autoview, and instead
 launch a .mailcap handler script via <view-attach> instead of the internal
 viewer.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3246#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |
headers
Vincent Lefevre | 11 May 2010 14:07

Forwarding and attaching attachments

Hi,

Some problems with the manual concerning attachment forwarding:

It is possible to forward attachments by using <forward-message>
from the attachment menu, but this doesn't seem to be described
in the manual, which just says:

   Finally, you can apply the usual message-related functions (like
   [923]<resend-message>, and the <reply> and <forward> functions) to
   attachments of type message/rfc822.

However forwarding seems to work with all kinds of attachments, not
just those of type message/rfc822. BTW, this is <forward-message>,
not <forward>, isn't it?

Now, is it possible to attach one or several attachments from some
message in some mailbox, instead of attaching the whole message
(except by copying them first)?

--

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Permalink | Reply | 1 comment |
headers
Rado S | 13 May 2010 13:01
Picon
Picon

Re: Forwarding and attaching attachments

=- Vincent Lefevre wrote on Tue 11.May'10 at 14:07:26 +0200 -=

> However forwarding seems to work with all kinds of attachments, not
> just those of type message/rfc822. BTW, this is <forward-message>,
> not <forward>, isn't it?

Yes.

> Now, is it possible to attach one or several attachments from some
> message in some mailbox, instead of attaching the whole message
> (except by copying them first)?

When in compose menu, see '?' search for "attach", maybe one of the
hits is what you want.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Permalink | Reply | 0 comments |

Gmane