Mailman 3 status of smtpd - python-committers

newer
Fwd: EuroPython 2021: Free tickets...

status of smtpd

Irit Katriel

22 Jun 2021 22 Jun '21

7:50 p.m.

The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd https://docs.python.org/3/library/smtpd.html#module-smtpd should be considered deprecated" and recommends aiosmtpd http://aiosmtpd.readthedocs.io/.

Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.

This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.

Attachments:

attachment.htm (text/html — 1.8 KB)

Show replies by thread

Guido van Rossum

22 Jun 22 Jun

7:57 p.m.

I would hope we’d remove it. It’s a toy implementation, unmaintained, probably doesn’t support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!

On Tue, Jun 22, 2021 at 17:51 Irit Katriel via python-committers < python-committers@python.org> wrote:

...

The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd https://docs.python.org/3/library/smtpd.html#module-smtpd should be considered deprecated" and recommends aiosmtpd http://aiosmtpd.readthedocs.io/.

Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.

This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- --Guido (mobile)

Andrew McNamara

23 Jun 23 Jun

2:03 a.m.

...

I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!

I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.

-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

Victor Stinner

3:06 a.m.

Hi Andrew,

If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.

Create a project on PyPI if you expect contributions.

Victor

On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara andrewm@object-craft.com.au wrote:

...

...
I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is probably full of bugs. Hopefully nobody uses it!

I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.

-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

Victor Stinner

3:14 a.m.

Hi Irit,

Since it's documented as deprecated, asyncore and asynchat are deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest to remove these 3 modules right now. I would prefer to make such incompatible change early in the development cycle, to give more time to users to adapt their projects.

We should explain to users how to handle this incompatible change in What's New in Python 3.11. IMO suggesting to copy the required modules into their project is an acceptable trade-off.

Victor

On Wed, Jun 23, 2021 at 2:51 AM Irit Katriel via python-committers python-committers@python.org wrote:

...

