On Sat, 18 Jun 2011 13:26:50 -0700, Senthil Kumaran <sent...@uthcode.com> wrote: > On Sat, Jun 18, 2011 at 03:26:00PM -0400, R. David Murray wrote: > > So, opinions: should I implement the heuristics, or should I refuse > > to guess and bail if from_addr and/or to_addrs is None and there are > > any Resent headers in the message? (Third alternative: continue to > > auto-detect it if there is only one set, as the current patch does.) > > It would be difficult to conclude on this, without knowing what would > be a reasonable user expectation. For e.g, if some existing software > is not following RFC to the dot, but provides some convenience which > users have gotten used to, then providing that convenience seems no > harm to me. I hope that landing upon the huristics would be a rare > occasion and not a common case.
Well, the most typical scenario is an MUA application that has processed a message, and the disposition it wants to make of the message (either at user command if it is an interactive ap or via rules if not) is to re-inject the message, sending it to new recipients. This is typically called "bouncing" the message. In that scenario, the *first* bounce involves one set of Resent- headers, and that is unambiguous. But as soon as you consider bouncing a message that has already been bounced, you have multiple sets of headers. Now, the application knows who it wants to send the message to and who is sending it, so it can correctly specify from_addr and to_addrs. The convenience being provided by send_message is not having to separately track compute the this-hop sender and recipients, but being able to compute them only once when creating the Resent- headers, and then have send_message extract them from the Message via the Resent- headers. But this use case is not supported by the RFC. So, how often would the heuristics be used? Any time an already-resent message was again resent. This is not a common occurrence, but neither is it a truly marginal one. -- R. David Murray http://www.bitdance.com _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
