To avoid mail throttles/spamming this adds a message_limit option to limit how many emails can get sent in a single call. I tested this with a number of settings and it's working for me.

In the custom views in the Message admin check check if the 'change' permission for the 'Message' model is set in addition to the existing check if for is_active and is_staff which the django's admin_site.admin_view decorator introduces.

It might be a matter of preference, however using loglevel warning for regular behaviour (1 or more emails have been sent successfully) seems incorrect in my eyes.

As such a slight tweak to only use warning when Yubin defers or skips 1 or more emails.

When trying to send email with priority 'now-not-queued' I can see in the errors files messages as :

failed due to: 'ascii' codec can't encode character '\xf3' in position 481: ordinal not in range(128)

This is the summarize:

• Add testUnicodePriorityNowNotQueuedMessage
• Bug fix for UnicodeEncodeError when priority is 'now-not-queued'
• Bug fix for counting num_sent emailsI
• Change models.QueuedMessage.objects.all() -> models.QueuedMessage.objects.filter(deferred__isnull=True) to check there is not deferred

Fix UnicodeEncodeErrors:

• Sending queued emails
• Sending non queued emails
• In admin detail view

Thanks to @xusy2k to find an trying to fix the bugs in PR #48.

Im having a significant issue with the lock system.

Usually yubin works great for everything. However, sometimes the lock file does not get deleted properly when the program exits. I dont know if its because of abnormal termination or due to some other reason.

Whatever the cause - after that, yubin cant run anymore because it sees the old lock file. Since Im not getting emails, sometimes it takes me days or weeks to realize that there is a problem. This happens rarely but often enough - roughly every few months.

Obviously this is a really serious issue on a production system.

I see there is a finally: block where the lock is supposed to get released. I have no idea why its not getting there sometimes.

Im not so familiar with the system, so the only solution I can think of is to create a management command that can be run say once or twice a day that checks for a really old lock file and deletes it. For instance a lock file thats 4 hours old is probably not really supposed to be there.

Maybe there is a more elegant and correct solution but thats all I can come up with given my limited knowledge

Thanks

Daniel

Traceback (most recent call last): File "./manage.py", line 10, in execute_from_command_line(sys.argv) File "/home/healersource/lib/python2.7/django/core/management/init.py", line 354, in execute_from_command_line utility.execute() File "/home/healersource/lib/python2.7/django/core/management/init.py", line 346, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/healersource/lib/python2.7/django/core/management/base.py", line 394, in run_from_argv self.execute(*args, **cmd_options) File "/home/healersource/lib/python2.7/django/core/management/base.py", line 445, in execute output = self.handle(*args, **options) File "/home/healersource/webapps/hs/env/lib/python2.7/site-packages/django_yubin/management/commands/send_mail.py", line 56, in handle message_limit=options['message_limit']) File "/home/healersource/webapps/hs/env/lib/python2.7/site-packages/django_yubin/engine.py", line 113, in send_all blacklist=blacklist) File "/home/healersource/webapps/hs/env/lib/python2.7/site-packages/django_yubin/engine.py", line 207, in send_queued_message smart_str(message.encoded_message).encode('utf-8')) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 559: ordinal not in range(128)

I see that there is no Travis integration. I could add this (set up the whole tox stack) so you can at least see if the build is failing for certain Python/Django versions or not.

What's the support policy? Which Python/Django versions? I'd suggest Py27, Py34 and Py35, Django 1.8 and Django 1.9. For the rest I would point to django-mailer-2, which is unsupported but so are the Python/Django versions lower than those specified.

Before this fix, when an attachment was added using the render_to_message the filename and the content of the attachment wasn't provided to the attach method at the same time. This provoke that the Content-Disposition header wasn't added at the attachment multipart.

The proposed solution force to assign a filename when an attachment is added (and vicecersa), in order to provide all the parameters to the attach method in order that the Content-Disposition header is written inside the attachment multipart.

Since the commands (send_mail etc.) are using the standard -v verbosity in the arg parser, the help for the command shows that there are four verbosity levels (0-3). At the moment if you run

python manage.py send_mail -v3

for instance, it fails with a cryptic message about the key "3" not being present in the LOGGING_LEVEL dictionary. This change duplicates the "2" key so that both 2 and 3 verbosity have the DEBUG message level.

An alternative would be to specify the -v option in each of the commands to only allow -v[0/1/2].

I've been using django-yubin for a while and it's a great addition. My challenge is sometimes my queue gets too many items in it and then I have a large amount of emails to send (all opt-in, no spamming). My email provider doesn't like it when the volume spikes and starts aggressively throttling and can even lock the account for a while. It would be really helpful if django-yubin had some way of limiting the number of emails per time period. So feed from the queue but if we've sent X emails in this cron cycle then stop sending emails until next cycle.

Is anything like this possible now or is it possible to add something like this?

I found an option, block_size, in the code which I didn't see in the docs. It's related but still sends all mail in the queue.

It would be nice to support multiple addresses (either with to / cc / bcc fields) for the same Email. Currently, a new Message object is created per address.

By allowing the same email to be sent to multiple addresses, we could reduce table space significantly.