| Summary: | dev-lang/python - smtplib.SMTPException: {'root@localhost': (451, b'a.b.c.4 : [PTR2]')} | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alex Efros <powerman-asdf> |
| Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | dev-portage |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I doubt sys-apps/portage is doing anything wrong here. Python's smtplib.SMTPException (obviously) returns SMTP Error 451, which indicates a problem with the local MTA. Does the mail server still accept other mail from that root@localhost to that server? What (simple) MTA are you using locally anyway? (In reply to Jeroen Roovers from comment #1) > I doubt sys-apps/portage is doing anything wrong here. Python's You shouldn't. I've changed order in which I `ip addr add` my IPs while boot to make a.b.c.64 first added (and thus primary) IP on this interface, and this fixed issue with portage - it now send emails with no problems. > Does the mail server still accept other mail from that root@localhost to > that server? What (simple) MTA are you using locally anyway? Yeah, even while a.b.c.64 wasn't primary IP and portage fails to send mail commands like: # echo -e "To: root\nSubject: test\n\nbody" | sendmail -t works just fine (the sendmail binary is from netqmail package). So it's python's smtplib that is being overly strict? Or sendmail? (In reply to Jeroen Roovers from comment #3) > So it's python's smtplib that is being overly strict? Or sendmail? It's not "overly strict". If it think it should check for PTR - that's ok, problem is what it's checking wrong IP. And I'm not sure where is the bug - in portage, python's lib or python itself, but it's surely not in sendmail - sendmail works ok in this case, as I already mentioned. I'm not quite clear on what this bug is like, but I suggest you open a bug with upstream (e.g. bugs.python.org) and see what they say. (In reply to Dirkjan Ochtman from comment #5) > I'm not quite clear on what this bug is like, but I suggest you open a bug > with upstream (e.g. bugs.python.org) and see what they say. I think such report should contain example script which demonstrate this issue, but I'm not a python developer and can't make it. Portage team, is there any way to get a full traceback out of Portage? Or does this bug ring any bell for you? Yes, the easy way is to comment out these 2 lines in /usr/lib/portage/pym/mail.py
except smtplib.SMTPException as e:
raise portage.exception.PortageException(_("!!! An error occurred while trying to send logmail:\n")+str(e))
they are at lines 172 and 173.
I agree, this error is from python, not portage. Also what python version is the user using?... has the user tried other python versions?
As for portage's mail.py it has only had a copyright and a couple pylint "a,b ==> a, b" space changes since Oct. 2011. So, it isn't because of changes in portage's code.
(In reply to Brian Dolbec from comment #8) > I agree, this error is from python, not portage. Also what python version > is the user using?... has the user tried other python versions? It's python-3.3.3. No, I didn't tried other versions. > So, it isn't because of changes in portage's code. Yeah, I don't think many people run mail service on non-primary IP, so this issue may exists unnoticed already for a long time. (In reply to Alex Efros from comment #9) Could you please comment out the lines that Brian pointed out and reproduce the issue? This should produce a verbose stack trace which will help us diagnose this better. (In reply to Mike Gilbert from comment #10) > Could you please comment out the lines that Brian pointed out and reproduce > the issue? I've found that file at slighly different path: /usr/lib/portage/pym/portage/mail.py ==================================== Error in portage.process.run_exitfuncs File "/usr/lib/portage/pym/portage/process.py", line 163, in run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 47, in finalize _finalize(mysettings, items) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 80, in _finalize portage.mail.send_mail(mysettings, mymessage) File "/usr/lib/portage/pym/portage/mail.py", line 169, in send_mail myconn.sendmail(myfrom, myrecipient, message_str) File "/usr/lib/python3.3/smtplib.py", line 774, in sendmail raise SMTPRecipientsRefused(senderrs) {'root@localhost': (451, b'a.b.c.4 : [PTR2]')} ==================================== Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib/portage/pym/portage/process.py", line 163, in run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 47, in finalize _finalize(mysettings, items) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 80, in _finalize portage.mail.send_mail(mysettings, mymessage) File "/usr/lib/portage/pym/portage/mail.py", line 169, in send_mail myconn.sendmail(myfrom, myrecipient, message_str) File "/usr/lib/python3.3/smtplib.py", line 774, in sendmail raise SMTPRecipientsRefused(senderrs) smtplib.SMTPRecipientsRefused: {'root@localhost': (451, b'a.b.c.4 : [PTR2]')} Also I've tried python-2.7 instead of 3.3 - it also have this issue, but stack trace differs: ==================================== Error in portage.process.run_exitfuncs File "/usr/lib/portage/pym/portage/process.py", line 163, in run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 47, in finalize _finalize(mysettings, items) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 80, in _finalize portage.mail.send_mail(mysettings, mymessage) File "/usr/lib/portage/pym/portage/mail.py", line 169, in send_mail myconn.sendmail(myfrom, myrecipient, message_str) File "/usr/lib/python2.7/smtplib.py", line 734, in sendmail raise SMTPRecipientsRefused(senderrs) {'root@localhost': (451, 'a.b.c.4 : [PTR2]')} ==================================== Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/process.py", line 174, in run_exitfuncs exec("raise exc_info[0], exc_info[1], exc_info[2]") File "/usr/lib/portage/pym/portage/process.py", line 163, in run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 47, in finalize _finalize(mysettings, items) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 80, in _finalize portage.mail.send_mail(mysettings, mymessage) File "/usr/lib/portage/pym/portage/mail.py", line 169, in send_mail myconn.sendmail(myfrom, myrecipient, message_str) File "/usr/lib/python2.7/smtplib.py", line 734, in sendmail raise SMTPRecipientsRefused(senderrs) SMTPRecipientsRefused: {'root@localhost': (451, 'a.b.c.4 : [PTR2]')} Error in sys.exitfunc: Traceback (most recent call last): File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/process.py", line 174, in run_exitfuncs exec("raise exc_info[0], exc_info[1], exc_info[2]") File "/usr/lib/portage/pym/portage/process.py", line 163, in run_exitfuncs func(*targs, **kargs) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 47, in finalize _finalize(mysettings, items) File "/usr/lib/portage/pym/portage/elog/mod_mail_summary.py", line 80, in _finalize portage.mail.send_mail(mysettings, mymessage) File "/usr/lib/portage/pym/portage/mail.py", line 169, in send_mail myconn.sendmail(myfrom, myrecipient, message_str) File "/usr/lib/python2.7/smtplib.py", line 734, in sendmail raise SMTPRecipientsRefused(senderrs) smtplib.SMTPRecipientsRefused: {'root@localhost': (451, 'a.b.c.4 : [PTR2]')} (In reply to Alex Efros from comment #11) Thanks Alex, very helpful. I have to agree with Jeroen, this seems to be some problem on your SMTP server. I don't see anything that would indicate this is a client-side problem. (In reply to Mike Gilbert from comment #12) > I have to agree with Jeroen, this seems to be some problem on your SMTP server. How this can be possible, if problem happens because portage/python try to use wrong IP address? The IP a.b.c.4 isn't mentioned anywhere in portage configs, and IP a.b.c.64 is configured in MAILURI. So why it tries to access SMTP server (or even just check for PTR record) on a.b.c.4? Maybe MAILURI isn't enough and IP of SMTP server should be configured somewhere else too? "a.b.c.4 : [PTR2]" is the response message that the SMTP server is sending back to the client. If the address is wrong in the message, the only software to blame is the mail server. To elaborate: I suspect portage is correctly connecting to a.b.c.64, but your mail server software is responding with a.b.c.4 in its error messages. (In reply to Mike Gilbert from comment #15) > To elaborate: I suspect portage is correctly connecting to a.b.c.64, but > your mail server software is responding with a.b.c.4 in its error messages. Yeah, you right - after adding a.b.c.4 to /etc/tcprules.d/tcp.qmail-smtp this issue was fixed. I think sendmail command works because it uses qmail-inject to add output message to queue without doing real SMTP, while portage connect to a.b.c.64:smtp and kernel does this by sending packet using loopback interface with source IP set to primary IP of external interface which have a.b.c.64 as secondary IP - thus qmail see incoming connect from a.b.c.4. Sorry for reporting this issue and thanks for your help! No problem. |
My server initially used block of IP addresses a.b.c.64-126. Mail server (qmail) is running only on a.b.c.64. Portage configured in make.conf this way: PORTAGE_ELOG_MAILURI="root@localhost a.b.c.64" Everything was fine, until new block of IP addresses a.b.c.4-63 was assigned to this server. This was the only change, mail server is still running on a.b.c.64. After this change portage fails to send email with this error: !!! An error occurred while trying to send logmail: {'root@localhost': (451, b'a.b.c.4 : [PTR2]')} The IP a.b.c.4 doesn't have PTR record in DNS, which probably explain this error, but why it check PTR for that IP at all? IP a.b.c.64 has correct PTR record. I suppose IP a.b.c.4 was used by portage because it's set as primary address on interface, but, anyway, portage should use only IP defined by PORTAGE_ELOG_MAILURI.