GNU bug report logs - #75628
31.0.50; Error sending mail using SMTP - base64 encoding fails

Previous Next

Full log

Message #26 received at 75628 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: ingo_brunberg <at> web.de, 75628 <at> debbugs.gnu.org
Subject: Re: bug#75628: 31.0.50; Error sending mail using SMTP - base64
 encoding fails
Date: Fri, 17 Jan 2025 18:43:57 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 75628 <at> debbugs.gnu.org,  ingo_brunberg <at> web.de
> Date: Fri, 17 Jan 2025 14:59:59 +0100
> 
> >>>>> On Fri, 17 Jan 2025 15:36:59 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> Cc: Ingo Brunberg <ingo_brunberg <at> web.de>
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Date: Fri, 17 Jan 2025 14:15:26 +0100
>     >> 
>     Ingo> With a simple password some time ago, I could send mail.
>     >> 
>     >> Does this fix it? I guess at least "AUTH LOGIN" needs similar
>     >> treatment, and probably "AUTH CRAM-MD5". I donʼt think XOAUTH2 needs
>     >> it, but Iʼll check.
> 
>     Eli> If this is the fix, then how do you explain what the OP says, that
>     Eli> "some time ago" he could do this without problems?  Do you assume that
>     Eli> the "simple password" was plain-ASCII or something?
> 
> Yes
> 
>     Eli> The OP didn't show the data collected by report-emacs-bug, so we don't
>     Eli> know the locale's encoding in his case.  That could perhaps explain
>     Eli> the difference in behavior.
> 
>     Eli> Also, smtpmail-command-or-throw calls process-send-string, which
>     Eli> should already encode the command.  So the call to
>     Eli> encode-coding-string is almost certainly incorrect; if anything, we
>     Eli> should bind coding-system-for-write to 'utf-8'.  (Btw, how do we know
>     Eli> UTF-8 is the right encoding in this case? is that in some relevant
>     Eli> RFC?)
> 
> The encoding done by process-send-string is done after the base64
> encoding of the password used by the "AUTH PLAIN" command, so it
> doesnʼt help.
> 
> RFC 4616 specifies that the arguments to "AUTH PLAIN" are in UTF-8
> (prior to encoding with base64, see RFC 4954), so we should be
> encoding 'user' as well, strictly speaking.

OK, but then I think we need to bind coding-system-for-write to
no-conversion when calling smtpmail-command-or-throw in this
case. because the string is already encoded.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.