gmane.mail.imap.uw.c-client

FYI: procmail/dmail rule

Andrew Daviel — 2008-07-04T19:00:57

FYI We run procmail rules for server-side spam filtering, using dmail as the delivery agent for MIX format. Generally this works well. I just realized that for years I've had the wrong rule. I had :0 |dmail as the final rule to deliver to INBOX, but it should have been :0 w |dmail If dmail failed, the mail was lost instead of being bounced or requeued. As I found out when I fixed up a user's mailbox as root, leaving a .mixnnn file with the wrong ownership. Duh. (still somewhat shocked by Mark's dismissal ... I hope imapd can continue as an open source project. To say nothing of Mark's work with the IETF developing the imap standard, and the ongoing standards work for mobile devices)

Re: Mix format? must have? Project direction? [was Re:imap-2007b on SLES10SP1]

Joel Reicher — 2008-06-28T12:04:41

... Why are you sticking with mbox? IMAP storage involves metadata storage, and by using mbox you are forcing imapd to embed the metadata as data, which is awkward. Nor does uw-imapd index this format, so opening a mailbox for the first time is slow. http://www.washington.edu/imap/documentation/formats.txt.html mix improves performance dramatically, partly because the different kinds of (meta)data are stored in separate files, and so can be accessed with different locking arrangements. Files are also kept small to make modifications fast and backing up efficient. http://www.washington.edu/imap/documentation/mixfmt.txt.html All the more reason to move away from mbox ASAP. imapd's snarfing mechanism provides an excellent way to migrate. For example, you can begin by rebuilding with CREATEPROTO=mixproto and then doing mailutil create INBOX as a user who does not already have an INBOX. The next time they access INBOX the contents of their unix/mbox maildrop will be converted and transferred to this new mix

Re: Mix format? must have? Project direction? [was Re:imap-2007b on SLES10SP1]

Tim Mooney — 2008-06-27T21:23:52

