Code for manipulating all messages matching some criteria?

[Bron Gondwana]

Yeah, that's going to break horribly in the future.  It probably already broke horribly in the past - if you change the size of the message file, then FETCH commands would have totally failed up until some version where I changed it to truncate or pad... the only fix would have been to reconstruct the folder afterwards.

Just don't do that.  You can inspect the messages on disk and then manipulate them via IMAP, but you're better off just doing an RFC822 fetch anyway.  There's no guarantee that internal layout will stay the same (indeed, in the FastMail branch, we support moving most of your spool to a different disk, so the current week of email is on SSD in every folder, but older emails are all on big slow RAID)

Bron.

On Tue, Oct 29, 2013, at 02:34 AM, Deniss wrote:
> Hi John,
> 
> i wondering that modifing the mesasges on the disk does not break any
> internal cyrus stuff like replication or something else cos message's
> size and GUID as stored in cyrus.index should be changed on edit:
> 
> http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.4.8/internal/mailbox-format.php
> 
> Did you expect any issue with the messages after editing ?
> 
> Bron, any ideas ?
> 
> 
> On 2013.10.23. 1:56, John Wade wrote:
> > Hi Jason,
> > 
> > We have run into this a number of times with various spear phishing
> > messages.    As a result, we cobbled together a total hack.   We have a
> > perl tool that searches the mail spool filesystems, (either inboxes only
> > or a full recursive search) and then searches and replaces the offending
> > link or text within the messages.   Does not help with clients who cache
> > the message contents and is not a perfect solution, but has worked when
> > we have needed it .    Since it only touches the contents of messages,
> > it does not require a reconstruct like nuking the file outside of Cyrus
> > would.   We ended up going through the file system to find the messages
> > since some of these attacks had a lot of variation of subject, sender
> > and links and regular expressions are a great tool.
> > 
> > I have been meaning for some time to rewrite this to have it do an IMAP
> > delete/purge of the offending messages, but have not had the time.    
> > If somebody has a great tool for this that they could share, I would
> > love to see it.
> > 
> > If anybody really wants our pathetic little hack, I would be happy to
> > share it.
> > 
> > Hope this helps,
> > John Wade
> > Oakton Community College
> > 
> > On 10/22/2013 2:24 PM, Jason L Tibbitts III wrote:
> >> Recently our campus was hit with a particularly bad targeted trojan
> >> attach and the IT overlords sent out a demand that we (a small
> >> department with several hundred mailboxes on our own server) go through
> >> all user mailboxes and actually delete the offending messages.  At least
> >> using the admin account this is actually kind of reasonable to do.
> >> While I'm sure I could whip something up if I actually had enough free
> >> time, I was wondering if anyone had already been through this kind of
> >> thing and had cobbled together any code to do it.
> >>
> >> I see something called imapfilter which might do the trick, but it seems
> >> to be completely opaque.
> >>
> >>   - J<
> >> ----
> >> Cyrus Home Page: http://www.cyrusimap.org/
> >> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> >> To Unsubscribe:
> >> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> > 
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


-- 
  Bron Gondwana
  brong at fastmail.fm