Re: [Dovecot] [dovecot] - filters
On 4-Mar-10, at 4:36 PM, Rick Romero wrote:
Quoting Marcus Rueckert da...@opensu.se:
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
and with an LDA that speaks only sieve?
how do you do it there?
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
I don't know enough about Sieve to give an example..
what you want is:
1. List-Id head contains Dovecot Mailing List
2. Subject does not contain [Dovecot]
3. Pass email to formail to modify Subject ( built in Sieve
equivalent?)
HTH
Rick
So what happen if I had this promail recipe and I reply to list?
If the subject line is Dovecot Mailing List, will it become Re:
Dovecot Mailing List or Re: [Dovecot] Mailing List? (I think it's
the latter case)
If it's the latter one, I vote to keep the prefix now.
The prefix helps visual eye filtering, works for people (including me)
who keep all new email to inbox rather than direct them to other
folder before reading them.
I vote to keep the prefix even it's the first scenario, but I'm not
strong into must keep prefix in both cases.
Joseph
Re: [Dovecot] feature question: local delivery from SMTP
Mail client interacts with MTA (sendmail, postfix, exim, etc) and then MTA 'calls' the delivery agent (LDA, some MTA, etc) to deliver the mail to mailboxes. Common mail clients do not interact with delivery agent directly, even it's inbound. So yes, you need MTA for inbound mail. HTH Joseph On Fri, Jan 22, 2010 at 7:11 AM, Phil Howard ka9...@gmail.com wrote: I saw something in the documentation called LDA that looked like it was accepting some kind of connection and delivering mail into mailboxes. On Fri, Jan 22, 2010 at 4:09 AM, Veiko Kukk veiko.k...@ekp.ee wrote: Phil Howard wrote: Does Dovecot really need a separate MTA for inbound mail? Why do you thing it might need? Or can it receive SMTP directly if there is no forwarding to do? What about spam/virus filtering in that case? Dovecot has nothing to do with smtp. You need MTA like postfix or exim to deliver mail to mbox/maildir. Then dovecot can show those mailboxes to client. -- Veiko -- Phil Howard KA9WGN - ka9...@gmail.com
Re: [Dovecot] UTF-8 mailbox names in filesystem
On 10-Nov-09, at 9:02 AM, Steffen Kaiser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Nov 2009, Laurent Blume wrote: I would personally find it useful. I use accented and Chinese characters, and I, too. Same here. I've worked in environments where they were common as well. Having a common name between MUA and FS would certainly be nice. It would be nicer for some scripts and plugins as well. Will there be an API to match folder names, upper and lower case etc.pp.? As for the risks, maybe some Unicode ranges could be restricted to avoid control characters and such? Or limit the use to given subsets? UTF8 does use octets = 0x80, every system should be 8bit clean nowadays. I had some worries rather than risk. Some MUA may convert before passing the name, and it results in no match... but maybe Timo thought about this already :) Other than looking weird to sys admin whose non foreign speaker, especially in bidirectional presentation, in file system, there should be no issue. best, Joseph regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSvlyg3WSIuGy1ktrAQLsLgf9HVO/E7jwHl8Vgug6esIVK6Icurez7EV5 tvPxtobDSwBDq+ZP8BC6Kdw1uzmRNH60xs/KnaKgscv3vHyOYoiPlRLzYJmNriVt Msct59wPsKwEYACXm1P9iVCMOX0TYLiXliC+LCfOpOL0BqxDBolULuqKw9X2OF9t 71L+WL79KOxgYD2EwUGD9yYoEOo3uixd3AQdsADYfhFqbO9JwsPvuACXmmgAEL0A L3cPGpAp7YeAeAS6DQNCn5d1r1jGRaK47dipHmNSU6U5F3YW40DCl+JUS50AT3no bxrxrNbvXUGFGyHli54RaQS3svArJyXOii9ro9rtqngrnF3xaqunuA== =0IFT -END PGP SIGNATURE-
Re: [Dovecot] Password and special caracter
Sounds more like SASL than Dovecot. I had my Dovecot authenticate against DB in UTF8 encoding, and it can handle Chinese character for password. Can your smtp authentication allows special character? Best, Joseph On 1-Oct-09, at 10:40 AM, Gilles Albusac wrote: Problem : I have a problem with special character in the password. Character like ! * é are deleted My configuration : - a smtp server with Postfix 2.6 and Dovcot 1.1.11. - a windows 2003 server with active directory for accounts and boxes I use SMTP / SASL on my postfix 2.6 to authenticate my remote laptop users (allow legitimate users to relay mail). To do that, I use SASL Dovecot fonctionnality and ldap request to verify login/password who are declared on a server in Windows 2003 (Active Directory). It works fine with simple password but not with complex password. I have a problem with special character in the password. Character like ! * é are deleted before comparaison. Any idea ? Regards
Re: [Dovecot] v2.0 configuration parsing
Hi Timo,
What's your thought on the 'precedence order' (hope it make sense),
on protocol, remote_ip, local_ip?
From your sample 1, it would read equals (to most technical people) to
protocol imap
{
remote_ip 192.168.0.0/16
{
foo = foo
}
}
protocol ALL
{
remote_ip 192.168.0.0/24
{
foo = bar
}
}
If follow this syntax, sample 1's answer would be foo = foo, assuming
specific rules overwrite general rules, and assuming protocol is the
first order.
Sample 2 is tough, that's why I asked what's your thought on
precedence order. Restricting syntax to only remote before local (or
vice versa) should resolve it.
Joseph
On 10-Aug-09, at 1:57 PM, Timo Sirainen wrote:
I'm trying to figure out how exactly v2.0 should be parsing
configuration files. The most annoying part is if it should always
just
use whatever comes first in config or try some kind of a use most
specific rule. The most specific kind of makes more sense
initially,
but then you start wondering how to handle e.g.:
1) User logs in to imap from 192.168.0.1. What is foo's value?
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
remote_ip 192.168.0.0/24 {
foo = bar
}
2) User logs in from 192.168.0.1 to 10.1.2.3. What is foo's value?
local_ip 192.168.0.1 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
remote_ip 10.1.2.3 {
local_ip 192.168.0.0/24 {
foo = bar
}
}
Any thoughts?
Re: [Dovecot] alias best practice
I can't say it's best practice, it depends on your setting. I'm allowing IMAP login from both us...@acme1.com and us...@acme2.com, to some extent it's us...@acme1.com us...@acme2.com to the same maildir location, and I'm taking the 2) approach. 2) The same maildir path specified in MySQL record HTH - Joseph On 3-Jul-09, at 10:47 AM, Luigi Rosa wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Given a Linux mail server with Postfix+Dovecot using MySQL as userbase, a single Linux user for file system access, two mail domains configured (acme1.com acme2.com) and a maildir structure as follows \var\spool\mail\acme1.com- \user1 \user2 \user3 \var\spool\mail\acme2.com- \user1 \user2 \user3 I want that the mail of us...@acme1.com and us...@acme2.com goes in \var\spool\mail\acme1.com\user1 Note that there could be some users not equal between two domains. What is the best practice? 1) Alias at Postfix level 2) The same maildir path specified in MySQL record 3) ln -s between \var\spool\mail\acme1.com\user1 and \var\spool\mail \acme2.com\user1 4) Else? (Dovecot virtual mailbox) Thank you. Ciao, luigi - -- / +--[Luigi Rosa]-- \ Blessed are they who Go Around in Circles, for they Shall be Known as Wheels. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpOGf8ACgkQ3kWu7Tfl6ZTJ1ACgp52Fy7PbGpnU9pFnvVioNcFO OO8AoJRGG2UkyPXczR/bkAXqwjmVtpyL =Loje -END PGP SIGNATURE-
Re: [Dovecot] Fwd: [MORG] IMAP5 List
Timo, Thanks for bringing it up. I dealt with i18n MUA. I would love to see i18n from IMAPEXT (http://www.ietf.org/rfc/rfc5255.txt) be part of IMAP5, the mechanism, not all language translations, of course :) And I guess no MUA needs to 'ENABLE' anything in IMAP5. Joseph PS. I had subscribed to the mailing list :) Timo Sirainen wrote: If anyone's interested, especially client developers. It's been a bit quiet there after the initial rush. Begin forwarded message: From: Randall Gellens [EMAIL PROTECTED] Date: August 1, 2008 5:08:39 AM EDT To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [MORG] IMAP5 List At the MORG BOF, a discussion as to if the proposed IMAP extensions would merely further add to the existing problem with IMAP being too hard to get right, for both clients and servers, let to a revival of the IMAP5 discussion (previous held during the IMAP EAI discussions). Here, IMAP5 refers to a Big Switch (new port and version) to distinguish this revision from current IMAP. The goal is to delete as much as possible from IMAP. A new mailing list now exists for this discussion on drastically slimming-down IMAP to make it easier to implement clients and servers. == To subscribe, click here: mailto:[EMAIL PROTECTED]. == It's been observed that most IMAP clients suck and that it's hard for both clients and servers to implement. One reason IMAP is hard to implement is that it has a lot of options. Often there are several alternative ways to accomplish something. It also has considerable functionality. Is it possible and desirable to start with the current set of (IMAP + all extensions) and consider subtracting as much as possible? The resulting protocol would still be IMAP, but not backwards-compatible with today's IMAP, since some currently-mandated items are likely to be deleted. General information about the IMAP5 mailing list is at: https://www.ietf.org/mailman/listinfo/imap5. You can subscribe and manage your subscription at https://www.ietf.org/mailman/listinfo/imap5. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- If Murphy's Law can go wrong, it will. ___ MORG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/morg Note Well: http://www.ietf.org/maillist.html
Re: [Dovecot] v1.2 development tree started
Hi Timo, First of all, dovecot is great! :) Question on CONDSTORE. I haven't re-read RFC to confirm, isn't CONDSTORE operates under switch mode with command ENABLE? So that IMAP client needs to request such capability. Maybe I mixed up with another IMAP command. Thanks Joseph Timo Sirainen wrote: Updates: On Mon, 2008-06-09 at 05:51 +0300, Timo Sirainen wrote: I merged all the new features and latest v1.1 changes under one tree: http://hg.dovecot.org/dovecot-1.2/ Nightly snapshots are also from v1.2 code tree nowadays. 1. CONDSTORE extension is probably the largest change. It adds new modification sequences for messages that increase whenever the message's metadata changes. I'll probably have to reimplement the way modseqs are calculated, because modseqs will be very useful when implementing replication and the current way just doesn't work with it. If modseq-supporting clients see the current modseqs and later the server gets upgraded to new modseqs, the clients will most likely break. So this change should be done for v1.2. Modseq changes are implemented. The only issue with CONDSTORE is that STORE UNCHANGEDSINCE command doesn't atomically check-and-update. Implementing the atomicity should be pretty easy since there is a similar check already in the code. The largest issue with it is changing APIs enough to support returning back which messages failed the STORE. Still should be pretty easy. 4. Virtual mailboxes should work fast after mailbox is opened. The initial opening could use several optimizations though. It could probably share some code with QRESYNC to avoid the full initial search (storing each backend's modseq to index header). Also if search parameters don't contain any dynamically changing data, there's no point in searching the old messages. Implemented initial opening optimizations. I haven't done much testing though, other than it appears not to crash and appears to work with simple tests. :) So the current implementation should be as fast as it's possible to make it. The current design doesn't allow changing the search parameters or list of mailboxes, otherwise it breaks more or less badly. I guess I could add code to check if the dovecot-virtual file's mtime has changed and if so make it do a full resync. This anyway means that there's no way to support wildcard mailbox names (e.g. all mailboxes). But does anyone really want that (yet)? It'll anyway be faster/easier to implement once mailbox list indexes are implemented. Changing mailbox list is now detected and handled, as well as UIDVALIDITY changing in mailboxes. Mailbox list wildcards wouldn't be all that difficult to implement anymore if someone wants them, but until then I don't think I'll bother. Changing search parameters still isn't detected though. Maybe it could store a MD5 sum of the search parameters in the header and if it changes rebuild the entire mailbox. I'll still have to add a new X-MAILBOX search parameter which can be used to test what the backend mailbox name is. This will be especially useful with INTHREAD extension. I guess it wouldn't hurt to have FETCH X-MAILBOX if someone wants it. Oh, almost forgot about this one. 6. INTHREAD extension isn't started yet, but I'll start it soon. Hopefully won't be too tricky to get it working with virtual mailboxes and CONTEXT=SEARCH.. This one is the last major unimplemented v1.2 feature. After that I'll start finishing, optimizing and stabilizing the features for a v1.2 release (as well as start v2.0/replication coding). I'm hoping for v1.2.0 release by the end of this summer.
