X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;ds=sidebyside;f=lib%2Fsup%2Fimap.rb;h=6c04d885d5856a719ba46460b465f51186034a3e;hb=167907a8ff0e9a87fc83612d48cdf09b3218b362;hp=d9a10a9144d9bae516ee1563118ce19542f9a693;hpb=e9fceea070ea2b9d4fd0db4194732fdfa3a030bb;p=sup diff --git a/lib/sup/imap.rb b/lib/sup/imap.rb index d9a10a9..6c04d88 100644 --- a/lib/sup/imap.rb +++ b/lib/sup/imap.rb @@ -5,39 +5,42 @@ require 'time' require 'rmail' require 'cgi' -## fucking imap fucking sucks. what the FUCK kind of committee of -## dunces designed this shit. +## TODO: remove synchronized method protector calls; use a Monitor instead +## (ruby's reentrant mutex) + +## fucking imap fucking sucks. what the FUCK kind of committee of dunces +## designed this shit. ## ## imap talks about 'unique ids' for messages, to be used for -## cross-session identification. great---just what sup needs! except -## it turns out the uids can be invalidated every time the -## 'uidvalidity' value changes on the server, and 'uidvalidity' can -## change without restriction. it can change any time you log in. it -## can change EVERY time you log in. of course the imap spec "strongly -## recommends" that it never change, but there's nothing to stop -## people from just setting it to the current timestamp, and in fact -## that's exactly what the one imap server i have at my disposal -## does. thus the so-called uids are absolutely useless and imap -## provides no cross-session way of uniquely identifying a -## message. but thanks for the "strong recommendation", guys! +## cross-session identification. great---just what sup needs! except it +## turns out the uids can be invalidated every time the 'uidvalidity' +## value changes on the server, and 'uidvalidity' can change without +## restriction. it can change any time you log in. it can change EVERY +## time you log in. of course the imap spec "strongly recommends" that it +## never change, but there's nothing to stop people from just setting it +## to the current timestamp, and in fact that's EXACTLY what the one imap +## server i have at my disposal does. thus the so-called uids are +## absolutely useless and imap provides no cross-session way of uniquely +## identifying a message. but thanks for the "strong recommendation", +## guys! ## ## so right now i'm using the 'internal date' and the size of each ## message to uniquely identify it, and i scan over the entire mailbox ## each time i open it to map those things to message ids. that can be -## slow for large mailboxes, and we'll just have to hope that there -## are no collisions. ho ho! a perfectly reasonable solution! +## slow for large mailboxes, and we'll just have to hope that there are +## no collisions. ho ho! a perfectly reasonable solution! ## ## and here's another thing. check out RFC2060 2.2.2 paragraph 5: ## -## A client MUST be prepared to accept any server response at all times. -## This includes server data that was not requested. +## A client MUST be prepared to accept any server response at all +## times. This includes server data that was not requested. ## -## yeah. that totally makes a lot of sense. and once again, the idiocy -## of the spec actually happens in practice. you'll request flags for -## one message, and get it interspersed with a random bunch of flags -## for some other messages, including a different set of flags for the -## same message! totally ok by the imap spec. totally retarded by any -## other metric. +## yeah. that totally makes a lot of sense. and once again, the idiocy of +## the spec actually happens in practice. you'll request flags for one +## message, and get it interspersed with a random bunch of flags for some +## other messages, including a different set of flags for the same +## message! totally ok by the imap spec. totally retarded by any other +## metric. ## ## fuck you, imap committee. you managed to design something nearly as ## shitty as mbox but goddamn THIRTY YEARS LATER. @@ -90,7 +93,7 @@ class IMAP < Source def == o; o.is_a?(IMAP) && o.uri == self.uri && o.username == self.username; end def load_header id - MBox::read_header StringIO.new(raw_header(id)) + parse_raw_email_header StringIO.new(raw_header(id)) end def load_message id @@ -108,26 +111,51 @@ class IMAP < Source end synchronized :raw_header + def store_message date, from_email, &block + message = StringIO.new + yield message + message.string.gsub! /\n/, "\r\n" + + safely { @imap.append mailbox, message.string, [:Seen], Time.now } + end + def raw_message id unsynchronized_scan_mailbox get_imap_fields(id, 'RFC822').first.gsub(/\r\n/, "\n") end synchronized :raw_message + def mark_as_deleted ids + ids = [ids].flatten # accept single arguments + unsynchronized_scan_mailbox + imap_ids = ids.map { |i| @imap_state[i] && @imap_state[i][:id] }.compact + return if imap_ids.empty? + @imap.store imap_ids, "+FLAGS", [:Deleted] + end + synchronized :mark_as_deleted + + def expunge + @imap.expunge + unsynchronized_scan_mailbox true + true + end + synchronized :expunge + def connect return if @imap safely { } # do nothing! end synchronized :connect - def scan_mailbox - return if @last_scan && (Time.now - @last_scan) < SCAN_INTERVAL + def scan_mailbox force=false + return if !force && @last_scan && (Time.now - @last_scan) < SCAN_INTERVAL last_id = safely do @imap.examine mailbox @imap.responses["EXISTS"].last end @last_scan = Time.now + @ids = [] if force return if last_id == @ids.length range = (@ids.length + 1) .. last_id @@ -176,7 +204,7 @@ class IMAP < Source def end_offset unsynchronized_scan_mailbox - @ids.last + @ids.last + 1 end synchronized :end_offset @@ -205,11 +233,11 @@ private def unsafe_connect say "Connecting to IMAP server #{host}:#{port}..." - ## apparently imap.rb does a lot of threaded stuff internally and - ## if an exception occurs, it will catch it and re-raise it on the - ## calling thread. but i can't seem to catch that exception, so - ## i've resorted to initializing it in its own thread. surely - ## there's a better way. + ## apparently imap.rb does a lot of threaded stuff internally and if + ## an exception occurs, it will catch it and re-raise it on the + ## calling thread. but i can't seem to catch that exception, so i've + ## resorted to initializing it in its own thread. surely there's a + ## better way. exception = nil ::Thread.new do begin @@ -217,9 +245,9 @@ private @imap = Net::IMAP.new host, port, ssl? say "Logging in..." - ## although RFC1730 claims that "If an AUTHENTICATE command - ## fails with a NO response, the client may try another", in - ## practice it seems like they can also send a BAD response. + ## although RFC1730 claims that "If an AUTHENTICATE command fails + ## with a NO response, the client may try another", in practice + ## it seems like they can also send a BAD response. begin raise Net::IMAP::NoResponseError unless @imap.capability().member? "AUTH=CRAM-MD5" @imap.authenticate 'CRAM-MD5', @username, @password @@ -259,7 +287,7 @@ private %w(RFC822.SIZE INTERNALDATE).each do |w| raise FatalSourceError, "requested data not in IMAP response: #{w}" unless imap_stuff.attr[w] end - + msize, mdate = imap_stuff.attr['RFC822.SIZE'] % 10000000, Time.parse(imap_stuff.attr["INTERNALDATE"]) sprintf("%d%07d", mdate.to_i, msize).to_i end @@ -271,18 +299,20 @@ private result = fetch(imap_id, (fields + ['RFC822.SIZE', 'INTERNALDATE']).uniq).first got_id = make_id result - ## I've turned off the following sanity check because Microsoft Exchange fails it. - ## Exchange actually reports two different INTERNALDATEs for the exact same message - ## when queried at different points in time. - ## - ## I don't actually see the semantics of INTERNALDATE actually defined anywhere - ## in either RFC 3501 or RFC 2060, beyond "the internal date of the message" - ## (gee, thanks guys, great job on that committee), so it's probably perfectly - ## acceptable to return any date you'd like for any message. + ## I've turned off the following sanity check because Microsoft + ## Exchange fails it. Exchange actually reports two different + ## INTERNALDATEs for the exact same message when queried at different + ## points in time. ## - ## Of course no OTHER imap server I've encountered returns DIFFERENT values for - ## the SAME message. But it's Microsoft; what do you expect? If their programmers - ## were any good they'd be working at Google. + ## RFC2060 defines the semantics of INTERNALDATE for messages that + ## arrive via SMTP for via various IMAP commands, but states that + ## "All other cases are implementation defined.". Great, thanks guys, + ## yet another useless field. + ## + ## Of course no OTHER imap server I've encountered returns DIFFERENT + ## values for the SAME message. But it's Microsoft; what do you + ## expect? If their programmers were any good they'd be working at + ## Google. # raise OutOfSyncSourceError, "IMAP message mismatch: requested #{id}, got #{got_id}." unless got_id == id