#2014 closed defect (fixed)
Notification e-mails unreadable, unsendable.
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | high | Milestone: | 0.10 |
Component: | ticket system | Version: | 0.9b1 |
Severity: | major | Keywords: | notification email |
Cc: | nunterberg@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
When trying to send notification E-mail, half of them get rejected, and all are un-readable.
headers are so badly damaged that sendmail adds default mail domain after email, I'm suprised it got trough.
could someone help?
Attachments (4)
Change History (21)
by , 19 years ago
Attachment: | bugmail.eml added |
---|
comment:1 by , 19 years ago
side note, this really prevents us from using trac to anything else than browsing subversion tree.
comment:2 by , 19 years ago
I don't understand python, so I wont go there, but looking at the mail, I think this is some serious overencoding and re-encoding shit :) From: =?utf-8?q?Taajama_=3Cpolarfox=40taajama=2Efi=3E?=@smtp.taajama.com '=40' there is '@', and so on, I think something is wrong way the mails are encoded. Having done webmail software with php I've done many mistakes with encodings myself too, but this looks like easy to fix? maybe I should shut up and learn python.
comment:3 by , 19 years ago
After few hours hammering my head to the wall, I think I have a solution, DO NOT USE MIMEText :)
I found others saying that unicode in headers doesn't work like it should. (http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MailFormatting)
And really, those mail headers do blow up when using utf-8 to encode fields like: date, content-type, MIME-Version and email address parts of recipients and senders. there might be others but those are required for things to work ok.
comment:4 by , 19 years ago
I'm not sure, but these might work with postfix. most e-mail clients do not parse headers that I listed that are encoded, but our webmail software does. sendmail doesn't work right with encoded addresses either. As you can see from my comments, this is really important to us, and I'm still on the case.
comment:5 by , 19 years ago
Priority: | normal → high |
---|
comment:6 by , 19 years ago
Cc: | added |
---|---|
Milestone: | → 0.9 |
I've added milestone 0.9 so the ticket does not get lost ;-)
comment:8 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:9 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
(I've started working on this one)
by , 19 years ago
Attachment: | Notify.py.patch added |
---|
First attempt to improve notification with MIME content
comment:10 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Mikko (polarfox@…), could you give a try with the patch I've attached to see whether it helps resolving this issue ?
The idea behind this patch is the following:
As we deal with MIME encoded data (utf-8/base64), a multipart MIME message is reated where only the mail body (text) and some headers are encoded, rather than creating a 'fully' encoded email, which seems to cause troubles with some kind of SMTP server.
Thanks. (patch built from [2391])
comment:11 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:13 by , 19 years ago
comment:14 by , 19 years ago
Keywords: | notification email added; notifications removed |
---|
by , 19 years ago
Attachment: | ugly-notify.patch added |
---|
add's some glue to eblot's patch that makes things work. ugly patch, but works for me.
comment:15 by , 19 years ago
Milestone: | 0.9.1 → 0.9.2 |
---|
comment:16 by , 19 years ago
Milestone: | 0.9.3 → 0.9.4 |
---|
comment:17 by , 19 years ago
Milestone: | 0.9.4 → 0.10 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Should be addressed by [2799]
fucked up e-mail source