smtplib.send_message

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

smtplib.send_message

R. David Murray
For various reasons the email6 work is on temporary hold.  But, I've
been working on some outstanding email5.1 bugs, and I've got a dilemma.

I introduced smtplib send_message as a convenient way of sending a Message
object.  I did not, however, fully consider the implications of having
done this the way I did it.  A bug has been reported that it doesn't
follow RFC2822 rules when auto-detecting the sender and sendee addresses.
Specifically it ignores Sender and any Resent headers.

The issue is here:

    http://bugs.python.org/issue12147

At first I thought, sure, let's go ahead and fix the logic.  But as I
was fixing up the docs in that patch, it occurred to me that there is a
problematic case: what if there is more than one set of Resent- headers?
Detecting just the most recent set of headers is not, as far as I can
tell, algorithmically possible, and indeed the RFC prohibits using
them for automated processing.  Heuristically we could be right
probably 99% of the time.

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.)

In hindsight I should probably have not supported defaulting to picking
up the values from the Message object, but absent the proposed email6
extended headers it really is a very handy convenience.

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Senthil Kumaran-7
Hi David,

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.

--
Senthil
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

R. David Murray
On Sat, 18 Jun 2011 13:26:50 -0700, Senthil Kumaran <[hidden email]> 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
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Éric Araujo
In reply to this post by R. David Murray
> In hindsight I should probably have not supported defaulting to picking
> up the values from the Message object, but absent the proposed email6
> extended headers it really is a very handy convenience.

Anecdotal user expectation: While I know that email and smtplib are
different modules, I really don’t see why I have to give again some
headers to the STMP object when they’re already here in the message
object.  So +1 for the convenience.

Regards
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Oleg Broytman
On Sun, Jun 19, 2011 at 04:44:01PM +0200, ??ric Araujo wrote:
> I really don???t see why I have to give again some
> headers to the STMP object when they???re already here in the message
> object.

   Bcc, e.g., is the header that isn't in the message or must be removed
from the message before hitting the wire.

Oleg.
--
     Oleg Broytman            http://phdru.name/            [hidden email]
           Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Oleg Broytman
In reply to this post by R. David Murray
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.)

   I vote for the third alternative: do your best if you can deduce the
values but refuse to guess.

Oleg.
--
     Oleg Broytman            http://phdru.name/            [hidden email]
           Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

smtplib.send_message

Stephen J. Turnbull
In reply to this post by R. David Murray
R. David Murray writes:

 > 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.)

The heuristics should be implemented as a separate function or method,
and a way to specify the function to call.  My taste would be to
default the control variable/attribute to None, but if the use case
you're thinking about is sufficiently common or you want backward
compatibility, you could default it to your heuristics.

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Senthil Kumaran-7
In reply to this post by R. David Murray
On Sat, Jun 18, 2011 at 06:26:16PM -0400, R. David Murray wrote:
> 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.

I got the point.  Can the heuristics be turned-off and defaulted to
reject if someone using the smtplib api wants it that way? If yes,
then approach seems fine to me. +1.

--
Senthil
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

R. David Murray
In reply to this post by Stephen J. Turnbull
On Mon, 20 Jun 2011 02:37:10 +0900, "Stephen J. Turnbull" <[hidden email]> wrote:

> R. David Murray writes:
>
>  > 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.)
>
> The heuristics should be implemented as a separate function or method,
> and a way to specify the function to call.  My taste would be to
> default the control variable/attribute to None, but if the use case
> you're thinking about is sufficiently common or you want backward
> compatibility, you could default it to your heuristics.

Hmm.  That would be an API addition.  Current the code is just buggy,
in that it completely ignores Resent- headers, which is just wrong.
So having a new API switch default to None would be fine, and my
preference.

Given what everyone has said, it sounds like for 3.2 I should fix the
bug by implementing the stuff that is not a guess (Sender, and using
Resent- if there is only *one* set of Resent- headers), and generate a
ValueError if there is more than one copy of any of the Resent- headers.
Then for 3.3 we could have a "guess please" knob...but I think I'm not
going to take the time to implement it until we get an actual request
for it.

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Stephen J. Turnbull
R. David Murray writes:
 > On Mon, 20 Jun 2011 02:37:10 +0900, "Stephen J. Turnbull" <[hidden email]> wrote:

 > > The heuristics should be implemented as a separate function or method,
 > > and a way to specify the function to call.
 >
 > Hmm.  That would be an API addition.

Conceded.  I'm happy to delegate that decision to you, as well as the
variable's default if implemented.

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: smtplib.send_message

Barry Warsaw
In reply to this post by Senthil Kumaran-7
My main concern is that whatever you decide to do, it is well documented, well
tested, and completely predictable.  We don't want to make it easy for
applications to do the wrong thing and accidentally send a message to the
wrong recipients.  Reducing functionality to ensure this is fine with me.

-Barry

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

signature.asc (853 bytes) Download Attachment