Re: 2.3's future?
On Fri, Feb 11, 2011 at 02:15:32PM +, Jeroen van Meeuwen (Kolab Systems) wrote: > Jukka Huhta wrote: > > I filed a bug 3397 (replication & partitions), also reported in > > http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39940.html. > > What are the odds to have it fixed in 2.3 or will it just be closed > > with WONTFIX? > > > > If we don't count these few replication related bugs, 2.3 appears to > > be fairly stable compared to 2.4, IMHO. I'm still waiting for 2.4 to > > grow up a bit before upgrading our production servers, even though I > > may be overly cautious. > > > > Our abilities right now only stretch so far; for the 2.5 series, Bron, Ken > and > Greg put in some serious effort. For the 2.4 series, is primarily me and Bron > looking at bugs reported against 2.4, which we will first atempt to solve in > 2.5, porting them back as necessary/possible, with lots of help from Bron > (again). FYI (everyone) - I'm not totally AWOL - I've been on leave (for real, it's even recorded in Opera's timesheet system) for the past couple of weeks, and I'm about to get on a plane to Oslo in a few hours. I'll be settling in to work over there from next week. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
André Schild wrote: > @bücher.ch is allowed. > In dns this is represented as a IDN encoded name in the form of*** > > xn--bcher-kva.ch* is the ACE string, and it is this string that is > entered in the DNS. > Fine, let me rephrase; The IDN<->ACE string conversion, while ASCII-only not being a limitation in the DNS specifications itself, is restrained by protocol-by-protocol compatibility (or, lifting of restrictions to 7-bit ASCII, if you will). SMTP, as far as I'm aware, has not yet been made fully compatible, and have continued -for the past decade or so- to use the ACE representation, while applications such as MUAs do the conversion. Continuing this down the path to DNS, it is not actually DNS supporting this at this moment, but applications which are DNS clients (including the web administration / registration utilities), which do the conversion before the query (and probably the same conversion on the return). Just for fun, and to illustrate the point the IDN<->ACE conversion is actually an application exercise, try the rather new 'dig' vs. the rather old 'mail' utilities; $ dig +short bücher.ch 82.210.242.149 $ date | mail -s "test" "somethingthatdoesnotexist@bücher.ch" somethingthatdoesnotexist@bücher.ch contains invalid character '\303' Send options without primary recipient specified. Usage: mail -eiIUdEFntBDNHRV~ -T FILE -u USER -h hops -r address -s SUBJECT -a FILE -q FILE -f FILE -A ACCOUNT -b USERS -c USERS -S OPTION users The latter illustrates that, as opposed to just off-loading the conversion task to the MTA or SMTP layer(s). Similarly, a TCP dump on your SMTP(S) / MSA will show you the conversion is done before you hit any actual mail infrastructure. The same can be shown using named's named-checkzone utility. Continuing on the path forward, I suppose the really interesting part is what happens if a user@bücher.ch mailbox is created, versus a mail being delivered, versus a user logging in, versus sieve scripts. However, I somehow doubt it has anything to do with the original point of lowercasing the recipient in LMTP's handling by default. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
Am 11.02.2011 15:06, schrieb Jeroen van Meeuwen (Kolab Systems): André Schild wrote: > Hello, > > Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems): > > Long story short; the proposal is to ship with a default > > lmtp_downcase_rcpt of 1. > > Sound OK for me. > > When chaning upper/lowercases we always have to consider character sets. > For the user part it's no problem because here only basic characters are > allowed, > but what about a mailbox like: user@BÜCHER.CH ? > I don't think these characters are allowed in DNS / KRB, so hopefully that addresses that concern. @bücher.ch is allowed. In dns this is represented as a IDN encoded name in the form of*** xn--bcher-kva.ch* is the ACE string, and it is this string that is entered in the DNS. For technical reasons, the character string that has been processed by the algorithm is several https://www.nic.ch/reg/wcmPage.action;jsessionid=256F10E27B3713EEAF8E2FBD89827125?lid=en&plain=&res=/reg/guest/faqs/idn.jsp André Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3's future?
Jukka Huhta wrote: > I filed a bug 3397 (replication & partitions), also reported in > http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39940.html. > What are the odds to have it fixed in 2.3 or will it just be closed > with WONTFIX? > > If we don't count these few replication related bugs, 2.3 appears to > be fairly stable compared to 2.4, IMHO. I'm still waiting for 2.4 to > grow up a bit before upgrading our production servers, even though I > may be overly cautious. > Our abilities right now only stretch so far; for the 2.5 series, Bron, Ken and Greg put in some serious effort. For the 2.4 series, is primarily me and Bron looking at bugs reported against 2.4, which we will first atempt to solve in 2.5, porting them back as necessary/possible, with lots of help from Bron (again). That said, 2.3 at this point is not getting an awful lot of attention. It's leaning towards maintenance mode, if you will, and no further developments are likely to take place. I'd say 2.4 is leaning towards stable, as fewer and fewer (serious) bug reports are being reported against it. If you have a special interest in 2.3 (and I know some people who have), please do feel free to contribute your efforts, they are most welcome! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
André Schild wrote: > Hello, > > Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems): > > Long story short; the proposal is to ship with a default > > lmtp_downcase_rcpt of 1. > > Sound OK for me. > > When chaning upper/lowercases we always have to consider character sets. > For the user part it's no problem because here only basic characters are > allowed, > but what about a mailbox like: user@BÜCHER.CH ? > I don't think these characters are allowed in DNS / KRB, so hopefully that addresses that concern. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
Hello, Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems): Hi there, (This is a re-posted message from our development mailing list.) In our IRC channel, it was suggested to look at RFC 2821, section 2.4, quoted as saying: "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged." The problem statement is as follows: The recipient is u...@domain.de, and while the mailbox name is "u...@domain.de", or even "user", the mail bounced. Not completely aware of the full implications and/or codebase, I wanted to put the topic on switching the default to be relaxed in the case of case sensitivity out there for discussion. Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of 1. Sound OK for me. When chaning upper/lowercases we always have to consider character sets. For the user part it's no problem because here only basic characters are allowed, but what about a mailbox like: user@BÜCHER.CH ? How is this represented in the store ? Via the same IDN mapping as for the dns servers ? If yes, then we don't have a problem, but otherwise this will potentially cause problems in the future. André Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: XFER problems with 2.4.6
Ops, Attaching the config file I missed in the previous messageidlemethod: idled foolstupidclients: yes duplicatesuppression: no configdirectory: /var/lib/cyrus defaultpartition: default partition-default: /var/spool/cyrus/mail allowusermoves: yes altnamespace: no unixhierarchysep: yes munge8bit: no lmtp_downcase_rcpt: yes admins: cyrus murder lmtp_admins: murder service_tester allowanonymouslogin: no popminpoll: 0 autocreatequota: 3000 umask: 077 sendmail: /usr/sbin/sendmail sieveusehomedir: false sievedir: /var/spool/sieve mailnotifier: external notify_external: /home/mm/imap-utils/cyrus-notification-args.php hashimapspool: true allowplaintext: yes sasl_mech_list: PLAIN allowapop: no sasl_minimum_layer: 0 sasl_maximum_layer: 256 virtdomains: userid sasl_pwcheck_method: auxprop saslauthd sasl_auto_transition: no quotawarn: 95 timeout: 480 proxyservers: murder proxy_authname: murder stor1_password: *** stor2_password: *** stor3_password: *** stor4_password: *** stor5_password: *** stor6_password: *** lmtpsocket: /var/run/cyrus/socket/lmtp idlesocket: /var/run/cyrus/socket/idle notifysocket: /var/run/cyrus/socket/notify Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
XFER problems with 2.4.6
Hello
This week I have installed a second server with Cyrus 2.4.6 (from
git.debian.org package) and I have found some unexpected behavior - I could
move users from old installations (2.3.16) to the new servers but I could not
move users between 2.4.6 servers. Here is an example session:
stor1.internal> info user/0...@.xx
{user/0...@.xx}:
duplicatedeliver: false
lastpop:
lastupdate: 11-Feb-2011 11:32:26 +0200
partition: default
pop3newuidl: true
sharedseen: false
size: 96470220
stor1.internal> xfer user/0...@.xx stor5 default
xfermailbox: The remote Server(s) denied the operation
stor1.internal> quit
the log file on the source server has this entry:
Feb 11 14:40:44 stor1 cyrus/imap[16158]: Could not set remote acl on
mail.bg!user.0666.pay
the log file on the destination server has this:
Feb 11 14:41:09 stor5 cyrus/imap[11569]: login: [10.0.0.130] murder PLAIN User
logged in
Feb 11 14:41:10 stor5 cyrus/imap[11569]: LOSTQUOTA: unable to record add of
256951 bytes in quota .xx!user.000
Feb 11 14:41:10 stor5 cyrus/imap[11569]: LOSTQUOTA: unable to record quota file
.xx!user.000
Feb 11 13:23:47 stor5 cyrus/imap[11445]: Deleted mailbox ^xx!user^000^pay
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox ^xx!user^000^Sent
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox ^xx!user^000^SPAM
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox
^xx!user^000^Facebook
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox ^xx!user^000^Drafts
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox ^xx!user^000^D^V^
Feb 11 14:41:10 stor5 cyrus/imap[11569]: Deleted mailbox ^xx!user^000
Feb 11 14:41:10 stor5 cyrus/imap[11569]: USAGE murder user: 0.00 sys:
0.05
I do not know if this is a bug or misconfiguration (it's the same with the old
servers) so I have attached the config file.
Thanks in advance for any suggestions
luben
--
"Perhaps, there is no greater love than that of a
revolutionary couple where each of the two lovers is
ready to abandon the other at any moment if revolution
demands it."
Zizek
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Tuning some defaults for 2.5: lmtp_downcase_rcpt
Hi there, (This is a re-posted message from our development mailing list.) In our IRC channel, it was suggested to look at RFC 2821, section 2.4, quoted as saying: "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged." The problem statement is as follows: The recipient is u...@domain.de, and while the mailbox name is "u...@domain.de", or even "user", the mail bounced. Not completely aware of the full implications and/or codebase, I wanted to put the topic on switching the default to be relaxed in the case of case sensitivity out there for discussion. Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of 1. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
