This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Nicolas.Estibals
Recipients Nicolas.Estibals, jcea, r.david.murray
Date 2011-06-20.17:02:18
SpamBayes Score 3.0873786e-09
Marked as misclassified No
Message-id <1308589340.01.0.602616517633.issue12147@psf.upfronthosting.co.za>
In-reply-to
Content
Hi,

Treating this as a bug is a good news, if we don't user of the function will ask for python 3.3

I also think the part concerning the Sender header is pretty clear and we can fix it easily.

About the Resent-* fields, I'm not sure of the right thing to do. But I haven't found the mention of no automatic processing for them but I found that RFC 2822 specify more exactly how to use them.

Contrary to the other fields, they have to be in block and the more recent block have to be at the beginning of the mail, moreover they must not be reordered during transfer. Thus I think we have to consider the first block of Resent-* fields if present. (cf. RFC 2822 third paragraph in section 3.6 and appendix A.3) However perhaps we have to wait for an answer from email-sig.

I have one more concern about the send_mesage method: if the Bcc field is present this one is deleted, thus we lose information if we copy it in a sent directory for instance. What do you think about the idea that send_message method should not modify the message ? (The sent message should get rid of the Bcc header but not the one the user keep after using the method.)

Best regards.
History
Date User Action Args
2011-06-20 17:02:20Nicolas.Estibalssetrecipients: + Nicolas.Estibals, jcea, r.david.murray
2011-06-20 17:02:20Nicolas.Estibalssetmessageid: <1308589340.01.0.602616517633.issue12147@psf.upfronthosting.co.za>
2011-06-20 17:02:19Nicolas.Estibalslinkissue12147 messages
2011-06-20 17:02:18Nicolas.Estibalscreate