[Email-SIG] smtplib.send_message

[R. David Murray]

On Sat, 18 Jun 2011 13:26:50 -0700, Senthil Kumaran <senthil at 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