Re: remove entry from deliver.db
At Fri, 13 Apr 2007 11:40:25 -0400, Derek T. Yarnell wrote: Subject: Re: remove entry from deliver.db > > On Thu, 2007-04-12 at 13:40 -0400, Greg A. Woods wrote: > > > > If the user accidentally deletes a message then restoring it from > > backups should be no different for a message in the "Junk" folder > > vs. one in any other folder, no? > > Depends, you need to know more of the circumstances and in this case it > happened minutes after it was delivered so yeah, backups won't help. OK, so you want to give messages that have been categorized as JUNK more careful treatment and make them more recoverable than all other non-junk messages? That sounds really backwards. I.e. if a user deletes a newly delivered non-junk message from their INBOX then it's _gone_, right? You couldn't re-deliver it to them either (because of the duplicate delivery suppression), even if you did keep a copy in some magic archive queue in the LDA. If you and/or your users want a more fool-proof message handling system then use the (new) delayed expunge feature as was suggested by someone else! Mucking with delivery agents is the wrong approach and doesn't solve any problems properly. You can never really push the problem far enough back to the source to truly solve it. MTAs and LDAs and the protocols they use are already designed for safe and reliable transport and delivery -- you can only break them by trying to solve problems they do not have in the first place. Don't fix what's not broken. > > Alternately the quarantine system could simply send a separate unique > > notification message to the user and then only deliver the quarantined > > message if the user requests it somehow. I really don't like that idea > > for many reasons though. > > The message is untouched by the quarantine, so to munge a new message id > would be the wrong way to approach this IMHO. That's not what I meant. The new message would be unique. I.e. it would not be a copy of the original message and it would not contain the original message. It would only contain enough information about the original to help the user decide whether or not they want to actually go retrieve the original from the quarantine system. Only when the user decides they want to retrieve the quarantined message would that original message be finally delivered (once) to their INBOX as if it were a normal ordinary non-junk message. For those who really insist on using the idea of a quarantine system which keeps the original message isolated from the user, that's the "right" way to do it. The other "right" way is to do as I suggested and design the system such that the original message is only ever delivered once (just as all other ordinary non-junk messages are), but instead of being delivered to the normal INBOX (or to other incoming folders via Sieve rules or folder suffix rules, etc.), it could be delivered to a "Quarantined" folder where the user could examine it directly in the normal ways with no further interaction with the local delivery agents necessary. No matter how you do it though, any system which automatically classifies e-mail in such a way that the user is invited to ignore messages which are deemed to be unworthy eventually leads to lost mail -- that's just human nature at work. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Réf. : Re: Réf. : Re: Alias es in Cyrus ?
On 13.04.2007, at 14:30, [EMAIL PROTECTED] wrote: I can't modify the LDAP schema. :( why not? And i don't really understand how LDAP works. It's a bad Idea to operate such an implementation then. To me, it's like a super read-optimized database representing objects like in a unix filesytem. It's a super read-optimized database. If you have good docs about how the protocols works, i'll read them. :) I recommend reading a book about ldap. openldap.org (if you use this ldap implementation) is pretty well documented, too. Daniel Sipasseuth Wolfgang -- [EMAIL PROTECTED] http://www.wogri.com http://www.einradfilm.at Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Global sieve scripts and spamfolders/bb
Janne Peltonen wrote: Hi! If the way to use sieve with bbs is sieve scripts in the global namespace, I was wondering whether there was any way to determine the destination mailbox based on the incoming address. That is: We'd like to create /one/ global spam-filtering script, which the BB owners could register their BB to use. At the same time, we'd like the email classified as spam to end up somewhere the BB owners could read them - so as to detect false positives. And we'd like that only the owners of the BB could read the spam sent to that BB's address. So spam that's coming to 'bb' should get filtered to, say, 'bb.spam', and spam coming to 'bb2' should get filtered to 'bb2.spam'. We do this, but in the MTA rather than via Sieve; If the mail is tagged as spam, we call 'mbpath -s' and check the exit state to see if the destination has a spam subfolder. If it does, we put the message there using deliver. Users can enable the filtering by making the subfolder. -- Adam Stephens Network Specialist - Email & DNS [EMAIL PROTECTED] Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
cyrus imapd MIBS?
cyrus imapd 2.3.8 can be builded with net-snmp support, but I can't find cyrus MIBs anywhere. Can somebody consult me -- what data can be provided from cyrus over snmp, how to connect cyrus imapd to runned snmpd and where I can find MIB files? WBR Dmitriy Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
sync_client & ptloader problem
Some time ago I was report about problem with sync_client (sync_client can't be run from cyrus.conf, when ptloader used) For details: http://lists.andrew.cmu.edu/pipermail/info-cyrus/2006-October/024121.html 2.3.8 have same issue. How I can inform developers about it? Some other list? bug-tracking system? WBR Dmitriy Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: last cyrus login date
John M. Crawford wrote: > Blake, > I'm wondering about the same thing... Did you come up with > a nice method to determine last login event? > thanks, > John I have not yet put in the effort into making a system to do this. It may be easy enough to hack at the cyrus code, but honestly I don't feel comfortable and besides it may not be the best solution for my end goal. Instead I may just tail the mail log for successful logins and keep dates in a sql database along with the mailbox information that we already have there. This will allow us to more quickly and easily poll for account activity at a global level. -Blake Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Global sieve scripts and spamfolders/bb
Hi Janne, partially answering your question: My sieve admin is cyrus. He "owns" the global cyrus scripts. Change these scripts as user cyrus. (I'm using 'Websieve') My config /setup imapd.conf ... sieve_extensions: fileinto reject vacation imapflags notify include envelope bod y relational regex subaddress copy ... # # global sieve file "spam" # require ["fileinto"]; if allof (header :contains "X-Spam-Flag" "YES") { fileinto "INBOX.Junk"; } # # private user sieve script # require ["include"]; include :global "spam"; More info: http://www.mvmf.org/docs/draft-daboo-sieve-include-02.txt Best regards Roland Janne Peltonen wrote: Hi! If the way to use sieve with bbs is sieve scripts in the global namespace, I was wondering whether there was any way to determine the destination mailbox based on the incoming address. That is: We'd like to create /one/ global spam-filtering script, which the BB owners could register their BB to use. At the same time, we'd like the email classified as spam to end up somewhere the BB owners could read them - so as to detect false positives. And we'd like that only the owners of the BB could read the spam sent to that BB's address. So spam that's coming to 'bb' should get filtered to, say, 'bb.spam', and spam coming to 'bb2' should get filtered to 'bb2.spam'. If this isn't possible without a sieve-script-per-bb, is there a way to allow normal users to (safely) add global sieve scripts? Or is the only way to go to (automatically) create a new global sieve script every time a new bb is created? Thanks. --Janne smime.p7s Description: S/MIME Cryptographic Signature Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Global sieve scripts and spamfolders/bb
Sorry here is a newer version: http://tools.ietf.org/html/draft-daboo-sieve-include-05 Best regards Roland Roland Felnhofer wrote: Hi Janne, partially answering your question: My sieve admin is cyrus. He "owns" the global cyrus scripts. Change these scripts as user cyrus. (I'm using 'Websieve') My config /setup imapd.conf ... sieve_extensions: fileinto reject vacation imapflags notify include envelope bod y relational regex subaddress copy ... # # global sieve file "spam" # require ["fileinto"]; if allof (header :contains "X-Spam-Flag" "YES") { fileinto "INBOX.Junk"; } # # private user sieve script # require ["include"]; include :global "spam"; More info: http://www.mvmf.org/docs/draft-daboo-sieve-include-02.txt Best regards Roland Janne Peltonen wrote: Hi! If the way to use sieve with bbs is sieve scripts in the global namespace, I was wondering whether there was any way to determine the destination mailbox based on the incoming address. That is: We'd like to create /one/ global spam-filtering script, which the BB owners could register their BB to use. At the same time, we'd like the email classified as spam to end up somewhere the BB owners could read them - so as to detect false positives. And we'd like that only the owners of the BB could read the spam sent to that BB's address. So spam that's coming to 'bb' should get filtered to, say, 'bb.spam', and spam coming to 'bb2' should get filtered to 'bb2.spam'. If this isn't possible without a sieve-script-per-bb, is there a way to allow normal users to (safely) add global sieve scripts? Or is the only way to go to (automatically) create a new global sieve script every time a new bb is created? Thanks. --Janne smime.p7s Description: S/MIME Cryptographic Signature Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: last cyrus login date
On Mon, Apr 16, 2007 at 11:13:54AM -0500, Blake Hudson wrote: > John M. Crawford wrote: > > Blake, > > I'm wondering about the same thing... Did you come up with > > a nice method to determine last login event? > > thanks, > > John > I have not yet put in the effort into making a system to do this. It may > be easy enough to hack at the cyrus code, but honestly I don't feel > comfortable and besides it may not be the best solution for my end goal. > > Instead I may just tail the mail log for successful logins and keep > dates in a sql database along with the mailbox information that we > already have there. This will allow us to more quickly and easily poll > for account activity at a global level. Another solution is a custom saslauthd implementation which logs the details to your database. That's what we do (actually, I think we only log from the authd on our frontend proxy servers, because we know the external IP address there, but we could flip a bit in the config file and get logging from the backends too) Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html