The documentation for smtpd (https://docs.python.org/3/library/smtpd.html) states that " smtpd should be considered deprecated" and recommends aiosmtpd.

Are we planning to remove it from the stdlib? Note that at the moment the smtpd module doesn't emit deprecation warnings, and aiosmtpd is not part of the stdlib.

This came up on https://bugs.python.org/issue28533, where we were hoping to be able to move the (properly) deprecated asyncore and asynhat to test.support (because there are still a few tests that use them). It seems that smtpd is that last blocker for that.

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

Irit Katriel

7:15 a.m.

I've created https://bugs.python.org/issue44498, so we can continue the discussion there.

Once we remove the libraries, we could create a list of all open issues, put this list in another issue, link to it from what's new and then close all issues (including the one with the list). This way the known bugs will not be lost in case someone wants to maintain the code outside the stdlib.

On Wed, Jun 23, 2021 at 9:14 AM Victor Stinner vstinner@python.org wrote:

...

Hi Irit,

Since it's documented as deprecated, asyncore and asynchat are deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest to remove these 3 modules right now. I would prefer to make such incompatible change early in the development cycle, to give more time to users to adapt their projects.

We should explain to users how to handle this incompatible change in What's New in Python 3.11. IMO suggesting to copy the required modules into their project is an acceptable trade-off.

Victor

Joannah Nanjekye

7:58 a.m.

Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?

For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.

For example, I now wonder how Andrew is different from those people?

On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner vstinner@python.org wrote:

...

Hi Andrew,

If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.

Create a project on PyPI if you expect contributions.

Victor

On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara andrewm@object-craft.com.au wrote:

...
...
I would hope we'd remove it. It's a toy implementation, unmaintained, probably doesn't support a lot of newer protocol features, and is

probably

...
...
full of bugs. Hopefully nobody uses it!

I use it and it works well for my specific use case - a Postfix spam filter. During incoming SMTP transactions, I have Postfix configured to pass the received message to my daemon via SMTP (smtpd_proxy_filter). My daemon pronounces judgement, allowing Postfix to potentially reject the message while the sender is still connected (so no bounce backscatter). My daemon only receives one connection at a time, and only well formed SMTP from postfix, so the smtpd module works well - no need for a 3rd party module or the hassle of async.

-- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Night gathers, and now my watch begins. It shall not end until my death.

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Best, Joannah Nanjekye

*"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis*

Antoine Pitrou

8:16 a.m.

Also, it seems this discussion should happen on python-dev so that more people are aware of it.

Regards

Antoine.

Le 23/06/2021 à 14:58, Joannah Nanjekye a écrit :

...

Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?

For example, I now wonder how Andrew is different from those people?

On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner mailto:vstinner@python.org> wrote:

Hi Andrew,

If someone ones smtpd, I would suggest to copy it from Python 3.10
(with asyncore and asynchat) and continue the maintenance outside the
CPython Git repository.

Create a project on PyPI if you expect contributions.

Victor

On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara
<andrewm@object-craft.com.au <mailto:andrewm@object-craft.com.au>>
wrote:
 >
 > >I would hope we'd remove it. It's a toy implementation,
unmaintained,
 > >probably doesn't support a lot of newer protocol features, and
is probably
 > >full of bugs. Hopefully nobody uses it!
 >
 > I use it and it works well for my specific use case - a Postfix spam
 > filter. During incoming SMTP transactions, I have Postfix
configured to
 > pass the received message to my daemon via SMTP
(smtpd_proxy_filter). My
 > daemon pronounces judgement, allowing Postfix to potentially
reject the
 > message while the sender is still connected (so no bounce
backscatter). My
 > daemon only receives one connection at a time, and only well
formed SMTP
 > from postfix, so the smtpd module works well - no need for a 3rd
party
 > module or the hassle of async.
 >
 > --
 > Andrew McNamara, Senior Developer, Object Craft
 > http://www.object-craft.com.au/ <http://www.object-craft.com.au/>
 > _______________________________________________
 > python-committers mailing list -- python-committers@python.org
<mailto:python-committers@python.org>
 > To unsubscribe send an email to
python-committers-leave@python.org
<mailto:python-committers-leave@python.org>
 >
https://mail.python.org/mailman3/lists/python-committers.python.org/
<https://mail.python.org/mailman3/lists/python-committers.python.org/>
 > Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/QA2OVVFX564H5EBARUKODUPMYHTJAMCO/
<https://mail.python.org/archives/list/python-committers@python.org/message/QA2OVVFX564H5EBARUKODUPMYHTJAMCO/>
 > Code of Conduct: https://www.python.org/psf/codeofconduct/
<https://www.python.org/psf/codeofconduct/>



-- 
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
python-committers mailing list -- python-committers@python.org
<mailto:python-committers@python.org>
To unsubscribe send an email to python-committers-leave@python.org
<mailto:python-committers-leave@python.org>
https://mail.python.org/mailman3/lists/python-committers.python.org/
<https://mail.python.org/mailman3/lists/python-committers.python.org/>
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/N7FUYCFY3HJ4WV43WOUYJ2VDABZ2LBRU/
<https://mail.python.org/archives/list/python-committers@python.org/message/N7FUYCFY3HJ4WV43WOUYJ2VDABZ2LBRU/>
Code of Conduct: https://www.python.org/psf/codeofconduct/
<https://www.python.org/psf/codeofconduct/>

-- //Best, Joannah Nanjekye /"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis/

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/W... Code of Conduct: https://www.python.org/psf/codeofconduct/

Irit Katriel

8:21 a.m.

On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye nanjekyejoannah@gmail.com wrote:

...

Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?

For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.

For example, I now wonder how Andrew is different from those people?

asynchat and asyncore are deprecated since 3.6. Doesn't this mean that the decision to remove them was already taken?

Petr Viktorin

8:28 a.m.

On 23. 06. 21 15:21, Irit Katriel via python-committers wrote:

...

On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye mailto:nanjekyejoannah@gmail.com> wrote:
Am not against removing dead batteries but Am still very skeptical
and disturbed about how the
decision to remove modules is made.i.e what goes and what remains?

For example, in the discussion section of PEP 594 , individuals kept
asking for some modules to remain and IIUC,
it's in the decision of the PEP to keep those modules on those
grounds that some people requested for those modules to remain.

For example, I now wonder how Andrew is different from those people?
asynchat and asyncore are deprecated since 3.6. Doesn't this mean that the decision to remove them was already taken?

"Deprecation" was much more vague in 3.6 than it is now. I don't think the current process from PEP-387 was followed with these modules -- I don't see any deprecation warnings being raised.

Marc-Andre Lemburg

8:46 a.m.

FWIW: PEP 594 doesn't seem to have been updated with all the discussions we had around it, e.g. the nntplib is still marked for removal, even though the only reason is related to servers used in the test suite sometimes causing delays, which I will be fixing with Ee by setting up our own test server.

Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.

On 23.06.2021 15:16, Antoine Pitrou wrote:

...

Also, it seems this discussion should happen on python-dev so that more people are aware of it.

Regards

Antoine.

Le 23/06/2021 à 14:58, Joannah Nanjekye a écrit :

...
Am not against removing dead batteries but Am still very skeptical and disturbed about how the decision to remove modules is made.i.e what goes and what remains?

For example, in the discussion section of PEP 594 , individuals kept asking for some modules to remain and IIUC, it's in the decision of the PEP to keep those modules on those grounds that some people requested for those modules to remain.

For example, I now wonder how Andrew is different from those people?

On Wed, Jun 23, 2021 at 5:06 AM Victor Stinner mailto:vstinner@python.org> wrote:

    Hi Andrew,

    If someone ones smtpd, I would suggest to copy it from Python 3.10 (with asyncore and asynchat) and continue the maintenance outside the CPython Git repository.

    Create a project on PyPI if you expect contributions.

    Victor

    On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara mailto:andrewm@object-craft.com.au> wrote: > > >I would hope we'd remove it. It's a toy implementation, unmaintained, > >probably doesn't support a lot of newer protocol features, and is probably > >full of bugs. Hopefully nobody uses it! > > I use it and it works well for my specific use case - a Postfix spam > filter. During incoming SMTP transactions, I have Postfix configured to > pass the received message to my daemon via SMTP (smtpd_proxy_filter). My > daemon pronounces judgement, allowing Postfix to potentially reject the > message while the sender is still connected (so no bounce backscatter). My > daemon only receives one connection at a time, and only well formed SMTP > from postfix, so the smtpd module works well - no need for a 3rd party > module or the hassle of async. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ http://www.object-craft.com.au/ > _______________________________________________ > python-committers mailing list -- python-committers@python.org mailto:python-committers@python.org > To unsubscribe send an email to python-committers-leave@python.org mailto:python-committers-leave@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q...

    https://mail.python.org/archives/list/python-committers@python.org/message/Q...

     > Code of Conduct: https://www.python.org/psf/codeofconduct/ https://www.python.org/psf/codeofconduct/

    --     Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- python-committers@python.org mailto:python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org mailto:python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N...

    https://mail.python.org/archives/list/python-committers@python.org/message/N...

    Code of Conduct: https://www.python.org/psf/codeofconduct/ https://www.python.org/psf/codeofconduct/

-- //Best, Joannah Nanjekye /"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis/

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/W...

Code of Conduct: https://www.python.org/psf/codeofconduct/

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/N...

Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, Jun 23 2021)

