kisli
SMTPUTF8 used incorrectly
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.
Hello!
Thank you for your report, I have fixed the issue with commit 1592cccb6102ba3c28dbcb2387741c692164631e. 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:
- The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).
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.
OK, that's clear, and it makes sense now, thanks. I have committed d7a1b5817e8389e9a4ea3d33c4dd250df9c6860c to fix this, I think that it's correct now.