Make LHLO behave like EHLO

[emersion]

The current logic makes LHLO behave like the legacy HELO. However the
RFC says:

The LHLO command has identical semantics to the EHLO command of ESMTP.

Clients connecting to the LMTP server expect extensions such as 8BITMIME
to be advertised. However aiosmtpd won't send any extension string.

Fix this by making LHLO an alias for EHLO instead of HELO.

Related issue number

• Closes LMTP server fails to list any extended services #123
• Closes LMTP server doesn't support require_starttls; require_starttls not RFC-compliant #124

Checklist

• I think the code is well written
• Unit tests for the changes exist
• tox testenvs have been executed in the following environments:
  • Linux (Arch): {py38}-{nocov,cov,diffcov}, qa, docs
• Documentation reflects the changes
• Add a news fragment into the NEWS.rst file

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov]

Codecov Report

Merging #207 (b88735a) into master (17541ae) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #207   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines         1048      1049    +1     
  Branches       184       184           
=========================================
+ Hits          1048      1049    +1     

Impacted Files	Coverage Δ
aiosmtpd/lmtp.py	100.00% <100.00%> (ø)
aiosmtpd/smtp.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 17541ae...b88735a. Read the comment docs.

[ddevault]

Hey, I'm the CEO of SourceHut, and @emersion wrote this patch under our direction.

We are opposed in principle to signing contributor license agreements, regardless of the apparently banality of the CLA in question. The changes @emersion made are available under the same terms as the aiosmtpd project itself: Apache 2.0. This gives you sufficient legal standing to apply the changes without additional fanfare. We use aiosmtpd to process tens of thousands of emails per year, and we're prepared to fork it if you insist.

Alternatively, you could consider adopting something like git and Linux's signed-off-by header, which indicates agreement with the Developer Certificate of Origin.

[asvetlov]

@ddevault I have a question to you. Did you found the CLA requirement for https://github.com/python/cpython also uncomfortable and not acceptable or agree to make an exception for that particular project?

[ddevault]

I don't think I have signed Python's CLA, and I probably would not do so. However, my level of investment in Python dwarfs that in aiosmtpd by scores, and it's much harder to fork it if I needed to. I have refused to sign Go's CLA, by the way.

[asvetlov]

That's sad to hear that CLA frustrates you.
I'm not a lawyer, my thought is the following:
If big projects like Python and Django think that they need to ask for CLA -- maybe aiohttp needs it too.
If aiohttp needs a CLA -- maybe the CLA requirement for all projects from aio-libs is a good idea.

[ddevault]

And if the largest project in the world, Linux, doesn't need one - maybe they have it right? The DCO is a good compromise that will get you everything you need to be confident that you can merge the patches.

And what of the hundreds of projects which don't have a CLA? Have you ever heard of any of them regretting it, for reasons other than the leadership's personal greed? It's precisely the horror stories of the fates of projects which have required a CLA, like MongoDB, RedisLabs, and many more, which should discredit the idea of CLAs. You should not sign one, and you definitely should not ask for one. Frankly, it's rude to.

[warsaw]

I hate to wade into this discussion, but I guess I will for whatever it's worth (probably not much :D).

I've obviously signed the Python CLA, and for Python I think it's both a good idea and very low friction for contributors. Python has paid legal opinions that require this, and I have zero problem signing it. Where I've needed my employer to give me permission, none have ever balked.

I've also contributed to and led GNU projects. On Mailman we required copyright assignment to the FSF for all contributions above a certain size. Some people didn't like that, but for the most part, it was never a problem. Also pretty much a legal requirement for contributions.

Both of these are big projects, and both the PSF and FSF have made it quite clear that contributions under the CLA are guaranteed to be released open source / free software. So there's no question of some nefarious organization profiting off labor of volunteers. The CLAs are there to protect the legal interests of the organization owning the IP, and since both the PSF and FSF have strongly open reputations, everyone is cool with it.

I have also worked on non-GNU, GPL'd projects owned by other corporations, and there I think the CLAs have been a hinderance. The biggest problem there was that the CLAs essentially said, "we'll release your contribution as FLOSS, but we reserve the right to include your contribution in closed commercial products". It's no surprise to me that that stance isn't very well received.

That all said, what is the purpose of a CLA for aio-libs? Are you afraid of being sued for copyright infringement? E.g. someone who doesn't sign the CLA contributes something significant, but either they don't own the rights to that, or they are using that as a weapon to shut the project down. I personally think that's very unlikely in practice, and also not very practical given that for the size of a project like aio-libs, almost all contributions are derivative works anyway, so it's unlikely that such a copyright claim would stand in court. And it's also pretty unlikely that CLA or no, bad copyright actors could still make your life uncomfortable.

I don't personally require CLAs in my small open source projects. I think they just add unnecessary friction for very little value.

But every project has to make their own decisions about the level of risk that a CLA mitigates.

[asvetlov]

Thank you @warsaw for the comprehensive comment.
You've convinced me that the CLA is not mandatory and aio-libs can just drop it.

I apologize for the inconvenience, I never had a target to make harm but was trying to satisfy all really required things.

Will drop the CLA in the moment.

[ddevault]

Thanks @asvetlov and @warsaw!

[warsaw]

Yay! Glad to help.

[asvetlov]

Thanks for not the silent disagree but opening a productive discussion!

[pepoluan]

Now that we're over the thing-that-shall-not-be-named, let's return to the PR proper 😉

I'll pick this up.

[pepoluan]

Temporarily converting this to Draft. Will UnDraft after I test this on my testing systems.

[pepoluan]

Test Progress on my Test Systems:

• Windows 10 (via PyCharm tox runner): (ALL)
• Windows 10 (via PSCore 7.1.0): (ALL)
• Windows 10 (via Cygwin): qa, py36-{nocov,cov}
• Ubuntu 18.04 on WSL 1.0: (ALL) + pypy3-{nocov,cov,diffcov}
• Ubuntu 18.04 on VBox: (ALL) + pypy3-{nocov,cov,diffcov}
• Ubuntu 20.04 on VBox: (ALL) + pypy3-{nocov,cov,diffcov}
• FreeBSD 12.1 on VBox: (ALL) + pypy3-nocov

[pepoluan]

.coveragerc has been renamed to coverage.cfg

Reason is explained in a59fd41

[pepoluan]

.coveragerc has been renamed to coverage.cfg

Reason is explained in a59fd41

[pepoluan]

All testing done.

Will now UnDraft.

[pepoluan]

I personally have no objections to the code / changes. But it will be cheating if I squamerge based on just my own approval 😅

[pepoluan]

If no objections within 2x24 I'll squamerge this 😄

Edit: Just saw the merge conflicts. When did that creep in?? Lemme fix those and repush.

Edit 2: Merged and repushed. If no objections to the patches within 2x24, I'll squamerge.