A new module that provides an SMTP server base class,
derived from the SocketServer class.

The class in this module does not implement a fully
functional SMTP server; it simply provides a framework
that subclasses can use to build their own
special-purpose SMTP servers.

Logged In: YES 
user_id=92689

1) If you're contributing code, it should follow the style guide 
(PEP 8)
2) How does this work relate to smtpd.py?

Logged In: YES 
user_id=341410

1) Agreed completely.

2) smtpd.py is written using the asynchat/asyncore
framework.  This uses the single/multi-threaded/forked
SocketServer.TCPServer framework (various protocols have
both an asynchronous and synchronous version in the standard
library).

Other comments:
3) I also think documentation for this module is necessary,
as is a 3rd party review of the code and error messages.

4) SSL/TLS support should also be included, along with a
reasonable assortment of EHLO, HELP, etc., though smtpd also
should gain such support, so this is not a deal-breaker.

5) Perhaps smtpd should gain allow_sender() and
allow_recipient() methods, and both should gain allow_host()*.

*proper implementations of the above 3
allow_(sender|recipient|host) methods (with either
framework) would be sufficient to do temporary hostname
blacklisting on remote hosts trying to brute-force a local
account listing.

Logged In: YES 
user_id=92689

I just wanted to check whether the author _knows_ smtpd.py, 
since he doesn't mention it. Maybe I should put it more bluntly:

What's the benefit of having an incompatible, less 
featureful, threaded version of smtpd.py in the library?

Logged In: YES 
user_id=994239

Yes, I am aware of smtpd.py.  My understanding is (although
please correct me if I'm wrong) that the asyncore/asynchat
framework will not be able to service network clients if the
found_terminator() method performs an operation that blocks.
 The BaseSMTPServer class doesn't suffer from that problem,
because it's threaded.

If you're interested in integrating this module, I'd be
happy to clean it up to conform with the Python style
guidelines, add documentation, and implement the
allow_host() method.

Logged In: YES 
user_id=341410

Re: features

Aside from NOOP (which is easily added), the provided
BaseSMTPServer seems to offer the same amount of
functionality as smtpd (ignoring DebuggingServer, PureProxy
and MailmanProxy, which are trivially borrowed from smtpd).


Re: What's the benefit...

Someone who wanted to use a synchronous SMTP server would
have one available.


I think that we should probably wait until the original
author answers how this relates to smtpd.py, and perhaps
decide then.

Logged In: YES 
user_id=341410

Hrm, nevemind, I just noticed mdr0's post.  I'll leave the
rest up to someone who has the authority to make decisions.

Logged In: YES 
user_id=994239

Here's a new version of BaseSMTPServer with the following
changes:

* Added lots of documentation.
* Changed code style to conform with PEP 8.
* Added allow_host() method.
* Added smtp_NOOP() method.
* Improved interface to process_message() and access-control
methods.

Please let me know what you think.  Thanks!

Logged In: YES 
user_id=341410

It still has a couple tabs, but I don't believe that is a
big deal.

I think it fits in with the standard SocketServer framework,
and that it would make sense to add it, but I don't have any
authority to make decisions.

Logged In: YES 
user_id=366566

Regarding blocking process_message implementations: there
really is no issue here.  If a blocking operation needs to
be performed, then a thread can be created inside
process_message.  Nothing is gained by starting a thread any
earlier than this.  Arguably, it is even a loss since it is
more  computationally and resource intensive to do so.

Support for blocking message processing therefore does not
seem to be sufficient reason for including this module.  Are
there other advantages?

Logged In: YES 
user_id=994239

Sorry for the delayed response; I've been out of town for a
while.

I understand the point about being able to create threads as
needed using asynchat/asyncore.  However, if there is no
advantage to using the SocketServer framework, why is it
there?  Is it just for backward compatibility?

There are a number of modules in the standard library that
use the SocketServer framework.  Is an effort being made to
rewrite all of them to use asynchat/asyncore?  Or are these
modules simply grandfathered in, even though no new
SocketServer modules are being accepted?

In any case, for anyone that might be interested, here's a
new version of BaseSMTPServer with the following changes:

* Fixed a few incorrect SMTP reply codes.
* Imrproved EOF handling.

Please let me know what you thinlk.  Thanks!

Logged In: YES 
user_id=21627

I think this code can be added to the standard library. Can
somebody please provide documentation changes, and also a
test suite (as far as reasonable)?

Also, Mark: Are you willing to sign a contributor form, at

http://www.python.org/psf/contrib/

Logged In: YES 
user_id=33168

If Mark is a Google employee and Google has rights to this
code, it would be covered under the existing Google contrib
agreement.

Logged In: YES 
user_id=366566

The code in smtp_DATA isn't factored to allow subclasses to
limit the amount of data received.  As is, the server is
vulnerable to a memory exhaustion attack, since it doesn't
implement any kind of limit on the number of lines buffered
in memory.  It should at least provide a hook for this, even
if it still doesn't enforce any limits.

I can't see this being accepted as it's not had public exposure, at least not that I'm aware of.  Other opinions welcomed.

I agree with opinions expressed by Jean-Paul in msg47196.
I see no real gain in providing a smptd.py clone which provides no other new difference other than using threads instead of a non-blocking approach.