Re: Sieve seems to break mailbody during automatic redirection
In case this helps, ctrl-m (0x0d) is ASCII carriage return. Ctrl-a (0x0a) is line feed. On old mechanical terminal (e.g. Teletype) you needed both to get to start of new line. CP/M, on which MS-DOS was based maintained this. UNIX used just 0x0a for new line. AppleDOS used just 0x0d. And it's been a PITA ever since as nothing based on these early systems has ever changed. IBM didn't use ASCII, so be glad there are only three standards Regards, Frank On June 30, 2014 10:09:54 AM GMT+01:00, Urban Loesch b...@enas.net wrote: Hi, I have a strange problem with sieve. After upgrading to 2.2.13 sieve seems to break the mailbody during automatic redirection. I have the following configuration. - User A sends mail to User B. - User B has an automatic redirect to User C - User C geht the mailbody broken I did some debugging. This is a part of the mailbody which i grabbed from the mailqueue before the mail gets delivered to user B: ... Message-ID: 53b12105.2020...@domain.net Date: Mon, 30 Jun 2014 10:34:13 +0200 From: =?ISO-8859-15?Q?Urban_L=F6sch_Enas?= us...@domain.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Urban Loesch us...@domain.net Subject: testmail 5 X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary=040308070600090201000704 This is a multi-part message in MIME format. --040308070600090201000704 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit --040308070600090201000704 Content-Type: application/rtf; name=elenco_siti_inibiti.2.rtf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=elenco_siti_inibiti.2.rtf e1xydGYxXGFkZWZsYW5nMTAyNVxhbnNpXGFuc2ljcGcxMjUyXHVjMVxhZGVmZjBcZGVmZjBc c3RzaGZkYmNoMFxzdHNoZmxvY2gwXHN0c2hmaGljaDBcc3RzaGZiaTBcZGVmbGFuZzEwNDBc ZGVmbGFuZ2ZlMTA0MFx0aGVtZWxhbmcxMDQwXHRoZW1lbGFuZ2ZlMFx0aGVtZWxhbmdjczB7 XGZvbnR0Ymx7XGYwXGZiaWRpIFxmcm9tYW5cZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAw MjAyMDYwMzA1MDQwNTAyMDMwNH1UaW1lcyBOZXcgUm9tYW47fQ0Ke1xmMVxmYmlkaSBcZnN3 aXNzXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMjAyMDIwMjAyMDR9QXJp YWx7XCpcZmFsdCBBcmlhbH07fXtcZjJcZmJpZGkgXGZtb2Rlcm5cZmNoYXJzZXQwXGZwcnEx e1wqXHBhbm9zZSAwMjA3MDMwOTAyMDIwNTAyMDQwNH1Db3VyaWVyIE5ldzt9e1xmM1xmYmlk aSBcZnJvbWFuXGZjaGFyc2V0MlxmcHJxMntcKlxwYW5vc2UgMDUwNTAxMDIwMTA3MDYwMjA1 MDd9U3ltYm9sO30NCntcZjRcZmJpZGkgXGZzd2lzc1xmY2hhcnNldDBcZnBycTJ7XCpccGFu b3NlIDAyMGIwNjA0MDIwMjAyMDIwMjA0fUhlbHZldGljYTt9e1xmNVxmYmlkaSBcZm1vZGVy blxmY2hhcnNldDBcZnBycTF7XCpccGFub3NlIDAyMDcwNDA5MDIwMjA1MDIwNDA0fUNvdXJp ZXI7fXtcZjZcZmJpZGkgXGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMDIw NjAzMDQwNTA1MDIwMzA0fVRtcyBSbW57XCpcZmFsdCBUaW1lcyBOZXcgUm9tYW59O30NCntc ZjdcZmJpZGkgXGZzd2lzc1xmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMGIwNjA0MDIw MjAyMDMwMjA0fUhlbHY7fXtcZjhcZmJpZGkgXGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpc cGFub3NlIDAyMDQwNTAzMDYwNTA2MDIwMzA0fU5ldyBZb3JrO317XGY5XGZiaWRpIFxmc3dp c3NcZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1TeXN0 ZW07fQ0Ke1xmMTBcZmJpZGkgXGZuaWxcZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwNTAw MDAwMDAwMDAwMDAwMDAwMH1XaW5nZGluZ3M7fXtcZjExXGZiaWRpIFxmbW9kZXJuXGZjaGFy c2V0MTI4XGZwcnExe1wqXHBhbm9zZSAwMjAyMDYwOTA0MDIwNTA4MDMwNH1NUyBNaW5jaG97 XCpcZmFsdCA/bD9yID8/XCc4MVwnNjZjfTt9DQp7XGYxMlxmYmlkaSBcZnJvbWFuXGZjaGFy c2V0MTI5XGZwcnEye1wqXHBhbm9zZSAwMjAzMDYwMDAwMDEwMTAxMDEwMX1CYXRhbmd7XCpc ZmFsdCA/Pz8/P0U/Pz8/P0VjRT8/Pz8/RT8/Y0VjRT8/Pz8/fTt9e1xmMTNcZmJpZGkgXGZu aWxcZmNoYXJzZXQxMzRcZnBycTJ7XCpccGFub3NlIDAyMDEwNjAwMDMwMTAxMDEwMTAxfVNp bVN1bntcKlxmYWx0ID8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz99O30NCntcZjE0 XGZiaWRpIFxmcm9tYW5cZmNoYXJzZXQxMzZcZnBycTJ7XCpccGFub3NlIDAyMDIwNTAwMDAw MDAwMDAwMDAwfVBNaW5nTGlVe1wqXGZhbHQgIVBzMk9jdUFlfTt9e1xmMTVcZmJpZGkgXGZt b2Rlcm5cZmNoYXJzZXQxMjhcZnBycTF7XCpccGFub3NlIDAyMGIwNjA5MDcwMjA1MDgwMjA0 fU1TIEdvdGhpY3tcKlxmYWx0ID9sP3IgP1M/Vj9iP059O30NCntcZjE2XGZiaWRpIFxmc3dp c3NcZmNoYXJzZXQxMjlcZnBycTJ7XCpccGFub3NlIDAyMGIwNjAwMDAwMTAxMDEwMTAxfURv dHVte1wqXGZhbHQgPz8/Pz9FPz9jRT8/Pz8/RWNFPz8/Pz9FPz8/Pz9FY307fXtcZjE3XGZi aWRpIFxmbW9kZXJuXGZjaGFyc2V0MTM0XGZwcnExe1wqXHBhbm9zZSAwMjAxMDYwOTA2MDEw MTAxMDEwMX1TaW1IZWl7XCpcZmFsdCBvPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ fTt9DQp7XGYxOFxmYmlkaSBcZm1vZGVyblxmY2hhcnNldDEzNlxmcHJxMXtcKlxwYW5vc2Ug ... Looks normal to me. Now: This is the part of the mailbody which i grabbed from the mailqueue after user B has received the mail and sieve has injectd it to the mailqueue for delivering to user C. ... Message-ID: 53b12105.2020...@domain.net Date: Mon, 30 Jun 2014 10:34:13 +0200 From: =?ISO-8859-15?Q?Urban_L=F6sch_Enas?= us...@domain.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Urban Loesch us...@domain.net Subject: testmail 5 X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary=040308070600090201000704 This is a multi-part message in MIME format.^M --040308070600090201000704^M Content-Type: text/plain;
Re: ot: accepting self certs into win pc?
On 11/06/2014 10:00, mourik jan heupink - merit wrote: Apologies. I noticed only now that the certificate was issued for the real servername, and I'm using a dns alias to connect. Sorry. On 6/11/2014 10:56, mourik jan heupink - merit wrote: Hi Frank, list, On 6/10/2014 3:10, Frank Leonhardt wrote: I get endless grief over this, but if you think Microsoft is bad, try Apple. I wrote some notes on it once: http://blog.frankleonhardt.com/2012/certificate-errors-on-internet-explorer-9-and-how-to-stop-them/ I didn't mention it in the post, but IIRC this did work for making some versions Outlook (and other Microsoft Mail things) happy at the same time. But do the above steps work for folks here..? I've tried them (IE 11, win7, outlook 2013) but outlook keeps asking about (self signed) imaps certificates. Is it just me who cannot import self-signed certificates into microsoft products anymore? MJ There is an option to fiddle (mentioned in the blog) to tell SOME MS software to ignore name mismatches. Make a wish and try it :-)
Re: ot: accepting self certs into win pc?
On 11/06/2014 09:56, mourik jan heupink - merit wrote: Hi Frank, list, On 6/10/2014 3:10, Frank Leonhardt wrote: I get endless grief over this, but if you think Microsoft is bad, try Apple. I wrote some notes on it once: http://blog.frankleonhardt.com/2012/certificate-errors-on-internet-explorer-9-and-how-to-stop-them/ I didn't mention it in the post, but IIRC this did work for making some versions Outlook (and other Microsoft Mail things) happy at the same time. But do the above steps work for folks here..? I've tried them (IE 11, win7, outlook 2013) but outlook keeps asking about (self signed) imaps certificates. Is it just me who cannot import self-signed certificates into microsoft products anymore? MJ I did say it was a PITA and I did say it was using IE9! It's only a place to start. Another method that *has* worked is to download the certificate as a file ending in .cer. Open in and it'll give you the option to install it. As the blog says, I always install certificates in the place where they can be used for absolutely everything! You can convert a .pem to .cer, which is actually PKCS#12/PFX, using something like: openssl pkcs12 -inkey my_key.pem -in my_cert.cert -export -out my_pfx.cer I'm not guaranteeing this, and I could even be talking complete rubbish. I know enough about this stuff to know that I don't understand it fully, but I do know what's worked by pure dumb luck in the past! Regards, Frank.
Re: ot: accepting self certs into win pc?
On 10/06/2014 01:48, voy...@sbt.net.au wrote: few month ago, I've got a new Dovecot/Postfix server with self issued certificate (like the previous server), transferred users, all went well EXCEPT for one user on Win/Outlook (or Outlook Express) who tells me his new PC 'doesn't want to accept certificate' (sorry, I'm short on exact details at this time) I need to get it sorted out, I expect it 'should just work' like it did for other users, BUT, before I start looking, trying to 'educate myself' better if any one has any pointers, dos or don't regarding win email clients with self certified server, pls point me that way is using IE withwww.dom.com/mycert.crt good point to start ? (after copying mycer.crt to web linked directory first?) thanks, V I get endless grief over this, but if you think Microsoft is bad, try Apple. I wrote some notes on it once: http://blog.frankleonhardt.com/2012/certificate-errors-on-internet-explorer-9-and-how-to-stop-them/ I didn't mention it in the post, but IIRC this did work for making some versions Outlook (and other Microsoft Mail things) happy at the same time. Regards, Frank.
[Dovecot] login crashes - maybe too many simultan connections
Hallo, since a few days, users sometimes have problems connecting to our mailserver, in the mail.err are many lines like this: Apr 23 11:14:25 psy2 dovecot: dovecot: child 17607 (login) killed with signal 11 (core dumps disabled) (ip=xx.xx.146.84) Users who are already logged in keep connected, but new connections are not possible.This happens only between 10 am and 3 pm, never in the early morning or at night, so i assume, maybe this is caused by too many simultaneous connections? After restarting dovecot the problem is temporary solved, new users may connect, but after one or a few days, this may happen again. # 1.2.15: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.1 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: alle mail_location: maildir:~/Maildir fsync_disable: yes mbox_write_locks: fcntl dotlock mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: passdb: driver: pam args: dovecot userdb: driver: passwd May anybody help? Thanks in advance! Greetings from Frank.
Re: [Dovecot] All mail in mbox disappears when using Outlook
Adam McDougall wrote on 07 August 2009 15:01 Frank Leonhardt wrote: Timo Sirainen wrote on 03 August 2009 20:11: On Mon, 2009-08-03 at 20:03 +0100, Frank Leonhardt wrote: Any suggestions about where I could look for a clue will be followed up immediately. I'm new to Dovecot, but not BSD. My next step will be to put a network analyser on it. Looking at the imap traffic could help, especially if you can reproduce works and doesn't work cases. You could use also http://wiki.dovecot.org/Debugging/Rawlog I saw that a few weeks back and thought I'd give it a go - the analyser looks less scarey ;-) I've had some progress. The problem was the same on 1.1.16. However, if I rename the mbox file to something completely different (rather than adding a suffix as I had done before) it all suddenly starts to work. The old file was called inbox090630. It doesn't like inbox090630-1 but it's okay about Inbox-09-06-30. Moving the file name back makes everything disappear again. Unsubscribing and subscribing alone makes no difference. It's obviously looking like an internal Outlook problem. I'll check it out with other IMAP servers and see if I can confirm it. However, I'll let Microsoft fix it themselves. Thanks for all your help! This sounds like an issue I've noticed with Outlook myself, in that whenever it sees a mail folder starting with the word inbox (whether it is inboX or iNbOX or inbox-dfsjaf), Outlook always looks for Inbox or Inbox-dfsjaf (it uppercases the I and lowercases the nbox before passing the request to the backend). Thus when I was converting my users from UW imap mboxes to Dovecot IMAP, I took care in my conversion script to rename folders on their behalf if they start with inbox so they are Inbox instead. Also, if you have a mailbox called Inbox, Thunderbird will not see it since it is hidden by the real inbox. Workarounds in perl: # If a folder is named Inbox, thunderbird will not see it. Rename. $target =~ s/^inbox$/Inbox-renamed-by-migrate/ig; # If a folder starts with inbox (any case, eg. INbOX) Outlook won't see it properly. # Outlook expects Inbox(something) or bust. $target =~ s/^inbox(.*)$/Inbox$1/ig; Thanks - very interesting (and stupid!). I'm glad you've confirmed it's not my imagination. What WAS MS thinking? I've reproduced the problem with Outlook 2000 and 2003 so far. Anyone tried 2007? Is there a general case-sensitivity problem with other folder names? I'm taking a look at commands-util.c and RCF3501 Section 5.1, which has some interesting things to say about folders called *exactly* inbox (case insensitive). Regards, Frank
Re: [Dovecot] All mail in mbox disappears when using Outlook
Further to this, Outlook 2000 has the same problem as Outlook 2003 - if the folder name takes the form 'inbox123456' then it will display as empty in Outlook (although other IMAP clients have no trouble). I'd have difficulty believing this if I wasn't seeing it myself.
Re: [Dovecot] All mail in mbox disappears when using Outlook
This was sent on Saturday but didn't make it to the list (possibly a problem my end). Incidentally, I've since restarted Dovecot to see if that helped. It didn't. Luigi Rosa wrote on 01 August 2009 14:10 Frank Leonhardt said the following on 01/08/09 12:00: I've searched as far as I can for any known problems using Outlook. What about the size of the mailbox? Each version of Outlook has its own issue regarding the maximum size of PST files. Good guess knowing Outlook, and a good question as I'd forgot to mention it, but these are IMAP mailboxes, and they're therefore 'cached' in individual .pst files for each box. Originally I'd suspected it was a size issue with Dovecot as it worked when I split the files, but I now know that simply copying the files is enough. FWIW the problem mbox files are ~100M on the server - nothing exceptional. Incidentally, having had much experience of Outlook, 2Gb is a good working assumption (32-bit signed addressing). This was the official limit in earlier versions (pre-Unicode), but if you reached it, big trouble. Personally I never let them get to more than 1.5Gb. Outlook 2003 is an interesting case - standard PST files are Unicode but those used for caching IMAP are ASCII, so you still have the limit to worry about. I believe the physical limit was removed in Outlook 2007 - the upper limit is now set in the registry at a default of ~20Gb - but creating bigger files is still bad news as you'll either wreck a Microsoft filing system somewhere or need to import the file into an older version of Outlook (or data recover tool).
Re: [Dovecot] All mail in mbox disappears when using Outlook
Timo Sirainen wrote on 03 August 2009 19:46: On Sat, 2009-08-01 at 11:00 +0100, Frank Leonhardt wrote: Corrupt mbox file? Probably not. If you copy the problem one, the copy works fine. The really weird thing is that if you rename the problem file (using mv) it STILL DOESN'T work. I've considered the possibility that it's got a bad lock on it, but if so, how come Squirrel and Eudora have no problem? If it works in other clients, I can't think of how this could be Dovecot's fault. But I guess it's possible that Outlook gets confused by something that Dovecot sends. I've no idea, and I can't test it myself.. Yes - it's VERY strange, and very repeatable. Both client machines are running Outlook 2003 SP3 (Version 11.8217.8221), one on XP and the other on Vista. Dovecot is running on FreeBSD 7.0-RELEASE #0, which is a bit unusual. It's the Vista machine that broke it - I've never had any problems with the XP box (in relation to this, anyway!) I'm currently compiling the latest FreeBSD port of Dovecot (1.1.16) to see what happens (and rebuilding what looks like the entire planet in the process - 5+ hours and still building). Any suggestions about where I could look for a clue will be followed up immediately. I'm new to Dovecot, but not BSD. My next step will be to put a network analyser on it. Thanks, Frank.
Re: [Dovecot] E-Mail Encryption
On 19/07/2009 16:03, Tapani Tarvainen wrote: On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt (t200...@fjl.co.uk) wrote: Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on the door. I'm not too worried about them. How much good do your locks do when police comes and wants to confiscate your servers because they suspect one of your users has done something criminal? Do you trust they take as good care of the machines as you do? How do you know I'm *not* the Police? We're in very interesting territory here, and it's going to depend on your local laws. In England the police are pretty okay about things, and are glad to have you extract the data yourself. If they really want to do it themselves it's easy enough to give them half a mirror. I'm not in favour of whole disk encryption for data recovery and forensic reasons. Some people favour it for the very same reasons... Again, it depends on the jurisdiction. In England, if you can't decrypt the data it can be a bit awkward (RIPA) - unless it's clearly NOT your data in the first place (i.e. a message body). Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place. Here I beg to differ. You are right in the simple situation where there's just one admin who's a crook to begin with, but often enough there're several and only one (or few) unreliable ones among them, and even if they're all good they can be forced by their bosses or blackmailers or even untrustworthy authorities. This is not purely theoretical, I can assure you. Yes, but the rogue administrator ought to be able to circumvent encryption anyway - if it's whole disk it's effectively not encrypted. It'd rely on a policy of someone else periodically checking the files to see if they were still encrypted - don't see that happening somehow! And even then, an administrator could easily tee the data off before its stored. The main reason I'd be in favour of application-based file encryption is to get around the fact that whole-disk encryption is meaningless as protection from the operator - if the operator is dodgy (or someone's bypassed security) then they can read the mail files just as easily as everything else. If the files themselves are encrypted then access to the running system won't reveal their contents (although it would help).
Re: [Dovecot] E-Mail Encryption
From: to...@tuxteam.de We do agree that local encryption of messages is a Good Thing. But just like that, without context, this phrase just amounts to Marketing Oriented Hand Wawing, sorry. The meat of the discussion (and what was being talked about in this thread is: where do you decrypt? (1)Server-side? (1.1) Only on the running server? (nearly equivalent to this would be to have a permanent key storage on the server, but suitably armored by passphrase). (1.2) On the quiescent server? (2)client-side? Now it all amounts to the threat models you want to protect against. (1.2) just protects you against very little. Whoever gets the server (dead or alive) gets the decryption key. You've lost. And if your server is sufficiently protected, you just don't need encryption. (1.1) would protect yoou against someone getting the dead server (e.g. by stealing its disk). Just the same as encrypting the whole disk (assuming the unlock passprhase isn't stored near the server). Encrypting the whole disk has even the advantage that your swap space will be encrypted, which protects you against key bits hitting swap (by some dumb bug in key management software -- this has definitely happened!). This option doen't offer any relief if someone hi-jacks the live server (trojan or similar). So For this threat model (no hi-jacking, just loss of hardware) I'd definitely go for whole-disk encryption. That's what I do with my laptops. (2) This is actually the best solution. It won't protect you against the client being hi-jacked or stolen, but all other schemes above are vulnerable against that. Did I forget anything? I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server. This, of course, depends a lot on the environment its running in so everyone's experience is going to differ. Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on the door. I'm not too worried about them. What experience has shown me is that there's a good chance that a running server will compromised eventually. If you think your software locks are good enough it probably means you haven't been around long enough. Remember Qpopper? No? 'nuff said. A quick reminder - the risk level is the product of the probability and the severity of an event occuring. The probability can be a lot less than unity when the severity relates to the theft of everyone email (including passwords, CC details c) - not to mention the embarrassment factor. So, encrypting the mail file makes a lot of sense. If it's done properly (not always a given). No alien process could read the mail, even if it had access to the file itself. Depending on the 'whole disk' encryption scheme used, if the attacker had root access there'd be no protection whatsoever. It's long been a rule-of-thumb to assume that the root password is compromised in any security scenario. Part of the definition of 'done properly' above is NOT placing the decryption keys in backing store. I'm not in favour of whole disk encryption for data recovery and forensic reasons. Another advantage of doing your own encryption is the possibility of only encrypting the message bodies. Having the message headers in clear text has obvious advantages. I'm sure we're all used to skipping through mail files to find out what's gone wrong - you never want to read the message anyway. Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place. Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem! Regards, Frank
[Dovecot] Expire plugin - where to start?
I'm running Dovecot 1.1.3 on FreeBSD 7.0 with procmail 3.22 sorting the output of Spamassassin. Just for me and a few friends. I didn't like the ageing 'standard' IMAP implementation so I thought I'd give Dovecot a try and it's really impressive. However, I'm a complete newbie to its inner workings. Spamassassin is able to find plenty to chew on so the Probable spam mbox (note) fills up fast. I obviously want to zap the old stuff in there automatically. It seems to me that the expire plugin is the thing I need BUT reading the documentation: http://wiki.dovecot.org/Plugins/Expire Leaves me to scared to try anything. It's all working and I don't want to break it or delete anyone's mail. The problem that the wiki isn't accurate to the version I'm running. For example /usr/libexec/dovecot/expire-tool.sh doesn't exist. Okay, this isn't Linux, and there's something likely where I'd expect it on BSD (/usr/local/...) - but it's a binary, not a shell script. It may be a direct replacement AFAIK, but it may not. I've been reading the old mailing list about problems with 1.2 and this reinforces the feeling that the wiki is out-of-sync. Am I being paranoid? Possibly, but I don't want to be posting a Help! I've wrecked my config and deleted all my friend's mail type message. (Okay, I'd take a backup first). So could some kind person point me at the latest documentation? Thanks, Frank.
Re: [Dovecot] Expire plugin - where to start?
Timo Sirainen Wrote On Wed, 2009-07-15 at 21:35 +0100, Frank Leonhardt wrote: I'm running Dovecot 1.1.3 I'm pretty sure expire plugin is broken with this version. v1.1.17 had the last fixes to it. http://wiki.dovecot.org/Plugins/Expire Leaves me to scared to try anything. It's all working and I don't want to break it or delete anyone's mail. The problem that the wiki isn't accurate to the version I'm running. For example /usr/libexec/dovecot/expire-tool.sh doesn't exist. The wiki is written a bit badly there. The expire-tool.sh is included in the v1.2.x section in the wiki page. I'll try to clean it up a bit. Am I being paranoid? Possibly, but I don't want to be posting a Help! I've wrecked my config and deleted all my friend's mail type message. (Okay, I'd take a backup first). So could some kind person point me at the latest documentation? The problem has never been that expire plugin deletes mails too early. It's always been that it doesn't seem to delete anything. --- Many thanks I shall forget the expire plugin for now and worry about upgrading the whole system instead. Off to do some more reading.
