deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
a) deliver binary, protocol deliver {}
b) lda binary, protocol lda {}
c) dovecot-lda binary, protocol lda {}
d) mda binary, protocol mda {}
e) dovecot-mda binary, protocol mda {}
f) something else?
In any case protocol lda {} would work for a while longer for backwards compatibility.
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
Timo Sirainen wrote:
deliver is the binary name.
a) deliver binary, protocol deliver {}
The problem I have with the deliver name in general is that there is a pre-existing LDA project[1] with the same name, and even within the scope of the Dovecot mailing list, it isn't a unique term, so it makes it harder to sift out information specific to the LDA sub-project.
c) dovecot-lda binary, protocol lda {}
This gets my vote. (Assuming "Dovecot-lda" replaces the "deliver" name in the documentation, as well.)
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
Agreed.
-Tom
On Wed, 2009-04-08 at 04:01, Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
annoying? who complains? I suspect a negligible number of people.
a) deliver binary, protocol deliver {}
changing protocol would be a huge mistake due to its current widespread use and I can envisage many many many complaints of "it stopped working" etc, lets face it, most people don't read changelogs in detail, if at all, and almost all are used in automated startups so start-up warnings are not really much use.
c) dovecot-lda binary, protocol lda {}
if you absolutely must change the binary name, then C would be my option, but be warned of the above caution for this as well.
Basically, if it aint broke, why break it?
On Wed, 2009-04-08 at 07:51 +1000, Noel Butler wrote:
On Wed, 2009-04-08 at 04:01, Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
annoying? who complains? I suspect a negligible number of people.
Me. It makes my code ugly. It makes writing to wiki difficult when you never know if you should call it deliver or lda. Basically there's no consistency, which is annoying.
a) deliver binary, protocol deliver {}
changing protocol would be a huge mistake due to its current widespread use and I can envisage many many many complaints of "it stopped working" etc, lets face it, most people don't read changelogs in detail, if at all, and almost all are used in automated startups so start-up warnings are not really much use.
My plan was to keep it working as protocol lda {} in any case for v1.x and drop it in v2.0 when there are probably going to be other configuration changes.
c) dovecot-lda binary, protocol lda {}
if you absolutely must change the binary name, then C would be my option, but be warned of the above caution for this as well.
C is beginning to sound pretty good.
<snip>
My plan was to keep it working as protocol lda {} in any case for v1.x and drop it in v2.0 when there are probably going to be other configuration changes.
Renaming it at a major version change makes the most sense since an admin will have to test and fix config files anyway.
On 4/7/2009, Timo Sirainen (tss@iki.fi) wrote:
Me. It makes my code ugly. It makes writing to wiki difficult when you never know if you should call it deliver or lda. Basically there's no consistency, which is annoying.
How about dda (dovecot delivery agent)?
--
Best regards,
Charles
On Apr 8, 2009, at 6:01 AM, Charles Marcus wrote:
On 4/7/2009, Timo Sirainen (tss@iki.fi) wrote:
Me. It makes my code ugly. It makes writing to wiki difficult when
you never know if you should call it deliver or lda. Basically there's no consistency, which is annoying.How about dda (dovecot delivery agent)?
No one's going to have any idea what that is :)
On 4/8/2009 11:16 AM, Timo Sirainen wrote:
Me. It makes my code ugly. It makes writing to wiki difficult when you never know if you should call it deliver or lda. Basically there's no consistency, which is annoying.
How about dda (dovecot delivery agent)?
No one's going to have any idea what that is :)
heh... well, they would soon enough...
Seriously though... why call it a 'local delivery agent', when its really more than that? Local suggests local/system users, and dovecot delivery agent works fine for both local and virtual users. Postfix calls its local delivery agent 'local', and its virtual delivery agent 'virtual'
:)
So, fwiw (about 2 cents, in current dollars), I'd just vote for:
dovecot-deliver binary, protocol-deliver {}...
--
Best regards,
Charles
Charles Marcus wrote:
heh... well, they would soon enough...
Seriously though... why call it a 'local delivery agent', when its really more than that? Local suggests local/system users, and dovecot delivery agent works fine for both local and virtual users. Postfix calls its local delivery agent 'local', and its virtual delivery agent 'virtual'
It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol).
I don't know postfix a lot, but I wonder why it needs two LDAs, one for real users and one for virtual ones, when the only conceptual difference should be where to store e-mails and where to lookup information on the existence of the user and his mail spool directory.
-- A lost ounce of gold may be found, a lost moment of time never.
Eduardo M KALINOWSKI eduardo@kalinowski.com.br
On 4/8/2009, Eduardo M KALINOWSKI (eduardo@kalinowski.com.br) wrote:
It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol).
But thats not the generally accepted meaning of local in context of email servers. Besides, this isn't true if you're using NFS...
--
Best regards,
Charles
Charles Marcus wrote:
On 4/8/2009, Eduardo M KALINOWSKI (eduardo@kalinowski.com.br) wrote:
It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol).
But thats not the generally accepted meaning of local in context of email servers.
I don't know what is the generally accepted, but to me virtual users are just as local as real users, they just don't have a proper account (because there is no need to).
Besides, this isn't true if you're using NFS...
Not quite... in the point of view of a program, writing to a NFS share or a filesystem in the same machine is the same thing, the program doesn't even have to know that it's storing a file in another machine. And mail is not being "transported", which would involve another MTA that would further handle the e-mail.
-- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Eduardo M KALINOWSKI eduardo@kalinowski.com.br
Eduardo M KALINOWSKI wrote:
Charles Marcus wrote:
heh... well, they would soon enough...
Seriously though... why call it a 'local delivery agent', when its really more than that? Local suggests local/system users, and dovecot delivery agent works fine for both local and virtual users. Postfix calls its local delivery agent 'local', and its virtual delivery agent 'virtual'
It's local because it stores e-mails somewhere in the local filesystem hierarchy, instead of sending it to a remote machine via SMTP (or any other protocol).
I don't know postfix a lot, but I wonder why it needs two LDAs, one for real users and one for virtual ones, when the only conceptual difference should be where to store e-mails and where to lookup information on the existence of the user and his mail spool directory.
Postfix's "local" and "virtual" exist because of specialized lookup mechanisms. Local just checks username portion of an address against the local password database, Virtual checks a configured mapping against the complete mail address.
The choice of a multi-function agent vs multiple specialized agents is a matter of preference and always a subject of debate. For a Dovecot analogy, the current incarnation of "deliver" might be split up into "deliver-mbox", "deliver-maildir", and "deliver-dbox" - although that doesn't translate fully, as the Postfix delivery agents do both mbox & maildir. I guess a better comparison would be "deliver-local", "deliver-ldap", "deliver-sql", etc.
Daniel
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
a) deliver binary, protocol deliver {}
b) lda binary, protocol lda {}
c) dovecot-lda binary, protocol lda {}
d) mda binary, protocol mda {}
e) dovecot-mda binary, protocol mda {}
f) something else?
In any case protocol lda {} would work for a while longer for backwards compatibility.
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
Having a consistent name prefix for all the processes sounds nice - but then you'd stick out as the exception to typical multi-process server names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing to deviate from accepted (poor) practices? Hmm....
Other tradeoffs...more space consumed in logfiles. More screen width consumed during listings. Not necessarily a Good Thing - not necessarily a Bad Thing. But something to ponder on.
I would also consider the Dovecot architecture. As I (mis)understand it, the "dovecot" process spawns the necessary imap, pop3, and login daemons. So having a "dovecot.conf" file for controlling these is quite appropriate. However, unless I've missed something (quite likely) - "deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to).
I like option c.
Daniel
On mer., avr 08, 2009, Daniel L. Miller wrote:
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
a) deliver binary, protocol deliver {}
b) lda binary, protocol lda {}
c) dovecot-lda binary, protocol lda {}
d) mda binary, protocol mda {}
e) dovecot-mda binary, protocol mda {}
f) something else?
In any case protocol lda {} would work for a while longer for backwards compatibility.
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
I like option c as well, however I don't like the idea of three level binary and process names dovecot-this-that. Hopefully a better solution to the imap/imap-login missing 'dovecot' will be found.
-- Eduard
On Wed, 2009-04-08 at 14:38 -0700, Daniel L. Miller wrote:
Having a consistent name prefix for all the processes sounds nice - but then you'd stick out as the exception to typical multi-process server names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing to deviate from accepted (poor) practices? Hmm....
Other tradeoffs...more space consumed in logfiles. More screen width consumed during listings. Not necessarily a Good Thing - not necessarily a Bad Thing. But something to ponder on.
No, I wouldn't write the dovecot- prefix to log files. So while the binary names would be dovecot-lda, dovecot-imap-login, etc. the logs would contain only lda(user), imap-login(user), etc.
Another thing I was thinking about previously was that in process lists they were prefixed with dovecot/. So the binary names could be lda, imap-login, etc. but they'd show up in process lists as dovecot/lda, dovecot/imap-login, etc.
I would also consider the Dovecot architecture. As I (mis)understand it, the "dovecot" process spawns the necessary imap, pop3, and login daemons. So having a "dovecot.conf" file for controlling these is quite appropriate. However, unless I've missed something (quite likely) - "deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to).
But deliver also reads dovecot.conf and inside protocol lda {} it can also override all settings from dovecot.conf. So I don't really like the idea of splitting the configuration. Also in v1.3+ the only thing that reads dovecot.conf is doveconf binary, master and deliver and everything else get their configuration from it.
Timo Sirainen wrote:
On Wed, 2009-04-08 at 14:38 -0700, Daniel L. Miller wrote:
Having a consistent name prefix for all the processes sounds nice - but then you'd stick out as the exception to typical multi-process server names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing to deviate from accepted (poor) practices? Hmm....
Other tradeoffs...more space consumed in logfiles. More screen width consumed during listings. Not necessarily a Good Thing - not necessarily a Bad Thing. But something to ponder on.
No, I wouldn't write the dovecot- prefix to log files. So while the binary names would be dovecot-lda, dovecot-imap-login, etc. the logs would contain only lda(user), imap-login(user), etc.
So the process name won't match the name in the log file? That sounds like a Bad Thing.
Another thing I was thinking about previously was that in process lists they were prefixed with dovecot/. So the binary names could be lda, imap-login, etc. but they'd show up in process lists as dovecot/lda, dovecot/imap-login, etc.
That I like.
I would also consider the Dovecot architecture. As I (mis)understand it, the "dovecot" process spawns the necessary imap, pop3, and login daemons. So having a "dovecot.conf" file for controlling these is quite appropriate. However, unless I've missed something (quite likely) - "deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to).
But deliver also reads dovecot.conf and inside protocol lda {} it can also override all settings from dovecot.conf. So I don't really like the idea of splitting the configuration. Also in v1.3+ the only thing that reads dovecot.conf is doveconf binary, master and deliver and everything else get their configuration from it.
Told you I didn't know what I was talking about!
-- Daniel
On Thu, 2009-04-09 at 08:05, Timo Sirainen wrote:
Another thing I was thinking about previously was that in process lists they were prefixed with dovecot/. So the binary names could be lda, imap-login, etc. but they'd show up in process lists as dovecot/lda, dovecot/imap-login, etc.
seems like more work for no reason, just call the binary dovecot-lda etc, makes it easier if you get someone not familiar with dovecot trying to locate it, having a temper tantrum with dovecot-lda showing up but unable to locate that binary :)
It seems most the consensus is with option C which makes most sense.
On Thu, 2009-04-09 at 08:29 +1000, Noel Butler wrote:
Another thing I was thinking about previously was that in process lists they were prefixed with dovecot/. So the binary names could be lda, imap-login, etc. but they'd show up in process lists as dovecot/lda, dovecot/imap-login, etc.
seems like more work for no reason, just call the binary dovecot-lda etc, makes it easier if you get someone not familiar with dovecot trying to locate it, having a temper tantrum with dovecot-lda showing up but unable to locate that binary :)
If I used dovecot/lda process name, then there would be $lib/dovecot/lda binary also, not dovecot-lda.
Daniel L. Miller wrote:
"deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to).
I found the combination of configuration for IMAP and LDA to be a bit unnatural as well, with little to no overlap between the two. And so I ended up splitting them up so that I could have each logging to different places (IMAP to its own file, as it doesn't relate to mail delivery), and their own base_dir.
I also created a separate init script (or more accurately, modified the stock Debian init script so that I cold symlink to it, and it would load a matching config from /etc/defaults to get the non-default config file used by deliver).
Timo Sirainen wrote:
...inside protocol lda {} it can also override all settings from dovecot.conf.
I might not have been aware of that at the time I set up deliver, or ran into complications with it. I don't recall. In any case, I prefer the logical separation. Delivery and access are related, but still quite separate functions.
-Tom
On Wed, 2009-04-08 at 19:32 -0400, Tom Metro wrote:
I found the combination of configuration for IMAP and LDA to be a bit unnatural as well, with little to no overlap between the two. And so I ended up splitting them up so that I could have each logging to different places (IMAP to its own file, as it doesn't relate to mail delivery), and their own base_dir.
deliver doesn't use base_dir at all. Anyway the main problem I see with that setup is if you change some mail-related setting you might not remember to change it in both files. This is especially bad if you change a locking related setting.
Timo Sirainen wrote:
deliver doesn't use base_dir at all.
Hmmm...looks like it came about due to needing a different authentication configuration between IMAP and deliver, which led to a different auth process and necessitated a separate base_dir. The two run directories are clearly different, and both used:
/var/run/dovecot: auth-worker.25176= dict-server= login/ master.pid
/var/run/dovecot-deliver: auth-master= auth-worker.13452= dict-server= login/ master.pid
Perhaps there's a way to do that within a single config file.
-Tom
On 4/8/2009, Tom Metro (tmetro+dovecot@vl.com) wrote:
I ended up splitting them up so that I could have each logging to different places (IMAP to its own file, as it doesn't relate to mail delivery),
I like this idea (of splitting the logging)...
Maybe this would be a good thing to be able to specify in the config file? POP, IMAP and LDA logging each to their own files...
Or, is there a simple way to do this with syslog-ng (I'm not a programmer, so be kind)?
--
Best regards,
Charles
On Thu, 09 Apr 2009, Charles Marcus wrote:
On 4/8/2009, Tom Metro (tmetro+dovecot@vl.com) wrote:
I ended up splitting them up so that I could have each logging to different places (IMAP to its own file, as it doesn't relate to mail delivery),
I like this idea (of splitting the logging)...
As do I and many others.
Maybe this would be a good thing to be able to specify in the config file? POP, IMAP and LDA logging each to their own files...
Or, is there a simple way to do this with syslog-ng (I'm not a programmer, so be kind)?
You could do this with syslog(-ng), or you could just specify the log_path and info_log_path variables in dovecot.conf. For example, in my protocol lda {} declaration, I have:
log_path = /var/log/deliver.log info_log_path = /var/log/deliver.log
Read the documentation and try something similar: http://wiki.dovecot.org/Logging
-- Sahil Tandon <sahil@tandon.net>
On 4/9/2009 7:46 AM, Sahil Tandon wrote:
I like this idea (of splitting the logging)...
As do I and many others.
You could do this with syslog(-ng), or you could just specify the log_path and info_log_path variables in dovecot.conf. For example, in my protocol lda {} declaration, I have:
log_path = /var/log/deliver.log info_log_path = /var/log/deliver.log
Read the documentation and try something similar: http://wiki.dovecot.org/Logging
Doesn't specifically mention separating out POP and IMAP... but...
Extrapolating from your example, I can I just:
protocol imap { ... log_path = /var/log/imap.log info_log_path = /var/log/imap.log } protocol pop3 { ... log_path = /var/log/pop3.log info_log_path = /var/log/pop3.log }
?
Thanks!
--
Best regards,
Charles
On Thu, 09 Apr 2009, Charles Marcus wrote:
On 4/9/2009 7:46 AM, Sahil Tandon wrote:
I like this idea (of splitting the logging)...
As do I and many others.
You could do this with syslog(-ng), or you could just specify the log_path and info_log_path variables in dovecot.conf. For example, in my protocol lda {} declaration, I have:
log_path = /var/log/deliver.log info_log_path = /var/log/deliver.log
Read the documentation and try something similar: http://wiki.dovecot.org/Logging
Doesn't specifically mention separating out POP and IMAP... but...
The documentation would quickly become cluttered if it included an example of every little iteration of each configuration variable.
Extrapolating from your example, I can I just:
protocol imap { ... log_path = /var/log/imap.log info_log_path = /var/log/imap.log } protocol pop3 { ... log_path = /var/log/pop3.log info_log_path = /var/log/pop3.log }
Seems reasonable. Try and see for yourself. And if you go this route, you may want to configure log rotation, via newsyslog(8) perhaps.
-- Sahil Tandon <sahil@tandon.net>
On Thu, 2009-04-09 at 21:57, Charles Marcus wrote:
Extrapolating from your example, I can I just:
protocol imap { ... log_path = /var/log/imap.log info_log_path = /var/log/imap.log } protocol pop3 { ... log_path = /var/log/pop3.log info_log_path = /var/log/pop3.log }
In using this as above, you can omit info_log_path entries (unless you want it to go to yet another file altogether)
On Fri, 2009-04-10 at 07:42, Noel Butler wrote:
On Thu, 2009-04-09 at 21:57, Charles Marcus wrote:
Extrapolating from your example, I can I just:
protocol imap { ... log_path = /var/log/imap.log info_log_path = /var/log/imap.log } protocol pop3 { ... log_path = /var/log/pop3.log info_log_path = /var/log/pop3.log }
In using this as above, you can omit info_log_path entries (unless you want it to go to yet another file altogether)
Actually scrap that, I don't think any of that would work, it would use first match , the imap file for everything
On Fri, 2009-04-10 at 07:57 +1000, Noel Butler wrote:
protocol imap { ... log_path = /var/log/imap.log info_log_path = /var/log/imap.log } protocol pop3 { ... log_path = /var/log/pop3.log info_log_path = /var/log/pop3.log }
In using this as above, you can omit info_log_path entries (unless you want it to go to yet another file altogether)
Actually scrap that, I don't think any of that would work, it would use first match , the imap file for everything
Yeah. That's because all logging is done via master process, which logs only to one log (and one info log). deliver however doesn't log via master, because it's executed independently.
On 4/9/2009, Timo Sirainen (tss@iki.fi) wrote:
Yeah. That's because all logging is done via master process, which logs only to one log (and one info log). deliver however doesn't log via master, because it's executed independently.
Hmmm...
Reading the Logging page on the wiki, it mentions if you don't want to use your system syslogger, you can specify different log paths...
Would it be possible to do both? For example, if I'm troubleshooting a particular problem, I might like to temporarily dump all warn and err messages from dovecot to separate files - but I'd still like these to go to my main syslogger too...
Is this possible? Or would I have to find a way to do this with syslog-ng?
Thanks,
--
Best regards,
Charles
On Fri, 2009-04-10 at 07:40 -0400, Charles Marcus wrote:
Reading the Logging page on the wiki, it mentions if you don't want to use your system syslogger, you can specify different log paths...
Would it be possible to do both? For example, if I'm troubleshooting a particular problem, I might like to temporarily dump all warn and err messages from dovecot to separate files - but I'd still like these to go to my main syslogger too...
Is this possible? Or would I have to find a way to do this with syslog-ng?
Seems more like a job for syslog-ng to me.
On 4/11/2009 10:05 PM, Timo Sirainen wrote:
Would it be possible to do both? For example, if I'm troubleshooting a particular problem, I might like to temporarily dump all warn and err messages from dovecot to separate files - but I'd still like these to go to my main syslogger too...
Is this possible? Or would I have to find a way to do this with syslog-ng?
Seems more like a job for syslog-ng to me.
Yeah, I think you're right...
Guess its time to finally learn how to really use syslog-ng...
Thanks,
--
Best regards,
Charles
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
c) dovecot-lda binary, protocol lda {}
I'm in favor of this ... outside of dovecot, explicitly saying dovecot is important, whereas inside the config file, it's implicit we're talking about Dovecot's LDA.
dovecot-lda also fits with the dovecot-auth precedent. Of course, saying "dovecot-imap-login" is getting a bit too verbose :P
-- Curtis Maloney cmaloney@cardgate.net
Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
I hope you didn't intend such a bikeshed discussion :)
c) dovecot-lda binary, protocol lda {}
This is perfectly fine.
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
Good idea.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 7 Apr 2009, Timo Sirainen wrote:
c) dovecot-lda binary, protocol lda {}
e) dovecot-mda binary, protocol mda {}
c) and e) choices also makes me think if e.g. imap and imap-login should be called dovecot-imap and dovecot-imap-login instead. People have had trouble finding them since ps|grep dovecot doesn't find them..
Yeah: "deliver" is too generic, I think. I'd prefer c) over e), but just a bit.
Currently, I symlink the Dovecot "deliver" to "dovecot-deliver", to know what deliver it is.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSd20wnWSIuGy1ktrAQKtmQf/bbNsl8aEJAI1EFpDHnAnKoDMPaLrOyRE 56yF93GMzlZWZPrNqbDalC//4kWpyNGVlJ5Ly546vdToXWFxO2YMx+uVzbMx0GOg RmWkOMajPkiqaPmUlYimbvMcbQBct1I3OsLHxcAua1ks4Tv7TT1K3Ftkj/nWo9y3 5+Y5RJH4SD/SEsWd02ydgJuMkuVGrrpjGfyjOkNfg1RUh+Dh9eUUsgLMYfnGftop cdzoxO7x7UMJdJgPgLskDaBA7wrGWYvVK2uRYcBERr9P9LGRkp5w6iWPyleMxbtH akj5z9CUCC5WeUa5ffNOJRhDjOT6rHl4b+ecu4/RLuQmTpKQm0ofMA== =k2jf -----END PGP SIGNATURE-----
On Tue, 2009-04-07 at 14:01 -0400, Timo Sirainen wrote:
deliver is the binary name. but it's configured inside protocol lda {} section. This is getting annoying, any thoughts on what would be a good unifying name?
Hmm. I just realized. Once I implement LMTP server, it needs to read the same settings as deliver. And perhaps it also needs some of its own settings?.. So I'm thinking that the whole protocol lda {} section should go away in dovecot-example.conf. Only if you truly want some settings to be read only by deliver you should add it and put stuff in there. LMTP server would also read only protocol lmtp {} section.
On Sun, 2009-04-12 at 13:45, Timo Sirainen wrote:
Hmm. I just realized. Once I implement LMTP server, it needs to read the same settings as deliver. And perhaps it also needs some of its own settings?.. So I'm thinking that the whole protocol lda {} section should go away in dovecot-example.conf.
I hope you mean just commented out, as I'd think that many would use at least
mail_plugins, quota_full_tempfail, and log_pathOn Sun, 2009-04-12 at 13:56 +1000, Noel Butler wrote:
Hmm. I just realized. Once I implement LMTP server, it needs to read the same settings as deliver. And perhaps it also needs some of its own settings?.. So I'm thinking that the whole protocol lda {} section should go away in dovecot-example.conf.
I hope you mean just commented out, as I'd think that many would use at least
mail_plugins, quota_full_tempfail, and log_path
mail_plugins is actually an exception, that would still be in protocol lda{}. Already did the change, see: http://hg.dovecot.org/dovecot-1.3/file/tip/dovecot-example.conf
On Sun, 2009-04-12 at 14:08, Timo Sirainen wrote:
On Sun, 2009-04-12 at 13:56 +1000, Noel Butler wrote:
Hmm. I just realized. Once I implement LMTP server, it needs to read the same settings as deliver. And perhaps it also needs some of its own settings?.. So I'm thinking that the whole protocol lda {} section should go away in dovecot-example.conf.
I hope you mean just commented out, as I'd think that many would use at least
mail_plugins, quota_full_tempfail, and log_pathmail_plugins is actually an exception, that would still be in protocol lda{}. Already did the change, see: http://hg.dovecot.org/dovecot-1.3/file/tip/dovecot-example.conf
Looks good.
participants (14)
-
Charles Marcus
-
Curtis Maloney
-
Daniel L. Miller
-
dovecotlist＠encambio.com
-
Eduardo M KALINOWSKI
-
Jakob Hirsch
-
Jonathan
-
Noel Butler
-
Roderick A. Anderson
-
Sahil Tandon
-
Scott Silva
-
Steffen Kaiser
-
Timo Sirainen
-
Tom Metro