RE: Hostname Lookup Delay and Timeout
Hi Jeremy, --On Tuesday, April 13, 2004 8:22 AM -0700 Jeremy Fisher <[EMAIL PROTECTED]> wrote: | It's a good thought, and I've tried that from the | shell. Took a few seconds to figure out that there was | no hostname available for the IP address -- not ten | minutes! So I'm not sure if Sendmail and Cyrus are | calling a separate process that is more persistent in | its attempts to get the hostname, or if they are just | that stubborn on their own (in which case, there must | be a feature to disable this somewhere). | | As a temporary fix, I took the offending IP address | and added it to the /etc/hosts file (performance is | now lightning fast, of course). The more I look at | this, the more it appears that it is a general DNS | problem of some sort. Also check to see whether you have identd running. A quick google on identd delays produced the following at the top of the results: <http://www.exocore.com/technologies/linux/identd/> -- Cyrus Daboo --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Invalid flag in Append command
Hi Jared, --On Monday, March 22, 2004 12:18 PM -0500 Jared Watkins <[EMAIL PROTECTED]> wrote: | I'm guessing it's not as simple as adding Recent as a known type... but | what's the story on this... and is there an easy way around it? I | couldn't find anything relevant in the archives. The \Recent flag cannot be changed by the client - its completely managed by the server. Whatever client generated the command is at fault as the IMAP spec clearly shows that \Recent is not one of the allowed flags for the APPEND command. In actual fact any message being appended will always end up with the \Recent flag as it is considered 'recent' when added to the mailbox, so its use in APPEND in superfluous anyway. Bottom line is: its a client bug - fix the client. -- Cyrus Daboo --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: IMSP and Digest-MD5
Hi Rob, --On Tuesday, February 17, 2004 11:48 AM -0500 Rob Siemborski <[EMAIL PROTECTED]> wrote: |> Wouldn't it be better if this were filed as a bug with CMU and get the |> service name changed in the server sources? That, to me, would seem to be |> the better way to handle this going forward, since imap and imsp are two |> different services. | | That's the problem with a lack of standardization of this protocol. | | Unfortuinately, *all* of the deployment is using "imap" as the service | name. Changing this now will break *all* deployed software. | | I'm not about to do that. At best, it could be made a config option. Agreed - I would rather fix Mulberry to be consistent with the other authenticators we support that do use 'imap' rather than 'imsp'. However, if a change to the server were to be made, perhaps it could be set to accept either 'imap' or 'imsp'? Or would that be too hard to do within the constraints of SASL lib? -- Cyrus Daboo --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: IMSP and Digest-MD5
Hi William, --On Tuesday, February 17, 2004 10:52 AM -0500 "William K. Hardeman" <[EMAIL PROTECTED]> wrote: | I do have DIGEST-MD5 working with IMAP. Actually, in the 3 years I've | been using both Cyrus IMAP and Cyrus IMSP, I've always been able to use | DIGEST-MD5 on the IMAP connections and never on the IMSP connections. | | IMAP connection with DIGEST-MD5 from the logs: | Feb 17 10:49:26 mail imap[17487]: login: dilbert.wkh.org | [xxx.xxx.xxx.xxx] [EMAIL PROTECTED] DIGEST-MD5 User logged in | | | The error I'm seeing in messages when I try using DIGEST-MD5 is: | | Feb 17 10:44:21 mail imsp[17643]: bad digest-uri: doesn't match service | Feb 17 10:44:21 mail imsp[17643]: badlogin: dilbert.wkh.org - digest-md5 | authentication failure OK - I think I see the problem. The DIGEST mechanism requires a 'service name' parameter. For IMAP that is 'imap'. We have been using 'imsp' for IMSP, however CMU uses 'imap' as the service name for IMSP. GSSAPI also uses a service name and there we do use 'imap' for IMSP. I need to change our digest plugin to use 'imap' then it should work. I will work on fixing that for our next update. -- Cyrus Daboo --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: IMSP and Digest-MD5
Hi William, --On Tuesday, February 17, 2004 3:30 AM -0500 "William K. Hardeman" <[EMAIL PROTECTED]> wrote: | My apologies for the cross-post, but I'm hoping to cover all bases with | my question. :-) | | I've just upgraded my IMSP server to the lastest Cyrus 1.7b, as | recommended by CMU. I had hoped that, with that upgrade, I would finally | be able to use Digest-MD5 authentication to the IMSP server. However, | it's still not working in either the 3.1 releases or the 2.2 releases of | Mulberry. Cram-MD5 and Plain/Login continue to work fine, though. | | Does anyone know if my inability to use Digest-MD5 is a problem with | Mulberry, or is a problem with Cyrus IMSP? Are there any known fixes? Do you have DIGEST working with IMAP? What error do you get when you try it? | Finally, I thought I saw mentioned somewhere awhile back that work was | ongoing to implement SSL/TLS capabilities into the IMSP server. Can | anyone comment on how well that might be progressing? Sorry, I have been tardy wrt getting out TLS patches into the CMU code. I will do some work on that over the next couple of days. -- Cyrus Daboo --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Sieve vacation question : does :addresses match case-insensitively ?
Hi Cyrus, --On Monday, December 15, 2003 11:35 AM -0500 Cyrus Daboo <[EMAIL PROTECTED]> wrote: || Does the :addresses parameter will be matched case insentively, meaning || that the vacation will also trigger for mail addressed to || [EMAIL PROTECTED] ? | | Good question - the vacation spec is not clear on that. The RFC2821 spec | actually says that the local part of an address (to the left of the @) is | case-sensitive, whilst the domain part (to the right of the @) is not. | Thus '[EMAIL PROTECTED]' and '[EMAIL PROTECTED]' are not the | same. Of course it turns out that many implementations do treat those as | the same, so there does need to be a way to handle that in vacation. The | SIEVE base-spec gets around this by allowing comparisons (with either | case-sensitive or case-insensitive comparators) against the local or | domain part of an address separately if so desired. I will bring this | matter up on the sieve list as it needs to be cleared up wrt vacation. Further to this I see that newer versions of CMU SIEVE do case-insensitive comparisons, but older versions did not - perhaps Ken/Rob can confirm when that change was made so you can decide whether you need to upgrade/patch. -- Cyrus Daboo
Re: Sieve vacation question : does :addresses match case-insensitively ?
Hi Etienne, --On Monday, December 15, 2003 10:50 AM -0500 Etienne Goyer <[EMAIL PROTECTED]> wrote: | Given the following script : | | | require "vacation"; | | vacation :days 1 :addresses "[EMAIL PROTECTED]" :subject "Some | subject" "Just testing vacation, folks. | "; | | | Does the :addresses parameter will be matched case insentively, meaning | that the vacation will also trigger for mail addressed to | [EMAIL PROTECTED] ? Good question - the vacation spec is not clear on that. The RFC2821 spec actually says that the local part of an address (to the left of the @) is case-sensitive, whilst the domain part (to the right of the @) is not. Thus '[EMAIL PROTECTED]' and '[EMAIL PROTECTED]' are not the same. Of course it turns out that many implementations do treat those as the same, so there does need to be a way to handle that in vacation. The SIEVE base-spec gets around this by allowing comparisons (with either case-sensitive or case-insensitive comparators) against the local or domain part of an address separately if so desired. I will bring this matter up on the sieve list as it needs to be cleared up wrt vacation. -- Cyrus Daboo
Re: Cyrus IMSPd 1.6a4 and 1.7a Released
Hi Scott, --On Friday, December 12, 2003 3:10 PM -0500 Scott Adkins <[EMAIL PROTECTED]> wrote: | Are there changelogs for these releases? I am particularly interested in | whether or not the SSL patches previously posted for IMSP has been rolled | in or not. What is the difference between the 1.6 and 1.7 releases, since | they were both released at the same time? SSL (STARTTLS) is currently not in the v1.7a code-base, but I do plan on integrating our implementation in in the next few weeks. I suspect that will initially need to go out as a beta to get some thorough testing under load. -- Cyrus Daboo
Re: imsp and sasl config
Hi Phil, --On Thursday, November 27, 2003 4:54 PM + Phil Chambers <[EMAIL PROTECTED]> wrote: | I am using saslauthd and that is working fine for my IMAP and POP | processes with | | allowplaintext: yes | sasl_pwcheck_method: saslauthd | sasl_mech_list: plain | | in /etc/imapd.conf. | | I have the following in my /var/imsp/options: | | imsp.allowplaintext N + | imsp.pwcheck_method N saslauthd | imsp.sasl.mech_list n (plain) | | but I get "no mechanism available" when I try to login to IMSP with plain | text password. (CAPABILITY shows AUTH=PLAIN) Options for SASL in the IMSP options file must all begin with 'imsp.sasl.'. Thus you need: imsp.sasl.allowplaintext N + imsp.sasl.pwcheck_method N saslauthd imsp.sasl.mech_list n (plain) Check the 'sasl_syupport.c' file in the IMSP source distribution to see this. -- Cyrus Daboo
Re: received date and reconstruct
Hi Ken, --On Thursday, November 20, 2003 10:19 -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: |> based on specified criteria, including age. Hm. Not sure though |> how it determines age. | | It uses the sent date (Date: header). OK - so if spammers knew about this they could forge Date: so that it was 20 years in the future and ipurge would never remove those messages from the spam folder. I think ipurge needs to have an option to use internaldate (from IMAP envelope) as an alternative, and that ought to be the default. Perhaps it alrady has that option? -- Cyrus Daboo
Re: Weird behavior between Mulberry and Cyrus 2.1.12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sebastian, - --On Friday, October 31, 2003 15:58 +0100 Sebastian Hagedorn <[EMAIL PROTECTED]> wrote: | Any ideas? Unfortunately I can't reproduce this, it just happens every | once in a while. Does your server machine log indicate any kind of segfaults in imapd at about the same time? Once this happens, does it continue to happen if you immediately try to re-open the mailbox? Once you get into a state like that, can you try telnetting to the server and issuing the thread command (as seen in the log) and see what happens? - -- Cyrus Daboo -BEGIN PGP SIGNATURE- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP6KF8yK4BGrbmMvFEQLWOgCguMsINeSj6eEqG4kZN8OHc7YQAEoAn0rY cPoDyaQ+aVXpQoBTf3m8qlxd =QERP -END PGP SIGNATURE-
Re: To the one who posted Cyrus SASL diagram...
Hi Etienne, --On Thursday, October 30, 2003 9:07 -0500 Etienne Goyer <[EMAIL PROTECTED]> wrote: | It might be interesting to add that only certain mechanism provide | so-called "proxy" authentication (authcid/authzid separation; how would | this feature be called ?). PLAIN and DIGEST-MD5 are the one I know for | sure provide it, while CRAM-MD5 don't. I am not sure about GSSAPI, | EXTERNAL and other. Both Kerberos_v4 and GSSAPI have authorization ids, as does EXTERNAL. The only standard ones that currently do not are CRAM-MD5 and (obviously) ANONYMOUS. -- Cyrus Daboo
Re: How to filter based on "garbage" subjects ... ?
Hi Marc, --On Tuesday, September 30, 2003 11:32 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: | | I've yet to be able to come up with a sieve rule that will allow me to | filter all "garbage" subjects to a separate folder ... you know the ones | that look like: | | Subject: =?euc-kr?q?(=B1=A4=B0=ED)=B5=F0=C1=F6= | | I've even tried to use Pine filtering to filter based on 8bit subjects, | but it doesn't pick them up either ... | | For instance, under Pine, if I try to select all subjects with =B1= in | them, which the above contains, it selects nothing, so I'm figuring there | has to be some control characters in there somewhere ... ? | | Thoughts? | From the SIEVE RFC: | Implementations decode header charsets to UTF-8. Two strings are | considered equal if their UTF-8 representations are identical. | Implementations should decode charsets represented in the forms | specified by [MIME] for both message headers and bodies. | Implementations must be capable of decoding US-ASCII, ISO-8859-1, | the ASCII subset of ISO-8859-* character sets, and UTF-8. i.e. SIEVE should be decoding the =?euc-kr? header into its utf8 form BEFORE doing the comparison with the text you provide. i.e. the =B1 quoted-printable encoded character will have been decoded into the utf8 representation of that for the euc-kr character set, and thus won't match the text you provide. Actually the euc-ky character set is a multibyte character set so in fact the unicode character is made up of =B1 and =A4. By my reckoning that is the unicode character 0xad11 - I'll leave you to work out the utf8 encoding of that! Basically you are going to have a hard time trying to filter on arbitrary unicode characters in some random character set given that sieve expects utf8 in its scripts. -- Cyrus Daboo
Re: suppressing DIGEST-MD5
Hi Gary, --On Friday, July 18, 2003 11:51 AM -0500 Gary Mills <[EMAIL PROTECTED]> wrote: | Using both shared secrets and plain-text passwords introduces a | client/server interaction problem. Many IMAP clients will not fall | back to plain-text authentication when the server advertizes the | shared secret mechanisms, but the specific user does not have a | shared secret. The result is an impasse, since the user cannot | authenticate and also cannot set the shared secret. My current | workaround is to modify the c-client library so that it will fall | back to plain-text passwords. I did not implement fallback because my feeling is that if a user sets a particular authentication mechanism then that is what they want. Certainly fallback from a relatively secure mechanism like CRAM or DIGEST to one with no security like plain is bad practice as man-in-the-middle attacks could be used to trick clients into sending clear-text passwords, and the user would be non the wiser. -- Cyrus Daboo
Re: suppressing DIGEST-MD5
Hi Phil, --On Friday, July 18, 2003 4:29 PM +0100 Phil Chambers <[EMAIL PROTECTED]> wrote: | I can't get Execmail or Mulberry to connect because they appear to see | that DIGEST-MD5 is available and trys that. It fails, of course, | because there is no shared secret. In Mulberry you have to explicitly set the authentication method - it won't try one simply because its present, so you can simply set your preferences to not use DIGEST or CRAM. -- Cyrus Daboo
Re: FLAGS problem / version question
Hi Rob, --On Wednesday, July 16, 2003 03:23:29 PM -0400 Rob Siemborski <[EMAIL PROTECTED]> wrote: |> Transcript of the garbled response is below. My question is, has this |> been fixed in a later version (I couldn't find any release notes on the |> site)?? | | I'll presume "yes" for now, since I've never seen it and I'm not going to | research a problem on code that is 5+ years out of date. That was a known problem with v1.5 and keywords. -- Cyrus Daboo
RE: Is it possible to store user contact/ address book in imapserver?
Hi David, --On Tuesday, July 15, 2003 04:30:24 AM -0400 "David H. Lynch Jr." <[EMAIL PROTECTED]> wrote: | There is nothing special about contact/address book information. | There is no reason you can not store contacts, tasks, calendar items, | ... In any IMAP server you choose. All they are is specially formatted | messages. | | The Problem is that there are no IMAP clients that can properly | understand and treat those messages as contacts, tasks, ... | If you consider IMAP as a MIME store rather than a message store (the later is of course a subset of the former) then one can consider storing any type of data in IMAP. Obviously one could store vCards and vCalendar objects in messages and have special mailboxes for those to represent address books and calendars. The problem is there is no 'standard' way to do this, and without a formal standard to describe where those items go and how they should be managed, there is no way to guarantee interoperability between clients, which is of course essential. IMAP also presents certain hurdles. In particular, messages in IMAP are immutable - i.e. you cannot edit the content of a message once it is in the mail store. The only option for editing addresses or calendar events then, is to delete/expunge the old item and append a new item. That leads to the possibility of race-conditions when multiple clients are being used at the same time. -- Cyrus Daboo
Re: APPEND vs RFC2822 vs STD0011
Hi Edward, --On Wednesday, July 9, 2003 11:58 AM -0400 Edward Reid <[EMAIL PROTECTED]> wrote: |> Allowing null characters in particular is problematic for any code |> that |> uses null-terminated strings for messages or parts of messages, and | | Using null-terminated strings with data that might contain nulls is | problematic. On the NULL issue, IMAP does not allow bare NULLs in any data that either the server or client sends. If you check the formal syntax you will see that the 'literal' element used to send the message content in an APPEND explicitly excludes NULL as a valid character. So if Eudora is sending bare NULLs that is a protocol bug you can bounce back to them and justify having them fix. NB There is an IMAP BINARY extension in the works that does allow bare NULLs, but only when used with the specific extension syntax. Bare CR or LF is another issue... -- Cyrus Daboo
Re: Question about Sieve and "filters"
Hi Michael, --On Tuesday, July 8, 2003 9:38 PM -0700 Michael Fair <[EMAIL PROTECTED]> wrote: | What do others think about this? | Would this simple "pass through" filtering be useful? | I'm primarily thinking of Spam catchers, Virus Scanners, | and any other use where shoving the email through an | external application would be useful. First off there is a general reluctance, from a security standpoint, of allowing sieve to call out to arbitrary bits of code. I suspect that would frighten most sysadmins if users were allowed to write their own bits of code to run via sieve. The alternative is to build specific extensions in sieve to accomplish particular tasks. In particular I have written a 'spamtest' and 'virustest' draft (link below) that proposes adding two new tests that return a fixed numeric range of values that can be tested against. Its up to each sieve implementation to choose how the results themselves are actually determined - I would envisage a plugin architecture that allows different spam/virus check systems to be used, but the user does not get to choose which - that would be a compile/configuration option for the server admin. The main goal for these extensions was to actually remove the need for end-users to know about the particular spam/virus test system in use, which would otherwise require them to tailor scripts specifically for those systems. The new tests allow scripts that do spam/virus checking to be portable across different systems, and to also allow sysadmins to change spam/virus checkers without having to have users change all their scripts. Given that spam checking tools are changing so rapidly right now, this solution would be really useful. <http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-03.txt> -- Cyrus Daboo
Re: [PROPOSAL] Sieve for shared mailboxes
Hi Ken, --On Tuesday, July 8, 2003 11:34 AM -0400 Ken Murchison <[EMAIL PROTECTED]> wrote: |> What about IMAP APPEND? Does that trigger the script? It really ought to |> as well. | | I hadn't anticipated this. What would be the need/advantage of this? | There is a huge potential for using sieve scripts for IMAP COPY/APPEND operations to help automate processing of messages once they have arrived. For example, I use the mailbox hierarchy as a way of organising my email, so I have a 'Personal' mailbox, 'Personal. Friends', 'Personal.Family' etc. Since I still choose to have messages delivered to INBOX, I then need to manually classify each message and copy into the relevant mailbox after reading/responding. What would be good is to have a single 'Rule' mailbox with a script attached to it and that script would have all the logic for determining the appropriate mailbox to copy the message into. All I would then need to do is copy all messages I want to file away into the Rule mailbox and the server/script would take care of filing it away properly for me. Obviously clients can implement logic like that on the client-side, but it would be nice to have it done on the server. The same kind of behaviour would be nice for sent-mail messages too (i.e. APPEND). Clearly certain sieve script actions do not make sense with COPY/APPEND - in particular reject, so there would have to be some form of 'profile' of sieve that would make sense. -- Cyrus Daboo
Re: [PROPOSAL] Sieve for shared mailboxes
Hi Rob, --On Wednesday, July 09, 2003 2:08 AM +1000 Rob Mueller <[EMAIL PROTECTED]> wrote: |> True. I hadn't thought about that. This might be worth exploring. | | I think this would be great. Personally I found the whole concept of | having an entirely different protocol to manage sieve scripts a bit | bewildering when a few simple additions to IMAP would have done it. I | guess someone thought it was a sufficiently distinct problem space... SIEVE can of course be used with POP, so there does need to be a more general script management protocol, unless you want to extend both POP and IMAP. | Anyway, now that the ANNOTATE extension provides more aribtrary meta-data | abilities, I think being able to set user sieve scripts by it would be | great. Of course interactions with managesieve could be tricky, but | still, I think it's definitely a worthwhile goal. ManageSIEVE does allow arbitrary named scripts to be stored on the server and activated. Doing that with ANNOTATEMORE is possible but may be complex. It could probably be done by having the user's scripts all listed under a server-level annotation (rather than a per-mailbox annotation) with a specific annotation used to hold the name of the active script. One other thing that ManageSIEVE does that is useful is syntax checking of a script being uploaded. Whilst Ken did not mention that, ideally storing a script via IMAP should also do a syntax check and prevent the store if the script is bad. -- Cyrus Daboo
Re: [PROPOSAL] Sieve for shared mailboxes
Hi Ken, --On Tuesday, July 8, 2003 9:59 AM -0400 Ken Murchison <[EMAIL PROTECTED]> wrote: | In the past, people have requested the ability to run sieve scripts when | messages are posted directly to shared mailboxes (via +detail | addressing). I have suggested that this would be possible by associating | a script with the 'postuser' (typically "bb" or ""), but this was deemed | unacceptable as people wanted more fine grained control over which | mailboxes would have the script run. | | Now that Cyrus 2.2 has support for mailbox annotations, I believe that we | can provide the functionality that people desire. I propose the | following: | | We will create a new "/vendor/cmu/cyrus-imapd/sieve" shared annotation | which can only be set by an admin. Whenever a message is posted directly | to a shared mailbox, the script specified by the /sieve annotation (if | any) will be run. | | Question: Should the annotation be inherited by child mailboxes? This | would allow the same script to be run on an entire hierarchy by only | setting one annotation. Inheritance may be wanted (I suspect a lot of people will want that given that I know a lot of people have requested various mailbox inheritance behaviours in Mulberry). I think you will need to add another annotation to turn on or off inheritance for all children: "/vendor/cmu/cyrus-imapd/sieve-inherit" with values "true" or "false". The server would have to manage the inheritance behaviour itself since ANNOTATEMORE does not have inheritance built-in (this does beg the question as to whether ANNOTATEMORE should have inheritance built-in but that will add a lot of complexity). The question is whether to make inheritance the default or not. Also note that this has to also work by adding a script to a \NoSelect mailbox (i.e. one that is a 'directory' rather than a message container) - but ANNOTATEMORE requires that to be supported. Does a SIEVE fileinto constitute a 'post' operation that would trigger an attached script? If so, then you need to make sure loops are prevented. What about IMAP APPEND? Does that trigger the script? It really ought to as well. Will you extend ManageSIEVE to allow setting scripts on mailboxes via that protocol? Should a script attached to INBOX actually be the users primary (delivery) SIEVE script? If so setting that script via IMAP ANNTATEMORE should have the same effect as doing so via ManageSIEVE. -- Cyrus Daboo
Re: multiple problems with imsp
Hi Ben, --On Wednesday, February 19, 2003 4:13 PM -0800 Ben Poliakoff <[EMAIL PROTECTED]> wrote: | a OK User `benp' Logged in | A2 CREATEADDRESSBOOK .benp.foo | A2 NO User 'benp' not permitted to create address book '.benp.foo' | * BYE IMSP server exiting (probably out of memory) | | Is this a namespace thing? Why is it trying to create using '.' as the first part of the address book name? Exactly what are you typing into Mulberry's create address book dialog? -- Cyrus Daboo
Re: multiple problems with imsp
Hi Ben, --On Wednesday, February 19, 2003 3:15 PM -0800 Ben Poliakoff <[EMAIL PROTECTED]> wrote: | a OK User `benp' Logged in | A2 CREATEADDRESSBOOK .foo | A2 NO User 'benp' not permitted to create address book '.foo' This isn't going to work even if the server itself is working. By default users are only allowed to create personal address books, and under the IMSP naming scheme that means address books with the user id as a prefix. i.e. you should have been able to create 'benp.foo'. Using '.' at the start of the name is also going to be a problem given that that character is the hierarchy separator character, and you can't start with a 'null' level of hierarchy. -- Cyrus Daboo
Re: Spamattack!
Hi Mike,
--On Wednesday, January 29, 2003 06:22:25 PM -0500 Mike Cathey
<[EMAIL PROTECTED]> wrote:
| SNIP
| require
| ["fileinto","reject","vacation","imapflags","relational","comparator-i;as
| cii-numeric","regex"]; if
| header :contains "X-Spam-Flag" "YES"
| {
| fileinto "Spam";
| stop;
| }
| if
| header :contains "X-Amavis-Alert" "INFECTED"
| {
| fileinto "Virus";
| stop;
| }
| SNIP
|
With this setup isn't it possible for a virus to end up in the spam folder
if it gets classified as spam as well as a virus, given the order of the
actions in the SIEVE script? I would have thought it better to put all
virii into the virus folder irrespective of whether its also spam or not.
Just interested to know why you have it this way around.
--
Cyrus Daboo
Re: sasl2 + imsp / acap ???
Hi, --On Tuesday, May 14, 2002 10:46 PM -0500 Alon <[EMAIL PROTECTED]> wrote: | I have imapd running using sasl2 for authentication, but I'd like to add | remote preferences support. Unfortunately, neither smlacapd nor imspd | seem to support sasl2 in their current form. Is there any way to get | either one to authenticate against sasl2, maybe a patch somewhere, or am | I stuck using sasl1 ? Thanks, aLoN We have been working on some updates to imsp that will include sasl2 support and integrated TLS support. We're planning on some other major changes too, including improving the backend database support to improve performance of address books etc, plus some other changes that will tie in directly with some major new functionality that will be appearing in Mulberry hopefully later this year. I'm going to try and get the IMSP stuff available off our site soon. -- Cyrus Daboo
Re: addheader action ... or something like it?
Hi, --On Monday, May 13, 2002 1:57 PM -0400 Ken Murchison <[EMAIL PROTECTED]> wrote: | I know the code pretty well, and personally I wouldn't even attempt it. | Of course, I'm not a fan of the spam extension. Quick question: where does the X-Sieve header get added, and would it be possible to use that to add extra info? -- Cyrus Daboo
Re: SCAN command?
Hi, --On Wednesday, April 24, 2002 1:12 PM -0400 Lawrence Greenfield <[EMAIL PROTECTED]> wrote: | I think LISTEXT will eventually allow for STATUS information returned | with the LIST. Also ANNOTEMORE may have status information and that could allow a single command to match multiple mailboxes to return all results in one go. -- Cyrus Daboo
Re: SCAN command?
Hi, --On Tuesday, April 23, 2002 7:51 PM -0700 Ashley Yakeley <[EMAIL PROTECTED]> wrote: | So what is the best way for an IMAP client to detect recently arrived | mail in a hierarchy of around a thousand mailbox folders? Should it do a | SELECT on each one periodically? Or should it open up 1000 connections, | SELECT a folder and do IDLE on each one? The only sensible choice in this situation is probably STATUS command polling. You'll have to do one command for each mailbox. You could split that up over several connections running in background threads on the client so as not to affect user performance too much. In Mulberry we choose to implement a scheme where a user can set up multiple 'alert styles' that allow them to set different polling intervals. You can then apply that to different mailboxes. For example, I have one style set to poll every minute and that acts on my INBOX plus some other important mailboxes, another style is set for every ten minutes for less important mailboxes, another set for every half-hour for mailing lists, and another set to check only when the app is started for mailboxes I'm not too bothered about. This allows the user to set their own precendence for new mail notifications. This works pretty well for my setup with about 50 mailboxes in total being checked. I suspect 1000 is really pushing it though. If that were something that needed to be done a lot, then a better approach would be a multi-mailbox IDLE extension, or one of the mailbox notification protocols that are being discussed (e.g. the SNAP protocol discussed in IMAPext/VPIM groups). -- Cyrus Daboo
Re: e-mail expiry (a strange request)
Hi, --On Monday, March 11, 2002 8:55 PM -0800 Ian Macdonald <[EMAIL PROTECTED]> wrote: |> Depending on the version you have, try ipurge that comes with Cyrus: | | Great, just what I need. I had no idea such a program was part of the | Cyrus package itself :-) Presumably you are also making backups of your mail store? Do you plan omn 'shredding' those as well? What about users that have a disconnected cache of the old messages? It seems to me that 'shredding' the messages on the server is no guarantee that they are really gone. Most forensic computer analysts will find the old copies one way or another... -- Cyrus Daboo
Re: Which module in cyrus provides return receipt ?
Hi, --On Thursday, March 7, 2002 10:49 AM -0600 Amos Gouaux <[EMAIL PROTECTED]> wrote: | tjk> Problem: Management wants a return receipt feature for emails. | | For what, read receipt or delivery receipt? For delivery receipt, I | wonder if that's something lmtpd could do? Isn't read receipt | something the mail client would do? | | Though, if delivery failed the message would be bounced, so the | sender *should* know from that whether the message has been | delivered. There are two kinds of receipt in email that you can use: 1) Message Delivery Notification (MDN) - this consists of a set of headers added to the message by the sender, indicating that they want notification of when the message is processed (either read or deleted) by the recipient. The recipients client is in charge of sending back the receipts. Clients that support it usually have the option to turn it off, prompt before sending, or automatically sending the receipt. It seems like the majority of people turn it off! 2) Delivery Status Notification (DSN) - this consists of some optional parameters added to the SMTP protocol exchange between the client and the SMTP server. Clients can request DSN's for success, delay or failure, and specify whether they want returned just the headers or the entire message body as part of the receipt. In order for DSN's to work properly, each SMTP server that handles the message enroute to delivery must support the DSN extension, as these options are passed along with the message. Usually if a DSN-aware server has to pass the message on to a non-DSN-aware server it will send a receipt back to the sender stating that the message got that far. A DSN success only guarantees that the message got delivered into the recipients INBOX - it won't tell you anything about whether the recipient actually sees the message. I think the DSN extension is pretty widely deployed in SMTP servers so this ought to be a fairly reliable method, though sometimes firewalls can get in the way. -- Cyrus Daboo
Re: voicemail to IMAP (cyrus) gateway?
Hi, --On Wednesday, February 27, 2002 11:37 AM -0600 Dave Caplinger <[EMAIL PROTECTED]> wrote: | Is anyone aware of a voicemail system that will inter-operate with a | cyrus IMAP server to either | | a) send users email with a URL where they can retrieve the voicemail | (relying on a web browser for voicemail delivery) or | b) deposit voicemail into a user's IMAP mailbox as a message with a sound | file attachment | | Option "a" would actually be ideal since then I don't have to deal with | mailbox quotas getting full because of voicemails (which means that | sometimes the voicemail system would not be able to successfully deliver | the message and must deal with that possibility), but "b" would certainly | be acceptable. | | I've been looking in the obvious places, but virtually everything having | to do with "unified messaging" of this type is specific to Microsoft | Exchange Server and/or Lotus Notes. My needs are meager, I'm not looking | for FAX support etc, just voicemail --> IMAP mailbox. My only other | requirement is that it not be win32-specific for the end users. Most of | our users are on Macs and for the rest we banned Outlook long ago. | | If you email to me directly, I'll summarize to the list later. Thanks! You might want to take a look at the VPIM (Voice Profile for Internet Mail) work at the IETF which is working on standards to help this type of behaviour: <http://www.ietf.org/html.charters/vpim-charter.html> There are a number of commercial vendors (not just MS and Lotus) that do have solutions in this space, but I don't have details myself. I think a lot of the telecomms companies (e.g. Nortel, AT&T etc) who already have voicemail products are involved in this space. -- Cyrus Daboo
Re: RECENT/SEEN flags
Hi, --On Wednesday, February 27, 2002 9:05 AM -0700 "Alec H. Peterson" <[EMAIL PROTECTED]> wrote: |> The important thing to note is a recent change in our connection handling |> that keeps a connection active for a short while after the user closes a |> mailbox window, so that if they open another mailbox soon after, the |> connection can be reused, avoiding the overhead of connection setup and |> authentication. In this case we use the UNSELECT command on the previous |> mailbox to effectively 'close' it. That command ought to invalidate the |> cache, as should the CLOSE command, which may be used in other |> situations. | | But when I open the mailbox the counts are always right. | | Unless I'm mistaken, there is an entirely separate connection that always | does the STATUS commands periodically, yes? Since it's never selecting a | mailbox then the cache will never be cleared, right? Yes, one connection is used to do periodic STATUS polls of all mailboxes you have marked for new mail checking. Then a new connection is used when you actually open a mailbox. When a mailbox is open, the checking is done via that connection using NOOPs. Based on the brief description that Larry had provided I'm guessing the caching happens on for the connection where the mailbox is SELECT'ed - i.e. the one where the mailbox is opened by the user - and not the STATUS connection. The code is the definitive source for this... -- Cyrus Daboo
Re: RECENT/SEEN flags
Hi, --On Wednesday, February 27, 2002 8:20 AM -0700 "Alec H. Peterson" <[EMAIL PROTECTED]> wrote: |> For improved performance, Cyrus tends to cache seen state changes |> until the connection SELECTs some other mailbox. Thus the other |> connection isn't changing its count. |> |> I don't have time to go looking through the code to see where this |> behavior can be modified; I don't think it would be all that difficult |> but the performance impact could be substantial. | | Well if you could point me in the direction of where said caching takes | place I'd be happy to play with it myself and report back. The important thing to note is a recent change in our connection handling that keeps a connection active for a short while after the user closes a mailbox window, so that if they open another mailbox soon after, the connection can be reused, avoiding the overhead of connection setup and authentication. In this case we use the UNSELECT command on the previous mailbox to effectively 'close' it. That command ought to invalidate the cache, as should the CLOSE command, which may be used in other situations. -- Cyrus Daboo
Re: How can a program securely get new/unread msg status on lots ofCyrus mailboxes?
Hi, --On Thursday, February 14, 2002 11:39 PM -0800 Don Jackson <[EMAIL PROTECTED]> wrote: > Is there a way to create a user that has access to the unseen msg count > for other users, but nothing else? (eg, would not be able to actually > read any users messages). That way if the password was compromised, the > only thing that could be done with it is to find out how many unseen > msgs other people have. Is it possible to change from one user's > mailbox to another users's mail via the IMAP protocol? The STATUS command does allow you to get unseen count on any mailbox to which you have the 'r' ACL right - it does not require you to actually select the mailbox to get the count. Unfortunately the 'r' right does allow that user to also open the mailbox in read-only mode so the message data would be exposed. If having access to the message data were not an issue, what you could do is setup a user that has 'r' rights to each of the mailboxes of other users you want to examine, and then you just issue status commands for those mailboxes to get the unseen count. -- Cyrus Daboo
Re: [Exim] Cyrus/Exim incompatibility
--On Thursday, January 24, 2002 12:04 PM -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: > Yeah, I mentioned this to Larry a while back, but he didn't really like > the idea. I don't remember his exact reasoning, but I think it had > something to do with not knowing whether the reject/vacation message > ever got sent or something. Larry? > > I would be nice if there was some kind of LMTP/ESMTP backchannel for > sending out a responses to a message just delivered, via the already > open connection to the MTA. I think SMTP TURN may do this, but its use > is deprecated. Hmm. Why not just jave LMTP keep an SMTP connection (or pool of connections) permanently open, and send all messages through that using RSET after each one? Wouldn't that be more efficient than calling sendmail/exim etc once per message if the volume gets to be large? -- Cyrus Daboo
Re: IMSP and address synchronization support (was Re: WebmailClient)
--On Saturday, September 15, 2001 9:48 AM +1000 Jeremy Howard <[EMAIL PROTECTED]> wrote: >> In an ideal world, ACAP, the successor protocol to IMSP, would be >> available, and that would deal with these types of issues. However, the >> ACAP effort is all but dead, leaving IMSP as the only viable remote > address >> book and preferences protocol in use. >> > Thanks for clarifying that, Cyrus. What about LDAP--is there any reason > that LDAP cannot be used for address-book synchronization? Its feasable. I think LDAP has the same problem as IMSP does of having to download the entire address book to do the sync. operation. Plus mapping between other address book formats and LDAP schema is the same problem as mapping to IMSP fields. The question is what you intend to do with the data in LDAP. If all you use it for is a network repository for syncing with some other clients' address books, then all you really need is a network database. In fact in that case, ftp would be just as good. However, if you want to actually allow use of the data in LDAP aware clients, then you need to store the address information there in a format that all clients will understand and can 'browse'. LDAP has typically been used to provide a directory service, and this is different from a personal address book, in that in general the directory is read-only. Managing personal address books in LDAP, which requires users to have read-write access to the LDAP server, is harder, and has generally not been done. IMSP is specifically designed for that of course. > The only other address synchronization client I'm aware of is Windows > Address Book (wab.exe) which can sync with the HotMail address book. > However I'm not aware of a published standard that this uses--it's > probably proprietary. A lot of HotMail is proprietary! > If there are no real options for standards that support address book sync > I guess we'll have to write our own for our webmail site :-( This goes back to how you want to use the remote stored data. If you really want to have a remote personal address book store, then I would argue that IMSP is the way to go. Of course others may disagree... -- Cyrus Daboo
Re: IMSP and address synchronization support (was Re: WebmailClient)
--On Saturday, September 15, 2001 8:23 AM +1000 Jeremy Howard <[EMAIL PROTECTED]> wrote: >> In particular, Silkymail has support for IMSP preferences and adress >> books, A very interesting feature if you want user being able to share >> address books between Webmail and other mail clients. >> > What clients support IMSP? Is this support synchronization/off-line access > (like good IMAP clients), or on-line access only, or import/export only? > > I'm looking to add something to our webmail site that synchronizes the > Windows Address Book and other common mail client address books with our > server address book. I can't find anything that supports this--the obvious > choice would appear to be to use LDAP on the server, but I can't find any > clients that support synchronization of LDAP with local address books. Our products Mulberry and SilkyMail are pretty much the only shipping clients that use IMSP. The old Simeon/ExecMail client used IMSP too, but that is no longer being supported. The SilkyMail IMSP support is provided as a PHP module. This is currently not available as part of the base PHP4 distribution, but you can grab it from the SilkyMail source distribution which is free. Mulberry does allow disconnected use of IMSP address books, in the same way that it does IMAP mailboxes. However, IMSP does not have the same level of protocol support as IMAP does to make disconnected operations as efficient as they could be. In particular, there is no easy way to determine which addresses have changed on the server, in order to minimise the number of addresses to be synchronised. As a result a client has to download the entire contents of an address book everytime it disconnects to ensure it has an accurate cache of the address book contents. There are other issues related to what address fields it stores and how groups are handled - these would impact on how you synchronise withg some other address book format In an ideal world, ACAP, the successor protocol to IMSP, would be available, and that would deal with these types of issues. However, the ACAP effort is all but dead, leaving IMSP as the only viable remote address book and preferences protocol in use. -- Cyrus Daboo Cyrusoft International, Inc.
Re: BAD response to FETCH
--On Monday, April 2, 2001 8:44 PM +0200 Vadim Zeitlin <[EMAIL PROTECTED]> wrote: > 000d FETCH 1 BODY.PEEK[HEADER.FIELDS (Newsgroups)] > 000d BAD Missing required argument to Fetch > > As I don't see this behaviour with neither Courier nor UW IMAPd I suspect > that this is a bug in Cyrus, am I wrong? If it's really a bug, has it been > fixed in the newer versions and/or is there any workaround for it? Yes it is a bug in the server. The fix is to upgrade to a more recent version of the server: the latest v1.6.x release or v2.0.x. -- Cyrus Daboo
Re: Set permissions (ACL) recursive
--On Sunday, April 1, 2001 12:37 PM -0700 Rob Tanner <[EMAIL PROTECTED]> wrote: > There are two possibilities. > > 1) Write a cyradm script (the -file option with cyradm) to make the > changes. Read through the cyradm manpage and you should find everything > you need. > > 2) If you're a perler, check out the perl package IMAP::Admin. I was > exceedingly happy to find the it (its on CPAN) since I don't really know > tcl, so cyradm scripts have always been a real pain for me. The perl > package, on the other hand, has been a life saver. There's a third choice if you have Mulberry: our ACL support lets you 'transfer' the ACLs from one selected mailbox to any others pretty easily. However, this is not particularly efficient because of the way the ACL support via IMAP is defined, so it may take a while with a lot of mailboxes - however, it does work. -- Cyrus Daboo
Re: TLS and client certificates
--On Friday, March 16, 2001 10:41 AM +0100 Norbert Klasen <[EMAIL PROTECTED]> wrote: >> Excellent catch. This looks like a bug; as you might've guessed, we >> don't yet use client side authentication with STARTTLS, and this code >> was only tested a few times when it was first inserted. > > BTW are there any MUAs that support STARTTLS/IMAPS with client > certificates and SASL EXTERNAL? > If I change the askcert parameter in the call to tls_init_serverengine > to 1, Netscape Messenger (4.76) prompts for a client cert and sends it > to the server but then does plaintext authentication. We've looked into the possibility of adding this capability to Mulberry, but there really hasn't been a great demand for it so its a low priority. I'd certainly like to hear from people who think its important. -- Cyrus Daboo
Re: installsieve protocol as standard track
--On Saturday, February 24, 2001 7:41 PM +0100 Simon Josefsson <[EMAIL PROTECTED]> wrote: > Is there any work in progress or interest in making the installsieve > protocol a standards track protocol? > > How do existing MUAs handle uploading of Sieve scripts? ACAP? I'm working on adding the managesieve (installsieve) support to Mulberry. Right now we generate scripts but they're saved as a local file and the user has to ftp to the sieve server - not ideal but the sieve support is still 'alpha'. I would like to see a standard protocol that all clients could use. This would act as a 'wrapper' for whatever storage mechanism a particular implemenation may want to use on the back-end, e.g. file system, ACAP, IMSP, LDAP etc, but would provide sieve clients with a single upload/download API to use. Currently there doesn't seem to be a lot of interest in doing this - but you might want to propose it again on the sieve list. -- Cyrus Daboo
Re: Connection reset when using TLS (Mulberry 2.0.5 and Cyrus1.6.22)
--On Wednesday, January 10, 2001 10:51 AM -0500 Jerry Kendall <[EMAIL PROTECTED]> wrote: > When I try to access using TLS I am having some dificulty. > My imapd.log file when I connect using Mulbery from Cyrusoft.com: > = > Jan 10 11:01:46 gw imapd[1916]: starttls: TLSv1 with cipher DES-CBC3-SHA > (168/168 bits) no authentication > Jan 10 11:01:52 gw imapd[1916]: PROTERR: Connection reset by peer > = Hi Jerry, Looking at your imtest log shows that there is a server problem: the CAPABILITY command being issued after STARTTLS is being rejected by the server. This will cause Mulberry to display an error and shut down its connection. I did a test with Mulberry from here against the server address listed in the log and saw the same problem. I'm not sure why the server is refusing CAPABILITY after STARTTLS - it really shouldn't as clients are required to re-issue CAPABILITY after STARTTLS to make sure they have a legitimate set of authenticators and other capability items listed after the secure connection has been created. Hopefully one of the server experts on this list can explain what is causing this and how to fix it. -- Cyrus Daboo
Re: sieve: fileinto and keep
--On Wednesday, January 10, 2001 4:13 PM +0100 Walter Steiner
<[EMAIL PROTECTED]> wrote:
> elsif envelope :localpart :is "to" "ws+test" {
> fileinto "INBOX.test";
> keep;
> }
>
> (-- end of script --)
>
> Messages addressed to ws+test are saved into INBOX.test
> but there is no copy in my INBOX as expected.
>
> lmtpd[21763]: [ID 538540 local6.info] dupelim: eliminated duplicate
> message to user.ws.test id
>
> "to user user.ws.test" - nothing to do with the missing copy in INBOX?
>
> anyhow, how to keep a copy in inbox and in a special folder?
> (procmail c flag)
In the absence of sieve, the address 'ws+test' will naturally result in the
message being delivering into INBOX.test, assuming all the permissions for
'plus' delivery are setup correctly. The keep action in sieve is simply
doing the same thing and duplicate suppression kicks in (as indicated by
the lmtpd message). What you should probably do is:
elsif envelope :localpart :is "to" "ws+test" {
fileinto "INBOX";
keep;
}
That will force delivery to INBOX (fileinto) and also result in a copy in
INBOX.test (keep).
--
Cyrus Daboo
