bad idn problem
Hello Mutt users, I am in the process of moving my mutt platform from a Sparce Solaris 9 box to an x86 Solaris 10 box. In order to resolve issues with the terminal color map I am now (trying) to run a newer version of mutt but am receiving an error when I invoke it. I'm able to provide username and password, but then receive the error Bad IDN "imaps.wadsworth.org". I did not experience this issue on Solaris 9, Mutt 1.4.1i (which worked fine), nor on Solaris 10x86 Mutt 1.5.17, which did not map the colors at all but opened the mailbox just fine. The error is occuring on the Solaris 10x86 system with Mutt 1.5.20. I suspect a "set folder" syntax error but don't see it, the .muttrc files has not been altered. I think all versions where installed pre-built from sunfreeware. thank you, Brian --- Brian R Cuttler brian.cutt...@wadsworth.org Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation.
Re: IMAP with freenet.de: sent mails are saved in wrong folder
On Wed, 1 Sep 2010 09:42:18 -0700 Michael Elkins wrote: > Try running Mutt in debug mode (mutt -d 5) and look at > ~/.muttdebug0. I would be surprised if Mutt were saving to the wrong > folder by capitalizing the first letter of the last word. > Thanks for help. I found the error. I had another line in my Mutt config file: 'set record="=Sent"'. Changing it to 'set record="=sent"' fixed the issue. I should have seen that before. Now I wonder if I need that line at all since I am setting the sent folder in my folder hooks again like: folder-hook imaps://mx.freenet.de/ 'set folder=imaps://mx.freenet.de/INBOX record=imaps://mx.freenet.de/INBOX/sent from=...' Or do I need a default setting for that parameter? Regards, Chris
trouble with 'hostname' in reply-hook
Hi, Using mutt 1.5.20 I have this reply-hook: reply-hook '~h(X-Original-)?To:@example.net' "set hostname='example.net'" But the message-id always has the default 'hostname' (defined earlier in the ~/.muttrc) not 'example.net'. Am I missing something?
Re: IMAP with freenet.de: sent mails are saved in wrong folder
On Thursday, 02 September 2010, 15:43:46 +0200,
chs...@freenet.de wrote:
> Now I wonder if I need that line at all since I am setting the sent
> folder in my folder hooks again like:
>
> folder-hook imaps://mx.freenet.de/ 'set
> folder=imaps://mx.freenet.de/INBOX
> record=imaps://mx.freenet.de/INBOX/sent from=...'
Until one of your hooks matches, the record variable is default
("~/sent") or what you have set outside of a hook.
Re: trouble with 'hostname' in reply-hook
On Thu, Sep 02, 2010 at 04:02:01PM +0200, Louis-David Mitterrand wrote: reply-hook '~h(X-Original-)?To:@example.net' "set hostname='example.net'" try this: reply-hook '~h "(X-Original-)?To:@example.net"' set hostname=example.net The regexp needs to be quoted, otherwise the parenthesis are interpreted as part of Mutt's pattern language. me
Re: IMAP with freenet.de: sent mails are saved in wrong folder
On Thu, Sep 02, 2010 at 03:43:46PM +0200, chs...@freenet.de wrote: Now I wonder if I need that line at all since I am setting the sent folder in my folder hooks again like: folder-hook imaps://mx.freenet.de/ 'set folder=imaps://mx.freenet.de/INBOX record=imaps://mx.freenet.de/INBOX/sent from=...' Or do I need a default setting for that parameter? You almost always want a "default" hook in these situations, because the old value is not restored after a hook fires. For example, if you change folder after visiting your mx.freenet.de IMAP account, $record will still be the value that you set in your hook. me
Re: trouble with 'hostname' in reply-hook
On Thu, Sep 02, 2010 at 09:22:11AM -0700, Michael Elkins wrote: > On Thu, Sep 02, 2010 at 04:02:01PM +0200, Louis-David Mitterrand wrote: > >reply-hook '~h(X-Original-)?To:@example.net' "set hostname='example.net'" > > try this: > > reply-hook '~h "(X-Original-)?To:@example.net"' set hostname=example.net > > The regexp needs to be quoted, otherwise the parenthesis are > interpreted as part of Mutt's pattern language. Hi Michael, Nice to see you working on mutt again, I've been a fan since 0.41 :) Actually my reply-hook looks like: reply-hook '~h(X-Original-)?To:.+(contact\|root)@example.net' \ "set hostname=example.net; \ my_hdr From: Example Support " and now it works, go figure. I probably had whitespace after the '\'. In any case it matches contact@ and root@ without any quoting. Are your sure it is necessary to quote the regexp? Also I made a send-hook for when 'alt-e'dit an existing message: send2-hook '~...@example.net' set hostname=example.net But is only works as a send2-hook, not a send-hook. Is that expected? Thanks,
Re: trouble with 'hostname' in reply-hook
On Thu, Sep 02, 2010 at 07:00:56PM +0200, Louis-David Mitterrand wrote: In any case it matches contact@ and root@ without any quoting. Are your sure it is necessary to quote the regexp? I suppose not since it worked. :-) Also I made a send-hook for when 'alt-e'dit an existing message: send2-hook '~...@example.net' set hostname=example.net But is only works as a send2-hook, not a send-hook. Is that expected? Expected. The From: field is not set until after the send-hook's are processed, since one of the primary use of send-hook is to set the from: address. me
abook: query notes field
Hi
Say I have abook entries like
[0]
name=Bob B.
email=...@gmail.com
nick=bob
notes=friend,coworker
[1]
name=Alice A.
email=al...@gmail.com
nick=alice
notes=friend
Is it possible to query the notes field?
abook --mutt-query friend
abook --mutt-query coworker
abook returns "Not found" in that case and seems to search only in the
name and email fields.
The background is that I want to high-jack the notes field to tag
entries with an arbitrary (comma separated) list of tags ("friend",
"coworker") and, for instance, send a mail to all people with the
"friend" tag.
If that is not possible, what other address book systems do people use
which can handle tags which can be queried?
Thanks.
best,
Steve
RFC2047 Subjects
I've been seeing more and more "=?US-ASCII?Q?...?=" in email Subject lines lately. At first, it was all from a particular (and not very technically apt) source, and I assumed that they were doing something wrong, and more or less ignored it. But as I get emails from more and more sources, it's harder to assume they're all getting it wrong. I did a little searching and found that RFC 2047 is the technical specification for these encoded strings, and that mutt does have RFC 2047 support. However, none of the muttrc entries that mention it seem relevant to RFC 2047 decoding for the index and pager display of the Subject line. Here are the relevant headers from an email that isn't displayed correctly: Subject: =?US-ASCII?Q?Intrade_Gazette:_John_Thune_for_President?_Roger_Clemens_heads_to_court._Will_the_'Ground_Zero_Mosque'_get_built??= MIME-Version: 1.0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I would expect to see "Intrade Gazette: "... in the index and pager, instead of "=?US-ASCII?Q?Intrade_Gazette:_"... Thinking that it might be a charset issue, I tried "charset-hook US-ASCII ISO-8859-1", but that did not change the display. I'm using mutt from Ubunty hardy (8.04.4), with "LANG=en_US.UTF-8". "mutt -v" output follows: $ mutt -v Mutt 1.5.17+20080114 (2008-01-14) Copyright (C) 1996-2007 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.24-28-generic (i686) ncurses: ncurses 5.6.20071124 (compiled with 5.6) libidn: 1.1 (compiled with 1.1) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Jun 15 2006 21:19:27) Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_GSS -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE ISPELL="/usr/bin/ispell" SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. patch-1.5.13.cd.ifdef.2 patch-1.5.13.cd.purge_message.3.4 patch-1.5.13.nt+ab.xtitles.4 patch-1.5.4.vk.pgp_verbose_mime patch-1.5.6.dw.maildir-mtime.1 patch-1.5.8.hr.sensible_browser_position.3 Ed signature.txt Description: Digital signature
Re: RFC2047 Subjects
On Thu, Sep 02, 2010 at 04:39:23PM -0400, Ed Blackman wrote:
I did a little searching and found that RFC 2047 is the technical
specification for these encoded strings, and that mutt does have RFC
2047 support. However, none of the muttrc entries that mention it
seem relevant to RFC 2047 decoding for the index and pager display of
the Subject line.
There aren't any user configurable settings for RFC2047 support. It happens
automatically according to the rules in the RFC.
Here are the relevant headers from an email that isn't displayed
correctly:
Subject:
=?US-ASCII?Q?Intrade_Gazette:_John_Thune_for_President?_Roger_Clemens_heads_to_court._Will_the_'Ground_Zero_Mosque'_get_built??=
The problem is that the sender's MUA has not produced a valid RFC2047
encoding. Here is the ABNF (RFC2047, section 2, "Syntax of encoded-words"):
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
charset = token; see section 3
encoding = token ; see section 4
token = 1*
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*
; (but see "Use of encoded-words in message
; headers", section 5)
encoded-text may not contain bare question marks (?), and your example
includes two of them. Mutt has no way to parse this accurately, so it simply
displays the full string.
It is also curious that this header is RFC2047 encoded at all, since there are
no quoted-printable encodings anywhere in the string. There is no reason to
encoded that string at all.
MIME-Version: 1.0
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
I would expect to see "Intrade Gazette: "... in the index and pager,
instead of "=?US-ASCII?Q?Intrade_Gazette:_"...
Thinking that it might be a charset issue, I tried "charset-hook
US-ASCII ISO-8859-1", but that did not change the display.
me
Re: RFC2047 Subjects
On Thu, Sep 02, 2010 at 02:49:00PM -0700, Michael Elkins wrote: The problem is that the sender's MUA has not produced a valid RFC2047 encoding. Here is the ABNF (RFC2047, section 2, "Syntax of encoded-words"): Conincidentally, it appears that even Twitter doesn't get this right. From an email that I just received: From: Twitter Subject: =?utf-8?Q?Update: Twitter Apps and You=0A?= Spaces are not allowed either: encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) At least they did actually use Q-P encoding, although completely unnecessary since the encoded character is a newline. me
Re: RFC2047 Subjects
On Thu, Sep 02, 2010 at 03:11:30PM -0700, Michael Elkins wrote: On Thu, Sep 02, 2010 at 02:49:00PM -0700, Michael Elkins wrote: The problem is that the sender's MUA has not produced a valid RFC2047 encoding. Here is the ABNF (RFC2047, section 2, "Syntax of encoded-words"): Conincidentally, it appears that even Twitter doesn't get this right. From an email that I just received: From: Twitter Subject: =?utf-8?Q?Update: Twitter Apps and You=0A?= Spaces are not allowed either: Does mutt rely on the fact that encoded-text shouldn't have "?" or SPACE because it makes the implementation easier? Or is it just following the RFC strictly? Reading the RFC, it's not clear to me *why* encoded-text can't have "?" or SPACE. I forwarded the message I copied the headers from, along with a one that had spaces in the encoded-text, to my work Outlook and to my Gmail account. Both Outlook and Gmail decoded the subjects as intended, which is probably why Intrade and Twitter can get away with sending out non-conformant messages. Any chance of a rfc2047 lenient decode, perhaps as an option? Ed signature.txt Description: Digital signature
[PATCH] more lenient RFC2047 parsing (was Re: RFC2047 Subjects)
On Thu, Sep 02, 2010 at 07:20:18PM -0400, Ed Blackman wrote:
Does mutt rely on the fact that encoded-text shouldn't have "?" or
SPACE because it makes the implementation easier? Or is it just
following the RFC strictly? Reading the RFC, it's not clear to me
*why* encoded-text can't have "?" or SPACE.
Having unquoted delimeters (the question mark) in the middle of the string
makes it harder to parse. The space character can be problematic in certain
header fields that are structured. Thus, it is always a good idea to encode
those characters.
I forwarded the message I copied the headers from, along with a one
that had spaces in the encoded-text, to my work Outlook and to my
Gmail account. Both Outlook and Gmail decoded the subjects as
intended, which is probably why Intrade and Twitter can get away with
sending out non-conformant messages.
Any chance of a rfc2047 lenient decode, perhaps as an option?
Try the attached patch.
me
diff --git a/rfc2047.c b/rfc2047.c
--- a/rfc2047.c
+++ b/rfc2047.c
@@ -629,12 +629,23 @@
const char *t, *t1;
int enc = 0, count = 0;
char *charset = NULL;
+ int rv = -1;
pd = d0 = safe_malloc (strlen (s));
for (pp = s; (pp1 = strchr (pp, '?')); pp = pp1 + 1)
{
count++;
+
+/* hack for non-compliant MUAs that allow unquoted question marks in
encoded-text */
+if (count == 4)
+{
+ while (pp1 && *(pp1 + 1) != '=')
+ pp1 = strchr(pp1 + 1, '?');
+ if (!pp1)
+ goto error_out_0;
+}
+
switch (count)
{
case 2:
@@ -650,11 +661,7 @@
else if (toupper ((unsigned char) *pp) == 'B')
enc = ENCBASE64;
else
- {
- FREE (&charset);
- FREE (&d0);
- return (-1);
- }
+ goto error_out_0;
break;
case 4:
if (enc == ENCQUOTEDPRINTABLE)
@@ -707,9 +714,11 @@
mutt_convert_string (&d0, charset, Charset, M_ICONV_HOOK_FROM);
mutt_filter_unprintable (&d0);
strfcpy (d, d0, len);
+ rv = 0;
+error_out_0:
FREE (&charset);
FREE (&d0);
- return (0);
+ return rv;
}
/*
@@ -731,7 +740,8 @@
;
if (q[0] != '?' || !strchr ("BbQq", q[1]) || q[2] != '?')
continue;
-for (q = q + 3; 0x20 < *q && *q < 0x7f && *q != '?'; q++)
+/* non-strict check since many MUAs will not encode spaces and question
marks */
+for (q = q + 3; 0x20 <= *q && *q < 0x7f && (*q != '?' || q[1] != '='); q++)
;
if (q[0] != '?' || q[1] != '=')
{
Re: abook: query notes field
Quoth Steve Schmerler on Thursday, 02 September 2010:
> Hi
>
> Say I have abook entries like
>
> [0]
> name=Bob B.
> email=...@gmail.com
> nick=bob
> notes=friend,coworker
>
> [1]
> name=Alice A.
> email=al...@gmail.com
> nick=alice
> notes=friend
>
> Is it possible to query the notes field?
> abook --mutt-query friend
> abook --mutt-query coworker
>
> abook returns "Not found" in that case and seems to search only in the
> name and email fields.
>
> The background is that I want to high-jack the notes field to tag
> entries with an arbitrary (comma separated) list of tags ("friend",
> "coworker") and, for instance, send a mail to all people with the
> "friend" tag.
>
> If that is not possible, what other address book systems do people use
> which can handle tags which can be queried?
>
> Thanks.
>
> best,
> Steve
I have a solution for you. See the attached ruby script.
Change .muttrc to read:
set query_command="aqua %s"
now you can search any or every field. For instance,
Query: friend
would give you anyone with 'friend' in any field.
Query: notes=friend
would give you only people who have 'friend' in the 'notes' field.
Query state=wa notes=friend name=smith
would give you all your friends in Waashington with smith in their name.
Note that multiple arguments have an implied AND conjunction.
You can also use limited regexen (whatever you can get passed the CLI --
you might have to quote):
Query 'name=^(smith|jones)'
everyone with either smith or jones at the beginning of their name.
Enjoy!
--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com
#!/usr/bin/env ruby
require 'optparse'
abook = '~/.abook/addressbook'
optparse = OptionParser.new do |opts|
opts.banner = 'usage: aqua [-f addressbook] term...'
opts.on('-f', '--file addressbook', 'Specify address book to use') do |file|
abook = file
end
end
begin
optparse.parse!
rescue OptionParser::InvalidOption, OptionParser::MissingArgument => e
puts e
puts optparse
exit 1
end
search = []
ARGV.each do |arg|
if /(\w+?)=(.+)/ =~ arg
key = $1
val = /#{$2}/i
search << lambda {|who| val =~ who[key]}
else
val = /#{arg}/i
search << lambda {|who| who.detect {|k,v| val =~ v}}
end
end
who = nil
puts ""
File.open(File.expand_path abook).each do |line|
case line
when /^\s*$/
puts "#{who['email']}\t#{who['name']}\t#{who['notes']}" if who &&
who['email'] && !search.detect {|s| !s.call(who)}
when /^\[\d+\]/
who = {}
when /^(\w+?)=(.+)/
who[$1] = $2 if who
end
end
pgp4cORg7jiNC.pgp
Description: PGP signature
Re: abook: query notes field
Sorry to respond to myself -- but this version has minor improvements.
--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com
#!/usr/bin/env ruby
require 'optparse'
abook = '~/.abook/addressbook'
optparse = OptionParser.new do |opts|
opts.banner = 'usage: aqua [-f addressbook] term...'
opts.on('-f', '--file addressbook', 'Specify address book to use') do |file|
abook = file
end
end
begin
optparse.parse!
rescue OptionParser::InvalidOption, OptionParser::MissingArgument => e
puts e
puts optparse
exit 1
end
search = []
ARGV.each do |arg|
if /(\w+?)=(.+)/ =~ arg
key = $1
val = /#{$2}/i
search << lambda {|who| val =~ who[key]}
else
val = /#{arg}/i
search << lambda {|who| who.detect {|k,v| val =~ v}}
end
end
who = nil
found = []
File.open(File.expand_path abook).each do |line|
case line
when /^\s*$/
found << "#{who['email']}\t#{who['name']}\t#{who['notes']}" if who &&
who['email'] && search.all? {|s| s.call(who)}
when /^\[\d+\]/
who = {}
when /^(\w+?)=(.+)/
who[$1] = $2 if who
end
end
if found.size > 0
puts "#{found.size} found"
puts found
else
puts "Not found"
end
pgpOKNXMIqePy.pgp
Description: PGP signature
