Subject: [sup-talk] a few questions on mail handling with sup

From: [email-masked] (Sean Escriva)
Date: Fri, 4 Sep 2009 12:13:32 -0700

I've got sup working with the exchange server at work thanks to
offlineimap, but I have a few questions I was hope to get some input
on.

Currently I have no way to way move messages out of my inbox on the
imap server, since I'm accessing a local maildir created by
offlineimap. This is only an issue since mailboxes have a limit of
800mb in size on the server and given the volume of mail I have that
will be reached every other month. I've looked at imap filter and this
could possibly work, but anyone have experience with this sort of
sitatuation?

Additionally, since sup doesn't actually change the
maildir, messages in the maildir do not seem be getting marked as not
new when reading them with sup and offlineimap then doesn't update the
message state on the server. Is there any way to addess this?

thanks!

---

From: [email-masked] (Ben Walton)
Date: Fri, 04 Sep 2009 17:01:11 -0400

> could possibly work, but anyone have experience with this sort of

Could you pull it down with fetchmail into a local MTA setup that only
handles local delivery?  Fetchmail has the 'delete on server' option
if offlineimap doesn't.

-Ben

-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090904/7e4f505a/attachment.bin>

---

From: [email-masked] (Sean Escriva)
Date: Tue, 8 Sep 2009 14:50:23 -0700

> handles local delivery?  Fetchmail has the 'delete on server' option

thanks for the reply. fetchmail/procmail is a better option in this
case than offlineimap. No need to setup a whole different MTA since I
am already using msmtp for sending...

thanks again.

-sme