Author r.david.murray
Recipients Eric Lafontaine, Henning.von.Bargen, maciej.szulik, r.david.murray
Date 2016-12-19.10:43:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1482144194.77.0.959612061396.issue28879@psf.upfronthosting.co.za>
In-reply-to
Content
There is at least one open ticket (maybe two, I forget) about providing a way to insert headers at arbitrary locations in the header list.  Our trouble has been deciding on an API.  There is a mailing list (email-sig) where such things can be discussed (it has been idle for a while now...).

I think you are right about the 'heuristic'.  Thinking about it now I believe the problem was partly the lack of an API for inserting headers at the top: if there is only one resent block we are OK appending the address headers, but if there is more than one block then that would be wrong.  The other aspect, to which the comment is referring, is that if we are "augmenting" headers, how do we decide if we are augmenting an existing block, or creating a new one?  Looking at it now with fresh eyes I think we could just decide on the rules and document them.  And we probably want an option that says "this is a resend, add all the Resent headers as a new block".  Or maybe that is enough by itself.  No heuristics, refuse to guess :)  Either the user adds all the headers themselves, or none of them, and we construct them in send_message.  (I haven't reviewed the RFC lately, so I'm not sure that covers all the use cases.)

I don't have a strong opinion on the ehlo_helo issue, but I'm not clear on why its presence causes any difficulty for subclassing.
History
Date User Action Args
2016-12-19 10:43:14r.david.murraysetrecipients: + r.david.murray, maciej.szulik, Henning.von.Bargen, Eric Lafontaine
2016-12-19 10:43:14r.david.murraysetmessageid: <1482144194.77.0.959612061396.issue28879@psf.upfronthosting.co.za>
2016-12-19 10:43:14r.david.murraylinkissue28879 messages
2016-12-19 10:43:13r.david.murraycreate