Forums

Communications with Gmail got stuck today for exactly one my account. For another one it's OK. The code is exactly the same. How come? Any help or ideas?

Log from the affected account:

2018-03-29 19:46:13,678: send: 'ehlo [127.0.0.1]\r\n'
2018-03-29 19:46:13,704: reply: '250-smtp.gmail.com at your service, [23.23.219.95]\r\n'
2018-03-29 19:46:13,711: reply: '250-SIZE 35882577\r\n'
2018-03-29 19:46:13,718: reply: '250-8BITMIME\r\n'
2018-03-29 20:33:50,072: reply: '250-STARTTLS\r\n'

and it is still stuck there.

Account name is newadventures .

Python code:

import smtplib
from email.mime.text import MIMEText

import logging
log = logging.getLogger(__name__)

import threading

class EmailThread(threading.Thread):
    def __init__(self,         
        server_name=settings.EMAIL_HOST, 
        port=settings.EMAIL_PORT,
        sender=settings.EMAIL_HOST_USER,
        pwd=settings.EMAIL_HOST_PASSWORD,
        to=[],
        subj='',
        msg=''
    ):
        super(EmailThread, self).__init__()
        self.server_name = server_name
        self.port = port
        self.sender = sender
        self.pwd = pwd
        self.to = to
        self.subj = subj
        self.msg = msg

def run(self):
    if self.to:
        server = smtplib.SMTP(self.server_name, self.port)
        server.set_debuglevel(1)
        msg = MIMEText(self.msg.encode('utf-8'), 'html', 'UTF-8')
        msg['Subject'] = self.subj
        msg['From'] = self.sender
        msg['To'] = ", ".join(self.to)
        server.starttls()
        server.login(self.sender, self.pwd)
        server.sendmail(self.sender, self.to, msg.as_string())
        server.quit()

Hmm, that's odd. It's possible that your code is running on different physical servers, and GMail is doing some extra security checking on the one that's not working -- though I must admit that's a strange point in the handshake for it to be stopping if that is the case.

Are you using an app-specific password? I don't think it should matter (again, because of the point at which it seems to be blocking in the output you give) but it might be useful information.

Oh, also -- are you running the code in a website's code? Or from a console or a scheduled task?

In a website's code. Actually the web server is supposed to handle registrations for an event and to send email to every registered team. I tested this functionality only manually, so there couldn't be a ton of emails.

I allowed less secure apps in Gmail account. I use the same password to login from Chrome and my website app.

Also, just today it got slower before it stuck. For instance:

2018-03-29 18:00:16,321: reply: '250-smtp.gmail.com at your service, [23.23.219.95]\r\n'
...
2018-03-29 18:00:43,259: reply: retcode (221); Msg: 2.0.0 closing connection 20sm5394033qkw.75 - gsmtp

At that time it did send an email, but it took 27 seconds. I can send email from my home dev server web app (Django).

Until today it worked fine, it took 1-2 seconds, like this:

2018-03-13 11:48:50,446: send: 'ehlo [127.0.0.1]\r\n'
2018-03-13 11:48:50,572: reply: '250-smtp.gmail.com at your service, [52.91.37.139]\r\n'
...
2018-03-13 11:48:51,412: data: (354, 'Go ahead f131sm6459136qkb.60 - gsmtp')
2018-03-13 11:48:51,415: send: 'MIME-Version: 1.0\r\nContent-Type: text/html; charset="utf-8"\r\nContent-Transfer-Encoding: base64\r\nSubject:  .... \r\n.\r\n'
2018-03-13 11:48:52,726: reply: '250 2.0.0 OK 1520930932 f131sm6459136qkb.60 - gsmtp\r\n'
2018-03-13 11:48:52,729: reply: retcode (250); Msg: 2.0.0 OK 1520930932 f131sm6459136qkb.60 - gsmtp
2018-03-13 11:48:52,733: data: (250, '2.0.0 OK 1520930932 f131sm6459136qkb.60 - gsmtp')
2018-03-13 11:48:52,736: send: 'quit\r\n'
2018-03-13 11:48:52,748: reply: '221 2.0.0 closing connection f131sm6459136qkb.60 - gsmtp\r\n'
2018-03-13 11:48:52,751: reply: retcode (221); Msg: 2.0.0 closing connection f131sm6459136qkb.60 - gsmtp

