qmail Digest 16 Jan 2000 11:00:01 -0000 Issue 882
Topics (messages 35514 through 35551):
looking for a web-mail solution reading directely into the Maildirs
35514 by: Olivier M.
35516 by: Mikael Schmidt
35529 by: Olivier M.
35536 by: Sam
35537 by: iv0
35538 by: Olivier M.
35539 by: Olivier M.
35543 by: Sam
Re: Maildir format
35515 by: Len Budney
35517 by: Ruben van der Leij
35520 by: Russell Nelson
35523 by: Tim Tsai
35531 by: Greg Owen
35533 by: Russ Allbery
35534 by: Peter C. Norton
35544 by: Russell Nelson
35545 by: Frederik Lindberg
35546 by: Bruce Guenter
35547 by: Peter C. Norton
35548 by: Peter C. Norton
35549 by: Peter C. Norton
35550 by: Bruce Guenter
35551 by: Tracy R Reed
Re: PGP Server authentication and DUL list
35518 by: Russell Nelson
Re: Maildir format [get busy on it]
35519 by: David Harris
35521 by: Russell Nelson
35524 by: Sam
35525 by: David Harris
35526 by: David Harris
35527 by: David Harris
35528 by: David Harris
35535 by: Sam
Re: [vmailmgr] looking for a web-mail solution reading directely into the Maildirs
35522 by: Dan
Better log
35530 by: Alessandro Ambrosini
eliminate-dups
35532 by: Adil Tahiri
Mail not being delivered
35540 by: Kevin Waterson
ofmipd rewrite syntax
35541 by: Daniel Leeds
35542 by: Russ Allbery
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hi, Does a such solution already exist ? It would be more pratical and quicker to read the data directely from the maildirs as using pop or imap protocols. It should be a CGI running with the mail-domain uid (well, to be able to read and write to the maildir), and for the authentication, there is maybe a way to use checkpassword or vmailmgrd's checkvpw? These are just some ideas, but maybe somebody allready programmed such a script ? If yes, I'd be really interested to hear from you :) It shouldn't be really difficult to program in perl. Maybe the tricky part would be the parsing of MIME stuff... Regards, Olivier
At 13:50 15/01/00 , you wrote: >Hi, > >Does a such solution already exist ? It would be more pratical >and quicker to read the data directely from the maildirs as using pop or >imap protocols. > >It should be a CGI running with the mail-domain uid (well, to be able >to read and write to the maildir), and for the authentication, there >is maybe a way to use checkpassword or vmailmgrd's checkvpw? > >These are just some ideas, but maybe somebody allready programmed such >a script ? If yes, I'd be really interested to hear from you :) > >It shouldn't be really difficult to program in perl. Maybe the tricky >part would be the parsing of MIME stuff... > >Regards, >Olivier there is a solution that does just this... I know that there are at least one more, however my mind stops at the first... SqWebMail is what you are looking for. http://www.inter7.com/sqwebmail/ it is a cgi-based client, however, it only has support for the Maildir format, not the original Mailbox. The security of it I do not really know, but I hope that it is good cause I have for intention of running it later. Mikael Schmidt <[EMAIL PROTECTED]> http://teddybear.itsec.nu "When you dream, there are no rules.... Certified Linux Administrator People can fly, anything can happen..." watata tuoijombade dikombe - Astral Projection
On Sat, Jan 15, 2000 at 03:16:25PM +0100, Mikael Schmidt wrote: > there is a solution that does just this... I know that there are at least > one more, however my mind stops at the first... SqWebMail is what you are > looking for. http://www.inter7.com/sqwebmail/ Thanks for your post. Well, Sqwebmail seems to be nice if use a standard qmail system with only one account per uid, or a system with vpopmail. But _again_ (like Courrier-IMAP), it won't work with Bruce Guenter's vmailmgrd package. :(((( Or is there a way ? Olivier
On Sat, 15 Jan 2000, Olivier M. wrote: > On Sat, Jan 15, 2000 at 03:16:25PM +0100, Mikael Schmidt wrote: > > there is a solution that does just this... I know that there are at least > > one more, however my mind stops at the first... SqWebMail is what you are > > looking for. http://www.inter7.com/sqwebmail/ > > Thanks for your post. Well, Sqwebmail seems to be nice if use a standard qmail > system with only one account per uid, or a system with vpopmail. > > But _again_ (like Courrier-IMAP), it won't work with Bruce Guenter's vmailmgrd > package. :(((( Or is there a way ? Not entirely true. Both sqwebmail and Courier-IMAP can access virtual accounts - implemented by a GDBM or DB database - and can see each other's folders.
"Olivier M." wrote: > > Hi, > > Does a such solution already exist ? It would be more pratical > and quicker to read the data directely from the maildirs as using pop or > imap protocols. > > It should be a CGI running with the mail-domain uid (well, to be able > to read and write to the maildir), and for the authentication, there > is maybe a way to use checkpassword or vmailmgrd's checkvpw? > > These are just some ideas, but maybe somebody allready programmed such > a script ? If yes, I'd be really interested to hear from you :) > > It shouldn't be really difficult to program in perl. Maybe the tricky > part would be the parsing of MIME stuff... > > Regards, > Olivier try using sqwebmail: http://www.inter7.com/sqwebmail/ It reads directly from Maildirs. working with vpopmail http://www.inter7.com/vpopmail/ Ken Jones
On Sat, Jan 15, 2000 at 03:21:21PM -0500, Sam wrote: > > Thanks for your post. Well, Sqwebmail seems to be nice if use a standard qmail > > system with only one account per uid, or a system with vpopmail. > > > > But _again_ (like Courrier-IMAP), it won't work with Bruce Guenter's vmailmgrd > > package. :(((( Or is there a way ? > > Not entirely true. Both sqwebmail and Courier-IMAP can access virtual > accounts - implemented by a GDBM or DB database - and can see each other's > folders. "not entierly true" ? well, it works or it doesn't work... and actually, I can't make it work on my server, and I never read that anybody is using it with vmailmgrd (which is not compatible with vpopmail). Or is there a (little) probability to make it work ? that would be great... Olivier
Hi Ken, and thanks for your answer. On Sat, Jan 15, 2000 at 02:31:56PM -0600, iv0 wrote: > try using sqwebmail: > http://www.inter7.com/sqwebmail/ > It reads directly from Maildirs. already tried... > working with vpopmail > http://www.inter7.com/vpopmail/ ... and that is the problem (because I'm still using vmailmgrd). Regards, Olivier
On Sat, 15 Jan 2000, Olivier M. wrote: > On Sat, Jan 15, 2000 at 03:21:21PM -0500, Sam wrote: > > > Thanks for your post. Well, Sqwebmail seems to be nice if use a standard qmail > > > system with only one account per uid, or a system with vpopmail. > > > > > > But _again_ (like Courrier-IMAP), it won't work with Bruce Guenter's vmailmgrd > > > package. :(((( Or is there a way ? > > > > Not entirely true. Both sqwebmail and Courier-IMAP can access virtual > > accounts - implemented by a GDBM or DB database - and can see each other's > > folders. > > "not entierly true" ? well, it works or it doesn't work... and actually, I can't 'vmailmgr' and 'vpopmail' are not the only ways to implement virtual accounts. If you want to implement and define virtual accounts, the capability is there. That implementation is based on a GDBM or DB database, and the different implementation was due to the fact that a much more flexible, more generic, approach was required. For example, AFAIK, neither vpopmail nor vmailmgr are capable of supporting CRAM-MD5 IMAP authentication. > make it work on my server, and I never read that anybody is using it with vmailmgrd > (which is not compatible with vpopmail). > > Or is there a (little) probability to make it work ? that would be great... Of course it's possible to make it work, if you want to implement it yourself. Both sqwebmail and Courier-IMAP can be easily extended to support any other reasonable authentication mechanism, but you have to invest the time and effort to write the code yourself. I have no need for vmailmgr, because I have an alternate solution that works better for me.
Russell Nelson <[EMAIL PROTECTED]> wrote: > > ...the question in my mind is not "What should be used for large > folders instead of Maildirs?" but instead "What must be done to make > Maildirs more efficient"? If you mean "efficient of time", that's probably the right question when disk space is not a problem. For example using IMAP into an ISP who has a giant NFS mounted disk farm. Users who POP email onto a space-conscious laptop also care about efficiency of space. That's more or less where I was coming from in provoking this thread. > One way to do that would be for Dan to change the Maildir specification > so that a Maildir may have multiple "cur" directories. Then, keep a > CDB containing a subset of the message headers. This isn't a bad suggestion. But are multiple "cur" directories required? The point of the CDB is to avoid scanning directories, after all. If message lists are built by scanning a CDB, and messages are fetched with a "stat()" and an "open()", will there be a noticeable delay? If we care about space, though, how about this suggestion? Extend the maildir format by adding an "old" file (keeping a single "cur" directory). Allow MUA's to move messages into the "old" file according to any user-settable policy. Default: at 1 month old, or whenever "cur" contains 5,000 messages (oldest first). For faster scanning, we also add your CDB index of headers (suitably frobbed to handle locations within the "old" file). The "old" file consists of mail messages, individually gzip-ped and stored as netstrings. Operations on "old" are _slightly_ vulnerable to NFS failure; but any failure is recoverable if we 1) halt at the first error, 2) delete final partial netstrings, and 3) do not delete files from "cur" until they are safely appended to "old". We might also use an atomic update procedure, a la CDB. Corrupted "old" files should simply never happen. The "old" file is absolutely unsuitable for asynchronous delivery, but by definition "old" messages are already delivered; asynchrony needs should be minimal to nil. If a message survives in your folder for a month, then you're simply saving it for future reference. Question: this certainly saves space and inodes. Is it at least as good as maildir for performance? What is the seek penalty on a large "old" file? How does it compare to the penalty of "stat()" on files in large directories, say? My suggestion is intended to save space with at least equal performance; better performance would be okay too. Len. PS If required, to meet performance needs, consider my suggestion amended to say, "one 'old' file per 5,000 old messages," and/or to say, "MUAs only scan 'old' when requested, for example when sorting ascending by date or when sorting certain date ranges." PPS Worries about atomic updates to CDB can be avoided entirely if the update is performed whenever messages move from "new" to "cur". Why index "new"? The CDB update should be triggered by the MUA, not by message delivery. -- What I find most obnoxious about the patch is that it corrupts ``bad'' messages rather than bouncing them. Let's all thank Eric Allman for adding yet another roadblock to reliable Internet communication. -- Dan Bernstein
On Sat, Jan 15, 2000 at 12:23:31AM -0800, Russ Allbery wrote: > features of Netapps (snapshots, reliability, etc.) and therefore are stuck > having to use NFS whether they like it or not. CIFS? <grin, duck and run> -- Ruben
Tracy R Reed writes: > On Fri, Jan 14, 2000 at 03:07:09PM -0500, Russell Nelson wrote: > > Right, and any scalable email system is going to use NFS. Therefore > > Why? That's based on what I've seen people use. On the other hand, I have seen NFS breakage, so I'm certainly open to new solutions. But I haven't seen any first-class solution to the problems which NFS solves: having many users, all with the same domain name, fetch mail via POP3, IMAP, or the web, delivered to that domain name. I've seen clustering solutions that don't use NFS, but they don't solve the problem outlined above, and I don't like the quality of the implementation. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
On Sat, Jan 15, 2000 at 12:23:31AM -0800, Russ Allbery wrote: > Russell Nelson <[EMAIL PROTECTED]> writes: > > Because every such installation I've ever seen has used NFS. I'm not > > talking about what's good, or what's right. I'm talking about what's > > possible to do tomorrow. Yes, it might be that a specialized mail > > transfer protocol would work better; convince Netapp to support it. > > Um, how do you think we're scaling our mail system right now? (And we > don't need Netapps to do it.) Russ, what is your definition of a "large" installation? 10k, 100k, 1m users? Just exactly how many lighter-weight servers is practical to manage and upkeep before it's cheaper to buy NetApp's? Thanks, Tim
>Why not? It seems that people are building MTA's that can already talk to >mailbox, mh folders, maildir, imap, pop3, and apop (and maybe even kerberos >auth if you're lucky). If another protocol comes along that's useful and >clearer, it'll probably catch on in the next 5 years or so. > >Where would you start? My personal opinions: 1) Integrate support for some sort of calendaring. I've run both IMAP and Exchange based environments, and for all its faults, the integrated calendaring that Exchange does is extremely useful. None of the web-based calendaring systems I've seen compare. 2) Put useful filtering in on the server, and make it easy for the client to write rules. 3) Integrate configuration info onto the server, like ACAP or IMSP tries to do. All you should need to tell your client is you username, password, and server; it'll go do the rest to the best of its abilities. 4) Allow for security (both login and traffic). This may belong at a different level, obviously. 5) Allow hooks for things. Digitial signatures, encryption, etc. etc. It isn't clear how much the protocol needs to worry about these things - they may be totally seperate - but leave room to clip them in in case they benefit from integration.
Tim Tsai <[EMAIL PROTECTED]> writes: > Russ, what is your definition of a "large" installation? 10k, 100k, 1m > users? Just exactly how many lighter-weight servers is practical to > manage and upkeep before it's cheaper to buy NetApp's? Up to about 100k; above that limit, you really want to start doing something that's a bit more custom. (You want hot failover and lots of redundant small systems that can take over from each other, which means you need heartbeat systems and the ability for a new system to come on-line automatically when the old one fails.) At that point, I personally would be looking at an EMC for storage with a bunch of machines connected to it through one of their new crossbar switches, half of which are live and half of which are hot spares. NetApps are very nice file servers; don't get me wrong. But they aren't the high end of disk storage (EMC is), and NFS, despite everything they've done with it, is still a bad way of transferring mail. If you were asking me about Usenet, then for right now I'd have a different answer. :) -- Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
On Sat, Jan 15, 2000 at 12:46:44AM -0600, Bruce Guenter wrote: > > Asynchronous is a total botch. If you want multitasking, > > then open up another TCP connection. > > This leads me to question if it would be a good idea to look at the FTP > model of opening up a secondary channel (with the option of opening more > than just one) that transfers exactly one message before closing, > leaving the initial connection available for command data? As long as the mechanics aren't done the way that ftp does it. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
Bruce Guenter writes: > - message state storage (read, replied to, forwarded, flagged, etc.) > seperate from content delivery (a "Status:" header line) I wonder if that couldn't be handled by the Maildir code writing Status: XXXXXXX as the very first line in each message? Then, you could change the status by opening the message file, read in the first N bytes, modify one of those characters to set the status, and write out those bytes again. > - explicit message size notification You get this already. > - message upload (for draft messages ... Couldn't you just send it to $USER-draft, and direct $USER-draft into a draft Maildir? > A challenge-response authentication system is a debatable need. On one > hand, with it you never send your pass phrase in the clear. On the > other, all your content is still in the clear, so it would be better to > assume a SSL link where necessary. I'd assume ssh, now that there's http://openssh.org . -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
On Sat, Jan 15, 2000 at 10:57:00PM -0500, Russell Nelson wrote: > I wonder if that couldn't be handled by the Maildir code writing > Status: XXXXXXX as the very first line in each message? Then, you > could change the status by opening the message file, read in the first > N bytes, modify one of those characters to set the status, and write > out those bytes again. Why do you need to store the message state in the message? This could easily be kept in a (lockable) file in Maildir/. All that is required is that "MUA" (e.g. IMAP, Mutt, qmail-pop3d) that use the same file agree on format and possible locking mechanism. Opening the Maildir means reading the directory, reading the state file, and marking the messages not in the state file as new, removing messages that do not exist from the state file. Safe-write the file. Skip locking if it is acceptable that the state file misses modifications if two "MUA" access the dir at the same time (no problem, IMHO). Without locking it is cheap to write the file every x seconds for a client that keeps the connection to the maildir. Delivery notifications can be done via program delivery in .qmail, causing the MUA (that maintains a connection to the maildir) to reread the directory. There is no reason for the user to notice the time this may take. Renaming the files doesn't make much sense since a consequence is that a message may still exist, but not be accessible via its old name. For very large folders over slow links, the client can display info from the state file while scanning the directory. Most likely, the only difference is a new message or two. A cdb keyed on the file name would be nice for the state file. Of course, the name and format for a state file should be defined in the Maildir format. IMHO, the "INFO" extension to the file name should be removed from the Maildir format specification. "new" -> "cur" can be used as a delivery notification. Just read "new" every whatever seconds. Move files to "cur" and add them to the cached state info. -- -Sincerely, Fred Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA
On Sat, Jan 15, 2000 at 10:57:00PM -0500, Russell Nelson wrote: > Bruce Guenter writes: > > - message state storage (read, replied to, forwarded, flagged, etc.) > > seperate from content delivery (a "Status:" header line) > > I wonder if that couldn't be handled by the Maildir code writing > Status: XXXXXXX as the very first line in each message? Um, am I missing something? I thought the whole point of the "info" portion of the filename of the message in the maildir? > > - explicit message size notification > You get this already. In what? > > - message upload (for draft messages ... > Couldn't you just send it to $USER-draft, and direct $USER-draft into > a draft Maildir? That is an option, but messy, considering that the act of delivery will cause header manipulation and IMHO saving messages should keep them intact. Another option is to do it in reverse: no direct email sending, but rather a procedure that uploads a message to a folder, and then sends that email (by some unique identifier). > > On the > > other, all your content is still in the clear, so it would be better to > > assume a SSL link where necessary. > I'd assume ssh, now that there's http://openssh.org . Good thought, especially with the tunneling options, but unless things have changed, SSH still requires shell access -- something that should not be required for mailbox access. -- Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
Actually, using ssh would obviate the need for an ftp-like second connection protocol-mess for async notification. I think you could just forward 2 connections over the already-established link. So all connections from a particular client would be guranteed to land on the same server, despite any intermediary load balancers or firewalls. Does this make sense? -Peter On Sat, Jan 15, 2000 at 10:57:00PM -0500, Russell Nelson wrote: > Bruce Guenter writes: > > - message state storage (read, replied to, forwarded, flagged, etc.) > > seperate from content delivery (a "Status:" header line) > > I wonder if that couldn't be handled by the Maildir code writing > Status: XXXXXXX as the very first line in each message? Then, you > could change the status by opening the message file, read in the first > N bytes, modify one of those characters to set the status, and write > out those bytes again. > > > - explicit message size notification > > You get this already. > > > - message upload (for draft messages ... > > Couldn't you just send it to $USER-draft, and direct $USER-draft into > a draft Maildir? > > > A challenge-response authentication system is a debatable need. On one > > hand, with it you never send your pass phrase in the clear. On the > > other, all your content is still in the clear, so it would be better to > > assume a SSL link where necessary. > > I'd assume ssh, now that there's http://openssh.org . > > -- > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com > Crynwr sells support for free software | PGPok | "Ask not what your country > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
On Sun, Jan 16, 2000 at 12:09:13AM -0600, Bruce Guenter wrote: > Good thought, especially with the tunneling options, but unless things > have changed, SSH still requires shell access -- something that should > not be required for mailbox access. Not really. It only spawns a shell because sshd's usual procedure is to invoke /bin/login as it's last action (step 10 in the sshd(8) version 1 man page). If you give the server a unique user, and that user has the server binary as it's shell... then you've saved some effort for yourself. Sshd can be very tightly restricted by an admin. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
On Sat, Jan 15, 2000 at 10:26:22PM -0800, Peter C. Norton wrote: > Not really. It only spawns a shell because sshd's usual procedure is to > invoke /bin/login as it's last action (step 10 in the sshd(8) version 1 man Sorry, I meant "emulate /bin/login" and asit's last step start a shell. > page). If you give the server a unique user, and that user has the server > binary as it's shell... then you've saved some effort for yourself. > > Sshd can be very tightly restricted by an admin. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
On Sat, Jan 15, 2000 at 10:26:22PM -0800, Peter C. Norton wrote: > > Good thought, especially with the tunneling options, but unless things > > have changed, SSH still requires shell access -- something that should > > not be required for mailbox access. > > Not really. It only spawns a shell because sshd's usual procedure is to > invoke /bin/login as it's last action (step 10 in the sshd(8) version 1 man > page). If you give the server a unique user, and that user has the server > binary as it's shell... then you've saved some effort for yourself. If I read this right, you're saying that to access a service X, the user should (through an inteligent UA that hides the details, of course) connect with SSH and log in to a user (named specifically for the protocol being exchanged) with no password? That user would then have, as a shell, a setuid-root binary (for those protocols requiring setuid capabilities) that executes the required protocol handler? This has definite advantages to it, the biggest I can see being no more magic reserved port numbers. On the downside, I have at least a small distrust for setuid binaries no matter how reliable the source. Also, the initial connection setup cost for SSH is fairly high, both in terms of wall time due to the number of exchanges required, and CPU time, from my experience. Mind you, I always use RSA authentication, which adds a second set of challenge-response exchanges. It would be interesting to compare the connection cost of SSH (as outlined above -- a user with no password running /bin/true for a shell) and SSL, both in terms of wall time (important for perceived responsiveness) and CPU cost (important for scalability). -- Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
On Sat, Jan 15, 2000 at 09:41:48AM -0600, Tim Tsai wrote: > Russ, what is your definition of a "large" installation? 10k, 100k, 1m > users? Just exactly how many lighter-weight servers is practical to > manage and upkeep before it's cheaper to buy NetApp's? As someone who has purchased and maintained a lot of NetApp hardware over the last year let me tell you that NetApp is heinously expensive. The head unit alone usually goes for around $50k. Then add disks. We have since ditched the NetApp solution and re-architected things to use clusters of PC's. We are much happier with the cost effectiveness and the reliability. Of course we aren't using them for mail but I can think of ways to distribute a large mail load on cheap PC's. -- Tracy Reed http://www.ultraviolet.org http://www.linux.org - Escape the Gates of Hell "But these are not inherent flaws in the operating system - they don't happen by accident." - Mike Nash, "Director of Microsoft's Infrastructure Systems" explaining why NT has so many patches to fix crashes caused by malicious net users.
Tracy R Reed writes: > On Wed, Jan 12, 2000 at 02:17:35AM -0500, Len Budney wrote: > > Has DUL rejection been a problem for you personally? In my own experience, > > DUL has been a pain for me. I regularly get email bounced back to me because I > send my mail from my Linux box on a PacBell DSL line. When I first saw this > happen I debated it with the admin at the ISP but eventually gave up. Go straight to the DUL people and say "I have a fixed IP address. My provider has added this address to the DUL. I promise I will not spam. Please take my address off the DUL." -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Hi, It would be nice to see a group of people start _work_ on upgrading the Maildir format as discussed in this thread -- possibly adding a CDB and multiple cur directories. If some people would actually: setup a working group, work, document your new standard, farm it around for comments, and (if your standard survives this far) help current Maildir maintainers upgrade to your new standard. People have talked about revising Maildir before. But it's been just that: talk. Now if you care about it, start work on the project. Or, if nobody wants to actually work on this, we could just have this whole thread again in another three months.... - David Harris Principal Engineer, DRH Internet Services
David Harris writes: > (if your standard survives this far) help current Maildir maintainers > upgrade to your new standard. What's the point, unless Dan indicates that he will incorporate it into the Maildir standard? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
On Sat, 15 Jan 2000, Russell Nelson wrote: > David Harris writes: > > (if your standard survives this far) help current Maildir maintainers > > upgrade to your new standard. > > What's the point, unless Dan indicates that he will incorporate it > into the Maildir standard? Oh, who needs him. I was able to add several enhancements to Maildir - folders and quotas - and implement them in three different packages, without anyone's blessing. I'm currently contemplating about the best way to implement shared folders. When I decide as to the approach, I am going to do it without wasting my time on frivolous things of this nature.
Russell Nelson [mailto:[EMAIL PROTECTED]] wrote: > What's the point, unless Dan indicates that he will incorporate it > into the Maildir standard? Dan's unwillingness to cooperate has not stopped many other enhancements from being added to the qmail package as patches. Call you enhancement Maildir-idx.. just like ezmlm-idx. If Dan had been any other open source maintainer, he would have accepted all of those people's patches back into his working pot and issued new releases based on them. He does not do this, so if you want to enhance you have kind of fork off. (Imagine if Apache was run the same way as qmail!) Thank Dan for this problem. Also, the two extensions that are being talked about: the multiple cur directories and the CDB database are things that could be gracefully added. For example, multiple cur directories and a CDB database done require patching the delivery agent: (a) the delivery agent does not mess with the cur directory anyway, and the CDB can be updated when a compliant reader comes along and discovers new messages not in the database summary. Then here is compatibility the other way: old readers can read from the Maildir without using the CDB just fine, however you run into problems with old readers if you make multiple new directories. You can weight the advantages and disadvantages of this. There are lots of interesting things that you might do to make this work. For example, perhaps define the standard so that Maildir-idx readers and delivery agents don't create the CDB unless it already exists. That way the user has to explicitly upgrade the Maildir to Maildir-idx when they want it. But you will never know if this is workable unless you start putting together some real design documents and posting them on the web (i.e. setup a working group.) - David Harris Principal Engineer, DRH Internet Services
Sam [mailto:[EMAIL PROTECTED]] wrote: > Oh, who needs him. I was able to add several enhancements to Maildir - > folders and quotas - and implement them in three different packages, > without anyone's blessing. I'm currently contemplating about the best way > to implement shared folders. When I decide as to the approach, I am going > to do it without wasting my time on frivolous things of this nature. Wouldn't it be nice if this became more than a Sam-Extension and something that was part of a Maildir-idx standard that had enough backing to get into other MTA's? A working group would help coordinate these single-developer enhancements into more of a global standard. Otherwise we are going to have Sam's extensions and soon enough someone else's extensions and they will not be compatible with each other in the way they deal with nested subfolders and each have two different quota mechanisms... and then Sam will have his quota patch for the delivery agent and someone else will have their patch for quotas on the delivery agent... it could become a mess. If Dan refuses to pick up the mantle of dealing with people's feature requests, then we need some other coordinated group to pick the mantle up... otherwise chaos may happen. I probably sound like a broken record by now. So I'll just be quiet. I've said my peace. - David Harris Principal Engineer, DRH Internet Services
I forgot to carry something to its proper conclusion.. David Harris [mailto:[EMAIL PROTECTED]] wrote: > There are lots of interesting things that you might do to make this work. > > For example, perhaps define the standard so that Maildir-idx readers and > delivery agents don't create the CDB unless it already exists. That way the > user has to explicitly upgrade the Maildir to Maildir-idx when they want it. The purpose of this little example is at follows...... if you design your standard right someone can have a Maildir-idx compliant MTA and continue to use the Maildir standard.. so when they upgrade to the next version of mutt, their system does not fall apart on them. This will help you convince MTA people to adopt your standard, as it will not break any computability - but just provide the new features for those who want to use them. OK.. Now, I'm going back to lurking - David Harris Principal Engineer, DRH Internet Services
Another stupid thing I need to say: I can just hear people saying "so, David, why don't you start up this working group if you care about this so much? humm?".. Answer is that I don't use Maildir anymore. I'm using the uw-imap MBX driver for my web/IMAP/POP only users and Mbox for my shell users. I simply don't use NFS so the big "works over NFS" advantage means nothing to me. Anyway, I'm not sure why I care about the Maildir standard anymore. :-) Now I'm reeeallly going back to lurking. :-) - David Harris Principal Engineer, DRH Internet Services
On Sat, 15 Jan 2000, David Harris wrote: > > Sam [mailto:[EMAIL PROTECTED]] wrote: > > Oh, who needs him. I was able to add several enhancements to Maildir - > > folders and quotas - and implement them in three different packages, > > without anyone's blessing. I'm currently contemplating about the best way > > to implement shared folders. When I decide as to the approach, I am going > > to do it without wasting my time on frivolous things of this nature. > > Wouldn't it be nice if this became more than a Sam-Extension and something > that was part of a Maildir-idx standard that had enough backing to get into > other MTA's? Many other MTAs support the basic Maildir. Additionally, my maildir library includes a tiny utility to deliver mail to an enhanced maildir, that can be easily incorporated into any MTA. Even Qmail: qmail-start '| /usr/local/bin/deliverquota ./Maildir' I'm not sure what will change were it deemed to be "official", whatever that means... > Otherwise we are going to have Sam's extensions and soon enough someone > else's extensions and they will not be compatible with each other in the way > they deal with nested subfolders and each have two different quota > mechanisms... and then Sam will have his quota patch for the delivery agent > and someone else will have their patch for quotas on the delivery agent... > it could become a mess. That's fine by me. Let the best implementation win. Eventually, everything will shake down to one primary implementation. > If Dan refuses to pick up the mantle of dealing with people's feature > requests, then we need some other coordinated group to pick the mantle > up... otherwise chaos may happen. Nope. Eventually Qmail will be replaced by another MTA that includes all those popular requested features.
"Olivier M." wrote: > > Hi, > > Does a such solution already exist ? It would be more pratical > and quicker to read the data directely from the maildirs as using pop or > imap protocols. > > It should be a CGI running with the mail-domain uid (well, to be able > to read and write to the maildir), and for the authentication, there > is maybe a way to use checkpassword or vmailmgrd's checkvpw? > > These are just some ideas, but maybe somebody allready programmed such > a script ? If yes, I'd be really interested to hear from you :) > > It shouldn't be really difficult to program in perl. Maybe the tricky > part would be the parsing of MIME stuff... > > Regards, > Olivier I like the idea, but it would have to store things in a way that both the POP server and an IMAP server would still be able to read from the Maildir as well.
I'me using the .rpm distribution of qmail 1.03 on a RedHat 6.1 Linux box. Before, I've used for 2 years qmail 1.02 compiled from original source in a Debian distribution. Well, QMAIL 1.03 log (now in /var/log/qmail managed by cyclog) is missing some infos. One of this is the "from" field in "info" line. With qmail 1.02 I had something like this 2000-01-15 16:13:30.960523 info msg 31318: bytes 1095 from <[EMAIL PROTECTED]> uid 101 Now with qmail 1.03 I have 2000-01-15 16:13:30.960523 info msg 31318: bytes 1095 from qp 649 uid 101 The from address is missing, now I have the process ID (?) 649. How can I have the old information: for me it's useful. Thanks --- Alessandro Ambrosini Italy [EMAIL PROTECTED]
Hi I am having some problems getting eliminate-dups(Peter Sam version) to work. I am using fastforward for aliassing. Can any one tell me how to make it part of the qmail startup scripts so I don't have to create a .qmail file for every user. Your help is really appreciated.
With qmail up and running I send a message to [EMAIL PROTECTED] The mail seems to send without problems and /var/log/qmail-smtpd/@00000947882916 shows 947887469.145793 tcpserver: status: 1/40 947887469.149571 tcpserver: pid 722 from 192.168.0.9 947887469.164402 tcpserver: ok 722 :192.168.0.3:25 :192.168.0.9:kevin:1637 947887469.205235 tcpserver: end 722 status 0 947887469.205273 tcpserver: status: 0/40 But when I look in /home/user/Maildir/new there is nothing. So I do echo to: user | /var/qmail/bin/qmail-inject and all is well What is happening here? Kevin
are there any documents on ofmipd rewrite syntax? basically i need to setup a masquerade gateway so that all mail from any of the internal unix machines passes through and rewrites [EMAIL PROTECTED] to [EMAIL PROTECTED] from the man page the only syntax i see is user to user mapping like:
# From: "Joe Shmoe" <[EMAIL PROTECTED]>
[EMAIL PROTECTED]:Joe Shmoe:[EMAIL PROTECTED]:can i do wildcarding? ie, *@*.domain.com to *@domain.com ??
any help is appreciated.
--daniel
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Daniel Leeds [EMAIL PROTECTED] http://www.hepcat.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Daniel Leeds <[EMAIL PROTECTED]> writes:> are there any documents on ofmipd rewrite syntax? basically i need to > setup a masquerade gateway so that all mail from any of the internal > unix machines passes through and rewrites [EMAIL PROTECTED] to > [EMAIL PROTECTED] from the man page the only syntax i see is user to > user mapping like: > # From: "Joe Shmoe" <[EMAIL PROTECTED]> > [EMAIL PROTECTED]:Joe Shmoe:[EMAIL PROTECTED]: > can i do wildcarding? ie, *@*.domain.com to *@domain.com ?? Have you looked at rewriting(5)? It seems to cover all this. -- Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
