Hi
I have a annoying problem when sending an email with mutt and the
Subject header is something like
"Instalación de oracle 9i en cgricr1"
(please note the accent).
When mail arrives to the recipients, they get the following:
Subject: Instalació n de oracle 9i en cgricr1"
(the space between ó and n is a tab).
When the same mail is sent by mean of kmail, for example, this problem
doest not arise, and the recipients can see the correct Subject header:
Subject: Instalación de oracle 9i en cgricr1
Whenever, if the recipient is local user of my machine, the Subject is
correctly received:
Subject: Instalación del centro de respaldo
Thus, I am not sure if this is an mutt problem, it may be an exim4
problem, but with kmail I have not the problem and sendmail is used
also. Exim4 is configured to send every non local mail to a smarthost.
On both cases (mutt and kmail), exim4 is the MTA.
This is my .muttrc:
mailboxes /var/mail/juanino
set locale="es_ES.UTF-8"
set folder="~/mail"
set mbox="+leidos-`date +%b-%Y`"
set postponed=+postponed
set tmpdir=/tmp
set record="+sent_mail-`date +%b-%Y`"
set hostname="tid.es"
set use_domain
source ~/.mutt/colors.angdraug
source ~/.mutt/colors
color normal brightdefault default
ignore *
unignore from: date: subject: to: cc:
unignore organization organisation x-mailer x-newsreader x-mailing-list Reply-To
unignore X-Bogosity User-Agent
my_hdr X-Operating-System: `uname -a`
my_hdr From: "José G. Juanino" < missing >
my_hdr Cc: < missing >
hdr_order From: Date: To: Cc: Reply-To: x-spam: X-Bogosity: organization: organisation: User-Agent: x-mailer: x-newsreader: x-mailing-list: Reply-To: Subject:
set realname="Jose G. Juanino"
set envelope_from
source ~/.mutt/aliases
set alias_file=~/.mutt/aliases
set date_format="%a, %b %d %Y, %H:%M:%S %Z"
set attribution="El %d, %n escribió:"
set forward_format="[Fwd: %s]"
set index_format="%4C %Z %{%b %d %H:%M} %-20.20L (%4c) %s"
set folder_format="%t %2C %8s %d %f"
folder-hook . 'set index_format="%4C %Z %{%a %b %d %H:%M} %-20.20L (%4c) %s"'
folder-hook . 'unset read_only'
folder-hook sent_mail* 'set index_format="%4C %Z %{%a %b %d %Y} %-30.30t (%4c) %s"'
folder-hook \\.gz$ 'set read_only'
open-hook \\.gz$ "gzip -cd %f > %t"
lists us...@subversion.tigris.org
subscribe us...@subversion.tigris.org
lists mutt-...@mutt.org
subscribe mutt-...@mutt.org
set strict_mime=no
set send_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
set charset=utf-8
set assumed_charset="us-ascii:iso-8859-1:iso-8859-15:utf-8"
set xterm_set_titles
set xterm_title="Mutt con %?m?%m mensajes&no mensajes?%?n? [%n NUEVOS]?"
set help=no
set rfc2047_parameters=yes
set forward_edit=no
set query_command="~/.mutt/debian-ldap-query %s"
set beep_new
set fast_reply
unset mark_old
set mime_forward=yes
set move=yes
set pager_stop
set quit=ask-no
unset suspend
unset abort_unmodified
set ispell = /usr/lib/mutt/mailspell
set sort_browser=reverse-date
set print_command="muttprint"
set include
set menu_scroll
unset confirmappend
set confirmcreate=yes
set recall=ask-no
set reply_to=ask-yes # Ask me whether I want to honor users' reply-to headers.
set tilde
set arrow_cursor
set askcc
set pipe_decode=no
set wait_key=no
set delete=yes
auto_view text/html
alternative_order text/plain text/html
bind pager <up> previous-line
bind pager <down> next-line
bind pager k previous-line
bind pager j next-line
macro pager ">" <bottom>
macro pager "<" <top>
macro index <f10> "|munpack -f -C /tmp\n"
macro pager <f10> "|munpack -f -C /tmp\n"
macro index <F9> "|bogofilter -Nls\n"
macro pager <F9> "|bogofilter -Nls\n"
macro index <Esc><f9> "|bogofilter -lSn\n"
macro pager <Esc><f9> "|bogofilter -lSn\n"
macro index <home> "c!\n"
macro index <end> "c>\n"
macro index Ç "c-\n"
macro index <F3> "/~F\n"
macro index \cb |urlview\n
macro pager \cb |urlview\n
macro index M :exec\ middle-page\n
macro index L :exec\ bottom-page\n
macro pager <f2> "q:unalternative_order text/plain\n\n"
macro pager <esc><f2> "q:unalternative_order text/html\n:alternative_order text/plain text/html\n\n"
set smime_default_key=c4af3f33.0
set smime_sign_as=c4af3f33.0
set smime_get_cert_email_command=""
set smime_encrypt_with="rc2-128"
The version of mutt is Mutt/1.5.6+20040907i (debian sarge).
The raw header I can see in the pop3 machive (doing telnet mypop3server pop3)
is
=?iso-8859-1?Q?Instalaci=F3=09n_de_oracle_9i_en_cgricr=31?=
when the mail is sent by mean of mutt
and
=?iso-8859-1?Q?Instalaci=F3n_de_oracle_9i_en_cgricr=31?=
when the mail is sent by mean of kmail.
The first Received: headers are
Received: from tid (filvit [192.168.48.202])
by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
with ESMTP id <0IF800A...@tid.hi.inet> for jgj272@ims-ms-daemon;
Wed, 20 Apr 2005 14:48:59 +0200 (MEST)
Received: from sanabria.inad.es ([192.168.57.66])
by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
with ESMTPS id <0IF800D...@tid.hi.inet> for < missing >; Wed,
20 Apr 2005 14:48:40 +0200 (MEST)
Received: from juanino by sanabria.inad.es with local (Exim 4.50)
id 1DOEdB-0003KN-Cr for < missing > Wed, 20 Apr 2005 14:48:37 +0200
(if someone is interested in the exact configuration of my smarthost).
Thanks in advance
José G. Juanino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCZoAs0Yk+vzn/VIoRAvSGAKCWVIsO3lEVU3QpMX0eAIN+NQHsTgCZAXxU
E3oLyhYhSXr5MXtU0I93sQs=
=PNx/
-----END PGP SIGNATURE-----
I have a problem with clowns using PGP sigs on the Usenet
and thus cluttering up their posts needlessly and using
MIME on the Usenet, both of which are violations of
the Netiquette.
I hope Mutt bites you on your ass.
NO pgp sigs and plain text ONLY.
<snip>
AC
--
alanconnor AT earthlink DOT net
Use your real return address or I'll never know you
even tried to mail me. http://tinyurl.com/2t5kp
José G Juanino escribió en comp.mail.mutt:
>
>
> Whenever, if the recipient is local user of my machine, the Subject is
> correctly received:
>
> Subject: Instalación del centro de respaldo
Sorry, the correct header is
Subject: Instalación de oracle 9i en cgricr1
Juanino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCZo3y0Yk+vzn/VIoRAtqgAJ94JsRfnVKH32Do/IsrBXx/+NcUlwCeIeH3
o/y2sBDf97ZXSnSf4AsLOJo=
=x/eQ
-----END PGP SIGNATURE-----
- broken from
- broken reply-to
- broken attribution line
- broken signature separator
...and you are telling others about "violations of the
netiquette"... *sigh*
Hendrik
... and you're feeding a troll. :-P
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling Linux Counter #80292
- - http://www.ietf.org/rfc/rfc1855.txt
Spammers! http://www.spots.ab.ca/~keeling/autospam.html
Yes, my Subject line is exactly that.
> If it appears on two lines as mine
> does, then it's not mutt doing it, but instead something along the MTA
> path rewriting the Subject: header stupidly.
I am not sure... with the mail command
echo "test" | mail -s "Instalación de oracle 9i en cgricr1" mie...@remotedomain.com
the problem goes away:
But with
echo "test" | mutt -s "Instalación de oracle 9i en cgricr1" mie...@remotedomain.com
i receive the wrong Subject: header, and in both cases I have using the
same MTA (exim4). Notice that mie...@domain.com is not immediately
delivered locally; the smarthost is used instead.
> If the line appears as
> yours does in outgoing, try building a plain mutt (from official source
> archives, without debian's patches) and see if the problem goes away.
I have compiled mutt 1.4.2.1i from official sources, and the problem
holds.
> (For reference, my email is sent into Postfix as MTA, and is then
> immediately delivered locally.)
Notice that the problem does not arises if the recipient is a local user
of my system, as I said in the first post.
Thanks for your help
Peter, the Subject header taken from the fcc of kmail is the following:
Subject: =?iso-8859-1?q?Instalaci=F3n_de_oracle_9i_en?= cgricr1
As you can see, the overall of header is in the same line.
May be this the source of the problem?
Why mutt split the Subject: header in two lines? It is neccesary?
Thanks for your help
I have found the "problem": my smarthost appends a <Tab> as separator
when it see several lines in the Subject header. For example, if the Subject
header is
Subject: =?iso-8859-1?Q?Instalaci=F3?=
=?iso-8859-1?Q?n?= de oracle 9i en cgricr1
it transforms this header in something like
Subject: =?iso-8859-1?Q?Instalaci=F3?=\t\n =?iso-8859-1?Q?n?= de oracle 9i en cgricr1
(notice the \t character)
I do not know if this is allowed by the RFC 2822.
Some smarhost uses hard tabs and others spaces (in the last case, I
would to receive the Subject header over two lines, without the annoying
tab).
Since that I cannot change the behaviour of my smarthost :), I have to
enlarged the macro
#define ENCWORD_LEN_MAX 75
to
#define ENCWORD_LEN_MAX 150
in the rfc2047.c source file of mutt and the problem goes away.
Any better idea?
Juanino
On Friday, April 22, 2005 at 11:48:59 AM +0200, José G. Juanino wrote:
> I have found the "problem": my smarthost appends a <Tab> as separator
> when it see several lines in the Subject header.
In fact your smarthost rewrites everything, changing many things,
some minor harmless, and some more annoying. The spurious tab effect you
noticed is only one problem, there are others. The most annoying beeing
that in some precise conditions it mangles referenced msgids, thus
breaking threads. It also makes changes in nature and amount of spaces
and tabs, case of names, field order, field folding, etc...
A good MTA should reliably transfer mails cleanly unmodified,
verbatim in whatever circumstances, only adding a "Received:" field at
the top. iPlanet is an evil MTA, and should be trashed.
> I have to enlarged the macro #define ENCWORD_LEN_MAX 75
Would violate chapter 2 of RFC 2047:
| An 'encoded-word' may not be more than 75 characters long, including
| 'charset', 'encoding', 'encoded-text', and delimiters. If it is
| desirable to encode more text than will fit in an 'encoded-word' of 75
| characters, multiple 'encoded-word's (separated by CRLF SPACE) may be
| used.
|
| While there is no limit to the length of a multiple-line header field,
| each line of a header field that contains one or more 'encoded-word's
| is limited to 76 characters.
Bye! Alain.
--
Everything about locales on Sven Mascheck's excellent site at new
location <URL:http://www.in-ulm.de/~mascheck/locale/>. The little tester
utility is at <URL:http://www.in-ulm.de/~mascheck/locale/checklocale.c>.
> A good MTA should reliably transfer mails cleanly unmodified,
> verbatim in whatever circumstances, only adding a "Received:" field at
> the top. iPlanet is an evil MTA, and should be trashed.
OpenMail can join this list, for what it's worth. Anybody who's ever tried
to transfer PGP ASCII-armoured mail through it can vouch for this.
("What's this? This attachment isn't base64 encoded! That must be an
oversight - here, let me re-encode it for you.")
--
Paul
>I have found the "problem": my smarthost appends a <Tab> as separator
>when it see several lines in the Subject header. For example, if the Subject
>header is
>Subject: =?iso-8859-1?Q?Instalaci=F3?=
>=?iso-8859-1?Q?n?= de oracle 9i en cgricr1
This is wrong. I continued header line must start either with a space or
with a tab.
>Since that I cannot change the behaviour of my smarthost :), I have to
>enlarged the macro
[...]
This may solve your problem but has nothing to do with it. Everything
above between =? and ?= is an "encoded" word an other software may get
into trouble if you just change the maximum length of such words when
you send them.
Why not just contact the admin of the smarthost if it's really their
fault?
bye, Rocco
--
Yes, you are right, the correct header was:
Subject: =?iso-8859-1?Q?Instalaci=F3?=
=?iso-8859-1?Q?n?= de oracle 9i en cgricr1
(start with a tab).
>>Since that I cannot change the behaviour of my smarthost :), I have to
>>enlarged the macro
>
> [...]
>
> This may solve your problem but has nothing to do with it. Everything
> above between =? and ?= is an "encoded" word an other software may get
> into trouble if you just change the maximum length of such words when
> you send them.
>
> Why not just contact the admin of the smarthost if it's really their
> fault?
I suspect that person will not take into account my complaint...
her/his response would be something like "You have a broken MUA, as you
are the only person having this problem. Use another MUA" :->
I do not understand yet why the rest of MUAs have not this problem, it
seems to be that mutt is the only MUA using a correct ENCWORD_LEN_MAX.
Bye!