Django app email lignes brisées - la longueur maximale de la ligne (et comment le changer)?

Question

# settings.py
EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend'

# view.py
from django.core.mail import send_mail

def send_letter(request):
    the_text = 'this is a test of a really long line that has more words that could possibly fit in a single column of text.'
    send_mail('some_subject', the_text, 'me@test.com', ['me@test.com'])

Le code de Django vue ci-dessus, les résultats dans un fichier texte qui contient une ligne brisée:

this is a test of a really long line that has more words that could possibl=
y fit in a single column of text.
-------------------------------------------------------------------------------

Quelqu'un sait comment changer si le fichier de sortie n'a pas linebreaks? Est-il un paramètre dans Django qui contrôle cela? La version 1.2 de Django.

Mise à jour - pour sauvegarder un niveau et d'expliquer mon problème original :) Je suis en utilisant la django-inscription application, qui envoie un e-mail avec un lien d'activation de compte . Ce lien est une URL longue, avec un aléatoire jeton à la fin (de 30 caractères), et par conséquent, la ligne se brise au milieu du jeton.

Dans le cas où le problème utilisait le Django Filebased EmailBackend, je suis passé à la smtp back-end et a couru le serveur intégré smtpd Python, en mode débogage. Cet jeté mon e-mail à la console, où il était encore cassé.

Je suis sûr que django-inscription travaille, avec des zillions de personnes qui l'utilisent :) Donc, il doit être quelque chose que j'ai mal commis ou mal configuré. Je n'ai aucune idée quoi.

Mise à jour 2 - selon un article dans une liste Django, il est vraiment sous-jacent email Python objet .MIMEText , qui, si elle est correcte, ne fait que repousser le dos de problème un peu plus. Il ne me dit toujours pas comment le réparer. En regardant les documents, je ne vois rien qui mentionne même ligne d'emballage.

Mise à jour 3 (soupir) - Je l'ai Exclue étant un problème d'objet MimeText. J'ai utilisé un programme pur Python et le smtplib / MimeText pour créer et envoyer un email de test, et il a bien fonctionné. Il aussi a utilisé un charset = "us-ascii", dont quelqu'un a suggéré était le seul à charset pas texte wrap dans les objets MimeText. Je ne sais pas si cela est exact ou non, mais je l'ai regarder de plus près mon sortie email Django, et il a une charset de « utf-8 ».

pourrait le mauvais charset le problème? Et si oui, comment puis-je changement dans Django?

Voici l'ensemble du flux de sortie de l'e-mail de Django:

---------- MESSAGE FOLLOWS ----------
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: some_subject
From: me@test.com
To: me@test.com
Date: Tue, 17 May 2011 19:58:16 -0000

this is a test of a really long line that has more words that could possibl=
y fit in a single column of text.
------------ END MESSAGE ------------

Answer 1

Vous pourriez être en mesure d'obtenir votre client de messagerie pour ne pas casser la limite douce 78 caractères en créant un objet EmailMessage et en passant en-têtes = { « format »: « coulé »} comme ceci:

from django.core.mail import EmailMessage

def send_letter(request):
    the_text = 'this is a test of a really long line that has more words that could possibly fit in a single column of text.'
    email = EmailMessage(
        subject='some_subject', 
        body=the_text, 
        from_email='me@test.com', 
        to=['me@test.com'],
        headers={'format': 'flowed'})

    email.send()

Si cela ne fonctionne pas, essayez d'utiliser une configuration smtp non-debug pour envoyer le fichier à un client de messagerie réelle qui rend l'e-mail selon les règles définies dans l'en-tête de courrier électronique.

Answer 2

Je l'ai vu est python2.5 et il est fixé à python2.7.

Le code correspondant dans un email / generator.py a un commentaire disant

# Header's got lots of smarts, so use it.  Note that this is
# fundamentally broken though because we lose idempotency when
# the header string is continued with tabs.  It will now be
# continued with spaces.  This was reversedly broken before we
# fixed bug 1974.  Either way, we lose.

Vous pouvez lire sur le bug ici http://bugs.python.org/issue1974

Ou vous pouvez simplement changer le \ « t » à « » dans cette ligne de courrier électronique / generator.py

print >> self._fp, Header(
v, maxlinelen=self._maxheaderlen,
header_name=h, continuation_ws='\t').encode()

Answer 3

Essayez de définir EMAIL_BACKEND dans votre settings.py. Peut-être que cela ne résout pas votre problème, mais est le bon endroit où définir, sinon il est susceptible de ne pas être utilisé.

(Puisque je ne suis pas sûr que je suis résoudre votre problème ici, je tentais de faire un commentaire sur votre, mais apparemment je ne peux pas.)

Answer 4

Les lignes électroniques ne sont pas « cassé » en tant que tel - ils sont juste représentés dans le encodage quoted-imprimable . En tant que tel, à 76 caractères, =\n est insérée. Tout client de messagerie compétent doit décoder le message correctement et supprimer la pause.

Si vous voulez représenter le corps d'un e-mail décodé, vous pouvez l'utiliser en passant decode=True à get_payload méthode:

body = email.get_payload(decode=True)

Ceci indique le message à décoder le format quoted printable encodage.

Plus précisément, si votre principale préoccupation est d'obtenir le serveur de débogage console python pour imprimer le message décodé, vous pourriez faire quelque chose de rapide et sale comme cet extrait plutôt que d'utiliser le DebuggingServer intégré. Plus correctement, vous pouvez analyser la chaîne « données » comme un objet Email, imprimez les en-têtes que vous aimez, puis imprimez le corps avec decode=True.