...

...
...
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

Barry Warsaw

12:17 p.m.

On Jun 23, 2021, at 09:46, Marc-Andre Lemburg mal@egenix.com wrote:

...

Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.

That’s basically what PEP 594 suggests, and I think that’s a good approach while we’re working out the details and process for removing dead batteries.

-Barry

Marc-Andre Lemburg

24 Jun 24 Jun

4:29 a.m.

On 23.06.2021 19:17, Barry Warsaw wrote:

...

On Jun 23, 2021, at 09:46, Marc-Andre Lemburg mal@egenix.com wrote:

...
Since it's rather likely that we'll always find someone who still uses a module, I think we should find a better strategy on how to deal with such removals, e.g. create a separate attic repo where participation is easier than for CPython, publish the modules in this repo under a python-attic package, and move all deprecated code there.

That’s basically what PEP 594 suggests, and I think that’s a good approach while we’re working out the details and process for removing dead batteries.

Ah, found that section at the very bottom of the PEP now. Thanks.

It may be better to move this all the way up, since I'm pretty sure that it'll make people feel better.

The attic repo would need to go unter the Python Github account though to make it more official and also make sure the licensing aspect it dealt with properly (the PSF would have to officially distribute the package to be able to use the CLA relicensing).

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, Jun 24 2021)

...

...
...
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

1035

Age (days ago)

1036

Last active (days ago)

List overview

Download

12 comments

9 participants

participants (9)

Andrew McNamara
Antoine Pitrou
Barry Warsaw
Guido van Rossum
Irit Katriel
Joannah Nanjekye
Marc-Andre Lemburg
Petr Viktorin
Victor Stinner

status of smtpd

tags

participants (9)