In regard to: [Imap-uw] Mix format? must have? Project direction? [was Re:...: If you're using UW IMAP, mix has some major advantages over both traditional format and mbx. I think you're thinking of 2007b, as that was what was unreleased when Mark was let go. The future is uncertain, but it seems highly unlikely that UW would be the driving force behind UW imapd in a year's time. If it's going to continue to get future development, it probably has to come from some other source. I believe that is incorrect. Cyrus is probably the best known alternative, but I think dovecot is compelling, especially since it apparently can index traditional format -- kind of a better (IMHO) mbx. Mark also commented favorably on dovecot on this list. There are other options as well. In fact, there are a surprising number of options. Do a web search for the script "imapsync", download it, and then look at the products its been tested with in its README. That turned up several free or open source IMAP implementation

Re: Mix format? must have? Project direction? [was Re:imap-2007b on SLES10SP1]

Bob Atkins — 2008-06-27T20:47:07

_______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Mix format? must have? Project direction? [was Re: imap-2007b on SLES10SP1]

Linda Walsh — 2008-06-27T20:13:49

Mix format? Why is that a "must have" nowadays? Also, As for 2007'c', where would one obtain sources for it? I take it that it was never actually officially released, but I seem to remember Mark saying it was "ready to go". As for other features/work -- does anyone know if another UW project is picking up imapw? It seems to be fairly widely used. It seems that Cyrus IMAP is the only open-source alternative available that has any 'traction'? I've been unwilling to abandon the "mbox" format compatibility provided by IMAP -- though heaven knows, how many 3rd party open-source plug-ins don't handle the format (w/rt "From ") correctly all the time. Not sure I know of many that do. I get "ribbed" by occasional mbox chomping by Perl-scripts using CPAN modules and some derivations based on Berkeley Mail 8.x -- like the 'Nail' version that provides Mail/mailx drop-in support. (Maybe that means I'm not 'ribbed' by chomping, but 'nailed'??)...:-| Linda _______________________________________________ Ima

Re: is 2007b stable?

Steve Hubert — 2008-06-26T23:47:47

Yes, it is the most stable release. It's what Mark intended to release as 2007b. Steve Hubert washington.edu> Univ. of Washington Technology Services, Seattle _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

is 2007b stable?

Joe Pruett — 2008-06-26T22:56:07

i haven't really seen announcements about the 2007 series since mark's departure. is 2007b an "official" release? it's only a few weeks old. _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: imap-2007b on SLES10SP1

Oscar del Rio — 2008-06-20T14:21:04

As Mark would say, IMAP-2004 is ancient and there were many features/fixes introduced since then. For example, I don't think IMAP-2004 had "mix" format, which IMHO is a "must have" nowadays. _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: imap-2007b on SLES10SP1

Jarmila Holcova — 2008-06-20T13:05:42

_______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: imap-2007b on SLES10SP1

Joel Reicher — 2008-06-19T15:06:07

I have little experience with SUSE, but in the absence of other replies I would say you should just try to compile it. If you can get the build to complete I think you have good reason to believe the software will work (64-bit mysteries notwithstanding; I haven't yet delved into this). If you're *really* paranoid, send me your build log, and I'll let you know if I think anything looks particularly suspicious, but that's still not a substitute for testing. Cheers, - Joel _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

imap-2007b on SLES10SP1

Jarmila Holcova — 2008-06-18T14:00:30

Hello, I´m about to move mail server for 15000 users to a new server. The SLES10SP1 distribution contains imap-2004. I would like to use the newest version. Have you any experience with imap-2007b on SLES10SP1? There are any known issues with building and processing imap-2007b on SLES10SP (e.g. ipv6)? Thanks for your answers. Jarmila Holcova _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: x-imapbase timestamp field being rewritten

Joel Reicher — 2008-06-18T09:14:31

Don't tmail and dmail take care of this by writing valid headers on delivery, even to a UNIX-format maildrop? tmail at least overwrites X-UIDs; I just tested that case. Cheers, - Joel _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: x-imapbase timestamp field being rewritten

Joel Reicher — 2008-06-18T00:24:43

http://www.washington.edu/imap/IMAP-FAQs/index.html#6.15 That sounds like what is happening. I did, indeed, only mean that it is normal for the second field to change. So, is something (other than UW ipop3d) deleting this first message that should not be deleted, or are you saying the message is not being deleted, but is having its X-IMAP header regenerated anyway? Perhaps Oscar's suggestion of bogus headers on incoming messages is correct? Cheers, - Joel _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: x-imapbase timestamp field being rewritten

Andrew Tamm — 2008-06-15T21:19:46

yes, the mailboxes are in unix flat file format. This was necessitated by some users still using pine/mutt/mail to access their mail. For the users in question, POP clients are the only means of access. There are a few that have multiple clients connecting and checking the mail, but there are several notable examples of people who have never used command line programs and only have one POP client configued. Yes, that is the "placeholder" message I was referring to. In mailboxes that have never been empty when the POP client connected, the X-IMAP info is stored in the first message in the mailbox, which seems to be moved to the next message when that first message is deleted. Why is that correct to change over time? Do you mean the second field of the X-IMAP header to change? It was my understanding that the second field is a strict counter of the last assigned X-UID number, and the first field was a time stamp of when the "DO NOT DELETE" message was created. The POP server is using the two

Re: x-imapbase timestamp field being rewritten

Oscar del Rio — 2008-06-14T14:56:39

SPAM with bogus headers? We used to have this problem when using Unix mailbox format. Every once in a while a SPAM comes with bogus headers (X-UID, X-IMAPbase, etc) and the POP3/IMAP server has to reindex all messages. POP3 clients will see every message as new; IMAP clients will reload all headers - they don't see duplicates but a delay in "refreshing" the Inbox. The fix is to either switch to mix format and/or filter out incoming emails with bogus headers Our procmail filters remove the following headers ^(X-UID|X-IMAPbase|X-IMAP|X-Status|Status|X-Keywords) _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: x-imapbase timestamp field being rewritten

Joel Reicher — 2008-06-14T12:48:54

Are you using unix format mailboxes? Changing the format might fix this problem, and will almost certainly make your server more efficient. Is POP the only method of access to these mailboxes? Are none of these Mac clients configured to use IMAP and you're not running a webmail system either (which would almost certainly use IMAP)? Maybe something else has accessed the mailbox in the middle of a user's session; are the users getting any errors about sessions disconnecting? By "placeholder message" do you mean what is described here? http://www.washington.edu/imap/IMAP-FAQs/index.html#6.14 If so, then it is correct that this change over time. I'm not sure whether your real problem -- repeated downloads -- is related to the header contents you describe. You might be seeing a problem something like http://www.washington.edu/imap/IMAP-FAQs/index.html#7.13 which is why I asked before whether POP is the only way these mailboxes are being accessed. Cheers, - Joel _____________________________________

x-imapbase timestamp field being rewritten

Andrew Tamm — 2008-06-13T19:22:45

I'm having a problem with various users having repeated downloads of the messages in their mailboxes. Most, but not all, are using Mac Mail.app, although I'm not sure if this makes a difference. The problem occurs intermittently, although it does seem to appear in clusters, i.e. multiple users will be affected at the same time. For some reason, the X-IMAP field (in particular the first number, the time stamp) is being rewritten to the current time instead of its original value. This causes all the messages to have new UIDL values, and so the POP client thinks that these are new messages. The field in question is: X-IMAP: 1213219525 0000000002 Although if the data is not stored in a placeholder message, the header is named X-IMAPbase. Does anyone have any idea why that number would be changing? _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: imapd snarfing to mix formatted inbox

Steve Hubert — 2008-06-12T18:13:26

It is Mark's last final bits with no one else's bits. It is what he said should be called 2007b. Steve Hubert washington.edu> Univ. of Washington Technology Services, Seattle _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: imapd snarfing to mix formatted inbox

Andrew Laurence — 2008-06-12T17:48:44

Given Mark's departure, what does this release constitute? Is it more than the last development tarball? Does it contain Mark's "last final bits"? Does it contain someone else's bits? -Andrew At 2:44 PM -0700 5/20/08, Mark Crispin wrote:

Re: imapd snarfing to mix formatted inbox

Marius Micluta — 2008-06-12T15:54:34

Yes, this was indeed my problem. The special name INBOX looses its magic behavior if prefixed by "~/". At least for uw-imapd, "INBOX" means by default spool inbox AND non-spool home directory-based inboxes, as you already mentioned. The imapd server recognizes them both, if present, and messages are snarfed automagically. It is an easily overlooked subtlety, so it is worth outlining it here, as it is maybe not obvious from the documentation. It works like a charm, out of the box. Indeed, default names work pretty well with uw-imapd. but it might not be true for other IMAP servers. A somewhat more complex .pinerc file is prone to mistakes and fixing it is a matter of trial and error, where client-side idiosyncrasies add to IMAP server peculiarities. A little out of topic, I found that having an uw-imap server listening on both ports 993 and 143 with TLS negotiation enabled, I am able to access the mailboxes from a pine 4.64 client with both the {imap.server/tls} and {imap.server/ssl} configur

Re: imapd snarfing to mix formatted inbox

Marius Micluta — 2008-06-12T16:08:31

The inbox was created correctly, by conversion with mixcvt (the recommended way). I also used mailutil during the tests. The clue was that I addressed it as "{imap.server}~/INBOX" instead of "{imap.server}INBOX", or simply "{imap.server}". Problem solved, thanks to Joel Reicher's generous help. I also thank you for your reply. Marius Micluta _______________________________________________ Imap-uw mailing list Imap-uw< at >u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw