I am using Claws Mail version 3.11.1 with Debian GNU/Linux 8 (jessie). When you add a recipient from address book it is composed from display name and email address. E.g. "Xxxx Xxxxxx, XXXX Xxxxxxx" <xxxx.xxxxxx@xxxx-xxxxxxx.xx> (for masking person data the command `sed "s/[A-Z]/X/g;s/[a-z]/x/g"` has been applied). It appeared that while address was completely displayed in the input field after "To:" (in window "Compose message") smtp server complaint about syntax of command "RCPT TO:<Xxxx Xxxxxx>". So the address part beginning with the comma has been stripped. In compose window I manually deleted all characters before and after the plain mail address (xxxx.xxxxxx@xxxx-xxxxxxx.xx) and subsequent click on "Send message" succeeded. I could not systematically reproduced this bug. The bug arose having three Cc addresses defined. I assume the bug is caused by some editing (setting cursor, copy and paste of address strings, changing address type from "Cc" to "To" and similar). I did not use tab autocompletion from addressbook. There had been Cc values with special characters (German Umlauts like ö) while "To" address field in question just contained ascii characters. Best regards, Hagen Riedel > [11:30:03] ESMTP< 235 2.7.0 Authentication successful > [11:30:03] ESMTP> MAIL FROM:<xxx.xxx@xxx.de> SIZE=7451 > [11:30:03] SMTP< 250 2.1.0 Ok > [11:30:03] SMTP> RCPT TO:<Xxxx Xxxxxx> > [11:30:03] SMTP< 501 5.1.3 Bad recipient address syntax > ** error occurred on SMTP session > *** Error occurred while sending the message: > 501 5.1.3 Bad recipient address syntax
My guess is that during the mentioned editing, you ended up removing the quotes, so the To: entry read something like: Foo Bar, Foobar Zot <foo@bar.com> ...which got split into two recipients: "Foo Bar" and "Foobar Zot <foo@bar.com". And naturally, SMTP server refused the "Foo Bar" recipient. When I enter above string to "To" field and try sending, I get the behaviour described below - Claws Mail sends "RCPT TO:<Foo Bar>", which is rejected.
I would follow up with Andrej's guess. As user usually does not focus on some missing quotes bug report has to be regarded invalid. My test also shows the behaviour described when removing quotes. It even appears when just removing the leading quote! When I delete the trailing quote only the client displays a message window "Error: Could not queue message for sending." At the first glance I assumed a server-side cause of trouble. To this effect some more precise syntax check and user messaging may significantly improve usability. By the way: Another guess was that there occured some text conversion as sophisticated software sometimes tries to interpret/convert data according to special locale (e.g. "quote" is typeset as „quote“). This hypothesis has to be dropped as my tests reveal that for any character other than a double quote (ASCII Code 0x22) it is interpreted as part of the mail address and written to the log, e.g.: > [12:20:11] SMTP> RCPT TO:<˝Hagen Riedel> > [12:20:11] SMTP< 501 5.1.3 Bad recipient address syntax > ** error occurred on SMTP session > *** Error occurred while sending the message: > 501 5.1.3 Bad recipient address syntax It remains solely imaginable that somehow the quotes have been stripped as invalid characters for the data type of some variable/container.