Ticket 8638: Provide setting to disable e-mail sending
Rob Hudson
I saw that ticket[1] made it into the 1.1 list and I was drawn to it.
I have a project that will be doing some mass sending of emails soon,
so I could definitely use something more than what is currently there.
Firstly, the title simply says it wants the ability to disable emails,
while some of the comments on the ticket are looking for a bit more
than simply disabling. Where would we like to take this?
In case we headed down the road to trapping and looking at emails that
tried to send, I wanted to be a bit smarter about what needs to be
done so I poked around the code a bit and did some research. I ended
up writing a blog post on what I found[2]. Essentially you can fire
up a built-in SMTP server that's already baked into Python, change the
port number for your email, and you're trapping emails and can view
all headers, etc.
If we wanted to add the ability to trap, debug, and view emails that
were sent, I have a few ideas I'd like to get feedback on. The ideas
are in order of complexity in my mind...
1) Add a management command that launches a mail server. Something
similar to runserver, and the user would have to adjust their email
settings accordingly...
./manage.py runmailserver localhost:1025
What I like about this is it can be extended or redirected to a file.
We can add a --format= option for plain text, mbox format, eml format,
or whatever other standard mailbox formats there are.
Or possibly even provide a dotted path to the class you want to use in
its place, similar to middleware, that gets loaded. This might be
useful if you want to log emails to a database...
./manage.py runmailserver 1025 --
class=myproj.mailserver.EmailDatabaseLogger
I'm curious if running this should imply that the EMAIL_* settings get
hijacked and overridden for as long as the mail server is running. If
not, see idea #2.
2) In combination with #1, add a new option to runserver to override
the EMAIL_* settings. So you'd run #1 in one console, then something
like this in the 2nd:
./manage.py runserver --emailport=1025
This saves the user from having to adjust settings for local
development if they're not already set up to do so. But it still
requires both commands to have a matching port number, thus...
3) A step up in the automation and involving more discussion... Add
another option to runserver to launch a mail server for debugging.
This would hijack the mail server settings, launch a local smtp
server, and then runserver. All output would be in the same console.
I think this idea is a bit limiting considering all the fun stuff you
can do with #1. This would be option overload for runserver I think.
But it does have the added benefit of running a single command in a
single console.
./manage.py runserver --maildebugger
Other ideas or thoughts?
Thanks,
Rob
References:
[1] http://code.djangoproject.com/ticket/8638
[2] http://rob.cogit8.org/blog/2008/Nov/20/testing-emails-django/
Luke Plant
> Hi Django Devs,
>
> I saw that ticket[1] made it into the 1.1 list and I was drawn to
> it. I have a project that will be doing some mass sending of emails
> soon, so I could definitely use something more than what is
> currently there.
>
> Firstly, the title simply says it wants the ability to disable
> emails, while some of the comments on the ticket are looking for a
> bit more than simply disabling. Where would we like to take this?
I added a comment on the bug - in summary, why does this need to be
part of Django at all? I use fakemail [1], and it already does
almost everything you suggested. The only thing it doesn't do is
automatically override the settings, but every (sensible) user will
be using different settings for their dev box (for their database at
the very least), so I don't think we need to be that bothered about
users who haven't set up a settings file for their dev box.
I'm -1 on adding much functionality here unless there is some real
value -- it is just duplicating what is available elsewhere, and adds
to the maintainance burden of Django.
Regards,
Luke
[1] http://www.lastcraft.com/fakemail.php
--
"Mediocrity: It takes a lot less time, and most people don't realise
until it's too late." (despair.com)
Luke Plant || http://lukeplant.me.uk/
Russell Keith-Magee
>
> On Tuesday 25 November 2008 01:02:03 Rob Hudson wrote:
>> Hi Django Devs,
>>
>> I saw that ticket[1] made it into the 1.1 list and I was drawn to
>> it. I have a project that will be doing some mass sending of emails
>> soon, so I could definitely use something more than what is
>> currently there.
>>
>> Firstly, the title simply says it wants the ability to disable
>> emails, while some of the comments on the ticket are looking for a
>> bit more than simply disabling. Where would we like to take this?
>
> I added a comment on the bug - in summary, why does this need to be
> part of Django at all? I use fakemail [1], and it already does
> almost everything you suggested. The only thing it doesn't do is
> automatically override the settings, but every (sensible) user will
> be using different settings for their dev box (for their database at
> the very least), so I don't think we need to be that bothered about
> users who haven't set up a settings file for their dev box.
>
> I'm -1 on adding much functionality here unless there is some real
> value -- it is just duplicating what is available elsewhere, and adds
> to the maintainance burden of Django.
I'm not sure I agree, Luke. Part of the reason for the success of
Django is that it is useful out of the box. You can do all the basic
development activities without needing to seek out or configure other
packages. If you find that the builtins aren't rich enough, you can
seek out alternatives, but the builtins are enough to get you off the
ground.
Following your reasoning, Django shouldn't have:
* the runserver command - after all, there is a mod_python and wsgi
interface, so you can deploy it using external tools
* the test command - after all, there are plenty of unit test running
tools out there.
I'm sure there are other examples. My point is that there is something
to be said for making it easy to get started, as long as the simple
approach doesn't rule out more sophisticated approaches for advanced
users.
On a different front; I would agree with you if Rob's suggestion
involved introducing an external dependency, or writing a lot of code
to support a test mail server. However, in this case, Python's SMTPd
library does all the heavy lifting. We just need to plumb it into the
runserver command.
To that end - I'd be inclined to follow the simple option here:
* We add a --with-mailserver option to runserver, which redirects the
EMAIL_* options as appropriate, and starts a mail server that just
dumps to the same console as the HTTP server.
* We add a standalone mailserver command so that you can run the same
basic stdout console logging mail server on a standalone console. This
would require the user to manually configure their settings to point
to the test mail server.
* If the Python SMTP debug server can be easily configured, maybe use
the verbosity command to control how much is dumped to console (0=just
the to: line, 1=just the header, 2=full message).
All the other fruit - database logged emails, etc - is out of scope -
this is a simple debug tool, nothing more. If you want a complex mail
handling solution, go get yourself a real mail server; the
documentation can point to a few options (like FakeMail).
On an administrative note - I've offered to mentor this activity
("Maybe" item Test-02 on the v1.1 plan). I'm willing to entertain the
idea that the right solution here is to abandon the idea altogether -
I just need to be convinced that it's the right thing to do. However,
if we abandon the idea, some documentation is definitely in order,
directing people to options like FakeMail.
Yours,
Russ Magee %-)
Tai Lee
hijack the recipients if DEBUG is True. The idea being that I don't
want to send real emails to real recipients while developing,
debugging and testing.
In this case I get real emails delivered to everyone listed in
`settings.ADMINS`, but the emails I receive are not *exactly* what a
real recipient would receive.
I would love to be able to specify an option such as `--with-
mailserver` to `runserver` that dumps various amounts of data on
emails sent through django to the console.
The value add is that it's a quick and easy option that allows me to
be sure that no real emails will be sent and to allow immediately
inspection of messages being generated by Django, without having to go
and configure 3rd party dummy servers and alter settings.
+1 from me, if it is indeed a simple addition where Python's SMTPd can
do all the heavy lifting.
Cheers.
Tai.
On Nov 28, 12:53 pm, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
Mara Rinn
> I currently use my own versions of `send_mail` and `mail_*`, which
> hijack the recipients if DEBUG is True. The idea being that I don't
> want to send real emails to real recipients while developing,
> debugging and testing.
the lines of fakemail), and provide a "mail client" that can read
through the messages received by the server and allow certain tests to
be done (eg: "message.assertRecipient(User)")?
> I would love to be able to specify an option such as `--with-
> mailserver` to `runserver` that dumps various amounts of data on
> emails sent through django to the console.
something similar to a mail log:
Sending message from Alice to Bob, subject "Foobar")
> +1 from me, if it is indeed a simple addition where Python's SMTPd can
> do all the heavy lifting.
that were sent.