1998-12-22 11:02:20 +08:00
|
|
|
#! /usr/bin/env python
|
|
|
|
|
2000-07-10 05:24:31 +08:00
|
|
|
'''SMTP/ESMTP client class.
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
This should follow RFC 821 (SMTP) and RFC 1869 (ESMTP).
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
Notes:
|
|
|
|
|
|
|
|
Please remember, when doing ESMTP, that the names of the SMTP service
|
1998-12-22 11:02:20 +08:00
|
|
|
extensions are NOT the same thing as the option keywords for the RCPT
|
1998-08-04 23:29:54 +08:00
|
|
|
and MAIL commands!
|
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
Example:
|
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
>>> import smtplib
|
|
|
|
>>> s=smtplib.SMTP("localhost")
|
|
|
|
>>> print s.help()
|
|
|
|
This is Sendmail version 8.8.4
|
|
|
|
Topics:
|
|
|
|
HELO EHLO MAIL RCPT DATA
|
|
|
|
RSET NOOP QUIT HELP VRFY
|
|
|
|
EXPN VERB ETRN DSN
|
|
|
|
For more info use "HELP <topic>".
|
|
|
|
To report bugs in the implementation send email to
|
|
|
|
sendmail-bugs@sendmail.org.
|
|
|
|
For local information send email to Postmaster at your site.
|
|
|
|
End of HELP info
|
|
|
|
>>> s.putcmd("vrfy","someone@here")
|
|
|
|
>>> s.getreply()
|
|
|
|
(250, "Somebody OverHere <somebody@here.my.org>")
|
|
|
|
>>> s.quit()
|
2000-07-10 05:24:31 +08:00
|
|
|
'''
|
1998-01-30 01:24:40 +08:00
|
|
|
|
2000-02-28 23:12:25 +08:00
|
|
|
# Author: The Dragon De Monsyne <dragondm@integral.org>
|
|
|
|
# ESMTP support, test code and doc fixes added by
|
|
|
|
# Eric S. Raymond <esr@thyrsus.com>
|
|
|
|
# Better RFC 821 compliance (MAIL and RCPT, and CRLF in data)
|
|
|
|
# by Carey Evans <c.evans@clear.net.nz>, for picky mail servers.
|
2001-01-15 09:36:40 +08:00
|
|
|
#
|
2000-02-28 23:12:25 +08:00
|
|
|
# This was modified from the Python 1.5 library HTTP lib.
|
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
import socket
|
1998-12-23 04:37:36 +08:00
|
|
|
import re
|
1998-08-04 23:29:54 +08:00
|
|
|
import rfc822
|
1998-08-14 03:57:46 +08:00
|
|
|
import types
|
1998-01-30 01:24:40 +08:00
|
|
|
|
2001-02-16 06:15:14 +08:00
|
|
|
__all__ = ["SMTPException","SMTPServerDisconnected","SMTPResponseException",
|
|
|
|
"SMTPSenderRefused","SMTPRecipientsRefused","SMTPDataError",
|
|
|
|
"SMTPConnectError","SMTPHeloError","quoteaddr","quotedata",
|
|
|
|
"SMTP"]
|
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
SMTP_PORT = 25
|
|
|
|
CRLF="\r\n"
|
|
|
|
|
2001-01-15 09:36:40 +08:00
|
|
|
# Exception classes used by this module.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
class SMTPException(Exception):
|
|
|
|
"""Base class for all exceptions raised by this module."""
|
|
|
|
|
|
|
|
class SMTPServerDisconnected(SMTPException):
|
|
|
|
"""Not connected to any SMTP server.
|
|
|
|
|
|
|
|
This exception is raised when the server unexpectedly disconnects,
|
|
|
|
or when an attempt is made to use the SMTP instance before
|
|
|
|
connecting it to a server.
|
|
|
|
"""
|
|
|
|
|
|
|
|
class SMTPResponseException(SMTPException):
|
|
|
|
"""Base class for all exceptions that include an SMTP error code.
|
|
|
|
|
|
|
|
These exceptions are generated in some instances when the SMTP
|
|
|
|
server returns an error code. The error code is stored in the
|
|
|
|
`smtp_code' attribute of the error, and the `smtp_error' attribute
|
|
|
|
is set to the error message.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, code, msg):
|
|
|
|
self.smtp_code = code
|
|
|
|
self.smtp_error = msg
|
|
|
|
self.args = (code, msg)
|
|
|
|
|
|
|
|
class SMTPSenderRefused(SMTPResponseException):
|
|
|
|
"""Sender address refused.
|
|
|
|
In addition to the attributes set by on all SMTPResponseException
|
1999-11-29 01:11:06 +08:00
|
|
|
exceptions, this sets `sender' to the string that the SMTP refused.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, code, msg, sender):
|
|
|
|
self.smtp_code = code
|
|
|
|
self.smtp_error = msg
|
|
|
|
self.sender = sender
|
|
|
|
self.args = (code, msg, sender)
|
|
|
|
|
1999-04-22 00:52:20 +08:00
|
|
|
class SMTPRecipientsRefused(SMTPException):
|
1999-11-29 01:11:06 +08:00
|
|
|
"""All recipient addresses refused.
|
2000-07-16 20:04:32 +08:00
|
|
|
The errors for each recipient are accessible through the attribute
|
2001-01-15 09:36:40 +08:00
|
|
|
'recipients', which is a dictionary of exactly the same sort as
|
|
|
|
SMTP.sendmail() returns.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, recipients):
|
|
|
|
self.recipients = recipients
|
|
|
|
self.args = ( recipients,)
|
|
|
|
|
|
|
|
|
|
|
|
class SMTPDataError(SMTPResponseException):
|
|
|
|
"""The SMTP server didn't accept the data."""
|
|
|
|
|
|
|
|
class SMTPConnectError(SMTPResponseException):
|
1999-11-29 01:11:06 +08:00
|
|
|
"""Error during connection establishment."""
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
|
|
|
|
class SMTPHeloError(SMTPResponseException):
|
1999-11-29 01:11:06 +08:00
|
|
|
"""The server refused our HELO reply."""
|
1998-01-30 01:24:40 +08:00
|
|
|
|
2000-08-10 22:02:23 +08:00
|
|
|
|
1998-07-13 23:18:49 +08:00
|
|
|
def quoteaddr(addr):
|
|
|
|
"""Quote a subset of the email addresses defined by RFC 821.
|
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
Should be able to handle anything rfc822.parseaddr can handle.
|
|
|
|
"""
|
1998-08-04 23:29:54 +08:00
|
|
|
m=None
|
1998-07-13 23:18:49 +08:00
|
|
|
try:
|
1998-08-04 23:29:54 +08:00
|
|
|
m=rfc822.parseaddr(addr)[1]
|
|
|
|
except AttributeError:
|
|
|
|
pass
|
|
|
|
if not m:
|
|
|
|
#something weird here.. punt -ddm
|
|
|
|
return addr
|
|
|
|
else:
|
|
|
|
return "<%s>" % m
|
1998-07-13 23:18:49 +08:00
|
|
|
|
|
|
|
def quotedata(data):
|
|
|
|
"""Quote data for email.
|
|
|
|
|
1999-11-29 01:11:06 +08:00
|
|
|
Double leading '.', and change Unix newline '\\n', or Mac '\\r' into
|
1998-12-22 11:24:27 +08:00
|
|
|
Internet CRLF end-of-line.
|
|
|
|
"""
|
1998-07-13 23:18:49 +08:00
|
|
|
return re.sub(r'(?m)^\.', '..',
|
1998-08-04 23:29:54 +08:00
|
|
|
re.sub(r'(?:\r\n|\n|\r(?!\n))', CRLF, data))
|
1998-07-13 23:18:49 +08:00
|
|
|
|
2000-08-10 22:02:23 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
class SMTP:
|
1998-08-04 23:29:54 +08:00
|
|
|
"""This class manages a connection to an SMTP or ESMTP server.
|
|
|
|
SMTP Objects:
|
2001-01-15 09:36:40 +08:00
|
|
|
SMTP objects have the following attributes:
|
|
|
|
helo_resp
|
|
|
|
This is the message given by the server in response to the
|
1998-08-04 23:29:54 +08:00
|
|
|
most recent HELO command.
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
ehlo_resp
|
2001-01-15 09:36:40 +08:00
|
|
|
This is the message given by the server in response to the
|
1998-08-04 23:29:54 +08:00
|
|
|
most recent EHLO command. This is usually multiline.
|
|
|
|
|
2001-01-15 09:36:40 +08:00
|
|
|
does_esmtp
|
1998-08-04 23:29:54 +08:00
|
|
|
This is a True value _after you do an EHLO command_, if the
|
|
|
|
server supports ESMTP.
|
|
|
|
|
2001-01-15 09:36:40 +08:00
|
|
|
esmtp_features
|
1998-08-04 23:29:54 +08:00
|
|
|
This is a dictionary, which, if the server supports ESMTP,
|
1999-11-29 01:11:06 +08:00
|
|
|
will _after you do an EHLO command_, contain the names of the
|
|
|
|
SMTP service extensions this server supports, and their
|
1998-08-04 23:29:54 +08:00
|
|
|
parameters (if any).
|
1999-11-29 01:11:06 +08:00
|
|
|
|
2001-01-15 09:36:40 +08:00
|
|
|
Note, all extension names are mapped to lower case in the
|
|
|
|
dictionary.
|
1998-08-04 23:29:54 +08:00
|
|
|
|
1999-11-29 01:11:06 +08:00
|
|
|
See each method's docstrings for details. In general, there is a
|
|
|
|
method of the same name to perform each SMTP command. There is also a
|
|
|
|
method called 'sendmail' that will do an entire mail transaction.
|
|
|
|
"""
|
1998-06-25 10:15:50 +08:00
|
|
|
debuglevel = 0
|
|
|
|
file = None
|
|
|
|
helo_resp = None
|
|
|
|
ehlo_resp = None
|
1998-08-04 23:29:54 +08:00
|
|
|
does_esmtp = 0
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
def __init__(self, host = '', port = 0):
|
|
|
|
"""Initialize a new instance.
|
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
If specified, `host' is the name of the remote host to which to
|
|
|
|
connect. If specified, `port' specifies the port to which to connect.
|
1999-11-29 01:11:06 +08:00
|
|
|
By default, smtplib.SMTP_PORT is used. An SMTPConnectError is raised
|
|
|
|
if the specified `host' doesn't respond correctly.
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
"""
|
1998-08-04 23:29:54 +08:00
|
|
|
self.esmtp_features = {}
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
if host:
|
|
|
|
(code, msg) = self.connect(host, port)
|
|
|
|
if code != 220:
|
|
|
|
raise SMTPConnectError(code, msg)
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
def set_debuglevel(self, debuglevel):
|
|
|
|
"""Set the debug output level.
|
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
A non-false value results in debug messages for connection and for all
|
|
|
|
messages sent to and received from the server.
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
"""
|
|
|
|
self.debuglevel = debuglevel
|
|
|
|
|
|
|
|
def connect(self, host='localhost', port = 0):
|
|
|
|
"""Connect to a host on a given port.
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-12-22 11:02:20 +08:00
|
|
|
If the hostname ends with a colon (`:') followed by a number, and
|
|
|
|
there is no port specified, that suffix will be stripped off and the
|
|
|
|
number interpreted as the port number to use.
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
Note: This method is automatically invoked by __init__, if a host is
|
|
|
|
specified during instantiation.
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
"""
|
2001-07-26 21:37:33 +08:00
|
|
|
if not port and (host.find(':') == host.rfind(':')):
|
2001-07-25 04:34:08 +08:00
|
|
|
i = host.rfind(':')
|
1998-01-30 01:24:40 +08:00
|
|
|
if i >= 0:
|
|
|
|
host, port = host[:i], host[i+1:]
|
2001-02-09 13:40:38 +08:00
|
|
|
try: port = int(port)
|
2001-02-09 18:14:53 +08:00
|
|
|
except ValueError:
|
1998-01-30 01:24:40 +08:00
|
|
|
raise socket.error, "nonnumeric port"
|
|
|
|
if not port: port = SMTP_PORT
|
2001-07-26 21:37:33 +08:00
|
|
|
if self.debuglevel > 0: print 'connect:', (host, port)
|
2001-07-31 16:40:21 +08:00
|
|
|
msg = "getaddrinfo returns an empty list"
|
2001-07-26 21:37:33 +08:00
|
|
|
for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
|
|
|
|
af, socktype, proto, canonname, sa = res
|
|
|
|
try:
|
|
|
|
self.sock = socket.socket(af, socktype, proto)
|
|
|
|
if self.debuglevel > 0: print 'connect:', (host, port)
|
|
|
|
self.sock.connect(sa)
|
|
|
|
except socket.error, msg:
|
|
|
|
if self.debuglevel > 0: print 'connect fail:', (host, port)
|
|
|
|
self.sock.close()
|
|
|
|
self.sock = None
|
|
|
|
continue
|
|
|
|
break
|
|
|
|
if not self.sock:
|
|
|
|
raise socket.error, msg
|
2001-07-25 04:34:08 +08:00
|
|
|
(code, msg) = self.getreply()
|
|
|
|
if self.debuglevel > 0: print "connect:", msg
|
|
|
|
return (code, msg)
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
def send(self, str):
|
|
|
|
"""Send `str' to the server."""
|
|
|
|
if self.debuglevel > 0: print 'send:', `str`
|
1998-03-27 05:13:24 +08:00
|
|
|
if self.sock:
|
1998-08-11 04:07:00 +08:00
|
|
|
try:
|
2000-09-01 14:40:07 +08:00
|
|
|
sendptr = 0
|
|
|
|
while sendptr < len(str):
|
|
|
|
sendptr = sendptr + self.sock.send(str[sendptr:])
|
1998-08-11 04:07:00 +08:00
|
|
|
except socket.error:
|
1999-01-15 11:23:55 +08:00
|
|
|
raise SMTPServerDisconnected('Server not connected')
|
1998-01-30 01:26:45 +08:00
|
|
|
else:
|
1999-01-15 11:23:55 +08:00
|
|
|
raise SMTPServerDisconnected('please run connect() first')
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
def putcmd(self, cmd, args=""):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""Send a command to the server."""
|
1999-06-09 23:13:10 +08:00
|
|
|
if args == "":
|
|
|
|
str = '%s%s' % (cmd, CRLF)
|
|
|
|
else:
|
|
|
|
str = '%s %s%s' % (cmd, args, CRLF)
|
1998-01-30 01:24:40 +08:00
|
|
|
self.send(str)
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
def getreply(self):
|
1998-01-30 01:24:40 +08:00
|
|
|
"""Get a reply from the server.
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
Returns a tuple consisting of:
|
1998-12-22 11:24:27 +08:00
|
|
|
|
|
|
|
- server response code (e.g. '250', or such, if all goes well)
|
|
|
|
Note: returns -1 if it can't read response code.
|
|
|
|
|
|
|
|
- server response string corresponding to response code (multiline
|
|
|
|
responses are converted to a single, multiline string).
|
1999-03-30 04:33:21 +08:00
|
|
|
|
|
|
|
Raises SMTPServerDisconnected if end-of-file is reached.
|
1998-01-30 01:24:40 +08:00
|
|
|
"""
|
|
|
|
resp=[]
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
if self.file is None:
|
|
|
|
self.file = self.sock.makefile('rb')
|
1998-03-27 05:13:24 +08:00
|
|
|
while 1:
|
1998-01-30 01:24:40 +08:00
|
|
|
line = self.file.readline()
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
if line == '':
|
|
|
|
self.close()
|
|
|
|
raise SMTPServerDisconnected("Connection unexpectedly closed")
|
1998-01-30 01:24:40 +08:00
|
|
|
if self.debuglevel > 0: print 'reply:', `line`
|
2001-02-09 13:40:38 +08:00
|
|
|
resp.append(line[4:].strip())
|
1998-03-27 05:13:24 +08:00
|
|
|
code=line[:3]
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
# Check that the error code is syntactically correct.
|
|
|
|
# Don't attempt to read a continuation line if it is broken.
|
|
|
|
try:
|
2001-02-09 13:40:38 +08:00
|
|
|
errcode = int(code)
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
except ValueError:
|
|
|
|
errcode = -1
|
|
|
|
break
|
1999-03-30 04:33:21 +08:00
|
|
|
# Check if multiline response.
|
1998-03-27 05:13:24 +08:00
|
|
|
if line[3:4]!="-":
|
1998-01-30 01:24:40 +08:00
|
|
|
break
|
|
|
|
|
2001-02-09 13:40:38 +08:00
|
|
|
errmsg = "\n".join(resp)
|
2001-01-15 09:36:40 +08:00
|
|
|
if self.debuglevel > 0:
|
1998-01-30 01:26:45 +08:00
|
|
|
print 'reply: retcode (%s); Msg: %s' % (errcode,errmsg)
|
1998-01-30 01:24:40 +08:00
|
|
|
return errcode, errmsg
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
def docmd(self, cmd, args=""):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""Send a command, and return its response code."""
|
1998-03-27 05:13:24 +08:00
|
|
|
self.putcmd(cmd,args)
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return self.getreply()
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-12-22 11:24:27 +08:00
|
|
|
# std smtp commands
|
1998-01-30 01:24:40 +08:00
|
|
|
def helo(self, name=''):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'helo' command.
|
|
|
|
Hostname to send for this command defaults to the FQDN of the local
|
|
|
|
host.
|
|
|
|
"""
|
2000-08-16 03:30:36 +08:00
|
|
|
if name:
|
|
|
|
self.putcmd("helo", name)
|
|
|
|
else:
|
2000-08-16 22:26:22 +08:00
|
|
|
self.putcmd("helo", socket.getfqdn())
|
1998-03-27 05:13:24 +08:00
|
|
|
(code,msg)=self.getreply()
|
|
|
|
self.helo_resp=msg
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return (code,msg)
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
def ehlo(self, name=''):
|
1998-12-22 11:24:27 +08:00
|
|
|
""" SMTP 'ehlo' command.
|
|
|
|
Hostname to send for this command defaults to the FQDN of the local
|
|
|
|
host.
|
|
|
|
"""
|
2000-08-16 03:30:36 +08:00
|
|
|
if name:
|
|
|
|
self.putcmd("ehlo", name)
|
|
|
|
else:
|
2000-08-16 22:26:22 +08:00
|
|
|
self.putcmd("ehlo", socket.getfqdn())
|
1998-08-04 23:29:54 +08:00
|
|
|
(code,msg)=self.getreply()
|
2001-01-15 09:36:40 +08:00
|
|
|
# According to RFC1869 some (badly written)
|
|
|
|
# MTA's will disconnect on an ehlo. Toss an exception if
|
1998-08-04 23:29:54 +08:00
|
|
|
# that happens -ddm
|
|
|
|
if code == -1 and len(msg) == 0:
|
1999-01-15 11:23:55 +08:00
|
|
|
raise SMTPServerDisconnected("Server not connected")
|
1998-06-25 10:15:50 +08:00
|
|
|
self.ehlo_resp=msg
|
2000-12-13 07:20:45 +08:00
|
|
|
if code != 250:
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return (code,msg)
|
1998-08-04 23:29:54 +08:00
|
|
|
self.does_esmtp=1
|
2000-07-16 20:04:32 +08:00
|
|
|
#parse the ehlo response -ddm
|
2001-02-09 13:40:38 +08:00
|
|
|
resp=self.ehlo_resp.split('\n')
|
1998-08-04 23:29:54 +08:00
|
|
|
del resp[0]
|
1998-08-11 04:07:00 +08:00
|
|
|
for each in resp:
|
1998-08-04 23:29:54 +08:00
|
|
|
m=re.match(r'(?P<feature>[A-Za-z0-9][A-Za-z0-9\-]*)',each)
|
|
|
|
if m:
|
2001-02-09 13:40:38 +08:00
|
|
|
feature=m.group("feature").lower()
|
|
|
|
params=m.string[m.end("feature"):].strip()
|
1998-08-04 23:29:54 +08:00
|
|
|
self.esmtp_features[feature]=params
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return (code,msg)
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
def has_extn(self, opt):
|
|
|
|
"""Does the server support a given SMTP service extension?"""
|
2001-02-09 13:40:38 +08:00
|
|
|
return self.esmtp_features.has_key(opt.lower())
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-04-04 01:03:13 +08:00
|
|
|
def help(self, args=''):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'help' command.
|
|
|
|
Returns help text from server."""
|
1998-04-04 01:03:13 +08:00
|
|
|
self.putcmd("help", args)
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return self.getreply()
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
def rset(self):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'rset' command -- resets session."""
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return self.docmd("rset")
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
def noop(self):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'noop' command -- doesn't do anything :>"""
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return self.docmd("noop")
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
def mail(self,sender,options=[]):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'mail' command -- begins mail xfer session."""
|
1998-08-04 23:29:54 +08:00
|
|
|
optionlist = ''
|
|
|
|
if options and self.does_esmtp:
|
2001-02-09 13:40:38 +08:00
|
|
|
optionlist = ' ' + ' '.join(options)
|
1999-06-09 23:13:10 +08:00
|
|
|
self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender) ,optionlist))
|
1998-03-27 05:13:24 +08:00
|
|
|
return self.getreply()
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
def rcpt(self,recip,options=[]):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'rcpt' command -- indicates 1 recipient for this mail."""
|
1998-08-04 23:29:54 +08:00
|
|
|
optionlist = ''
|
|
|
|
if options and self.does_esmtp:
|
2001-02-09 13:40:38 +08:00
|
|
|
optionlist = ' ' + ' '.join(options)
|
1999-01-14 12:18:46 +08:00
|
|
|
self.putcmd("rcpt","TO:%s%s" % (quoteaddr(recip),optionlist))
|
1998-03-27 05:13:24 +08:00
|
|
|
return self.getreply()
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
def data(self,msg):
|
2001-01-15 09:36:40 +08:00
|
|
|
"""SMTP 'DATA' command -- sends message data to server.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
|
1998-12-22 11:02:20 +08:00
|
|
|
Automatically quotes lines beginning with a period per rfc821.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
Raises SMTPDataError if there is an unexpected reply to the
|
|
|
|
DATA command; the return value from this method is the final
|
|
|
|
response code received when the all data is sent.
|
1998-12-22 11:02:20 +08:00
|
|
|
"""
|
1998-03-27 05:13:24 +08:00
|
|
|
self.putcmd("data")
|
|
|
|
(code,repl)=self.getreply()
|
|
|
|
if self.debuglevel >0 : print "data:", (code,repl)
|
2000-12-13 07:20:45 +08:00
|
|
|
if code != 354:
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
raise SMTPDataError(code,repl)
|
1998-03-27 05:13:24 +08:00
|
|
|
else:
|
1999-04-22 00:52:20 +08:00
|
|
|
q = quotedata(msg)
|
|
|
|
if q[-2:] != CRLF:
|
|
|
|
q = q + CRLF
|
|
|
|
q = q + "." + CRLF
|
|
|
|
self.send(q)
|
1998-03-27 05:13:24 +08:00
|
|
|
(code,msg)=self.getreply()
|
|
|
|
if self.debuglevel >0 : print "data:", (code,msg)
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
return (code,msg)
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-08-04 23:29:54 +08:00
|
|
|
def verify(self, address):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'verify' command -- checks for address validity."""
|
1998-08-04 23:29:54 +08:00
|
|
|
self.putcmd("vrfy", quoteaddr(address))
|
|
|
|
return self.getreply()
|
1998-12-22 11:02:20 +08:00
|
|
|
# a.k.a.
|
|
|
|
vrfy=verify
|
1998-08-04 23:29:54 +08:00
|
|
|
|
|
|
|
def expn(self, address):
|
1998-12-22 11:24:27 +08:00
|
|
|
"""SMTP 'verify' command -- checks for address validity."""
|
1998-08-04 23:29:54 +08:00
|
|
|
self.putcmd("expn", quoteaddr(address))
|
|
|
|
return self.getreply()
|
|
|
|
|
1998-12-22 11:02:20 +08:00
|
|
|
# some useful methods
|
1998-08-14 03:57:46 +08:00
|
|
|
def sendmail(self, from_addr, to_addrs, msg, mail_options=[],
|
2001-01-15 09:36:40 +08:00
|
|
|
rcpt_options=[]):
|
|
|
|
"""This command performs an entire mail transaction.
|
1998-12-22 11:02:20 +08:00
|
|
|
|
2001-01-15 09:36:40 +08:00
|
|
|
The arguments are:
|
1998-12-22 11:02:20 +08:00
|
|
|
- from_addr : The address sending this mail.
|
|
|
|
- to_addrs : A list of addresses to send this mail to. A bare
|
|
|
|
string will be treated as a list with 1 address.
|
2001-01-15 09:36:40 +08:00
|
|
|
- msg : The message to send.
|
1998-12-22 11:02:20 +08:00
|
|
|
- mail_options : List of ESMTP options (such as 8bitmime) for the
|
|
|
|
mail command.
|
|
|
|
- rcpt_options : List of ESMTP options (such as DSN commands) for
|
|
|
|
all the rcpt commands.
|
|
|
|
|
|
|
|
If there has been no previous EHLO or HELO command this session, this
|
|
|
|
method tries ESMTP EHLO first. If the server does ESMTP, message size
|
|
|
|
and each of the specified options will be passed to it. If EHLO
|
|
|
|
fails, HELO will be tried and ESMTP options suppressed.
|
|
|
|
|
|
|
|
This method will return normally if the mail is accepted for at least
|
1999-11-29 01:11:06 +08:00
|
|
|
one recipient. It returns a dictionary, with one entry for each
|
|
|
|
recipient that was refused. Each entry contains a tuple of the SMTP
|
|
|
|
error code and the accompanying error message sent by the server.
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
|
|
|
|
This method may raise the following exceptions:
|
|
|
|
|
|
|
|
SMTPHeloError The server didn't reply properly to
|
2001-01-15 09:36:40 +08:00
|
|
|
the helo greeting.
|
1999-11-29 01:11:06 +08:00
|
|
|
SMTPRecipientsRefused The server rejected ALL recipients
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
(no mail was sent).
|
|
|
|
SMTPSenderRefused The server didn't accept the from_addr.
|
|
|
|
SMTPDataError The server replied with an unexpected
|
|
|
|
error code (other than a refusal of
|
|
|
|
a recipient).
|
|
|
|
|
|
|
|
Note: the connection will be open even after an exception is raised.
|
1998-01-30 01:24:40 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
Example:
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-01-30 01:24:40 +08:00
|
|
|
>>> import smtplib
|
|
|
|
>>> s=smtplib.SMTP("localhost")
|
1998-01-30 01:26:45 +08:00
|
|
|
>>> tolist=["one@one.org","two@two.org","three@three.org","four@four.org"]
|
1998-01-30 01:24:40 +08:00
|
|
|
>>> msg = '''
|
|
|
|
... From: Me@my.org
|
|
|
|
... Subject: testin'...
|
|
|
|
...
|
|
|
|
... This is a test '''
|
|
|
|
>>> s.sendmail("me@my.org",tolist,msg)
|
|
|
|
{ "three@three.org" : ( 550 ,"User unknown" ) }
|
|
|
|
>>> s.quit()
|
2001-01-15 09:36:40 +08:00
|
|
|
|
1998-12-22 11:02:20 +08:00
|
|
|
In the above example, the message was accepted for delivery to three
|
|
|
|
of the four addresses, and one was rejected, with the error code
|
1999-11-29 01:11:06 +08:00
|
|
|
550. If all addresses are accepted, then the method will return an
|
1998-12-22 11:02:20 +08:00
|
|
|
empty dictionary.
|
|
|
|
|
|
|
|
"""
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
if self.helo_resp is None and self.ehlo_resp is None:
|
|
|
|
if not (200 <= self.ehlo()[0] <= 299):
|
|
|
|
(code,resp) = self.helo()
|
|
|
|
if not (200 <= code <= 299):
|
|
|
|
raise SMTPHeloError(code, resp)
|
1998-06-25 10:15:50 +08:00
|
|
|
esmtp_opts = []
|
1998-08-04 23:29:54 +08:00
|
|
|
if self.does_esmtp:
|
|
|
|
# Hmmm? what's this? -ddm
|
|
|
|
# self.esmtp_features['7bit']=""
|
|
|
|
if self.has_extn('size'):
|
|
|
|
esmtp_opts.append("size=" + `len(msg)`)
|
|
|
|
for option in mail_options:
|
1998-06-25 10:15:50 +08:00
|
|
|
esmtp_opts.append(option)
|
1998-08-04 23:29:54 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
(code,resp) = self.mail(from_addr, esmtp_opts)
|
2000-12-13 07:20:45 +08:00
|
|
|
if code != 250:
|
1998-03-27 05:13:24 +08:00
|
|
|
self.rset()
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
raise SMTPSenderRefused(code, resp, from_addr)
|
1998-03-27 05:13:24 +08:00
|
|
|
senderrs={}
|
1998-08-14 03:57:46 +08:00
|
|
|
if type(to_addrs) == types.StringType:
|
|
|
|
to_addrs = [to_addrs]
|
1998-01-30 01:24:40 +08:00
|
|
|
for each in to_addrs:
|
1998-08-04 23:29:54 +08:00
|
|
|
(code,resp)=self.rcpt(each, rcpt_options)
|
2000-12-13 07:20:45 +08:00
|
|
|
if (code != 250) and (code != 251):
|
1998-01-30 01:26:45 +08:00
|
|
|
senderrs[each]=(code,resp)
|
1998-01-30 01:24:40 +08:00
|
|
|
if len(senderrs)==len(to_addrs):
|
1998-06-25 10:15:50 +08:00
|
|
|
# the server refused all our recipients
|
1998-01-30 01:24:40 +08:00
|
|
|
self.rset()
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
raise SMTPRecipientsRefused(senderrs)
|
2000-12-13 07:20:45 +08:00
|
|
|
(code,resp) = self.data(msg)
|
|
|
|
if code != 250:
|
1998-01-30 01:24:40 +08:00
|
|
|
self.rset()
|
Changes by Per Cederquist and The Dragon.
Per writes:
"""
The application where Signum Support uses smtplib needs to be able to
report good error messages to the user when sending email fails. To
help in diagnosing problems it is useful to be able to report the
entire message sent by the server, not only the SMTP error code of the
offending command.
A lot of the functions in sendmail.py unfortunately discards the
message, leaving only the code. The enclosed patch fixes that
problem.
The enclosed patch also introduces a base class for exceptions that
include an SMTP error code and error message, and make the code and
message available on separate attributes, so that surrounding code can
deal with them in whatever way it sees fit. I've also added some
documentation to the exception classes.
The constructor will now raise an exception if it cannot connect to
the SMTP server.
The data() method will raise an SMTPDataError if it doesn't receive
the expected 354 code in the middle of the exchange.
According to section 5.2.10 of RFC 1123 a smtp client must accept "any
text, including no text at all" after the error code. If the response
of a HELO command contains no text self.helo_resp will be set to the
empty string (""). The patch fixes the test in the sendmail() method
so that helo_resp is tested against None; if it has the empty string
as value the sendmail() method would invoke the helo() method again.
The code no longer accepts a -1 reply from the ehlo() method in
sendmail().
[Text about removing SMTPRecipientsRefused deleted --GvR]
"""
and also:
"""
smtplib.py appends an extra blank line to the outgoing mail if the
`msg' argument to the sendmail method already contains a trailing
newline. This patch should fix the problem.
"""
The Dragon writes:
"""
Mostly I just re-added the SMTPRecipientsRefused exception
(the exeption object now has the appropriate info in it ) [Per had
removed this in his patch --GvR] and tweaked the behavior of the
sendmail method whence it throws the newly added SMTPHeloException (it
was closing the connection, which it shouldn't. whatever catches the
exception should do that. )
I pondered the change of the return values to tuples all around,
and after some thinking I decided that regularizing the return values was
too much of the Right Thing (tm) to not do.
My one concern is that code expecting an integer & getting a tuple
may fail silently.
(i.e. if it's doing :
x.somemethod() >= 400:
expecting an integer, the expression will always be true if it gets a
tuple instead. )
However, most smtplib code I've seen only really uses the
sendmail() method, so this wouldn't bother it. Usually code I've seen
that calls the other methods usually only calls helo() and ehlo() for
doing ESMTP, a feature which was not in the smtplib included with 1.5.1,
and thus I would think not much code uses it yet.
"""
1999-04-07 23:03:39 +08:00
|
|
|
raise SMTPDataError(code, resp)
|
1998-01-30 01:24:40 +08:00
|
|
|
#if we got here then somebody got our mail
|
2001-01-15 09:36:40 +08:00
|
|
|
return senderrs
|
1998-01-30 01:24:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
def close(self):
|
|
|
|
"""Close the connection to the SMTP server."""
|
|
|
|
if self.file:
|
|
|
|
self.file.close()
|
|
|
|
self.file = None
|
|
|
|
if self.sock:
|
|
|
|
self.sock.close()
|
|
|
|
self.sock = None
|
|
|
|
|
|
|
|
|
|
|
|
def quit(self):
|
1998-06-25 10:15:50 +08:00
|
|
|
"""Terminate the SMTP session."""
|
1998-03-27 05:13:24 +08:00
|
|
|
self.docmd("quit")
|
|
|
|
self.close()
|
1998-06-25 10:15:50 +08:00
|
|
|
|
1998-12-22 11:02:20 +08:00
|
|
|
|
1998-06-25 10:15:50 +08:00
|
|
|
# Test the sendmail method, which tests most of the others.
|
|
|
|
# Note: This always sends to localhost.
|
|
|
|
if __name__ == '__main__':
|
2001-08-13 22:41:39 +08:00
|
|
|
import sys
|
1998-06-25 10:15:50 +08:00
|
|
|
|
|
|
|
def prompt(prompt):
|
|
|
|
sys.stdout.write(prompt + ": ")
|
2001-02-09 13:40:38 +08:00
|
|
|
return sys.stdin.readline().strip()
|
1998-06-25 10:15:50 +08:00
|
|
|
|
|
|
|
fromaddr = prompt("From")
|
2001-02-09 15:40:17 +08:00
|
|
|
toaddrs = prompt("To").split(',')
|
1998-06-25 10:15:50 +08:00
|
|
|
print "Enter message, end with ^D:"
|
|
|
|
msg = ''
|
|
|
|
while 1:
|
|
|
|
line = sys.stdin.readline()
|
|
|
|
if not line:
|
|
|
|
break
|
|
|
|
msg = msg + line
|
|
|
|
print "Message length is " + `len(msg)`
|
|
|
|
|
|
|
|
server = SMTP('localhost')
|
|
|
|
server.set_debuglevel(1)
|
|
|
|
server.sendmail(fromaddr, toaddrs, msg)
|
|
|
|
server.quit()
|