Name Description Size
moz.build 806
nsLocalMailFolder.cpp 127835
nsLocalMailFolder.h Interface for representing Local Mail folders. 12312
nsLocalUndoTxn.cpp 16797
nsLocalUndoTxn.h 2767
nsLocalUtils.cpp 6831
nsLocalUtils.h 1064
nsMailboxProtocol.cpp the output_buffer_size must be larger than the largest possible line 2000 seems good for news jwz: I increased this to 4k since it must be big enough to hold the entire button-bar HTML, and with the new "mailto" format, that can contain arbitrarily long header fields like "references". fortezza: proxy auth is huge, buffer increased to 8k (sigh). 28340
nsMailboxProtocol.h should we pause for the next read 4886
nsMailboxServer.cpp 887
nsMailboxServer.h 692
nsMailboxService.cpp 23892
nsMailboxService.h only used by open attachment 2154
nsMailboxUrl.cpp 16509
nsMailboxUrl.h 3817
nsMsgBrkMBoxStore.cpp Class for handling Berkeley Mailbox stores. 34202
nsMsgBrkMBoxStore.h Class for handling Berkeley Mailbox stores. 1776
nsMsgLocalStoreUtils.cpp We're passed a stream positioned at the start of the message. We start reading lines, looking for x-mozilla-keys: headers; If we're adding the keyword and we find a header with the desired keyword already in it, we don't need to do anything. Likewise, if removing keyword and we don't find it,we don't need to do anything. Otherwise, if adding, we need to see if there's an x-mozilla-keys header with room for the new keyword. If so, we replace the corresponding number of spaces with the keyword. If no room, we can't do anything until the folder is compacted and another x-mozilla-keys header is added. In that case, we set a property on the header, which the compaction code will check. This is not true for maildir, however, since it won't require compaction. 13039
nsMsgLocalStoreUtils.h Utility Class for handling local mail stores. Berkeley Mailbox and MailDir stores inherit from this class to share some code. 1696
nsMsgMaildirStore.cpp Class for handling Maildir stores. 47970
nsMsgMaildirStore.h Class for handling Maildir stores. 1121
nsNoIncomingServer.cpp 5826
nsNoIncomingServer.h get some implementation from nsMsgIncomingServer 1365
nsNoneService.cpp 4042
nsNoneService.h nsNoneService_h___ 674
nsParseMailbox.cpp the following macros actually implement addref, release and query interface for our component. 92964
nsParseMailbox.h Used for the various things that parse RFC822 headers... 9455
nsPop3IncomingServer.cpp 23953
nsPop3IncomingServer.h get some implementation from nsMsgIncomingServer 2262
nsPop3Protocol.cpp pool 140862
nsPop3Protocol.h A more guaranteed way of making sure that we never get duplicate messages is to always get each message's UIDL (if the server supports it) and use these for storing up deletes which were not committed on the server. Based on our experience, it looks like we do NOT need to do this (it has performance tradeoffs, etc.). To turn it on, three things need to happen: #define POP_ALWAYS_USE_UIDL_FOR_DUPLICATES, verify that the uidl's are correctly getting added when the delete response is received, and change the POP3_QUIT_RESPONSE state to flush the newly committed deletes. 15763
nsPop3Service.cpp don't download, just check 20041
nsPop3Service.h nsPop3Service_h___ 1797
nsPop3Sink.cpp for logging to Error Console 32541
nsPop3Sink.h 2086
nsPop3URL.cpp 1429
nsPop3URL.h Pop3 specific event sinks 710
nsRssIncomingServer.cpp 7960
nsRssIncomingServer.h __nsRssIncomingServer_h 1729
nsRssService.cpp 3290
nsRssService.h nsRssService_h___ 564