[issue12147] smtplib.send_message does not implement corectly rfc 2822

Nicolas Estibals added the comment: Thanks for your help and the interesting discussion with this issue. -- ___ Python tracker ___ __

[issue12147] smtplib.send_message does not implement corectly rfc 2822

R. David Murray added the comment: I tweaked the patch a bit (mostly style/cosmetic) and added some additional tests. Thanks, Nicolas! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Roundup Robot added the comment: New changeset 0f5ea42fb46c by R David Murray in branch '3.2': #12147: make send_message correctly handle Sender and Resent- headers. http://hg.python.org/cpython/rev/0f5ea42fb46c New changeset b8cec4f3faaa by R David Murray in branch 'default': merge #12147: mak

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Nicolas Estibals added the comment: Sorry for the late, my week-end was more busy than expected. Here is the corrected version of the patch. -- Added file: http://bugs.python.org/file22511/send_message_rfc2822_v2.patch ___ Python tracker

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Nicolas Estibals added the comment: I wasn't aware of the problem of guessing which are the correct Resent-* field, tthis does not seem to be that easy, however taking only the first one should be a good heuristic for next release. I think we now agree on the "automatic processing" part, this

[issue12147] smtplib.send_message does not implement corectly rfc 2822

R. David Murray added the comment: Note that that RFC language is clearly directed at automatic processing on *receipt*, not during sending. The RFC doesn't address automatic processing during sending, it leaves that the to the SMTP RFC. -- ___ Py

[issue12147] smtplib.send_message does not implement corectly rfc 2822

R. David Murray added the comment: Section 3.6.6 says: Resent fields are strictly informational. They MUST NOT be used in the normal processing of replies or other such automatic actions on messages. Further, since there is no specified order for the headers within a block, there is

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Nicolas Estibals added the comment: 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

[issue12147] smtplib.send_message does not implement corectly rfc 2822

R. David Murray added the comment: I think we can treat this as a bug. However... What if there is more than one set of Resent- headers? I think that it is not possible to guarantee we only look at the most recent set, since the RFC provides no way to identify a "set". Heuristically we cou

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Changes by R. David Murray : -- assignee: -> r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue12147] smtplib.send_message does not implement corectly rfc 2822

R. David Murray added the comment: Thanks for the patch. Adding support for this is a good idea. There could be a question about whether this constitutes a bug fix or a feature; I'll canvass some other devs and see if we have a consensus on it. It may take me a bit to find time to do a deta

[issue12147] smtplib.send_message does not implement corectly rfc 2822

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12147] smtplib.send_message does not implement corectly rfc 2822

New submission from Nicolas Estibals : smtplib.send_message permits to send messages that are in python Message representation by selecting smtp's "from" and "to" in the message headers. Most of the time the implementation is correct but if the message is bounced (Resent-* headers have to be c