Err(Parse(Invalid(...)) ) on most methods to select/examine/fetch from gmail

[softprops]

First off, thank you for your work on this crate.

I'm having trouble getting almost all session methods to work with authenticating with an app password with gmail

let domain = "...";
let tls = TlsConnector::builder().build().unwrap();

let client = imap::connect((domain, 993), domain, &tls)
            .expect(&format!("failed to connect to {}", domain));

let mut session = client.login(username, app_password).expect("failed to authenticate with domain");

println!("{:#?}", session. select("INBOX").expect("failed to select inbox"));

In this example and many others I'll get Parse(Invalid(...)) errors. When I view the bytes as a string in this case I see

 "* FLAGS (\\Answered \\Flagged \\Draft \\Deleted \\Seen $NotPhishing $Phishing OIB-Seen-INBOX OIB-Seen-OIB/Business OIB-Seen-OIB/Entertainment OIB-Seen-OIB/Finance OIB-Seen-OIB/Groups OIB-Seen-OIB/Home OIB-Seen-OIB/Jobs OIB-Seen-OIB/News OIB-Seen-OIB/Shopping OIB-Seen-OIB/Social Networking OIB-Seen-OIB/Travel OIB-Seen-[Gmail]/All Mail OIB-Seen-[Gmail]/Important OIB-Seen-[Gmail]/Spam OIB-Seen-[Gmail]/Trash)\r\n"

I'm not familiar with imap at the protocol level but am I missing something here?

[jonhoo]

Hmm, that's very interesting... Thanks for reporting it!
Could you please post the full error + backtrace that you get?

[dario23]

as far as i can see, imap-proto chokes on the ']' chars in its parser, flag_char references atom which is everything that is not an atom special and those include b']' in resp_specials.

not sure what the best path forward is, though i'd think towards having the parser be more liberal here.

[jonhoo]

Ah, good catch! Let's see what @djc has to say here ^

[softprops]

Thanks for the super fast response folks. I'll post a stacktrace soon. There's actually a Gmail example in this repo but uses oauth tokens instead of an app secret. I imagine that may be a repoducable case as well

[jonhoo]

Speaking of, we should probably change that example to use app secrets too, since that's probably the recommended approach these days anyways. Maybe you could submit a PR with that once you get a working example?

[softprops]

ok so this isn't that helpful but this is the output of RUST_BACKTRACE=full cargo run in my case. I actually need to update the title of this issue. the library doesn't panic. I panic ( I'm calling result.expect(...) on the fetch to select my inbox because I always expect that to succeed.

The issue is more like many methods are result in Err(Parse(...)) is more what I was going for

stack backtrace:
   0:        0x10b342c8f - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::haab3e9e4ad6801d1
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:        0x10b337e8d - std::sys_common::backtrace::print::ha116a70121383601
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
   2:        0x10b345583 - std::panicking::default_hook::{{closure}}::h111a5999ffc43b19
                               at libstd/panicking.rs:211
   3:        0x10b34530c - std::panicking::default_hook::h68d40004cf0facbc
                               at libstd/panicking.rs:227
   4:        0x10b345cb7 - <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get::h860b1aff5e2bb311
                               at libstd/panicking.rs:476
   5:        0x10b34581c - std::panicking::continue_panic_fmt::h604d00ec956509ef
                               at libstd/panicking.rs:390
   6:        0x10b345708 - std::panicking::try::do_call::ha38138adc359e978
                               at libstd/panicking.rs:325
   7:        0x10b37fc11 - core::ptr::drop_in_place::h17bb2eb4974d8208
                               at libcore/panicking.rs:77
   8:        0x10b2873ef - core::ptr::drop_in_place::hffa41ab4c16c3d8e
                               at libcore/macros.rs:26
   9:        0x10b286b7c - core::ptr::drop_in_place::hffa41ab4c16c3d8e
                               at libcore/result.rs:835
  10:        0x10b288005 - core::ptr::drop_in_place::hffa41ab4c16c3d8e
                               at lib/src/lib.rs:62
  11:        0x10b27ce93 - checkbox::main::h2180fa4ab32da1ee
                               at cli/src/main.rs:11
  12:        0x10b27d161 - std::rt::lang_start::{{closure}}::h8e17a3b02492aefd
                               at libstd/rt.rs:74
  13:        0x10b345687 - std::panicking::try::do_call::ha38138adc359e978
                               at libstd/rt.rs:59
                               at libstd/panicking.rs:310
  14:        0x10b351a2e - panic_unwind::imp::find_eh_action::{{closure}}::hd5dfb9ab0206071d
                               at libpanic_unwind/lib.rs:102
  15:        0x10b33bc0c - std::alloc::default_alloc_error_hook::hc04de1c966debfb0
                               at libstd/panicking.rs:289
                               at libstd/panic.rs:392
                               at libstd/rt.rs:58
  16:        0x10b27d141 - std::rt::lang_start::h4ae009f28048594c
                               at libstd/rt.rs:74
  17:        0x10b27cf11 - checkbox::main::h2180fa4ab32da1ee

I can add a new gmail the example. It's not going to be that different from the basic example because you just use the login method but I think it will be helpful for those getting started

[softprops]

I haven't looked to see if they are doing anything different ( I think they are actually using the same parser ) but this library also exists .

[softprops]

Pushed up a pull for that. This may help finding a fix simpler. I was able to reproduce this issue using the new example.

The example includes a link on how to create your own app password for gmail

cargo run --example gmail_app_password
   Compiling imap v0.10.0 (/Users/dougtangren/code/rust/rust-imap)
    Finished dev [unoptimized + debuginfo] target(s) in 3.86s
     Running `target/debug/examples/gmail_app_password`
Error selecting INBOX: Unable to parse status response
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[97, 50]`,
 right: `[97, 51]`', src/client.rs:1175:25
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[softprops]

https://support.google.com/mail/forum/AAAAK7un8RUB3i6PX4aWp0/?hl=en some info on folder names in gmail

[softprops]

I think the same bug exists in the other project as well. I'll try to cross post the gh for visibility

[softprops]

not sure what the best path forward is, though i'd think towards having the parser be more liberal here.

I get the strictness and wanting to adhere to rfcs for library author's perspective if this is a rfc spec thing. Coming from a user's perspective, gmail is kind of popular mail provider in this space :) Consideration for making this a mail client work with one of the most popular mail providers sounds like a great idea!

[jonhoo]

@softprops yeah, that's @djc's library, which is why I mentioned them 👍 Filing an issue with tokio-imap is probably the right thing to do though!