Revision 296e14301a7aa23a5ee2bfaa1210af54e594cbbf authored by Guido van Rossum on 07 April 1999, 15:03:39 UTC, committed by Guido van Rossum on 07 April 1999, 15:03:39 UTC
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.
"""
1 parent 630a9a6
cStringIO.h
#ifndef CSTRINGIO_INCLUDED
#define CSTRINGIO_INCLUDED
/*
cStringIO.h,v 1.4 1997/12/07 14:27:00 jim Exp
cStringIO C API
Copyright
Copyright 1996 Digital Creations, L.C., 910 Princess Anne
Street, Suite 300, Fredericksburg, Virginia 22401 U.S.A. All
rights reserved. Copyright in this software is owned by DCLC,
unless otherwise indicated. Permission to use, copy and
distribute this software is hereby granted, provided that the
above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear. Note that
any product, process or technology described in this software
may be the subject of other Intellectual Property rights
reserved by Digital Creations, L.C. and are not licensed
hereunder.
Trademarks
Digital Creations & DCLC, are trademarks of Digital Creations, L.C..
All other trademarks are owned by their respective companies.
No Warranty
The software is provided "as is" without warranty of any kind,
either express or implied, including, but not limited to, the
implied warranties of merchantability, fitness for a particular
purpose, or non-infringement. This software could include
technical inaccuracies or typographical errors. Changes are
periodically made to the software; these changes will be
incorporated in new editions of the software. DCLC may make
improvements and/or changes in this software at any time
without notice.
Limitation Of Liability
In no event will DCLC be liable for direct, indirect, special,
incidental, economic, cover, or consequential damages arising
out of the use of or inability to use this software even if
advised of the possibility of such damages. Some states do not
allow the exclusion or limitation of implied warranties or
limitation of liability for incidental or consequential
damages, so the above limitation or exclusion may not apply to
you.
If you have questions regarding this software,
contact:
info@digicool.com
Digital Creations L.C.
(540) 371-6909
This header provides access to cStringIO objects from C.
Functions are provided for calling cStringIO objects and
macros are provided for testing whether you have cStringIO
objects.
Before calling any of the functions or macros, you must initialize
the routines with:
PycString_IMPORT
This would typically be done in your init function.
*/
/* Basic fuctions to manipulate cStringIO objects from C */
static struct PycStringIO_CAPI {
/* Read a string. If the last argument is -1, the remainder will be read. */
int(*cread) Py_FPROTO((PyObject *, char **, int));
/* Read a line */
int(*creadline) Py_FPROTO((PyObject *, char **));
/* Write a string */
int(*cwrite) Py_FPROTO((PyObject *, char *, int));
/* Get the cStringIO object as a Python string */
PyObject *(*cgetvalue) Py_FPROTO((PyObject *));
/* Create a new output object */
PyObject *(*NewOutput) Py_FPROTO((int));
/* Create an input object from a Python string */
PyObject *(*NewInput) Py_FPROTO((PyObject *));
/* The Python types for cStringIO input and output objects.
Note that you can do input on an output object.
*/
PyTypeObject *InputType, *OutputType;
} * PycStringIO = NULL;
/* These can be used to test if you have one */
#define PycStringIO_InputCheck(O) \
((O)->ob_type==PycStringIO->InputType)
#define PycStringIO_OutputCheck(O) \
((O)->ob_type==PycStringIO->OutputType)
static void *
xxxPyCObject_Import(module_name, name)
char *module_name;
char *name;
{
PyObject *m, *c;
void *r=NULL;
if((m=PyImport_ImportModule(module_name)))
{
if((c=PyObject_GetAttrString(m,name)))
{
r=PyCObject_AsVoidPtr(c);
Py_DECREF(c);
}
Py_DECREF(m);
}
return r;
}
#define PycString_IMPORT \
PycStringIO=xxxPyCObject_Import("cStringIO", "cStringIO_CAPI")
#endif /* CSTRINGIO_INCLUDED */
Computing file changes ...
