-
Notifications
You must be signed in to change notification settings - Fork 109
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
SMTPUTF8 used incorrectly #186
Comments
Hello! Thank you for your report, I have fixed the issue with commit 1592ccc. Additionally, there was also a bug in RCPT command, where SMTPUTF8 was never sent even if extension is available. |
But RCPT should not have an SMTPUTF8 argument, only MAIL FROM should have that. |
Actually, I am not sure how to interpret this extract in the RFC:
It seems to imply that the argument is available for both commands? |
The argument SMTPUTF8 is sent only for MAIL FROM, and once sent, it extends the address format used in both MAIL FROM and RCPT TO (the reverse-path and forward-path syntax productions respectively). Philosophically, an entire message is SMTPUTF8, not just a specific address. If any address in the message uses non-ASCII, then the entire message is considered to do so, and the SMTPUTF8 flag must be set on MAIL FROM. |
…ddress must switch the whole message to SMTPUTF8.
OK, that's clear, and it makes sense now, thanks. I have committed d7a1b58 to fix this, I think that it's correct now. |
Hi,
SMTPTransport uses SMTPUTF8 incorrectly. It sends SMTPUTF8 if the server supports it, instead of when the message/addresses require it.
The RFC says that the flag should be used when necessary; vmime sends it when possible. The correct test would be to send SMTPUTF8 if any of the addresses involved (MAIL FROM or any RCPT TO) contain non-ASCII characters.
The problem with this mistake if that if vmime sets the flag even though all of the addresses used are pure ASCII, and then the message is forwarded to another server which does not support SMTPUTF8, then the transmission fails at that stage. The forwarding server sets the SMTPUTF8 flag because vmime instructed it to, the forwarded-to server issues an error message, and transmission fails.
The text was updated successfully, but these errors were encountered: