-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
[ This email was lost during the power outage, so I repost it. ]
[ 20081010 15:07:26 +0200 ]
On Thursday, 2008-10-09 at 17:20 -0700, j debert wrote:
Carlos E. R. さんは書きました:
|
|
| Hi,
|
| when I get an email going to my gmail account, with a from address with
| accented letters, it is corrupted; copying directly from the mbox file
| with less, I see this:
|
| Date: Mon, 6 Oct 2008 11:48:18 +0200
| From: =?ISO-8859-1?Q? "Camale=F3n" _ <....@gmail.com>,
| ?=@nimrodel.valinor
| To: "opensuse-es@opensuse.org"
|
|
The header is not in a valid RFC2822 format. There is no guarantee
that any MTA or any MUA will not mangle such a header since it is not
standard.
The header may have been been converted into MIME by gmail. That is a
no-no but it was apparently intended to only work with the gmail web
interface. Such headers will likely be mangled by Postfix, which is
RFC compliant, and probably by fetchmail, procmail, spamassassin and
amavis as well.
Well, that's the already garbled header after been fetched. The original
is probably closer to this:
Date: Mon, 6 Oct 2008 11:48:18 +0200
From: "=?ISO-8859-1?Q?Camale=F3n?=" <....@gmail.com>
To: "opensuse-es@opensuse.org"
but I'd have to intercept an imap session to make sure of what I'm really
getting.
I also mentioned that the problem is known to gmail:
https://mail.google.com/support/bin/static.py?page=known_issues.cs
] Non-Latin characters can corrupt message headers
]
] Message headers contain technical information necessary for the
] successful delivery of messages between email servers. Gmail's IMAP
] implementation re-encodes the information stored in message headers,
] but non-ASCII characters may become garbled. For example, this can
] affect the 'To:' line in an email message if a name is written in a
] language that uses non-Latin characters. Several issues can result
] from corrupt message headers, including delivery problems.
]
] The Gmail Team is working to resolve this issue.
I'm trying to capture an imap session, but I can't. I use this procedure:
pruebas@nimrodel:~> openssl s_client -connect imap.gmail.com.:imaps | tee gmail_imap.log
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
...
* OK Gimap ready for requests from 88.24.186.237 z34if130280ikz.0
A0001 CAPABILITY
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
A0001 OK Thats all she wrote! z34if130280ikz.0
A002 LOGIN "username" "password"
A002 OK username authenticated (Success)
A0003 SELECT "INBOX"
Here I should be getting something like: " * FLAGS (\Answered \Flagged
\Draft \Deleted \Seen)", but I get nothing. Nothing I type produces any
result. I have to type "control-D". Even the log file halts there:
A002 OK username authenticated (Success)
So the connection breaks somehow, gmail gets stuck. I have tested the
procedure locally, against my imapd, and it works. On a previous test with
gmail, before I knew the commands (nor that I know them now), I got further
than that point.
What can I do?
I have fired a fetchmail session to try getting to gmail imap, and it
worked fine, I got the test email I had sent with accents.
Oct 10 14:18:37 nimrodel fetchmail[10543]: IMAP< A0002 OK username authenticated (Success)
Oct 10 14:18:37 nimrodel fetchmail[10543]: IMAP> A0003 SELECT "INBOX"
Oct 10 14:18:38 nimrodel fetchmail[10543]: IMAP< * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
...
But there is no way I know of intercepting the raw data fetchmail gets.
Interestingly enough, the test messages I sent to my gmail account were
not broken, the headers get here correctly:
From: =?UTF-8?Q?Carlos_E=2ER=2E_--Ac=C3=A9nto--?=
Subject: =?UTF-8?Q?Prueba_ac=C3=A9ntos_en_gmail?=
which displays correctly as:
From: Carlos E.R. --Acénto--
Subject: Prueba acéntos en gmail
So, either they have repaired the problem, or the problem is only with
latin, not utf-8. Just a moment... yes, repaired:
Date: Thu, 9 Oct 2008 23:25:38 +0200
From: "=?ISO-8859-1?Q?Camale=F3n?=" <....@gmail.com>
To: "opensuse-es@opensuse.org"
which displays correctly too.
HA! So babbling here has made them repair the problem. Go figure! :-O
Thanks to whoever it was, I'll have a drink to his/her health, who is
invited - virtually, that is. Can't email a drink :-)
- --
Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjxJvYACgkQtTMYHG2NR9Uo7gCgjZwffwugWTBSPUXf0oZXlEWJ
oVoAn3n+NV52n6uTRUMaLjOLOanUPsVn
=mfCJ
-----END PGP SIGNATURE-----