IMAP login fails if the login ID in the "folders" file contains a "@"

[TheHippoMan]

I'm using the latest Wanderlust under Emacs 26.3, and I've also tried later Emacs versions up through 28.x.

In Wanderlust's "folders" file, if I represent a connection to folder on an IMAP server whose login name contains a "@", the connection to that IMAP server fails.

For example, for a certain account, I might have to log in as follows:

User ID:      myname@example.com
IMAP Server:  imap.example.com

If I put the following into the "folders" file, it's invalid syntax for Wanderlust because of the presence of two "at" signs:

%inbox.IMAPFOLDERNAME:myname@example.com@imap.example.com:starttls!! "FolderIdentifier"

All that happens in this case is that on the folders screen, this folder is shown in pink (instead of normal white), and if I try to enter the folder, I get the following message in the status line, even though there definitely are validly accessible messages in that IMAP folder:

No updates for "%inbox.IMAPFOLDERNAME:myname@example.com@imap.example.com:starttls!!"

This simply means that Wanderlust was unable to properly log in to the IMAP site, and that indicates that the login ID and/or IMAP server name must have been incorrectly parsed by elmo.

I hacked a workaround for this as follows:

In elmo-imap4.el in the "elmo" code base, I replaced the following ...

(defalias 'elmo-imap4-userid 'elmo-imap4-astring)

... with this:

(defun elmo-imap4-userid (string)
    (elmo-imap4-astring (replace-regexp-in-string "==ATSIGN==" "@" string)))

And I recompiled elmo-imap4.el .

Then, I put the following construct into the "folders" file, and it started working properly to represent login ID "myname@example.com" in the folder definition:

%inbox.IMAPFOLDERNAME:myname==ATSIGN==example.com@imap.example.com:starttls!! "FolderIdentifier"

I don't have any login ID's which contain the string "==ATSIGN==", so this works fine for me.

I think that the parsing of these folder entries should only split at the FINAL "@", not on the first one.

Thank you very much for looking into this!

[catap]

Try to escape username as "user@host.com"

[TheHippoMan]

Thank you very much. I tried that, but sadly, it doesn't fix the problem.

The problem is due to the fact that the function elmo-parse-separated-tokens is used within elmo-imap4.el to parse the folder string, and the way that function is written, it captures the IMAP server name after the first "@" that is found in the folder string, no matter what.

In elmo-net.el, we have this:

(defconst elmo-net-folder-name-syntax '((?@ [server ".+"])
                    (?: [port "^[0-9]+$"])
                    (?! stream-type)))

... and in elmo-imap4.el, we have this:

(defconst elmo-imap4-folder-name-syntax
  `(mailbox
    (?: [user "^[A-Za-z0-9]"] (?/ [auth ".+"]))
    ,@elmo-net-folder-name-syntax))

... and later in elmo-imap4.el, we have this:

    (setq tokens (car (elmo-parse-separated-tokens
                       name
                       elmo-imap4-folder-name-syntax)))

Because elmo-net-folder-name-syntax starts with this:

'((?@ [server ".+"])

... theelmo-parse-separated-tokens function assigns the data following the first "@" in the folder string to the server name.

I tried a number of regex variations in the elmo-net-server-name-syntax and elmo-imap4-server-name-syntax definitions, but the "?@" in the elmo-net-server-name-syntax definition forces elmo-parse-separated-tokens to always grab the first string that follows a "@".

In my opinion, either the elmo-imap4-server-name-syntax function needs to be changed, or else the folder string needs to be parsed using a different mechanism.

PS: If the elmo-parse-separated-tokens function could be enhanced so that it could optionally be told to accept the last "@" as the delimiter instead of the first "@", that might be a way to fix this problem.

[ikazuhiro]

Have you tried with below entry? Quoted username works for me and many other users.

%inbox.IMAPFOLDERNAME:"myname@example.com"@imap.example.com:starttls!! "FolderIdentifier"

AFAIK, elmo-parse-separated-tokens can hadle quoted username.

(let ((name "%inbox.IMAPFOLDERNAME:myname@example.com@imap.example.com:starttls!!"))
  (elmo-parse-separated-tokens name elmo-imap4-folder-name-syntax))
-> (((server . "example.com@imap.example.com") (user . "myname") (mailbox . "%inbox.IMAPFOLDERNAME")) . ":starttls!!")

(let ((name "%inbox.IMAPFOLDERNAME:\"myname@example.com\"@imap.example.com:starttls!!"))
  (elmo-parse-separated-tokens name elmo-imap4-folder-name-syntax))
-> (((server . "imap.example.com") (user . "myname@example.com") (mailbox . "%inbox.IMAPFOLDERNAME")) . ":starttls!!")

[catap]

On Sat, 13 Apr 2024 03:46:37 +0200, TheHippoMan wrote:

Thank you very much, but sadly, that doesn't fix the problem.

This is very strange, because I read your reply at WL which is get a message from my IMAP server to whcich I connect via string like:

***@***.******@***.***:993!

-- wbr, Kirill

[TheHippoMan]

Have you tried with below entry? Quoted username works for me and many other users.

%inbox.IMAPFOLDERNAME:"myname@example.com"@imap.example.com:starttls!! "FolderIdentifier"

I mentioned above that I already tried that, and it didn't work for me.

Given that this quoted username construct works for both of you (and thank you!), I'm going to go back and analyze my Emacs and WL setup. Perhaps something else in my literally dozens of *.el files, some of which I've been using for up to something like 30 or more years, is interfering with WL's and elmo's normal operation.

I'll report back when I have more data.

[Erk-]

I had the same issue some years ago in #144

[TheHippoMan]

I re-installed WL and elmo, and now this problem has disappeared. The following now works properly to connect me to IMAP sites where my user name contains "@":

%inbox.IMAPFOLDERNAME:"myname@example.com"@imap.example.com:starttls!! "FolderIdentifier"

I thought that I had been running the latest WL and elmo, but I now realize that I had accidentally installed them in the wrong directory, and that I had been unknowingly running ancient, stone-age versions of both of these packages.

So, all is well now.

I'm very sorry for the bandwidth!