In a perfect world, yes this would be great. But obviously we can’t control other servers now can we. The best course of action is to follow the most widely held convention instead of sending all lowercase which is no convention at all.
2 Likes
This means there is no actual issue.
1 Like
No, this means it’s impractical to find a specific server that is noncompliant like a needle in a haystack. It does not mean it is a nonexistent problem.
I see you are avoiding answer this question that is looking for real backwards compatibility issues. Otherwise, it seems clear that sending out uppercase smtp commands would only be beneficial and not cause real backwards compatibility concerns.
I’m all for consistency, and in an ideal world all of these strings would be upper case. But other than consistency, I don’t see any upside to making these changes, and if it were up to me, I’d leave it alone. We’ll surely break at least some people’s tests. In my mind, it’s not worth doing.
2 Likes
You dismissed the concern about breaking a 25-year-old convention within the implementation, yet you continue to revisit the same question and point out that I haven’t raised backward compatibility issues. I’m not sure how that makes sense.
However, if you can demonstrate that no other backward compatibility issues will arise (aside from my valid use case), then normalizing everything to uppercase would be reasonable.
If all uppercase became the new standard, we would end up with SMTP 2 and smtplib2. There is no need to adjust the old smtplib to fit new standards or suggestions about supporting legacy implementations. This approach doesn’t make sense because if an older implementation like smtplib has been working flawlessly for years, then everything is functioning as intended.
Actually not
This means that one writing code using Python’s SMTLIB will all of a suden be required to go from a few lines using the STDLIB to an subclassing/monkypatching journey combined with server debugging which could take some weeks.
There is no sense in not changing this. If you don’t use SMTPLIB, like more than 99% of Python users don’t use, there is just no issue for you - but there is an issue here, and even if it were not for non conformant servers in the wild, but just a styling and aesthetics change, it would still be worth it.
We might even take a deeper look if Python’s smtplib commands were consitently lower case, since its inception - but that is not the case either.
1 Like
Of course there is. Any backward incompatible change needs to be considered carefully. In this case, the incompatibility seems small. Any standards-compliant code being sent the output of smtplib will be unaffected, and the OP has pointed out that the RFC itself notes that the commonest example of non-compliant code is when only upper case is accepted.
While this change does have the potential to break some non-compliant consumers, the risk is small. The benefit is also small, but it has the advantage of following the RFC recommendation.
@elis.byberi is pointing out a real case where the change will break code. One breakage isn’t enough to mean that we shouldn’t do this. But we also shouldn’t dismiss people who are raising legitimate concerns with the change.
I’m +0 on making this change.
3 Likes
Building on the reply from @pf_moore , I’d say the potential gain from covering more servers slightly outweighs the relatively small risk of breaking the client implementations that are dependent on the lowercase commands. Since this change only affects what is being sent out by smtplib, it really shouldn’t affect any implementations from dev perspective as you wouldn’t see that. The only way it would break something is if you are checking the case of what you are sending out which seems to be a very edge case scenario. Ultimately, it’s undeniable that there will be at least a handful of implementations of smtplib out there that are using assertion tests that might break so -1 for that. But there’s also a definite advantage of covering more servers so +1 for that. And of course, adhering to RFC is always a plus so I’d say +1 for that too. I think correcting this to adhere to RFC is the best move as it makes smtplib’s responses standardized and would make changes in the future less likely. It’s better to fix your assertion tests to be with the RFC standard than to have them dependent on the case used by smtplib which is unreliable since some commands are uppercase while others are lower.
I just looked up a concise definition of a breaking change, and I’d argue that, at the language level, changing a function’s output for the same input qualifies. Such a change can break any tooling that relies on consistent output, including logging and testing.
Since case normalization is already handled in the current implementation, programs using this library don’t need to perform it themselves. Therefore, any modification to the existing normalization behavior would require manual updates in every program or tool that depends on smtplib.
The normalization may be inconsistent, but I believe it’s too late to change it. Introducing a smtplib2 or a separate PyPI package would be a much safer, non-breaking approach.
1 Like
I’d agree with this[1]. But you’re missing the point, which is that breaking changes aren’t prohibited, they just have to be carefully evaluated.
It would be reasonable to claim that as this is a potentially breaking change, rather than a bugfix, it needs to wait for Python 3.15, and not be changed in a bugfix release.
Mostly. Given that the case normalisation isn’t documented, it’s possible to claim that there’s no breaking change in the documented interface. And given that the docs appear to always quote the commands in uppercase, it’s arguable that sending lowercase is a bug, as it differs from what the docs imply. ↩︎
2 Likes
That’s what I was trying to emphasize. My assumption was that they considered this a simple bugfix.
If the change is properly documented in What’s New in Python 3.15, it seems acceptable.
I would prefer a longer transition phase, though I’m not sure how that would be implemented in the case of smtplib.
1 Like
That seems like a good way to go. 3.15 will be some time from now, but since there’s no rush for this, it doesn’t have to be an immediate bugfix.
1 Like
IF a transition phase is absolutely needed, there could be an additional argument to chose it the commands are lower or upper case, defaulting to lower to keep backward compatibility while advertising that the default will change after a few years.
I don’t think it’s worth it considering the additional complexity and the existence of the new option “forever”, but I wanted to point out that it’s definitely possible.
1 Like
I don’t think there is any need for a transition (in the sense of “a period where both work”). Just switch the behaviour in a feature release, not a bugfix release.
And to put this in perspective, while I understand this matters to you, there is as yet no evidence that this would affect anyone else - so we’re mostly trying to minimise potential breakage, not real issues.
2 Likes
potential gain from covering more servers
There is still no mention of which servers are case sensitive. Their number could be zero.
Also, there may exist implementations which aren’t case sensitive and only accept lowercase – those would be broken after this change. Could be zero.
So far, I haven’t seen any data to support this change.
1 Like
Again, it’s impractical to point out exact examples of servers with this but we know RFC states this IS a known issue for uppercase (not lowercase).
+1 for this
The RFC does not mention any non-compliant servers, or I have difficulty finding that information.
Section 2.4 of RFC 5321 explicitly outlines this issue.
To be honest, RFC 5321 is so old that any supposedly non-compliant servers should no longer be functioning. Personally, I would ignore them entirely and treat them as potentially malicious. I wouldn’t send them email under any circumstances.
A stronger argument would be the importance of consistency and adherence to the de facto industry standard of using all-uppercase commands.