New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smtpd strips final carraige return from received message body #69739
Comments
It's well known that in quoted-printable encoding the "CRLF" can be encoded to "=CRLF". The problem is caused by below code: class SMTP:
...
def data(self, msg):
...
q = quotedata(msg)
if q[-2:] != CRLF:
q = q + CRLF
q = q + "." + CRLF
self.send(q)
... Before it sends the message q, it will try to append the end-of-data sequence "<CRLF>.<CRLF>". Thus the corresponding action should be taken on SMTP client side, class SMTP:
...
def data(self, msg):
...
q = quotedata(msg)
q = q + CRLF + "." + CRLF
self.send(q)
... |
Correct the action of appending the end-of-data sequence "<CRLF>.<CRLF>" |
RFC 2812 says: Note that the first <CRLF> of this terminating sequence is also the <CRLF> that ends the final line of the data (message text) So, smtplib is correct. If you have a server that is not respecting this, then that server is out of compliance and there isn't anything we can do about it. However, I don't think that is your problem. = at the end of a line actually represents a "soft carriage return", which means one that is *eliminated* in the decoded output. If you will read section 6.7 of rfc 2045, specifically notes (2) and (3) in the second block of numbered paragraphs, you will see that an 'ultimate' = (an = at the end of an encoded block, with or without a CRLF after it), such as you have in your sample, is illegal. Further, the recommended recovery action if one is seen while decoding is to leave the = in the decoded output, just as you are observing happening. So, there is no bug here except in your message :) |
I can understand you, while could you please consider below fact: If we can just add "<CRLF>.<CRLF>" following mail data like postfix, which is influential amd authoritative in SMTP field, that will make things simple and will not make any trouble in reality situation. I just advise this, if you think no need then I can compromise. |
That does indeed appear to be a bug in smtpd.py. Even if postfix's client mode does do an unconditional add of an extra newline, it is wrong according to the RFC, so I don't think that we'd change smtplib. Especially since we've had no other reports of the current code causing problems (the only problem case you have reported is against smtpd.py, which is a bug in smtpd.py). |
I'm closing this as won't fix since smtpd.py is deprecated and likely won't see much future improvements. Please take a look at aiosmtpd as a much better third party replacement. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: