[Tutor] sending email via SMTP: code review requested

[Japhy Bartlett]

If you get deeper into processing emails, you might check out
http://lamsonproject.org/ .  I wasn't fond of the whole thing, but if you
dig into the src there is some pretty good code for handling malformed MIME
structures and unicode issues in a sane way.


On Mon, May 5, 2014 at 4:26 PM, Brian van den Broek <
brian.van.den.broek at gmail.com> wrote:

> On 5 May 2014 13:53, Steven D'Aprano <steve at pearwood.info> wrote:
> > On Sun, May 04, 2014 at 07:00:24PM -0400, Brian van den Broek wrote:
> >> Hi all,
> >>
> >> I am playing with the smtp and email modules from the standard library
> >> of Python 2.7.3 (I also want it to run on 2.6.6). I've not found the
> >> going easy; the SMTP and RFC 2822 standards are not ones I have worked
> >> with before.
> >
> > Neither have I :-(
>
>
> Hi All,
>
> Thanks for the feedback, Steven. (And to Japhy for the earlier reply).
>
> >> I have something that works, but I am not confident I am
> >> doing the right thing. For that matter, I am not very confident that I
> >> am not doing the wrong thing.
> >
> > The code seems nicely written, it's understandable and easy to read. I
> > haven't tried running it yet, but nothing stands out as obviously wrong.
>
> Well, gosh'n'golly-gee.
>
> >> I would very much appreciate some more experienced eyes on the code
> below.
> >> In addition to any outright errors concerning interaction with an SMTP
> >> server and constructing a MIME message, I would of course also welcome
> >> style comments. (Preemptively, I will note it isn't obvious I ought to
> >> have gone OOP with this.)
> >
> > Having the SMTPSender object send a message automatically on
> > instantiation strikes me as a bit wiffy. I'm not sure if it's a good
> > design or not. But for a simple cron job, it may be fine.
>
> That is a pattern I often have and for which I often have an
> associated spidey-tingle. If I have a class that exists to handle some
> processing and then be heard from no more, it always seems a bit funny
> to do:
>
> my_thing = MyOneTimeTaskClass(vars)
> my_thing.do_it()
>
> as every time I instantiate MyOneTimeTaskClass I am going to
> immediately ask the instance to do the things it does.
>
> Either way feels, as you say `wiffy.' (I think I shall steal that.)
>
>
> > [...]
> >> And, as I side note, could anyone explain why changing a first world
> >> of a body line 'From' to '>From' is the preferred standard?
> >
> > Because it's a dirty, nasty hack invented by somebody who wasn't
> > thinking very carefully at the time, and now everybody does it. Bleh.
> >
> >> I
> >> understand what the problem is that is being solved, but as most email
> >> clients interpret a leading '>' as an indication of quoting, I would
> >> have thought ' From' or something like '-From' would have been better.
> >> If I have my own code deal with the problem in one of these ways, will
> >> I be breaking anything?
> >
> > Yes. The idea is that your email client should recognise the hack when
> > it sees a line ">From ..." and hide the leading ">". So if you use some
> > other character, say, "!From ...", other people's mail clients won't
> > know to hide the "!".
>
>
> Oh dear.
>
> I developed my code mostly checking the resulting email with the gmail
> app on Android. It doesn't handle things this way; instead, some
> (variable! No, really) portion of the message body gets displayed as a
> quote. I would declare my surprise, but little about the act of malice
> that is the gmail Android app could surprise me now. (Unlike the web
> interface, there is quite literally no way to send plain text from the
> app.)
>
> Anyway, thanks again,
>
> Brian vdB
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140505/a4b8eed8/attachment-0001.html>