I can send mail with shell but can't sent mail via view

[Hossein Rashnoo]

Hi

I use this settings to send email:

settings.py

EMAIL_HOST = "mail.xxxxxx.ir"

EMAIL_PORT = "25"

EMAIL_HOST_USER = "xx...@xxx.ir"

EMAIL_HOST_PASSWORD = "xxxxxxxx"

EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

DEFAULT_FROM_EMAIL  = 'xx...@xxx.ir'

and in python shell:

from django.core.mail import send_mail

send_mail('test', 'hello', 'xx...@xxx.ir', ['myE...@gmail.com'])

And its successfully sent But when i use that two line code in view, i got this error:

gaierror at /userforget/

[Errno -3] Temporary failure in name resolution

Please help me.

[James Schneider]

Can you send the whole traceback?

Name resolution errors indicate an issue with DNS reachability, or a domain name incorrectly entered somewhere. I'm assuming that you are running the shell on the same server that is running your Django instance? You should be able to do the following on the server where Django is running:

$ python manage.py shell

>>> import socket

>>> # checks if name resolution is working at all

>>> socket.gethostbyname('www.google.com')

'74.125.20.105'

>>> # note you may get a different IP address

>>>

>>> # check if your email host value is resolvable

>>> socket.gethostbyname("mail.xxxxxx.ir")

Traceback (most recent call last):

  File "<console>", line 1, in <module>

gaierror: [Errno -5] No address associated with hostname

>>> 

Obviously I received an error here since I used the masked value you provided. You should get an IPv4/IPv6 address back, or an error similar to the one you posted.

You can also do a quick check if you have shell or command prompt access available on your server outside of Python:

$ nslookup www.google.com

Server: 127.0.1.1

Address: 127.0.1.1#53

Non-authoritative answer:

Name: www.google.com

Address: 74.125.239.112

Name: www.google.com

Address: 74.125.239.114

Name: www.google.com

Address: 74.125.239.113

Name: www.google.com

Address: 74.125.239.116

Name: www.google.com

Address: 74.125.239.115

$ nslookup mail.xxxxxx.ir

Server: 127.0.1.1

Address: 127.0.1.1#53

** server can't find mail.xxxxxx.ir: NXDOMAIN

An NXDOMAIN response means that the domain is either typed incorrectly, or just doesn't exist out on the wild Internet (or wherever your DNS server recursively looks for you)

That command should work on Windows and most Linux distributions (some Linux systems include the 'host' command as an alternative if BIND tools are installed). The output may be formatted differently but should provide similar information.

The full traceback for the error will likely be most helpful, though.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6aaaeaac-dc68-477a-b2d7-7b2821097c36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hossein Rashnoo]

Thank you for your reply, it seems that every thing is ok:

$ nslookup mail.pep.co.ir

Server:         10.252.84.50

Address:        10.252.84.50#53

Non-authoritative answer:

Name:   mail.pep.co.ir

Address: 79.175.161.174

and:

$ python manage.py shell

>>> import socket

>>> socket.gethostbyname("mail.pep.co.ir")

'79.175.161.174'

I attach the whole traceback with this reply.thank you.

[James Schneider]

Thanks.

I can see from the traceback that you have EMAIL_USE_TLS set to True, but you also have EMAIL_PORT set to 25. It doesn't appear that your email server supports TLS via port 25:

$ openssl s_client -starttls smtp -connect mail.pep.co.ir:25

CONNECTED(00000003)

didn't found starttls in server response, try anyway...

<hang>

I checked the other standard ports (tcp/465 and tcp/587) and they don't seem to offer SSL/TLS encryption either. I wouldn't necessarily recommend setting EMAIL_USE_TLS to False, although you could instead set EMAIL_USE_SSL to True and see if that works for you.

My guess is that your SMTP host does not support any sort of encrypted connection. I would check their documentation to see if that is the case. You can also check your (working) email client settings (assuming you are using the same SMTP server) to see if any SSL/TLS settings are enabled. If neither SSL or TLS are enabled in your client (which I suspect is the case unless you are using MAPI/RPC via MS Outlook/Exchange), then you may consider setting EMAIL_USE_TLS to False and re-run the test. Note that this will send your password across the Internet in clear text (unless the server is using CRAM-MD5 for challenge/response authentication, but still not a great idea). You could potentially change your SMTP password temporarily when you disable EMAIL_USE_TLS and change it back afterwards to be safe. If there is no encryption set in your email client, I wouldn't worry about changing the password since your email client is probably sending it out every 10 minutes anyway.

When you say 'python shell' do you mean an actual Python shell (ie. just typing python and manually importing the send_mail function) or are you starting a Python shell via 'python manage.py shell'? If you are using a vanilla python shell (no manage.py), the send_mail function may be relying on defaults since it won't take into account your settings.py file (which may try to relay through a local SMTP server on localhost, I haven't looked). If you are starting it through the manage.py shell, then I'm not sure where to go from there other than twiddling the settings I mentioned.

Does the traceback come back immediately when you execute the view, or does it seem like it needs a fair amount of time to 'time out' (several seconds or probably more)? If it is the former, we're probably still looking at a DNS problem, if it is the latter, my guess is the EMAIL_USE_TLS variable being set to True.

Since you have shell access, you could also potentially test the connection directly using the command:

$ telnet mail.pep.co.ir 25

Trying 79.175.161.174... Connected to mail.pep.co.ir. Escape character is '^]'. 220 CMS5 HighMail ESMTP Service, Version: 2008.8.0.0.4 ready at Thu, 8 Jan 2015 13:55:59 +0330 ehlo pep.co.ir 250-CMS5 says hello 250-DSN 250-AUTH LOGIN CRAM-MD5 250-AUTH=LOGIN 250 ok

I typed 'ehlo pep.co.ir' after the initial connection to show the various authentication schemes and operations offered by the SMTP server. Just type quit to exit. If you do test it, as long as you get the "220 CMS5 HighMail ESMTP..." line, you should be in good shape. Normally I would expect to see "250-STARTTLS" as one of the options (indicating TLS is supported).

Another option would be to try using the IP rather than the name for EMAIL_HOST. In this case it would be '79.175.161.174' from your nslookup command earlier. This 'should' bypass the DNS query to resolve the EMAIL_HOST to an IP address (since it is already an IP). If that works, then you definitely have some kind of DNS issue.

-James

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c3f6d078-c5d7-48f2-812a-9c078ac50a34%40googlegroups.com.

[James Schneider]

After a bit of reflection, I actually think the 'telnet' test would be a good one to run before troubleshooting your code any further. Many ISP's block port 25 going out to the Internet because that is the default port used for SMTP communication between SMTP servers to relay mail. Spammers use this port to directly send mail to remote servers, hence the reason it is blocked. I would try 587 as an alternative, as it appears your mail provider offers it. You may still need to set EMAIL_USE_TLS to False for it to work though. If you run the 'telnet mail.pep.co.ir 25' test and it comes back with 'connection refused' or just seems to hang without displaying the "220 CMS5...", then the alternate port will likely be (at least part of) your solution.

Sorry to get so far down into the technical muck, but these are the things that I would be trying in your situation.

-James

[Hossein Rashnoo]

Really really thank you for your help. I using the IP rather than the name for EMAIL_HOST and its worked and its probably DNS problem. Thanks again. Best regards .