#!/bin/sh # TODO FIX uh oh this and the other missing msg cases passed by accident after inc uses ESEARCH # and now switching inc to leave mailbox open has broken it completely! if test -z "$MH_OBJ_DIR"; then srcdir=`dirname "$0"`/../.. MH_OBJ_DIR=`cd "$srcdir" && pwd`; export MH_OBJ_DIR fi . "$MH_OBJ_DIR/test/common.sh" # common.sh sets this to something crazy; did i do that?! testname=${0#$srcdir/} setup_test_without_data Mail imap_cleanup() { #### Save exit status to use as status for this program. status=$? set +e rm -f "$imapd" [ -n "$imapd_pid" ] && kill $imapd_pid "$MH_OBJ_DIR/target/debug/mhimap" imap shutdown # TODO have cleanup allow additional cleanup registration? # Or just allow it to accept status as argument. (exit $status) cleanup } trap imap_cleanup 0 covdir="$MH_OBJ_DIR/covdata/${MH_COVERAGE_PROFILE:-default}/$testname" install -d "$covdir" export LLVM_PROFILE_FILE="$covdir/$profile-%m.profraw" imapd="$MH_TEST_DIR/$$.imapd" start_fakeinetd "$imapd" imapd_pid=$fakeinetd_pid cat >> "$MH" <> "$MH" echo "imap-log-$MH_TEST_IMAP_LOG_LEVEL-to: $MH_TEST_DIR/$profile/imap.d/log.$MH_TEST_IMAP_LOG_LEVEL" >> "$MH" fi start_test 'message disappears between FETCH UID and FETCH BODY' # test the case where a message goes missing between the time inc first # notices it and when it goes to download it, e.g. inc starts, sees a message, # and then another client deletes it before inc can fetch it. # I'm kinda surprised this just worked on the first try... hmm or not. # I see. The ServerData::Fetch loop doesn't know if it's procesinsg a # response from our request for a range of UIDS or from our request of a # message body. # TODO Teach it the difference so we can log when a message goes missing. # Documented behaviors: # https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.8 says: # A non-existent unique identifier is ignored without any error # message generated. Thus, it is possible for a UID FETCH command # to return an OK without any data or a UID COPY or UID STORE to # return an OK without performing any operations. # This seems to match the Panda behavior I see. # https://datatracker.ietf.org/doc/html/rfc2180#section-4.1.1 has an example: # => B003 FETCH 4:7 RFC822 # <= B003 NO Messages 4:7 are no longer available. # and in 4.1.2: # => B001 FETCH 3:5 ENVELOPE # <= * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) # <= B001 NO Some of the requested messages no longer exist # and in 4.1.3: # If all of the messages in the subsequent FETCH command have been # expunged, the server SHOULD return only a tagged NO. # and mayb it can return NIL or empty string for BODY[] ? # Observed behaviors # Panda: no data but just an OK! # (tls-encrypted) => fetch1 UID FETCH 101 BODY.PEEK[] # (tls-decrypted) <= fetch1 OK UID FETCH completed # Dovecot: same # => fetch1 UID FETCH 101 BODY.PEEK[] # <= fetch1 OK Fetch completed (0.001 + 0.000 secs). # Cyrus: same # => fetch1 UID FETCH 101 BODY.PEEK[] # <= fetch1 OK Completed (0.000 sec) # Gandi: same # (tls-encrypted) => fetch1 UID FETCH 101 BODY.PEEK[] # (tls-decrypted) <= fetch1 OK Fetch completed (0.001 + 0.000 secs). # Gmail # (tls-encrypted) => fetch1 UID FETCH 101 BODY.PEEK[] # (tls-decrypted) <= fetch1 OK Success cat > "$imapd" <