I have to add that this IP address of PA server

2018-03-29 17:32:22,952: reply: '250-smtp.gmail.com at your service, [23.23.219.95]\r\n'

appeared in the web app log file for the first time exactly today, and as soon as it happened, sending email became slow (20+ seconds) and then stuck at all.

Actually, right now it is stuck at another point.

2018-03-30 01:08:55 reply: retcode (250); Msg: smtp.gmail.com at your service, [23.23.219.95]
2018-03-30 01:08:55 SIZE 35882577
2018-03-30 01:08:55 8BITMIME
2018-03-30 01:08:55 AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
2018-03-30 01:08:55 ENHANCEDSTATUSCODES
2018-03-30 01:08:55 PIPELINING
2018-03-30 01:08:55 CHUNKING
2018-03-30 01:08:55 SMTPUTF8
2018-03-30 01:08:55 send: 'AUTH PLAIN ...
2018-03-30 01:08:55 reply: '235 2.7.0 Accepted\r\n'
2018-03-30 01:08:55 reply: retcode (235); Msg: 2.7.0 Accepted
2018-03-30 01:08:55 send: 'mail FROM:<newadventures.mail@gmail.com> size=1364\r\n'
2018-03-30 01:08:55 reply: '250 2.1.0 OK n129sm1325325qke.42 - gsmtp\r\n'
2018-03-30 01:08:55 reply: retcode (250); Msg: 2.1.0 OK n129sm1325325qke.42 - gsmtp
2018-03-30 01:08:55 send: u'rcpt TO:<bibigon-n@yandex.ru>\r\n'
2018-03-30 01:08:55 reply: '250 2.1.5 OK n129sm1325325qke.42 - gsmtp\r\n'
2018-03-30 01:08:55 reply: retcode (250); Msg: 2.1.5 OK n129sm1325325qke.42 - gsmtp
2018-03-30 01:08:55 send: u'rcpt TO:<bibigon-n@yandex.ru>\r\n'
2018-03-30 01:08:55 reply: '250 2.1.5 OK, duplicate recipients will be consolidated. n129sm1325325qke.42 - gsmtp\r\n'
2018-03-30 01:08:55 reply: retcode (250); Msg: 2.1.5 OK, duplicate recipients will be consolidated. n129sm1325325qke.42 - gsmtp
2018-03-30 01:08:55 send: 'data\r\n'

That's really odd. The new IP makes sense -- when we do a system update like the one yesterday, we replace all of the non-storage servers with completely new instances. But the behaviour doesn't make any more sense to me than it does to you.

A couple of things worth noting:

• Although your code doesn't seem to be using it, you do have code to use threads in the stuff you posted above. That generally won't work in website code on PythonAnywhere -- threads are disabled. That said, that should mean that your code wouldn't work at all if you were using it, so I don't think it's the cause of the issue here -- I mention it just for your information, or in case the code you give is an edited version of the code that's actually running.
• I would strongly recommend using an app-specific password -- with those, you create a special password for your Google account that is only used by a specific app (in this case, your Python code). That bypasses a number of their IP-based security checks, which makes it more reliable from cloud services like PythonAnywhere. Again, I don't think from the logs you give that it's the cause of the problem here, but it has worked around some pretty obscure issues in the past, so it's definitely worth a try.

IMHO, it could be using Threads, that's why the function run in "def run(self):" has self as the only argument, tho it seems not indented and seems not to be part of class EmailThread. I think it's supposed to be on the same level as def _init_. But I'm not expert in OOP ;)

Giles, thank you for your info and efforts. At the moment my web app works OK, sends emails.

At the moment I do not use threads (now I call EmailThread.run() from the main thread directly, not EmailThread.start()) and use app specific password for gmail.

In fact, the problem was that my web app worked without threads and with a regular gmail password just fine for 1 month, but after my web app had been transferred to the new IP, sending email became slow (27 sec instead of 1-2) and so I went to Google for the async (thread) solution which got stuck. (Yep, a thread code was executed half-way!)

Now, this way or another, my web app works OK. Thank you.

Well, I'm glad it's working now! Still pretty weird -- all I can imagine is that Google were rate-limiting the IP address of the new web server, but that would still be unusual -- you'd expect it to be blocked or not blocked, rather than just running slowly.