Re: [Dovecot] What best decision to make for flatfiles or SQL when I use Dovecot2 + Postfix together?
On 28.09.2011, at 00:14, terryjames9...@mm.st wrote: > Hello Patrick, > > On Tuesday, September 27, 2011 6:06 PM, "Patrick Domack" > wrote: >> Using dovecot lda/lmtp you remove all postfix needs to know mailbox >> name to directory mapping, that would be duplicated. > > With using the Dovecot lmtp option, where does Postfix know to refuse > email for a non-existing user or domain? That also has to be shared? I wondered that as well, and unfortunately the Howto doesn't explain the concept it builds upon. But I found it: it uses LMTP and recipient verification (see reject_unverified_recipient in smtpd_recipient_restictions). See http://www.postfix.org/ADDRESS_VERIFICATION_README.html for details. Rainer
[Dovecot] Authentication listener configuration
Hi,
I'm wondering about the authentication listeners that dovecot uses. In many
configurations I see:
service auth {
unix_listener auth-userdb {
Does any component of dovecot use this listener internally (lmtp, lda ...) and
does that read the config and search for the listener, or is the exact name
"auth-userdb" expected? Is this maybe dependent on the userdb? Which ones need
it? And if I want to use postfix SMTP auth, should I define a second listener,
or just re-configure that default one to postfix's needs?
Also, in which cases do I need to define an auth-worker service, and a
unix_listener for it?
I don't find this in the documentation, if that's caused by my lacking search
skills, please just send apointer.
Thanks
Rainer
Re: [Dovecot] Authentication listener configuration
On 29.11.2011, at 08:19, Rainer Frey wrote:
> Hi,
>
> I'm wondering about the authentication listeners that dovecot uses. In many
> configurations I see:
> service auth {
> unix_listener auth-userdb {
>
> Does any component of dovecot use this listener internally (lmtp, lda ...)
> and does that read the config and search for the listener, or is the exact
> name "auth-userdb" expected? Is this maybe dependent on the userdb? Which
> ones need it? And if I want to use postfix SMTP auth, should I define a
> second listener, or just re-configure that default one to postfix's needs?
I mean, specifically if I use ldaand/or lmtp as well ...
Thanks
Rainer
Re: [Dovecot] Authentication listener configuration
> On 29.11.2011, at 08:19, Rainer Frey wrote:
>> I'm wondering about the authentication listeners that dovecot uses. In many
>> configurations I see:
>> service auth {
>> unix_listener auth-userdb {
>>
>> Does any component of dovecot use this listener internally (lmtp, lda ...)
>> and does that read the config and search for the listener, or is the exact
>> name "auth-userdb" expected? Is this maybe dependent on the userdb? Which
>> ones need it? And if I want to use postfix SMTP auth, should I define a
>> second listener, or just re-configure that default one to postfix's needs?
>
> I mean, specifically if I use lda and/or lmtp as well ...
Sorry for the noise, found it commented in the example configuration - it's
configured in auth_socket_path. I didn't have a dovecot installation handy, so
I only looked online. For dovecot 1.x, the wiki contains the full configuration
file with all comments. Couldn't anything like that be done for 2.x as well
(even though it's more complicated)?
Rainer
Re: [Dovecot] sysconfdir depreacted
On Mar 23, 2012, at 10:51 AM, Timo Sirainen wrote: >>> :2012-03-22T11:55:Noel Butler: >>> perhaps it should be renamed then, given it violates the known normal for SYSCONF dir, you've just created another form of --datadir >>> >>> Not really. The way I see it works as expected. >> >>The directory for installing read-only data files that pertain >>to a single machine–that is to say, files for configuring a >>host. Mailer and network configuration files, ‘/etc/passwd’, and >>so forth belong here. All the files in this directory should be >>ordinary ASCII text files. This directory should normally be >>‘/usr/local/etc’, but write it as ‘$(prefix)/etc’. (If you are >>using Autoconf, write it as ‘@sysconfdir@’.) Well, I don't see that that prevents organizing the files in sysconfdir into a subdirectory. > ton of software installs into /etc// directory. [...] > So the only way I can think of how to change this is to add another option to > optionally remove the dovecot/ suffix from the directory, but is this really > worth the trouble? I really don't think so. What for? Nobody has shown a real-world problem with that subdirectory.
Re: [Dovecot] POP3 vs. IMAP Load/Memory usage in Dovecot 1.0.15
On 11.07.2011, at 17:03, Stan Hoeppner wrote: > The R410 is a two socket Xeon box with max 2 x 6 core CPUs. The 24 CPUs > you see is the result of HyperThreading being enabled. I'd disable HT > if I were you, or those boxen mine. Why? Rainer
Re: [Dovecot] best choice of user database file to work with postfix?
On Wednesday 21 April 2010 21:30:12 Thomas Leuxner wrote:
> I'm running a setup that should be good enough for what you are trying to
> achieve. All user information is stored in flat files per domain and you
> may override per user settings individually:
>
> passdb {
> args = username_format=%u /var/vmail/auth.d/%d/passwd
> driver = passwd-file
> }
>
> userdb {
> args = username_format=%u /var/vmail/auth.d/%d/passwd
> driver = passwd-file
> }
>
> $ cat passwd
> u...@domain.tld:{scheme}:5000:5000::/var/vmail/domain.tld/user::u
> serdb_quota_rule=*:storage=5G userdb_acl_groups=PublicMailboxAdmins
[...]
> See how aliases are used for routing and to authenticate valid mail from
> senders with one file:
>
> $ cat virtual
> al...@domain.tldlo...@domain.tld
> postmas...@domain.tld lo...@domain.tld
>
> [main.cf]
> virtual_mailbox_domains = domain.tld, domain1.tld
> virtual_mailbox_base = /var/vmail
> virtual_minimum_uid = 100
> virtual_uid_maps = static:5000
> virtual_gid_maps = static:5000
> virtual_alias_maps = hash:/etc/postfix/virtual
> virtual_transport = lmtp:unix:private/dovecot-lmtp
What I don't see here at all (and neither in your Wiki Howto) is how Postfix
determines the valid recipients for the domains in virtual_mailbox_domains.
The correct parameter would be virtual_mailbox_maps, but AFAIK there is no
lookup table that read the passwd format from an arbitrary file. So a script
that generates a hash/whatever postfix lookup file from the passwd-files would
still be necessary.
Or do you use recipient validation via LMTP? (I didn't notice a
reject_unverified_recipient though) This at least won't work with deliver, I'm
not even sure about LMTP.
> Regards
> Thomas
Rainer
Re: [Dovecot] best choice of user database file to wor k with postfix?
Please honour the Reply-To header next time. Thanks.
On Thursday 22 April 2010 11:42:01 Thomas Leuxner wrote:
> On Thu, Apr 22, 2010 at 11:18:09AM +0200, Rainer Frey wrote:
> > What I don't see here at all (and neither in your Wiki Howto) is how
> > Postfix determines the valid recipients for the domains in
> > virtual_mailbox_domains.
>
> Postfix will expand possible aliases first and determine the final
> recipient handing over to Dovecot:
>
> > > $ cat virtual
> > > al...@domain.tldlo...@domain.tld
> > > postmas...@domain.tld lo...@domain.tld
> > >
> virtual_alias_maps = hash:/etc/postfix/virtual
Do you define all valid recipients there (e.g. in you example virtual file
lo...@domain.tld)?
> It will query the recipients by connecting to the socket in its
> chroot provided by Dovecot:
>
> service auth {
This is wrong. The auth service is not queried for recipient, only for valid
SASL users (that connect to the submission service as *senders*). I'm talking
about determining valid *recipients* for the virtual_mailbox_domains.
[...]
> Once it has the homedir it will send it off via LMTP or deliver,
> whichever you configured via:
>
> virtual_transport = lmtp:unix:private/dovecot-lmtp
> or
> virtual_transport = dovecot
But this is at the delivery stage, when the mail has already been accepted.
This means, if no homedir/mailbox is found, bounce mails are sent, to
potentially forged senders. That is backscatter.
> > The correct parameter would be virtual_mailbox_maps, but AFAIK there is
> > no lookup table that read the passwd format from an arbitrary file. So a
> > script that generates a hash/whatever postfix lookup file from the
> > passwd-files would still be necessary.
>
> There is no such thing as a correct parameter from my perspective. I did
> not say that alias creation was to be unified/automated.
I'm not talking about aliases, I'm talking about recipient addresses of
virtual mailboxes. You need to verify whether a mailbox exists for a recipient
address in the SMTP server before accepting the message.
> Instead I said I
> did not even think this is good practice to me. Anyone with at least a bit
> of sed/awk knowledge can kludge it from the flat-files anyway.
Indeed, but you offered the original poster your solution as one that "should
be good enough for what you are trying to achieve", but your solution leaves
out the aspect of the valid recipient list for the virtual mailbox domain
address class.
> > Or do you use recipient validation via LMTP? (I didn't notice a
> > reject_unverified_recipient though) This at least won't work with
> > deliver, I'm not even sure about LMTP.
>
> This is not required in the example and optional at least:
Of course, but it would be a viable alternative to a lookup table for the
recipients.
Rainer
Re: [Dovecot] best choice of user database file to work with postfix?
On Thursday 22 April 2010 15:34:40 Phil Howard wrote: > So what would local_recipient_maps look like in this case? As the suggested setup uses virtual_mailbox_domains for the mailboxes hosted by dovecot, it would be virtual_mailbox_maps. Alternatively one could define relay_domains, relay_transport and relay_recipient_maps. local_recipient_maps is for use with mydestination and system (/etc/passwd) users only. But this aspect is indeed missing in Thomas' suggestion. > At this point, > I don't understand what is happening for this. I would be expecting > Postfix to be asking Dovecot if a user is valid. This is not directly possible as there is no postfix lookup table that can query any protocol that dovecot speaks. Neither is there one for the passwd- file format. Instead of a lookup table one could theoretically use reject_unverified_recipient as described in the Postfix ADDRESS_VERIFICATION_README but I don't know if it works with any non-SMTP transport for the destination domain. I can't tell from the first reading, and have no time to explore that. Otherwise there's no choice but to generate a hash/btree/cdb file from the dovecot passwd-files for use in virtual_mailbox_maps. > > > mailbox_command = /usr/lib/dovecot/deliver > > > > > > in Postfix main.cf. Is that workable instead of "virtual_transport = > > > lmtp:unix:private/dovecot-lmtp" Or would running LMTP be a better way? If you can't wait for Dovecot 2.0, you need to use dovecot deliver, but you should set it up as a pipe transport in master - see http://wiki.dovecot.org/LDA/Postfix for virtual users. mailbox_command again is for real system users only. Rainer
Re: [Dovecot] best choice of user database file to work with postfix?
On Thursday 22 April 2010 18:15:18 Phil Howard wrote: [ ... all standard stuff that is well documented ... ] > 5. Passwords stored encrypted, such as MD5. And it should be a scheme > that both Postfix and Dovecot can use so I don't have keep two different > encryption schemes. Postfix doesn't need any password directly. It only authenticates a user with a password in one case: SMTP SASL authentication of submission users, and it uses the dovecot auth service for that and does not read the password database itself. > 6. I'd prefer not to, but it looks like I will have to copy data from one > format to another format so Dovecot can read it and Postfix can read it. I > will most likely be using the CDB format (the constant database file format > from Dan Bernstein ... which I'd think should be easy enough for a future > version of Dovecot to support). It is not about supporting a certain database library. There is simply a difference in what Dovecot and Postfix need from a user/recipient database. Dovecot needs information like path to mailbox, uid/gid with which to put files into the mailboxes, extra configuration fields ... Therefore it uses a structured multi-value format like the passwd-file. CDB or similar don't work like this, so dovecot can't easily support using the same CDB files as postfix. Postfix only supports name:value tables, either to use the value (table-style lookup) or to check whether there is an entry for a name (list-style lookup). Therefore it only uses file databases with such a mapping. In the case of valid recipients which will be handed off to dovecot for delivery, it is such a simple list lookup. (If it interests you: the postfix virtual delivery agent needs very similar information to dovecot, but it uses several key:value maps for the different information, all with the recipient as key.) > 7. I am wondering if I can trick Postfix into reading virtual user info by > running it chrooted where I substitute /etc/passwd and /etc/shadow with > stuff I generate from Dovecot files. If you need to generate the files that postfix uses, you can generate supported lookup table formats as well. Rainer
Re: [Dovecot] Dovecot aspects of fighting spam
On Tuesday 01 June 2010 15:42:18 Phil Howard wrote: > I see no documents in the Dovecot documents wiki on how Dovecot > features can be used in the fight against spam. One hit came up in a > search, and it was about how to fight spam in the MoinMoin Wiki itself > (e.g. TextCHAs and such). I guess you'll have the mental transfer of "fight spam" into "cause dovecot to perform this and that action" yourself. The possible actions are, in general, documented. > I already asked in another thread about removing message files at the > search from a designated "learn-spam" folder. My next question would > be how to automatically place detected spam into a specific folder for > the user to access or ignore as they deem fit. You need to configure the MTA to accept and tag spam messages, e.g. with Amavis D_PASS policy and appropriate tag levels. Then the most flexible way to put the mails into a spam folder is to use the deliver plugin for sieve, which can sort and filter mails depending on many different conditions, like presence and/or value of any header. You can deploy a single system wide default script for all users, which can be complemented or overwritten by individual users (depending on configuration). See http://wiki.dovecot.org/LDA/Sieve If you use dovecot 1.2, using the new Dovecot Sieve plugin is highly recommended above the old CMUsieve. See http://wiki.dovecot.org/LDA/Sieve/Dovecot The really recommended way nowadays is different though: *reject* as much spam as possible in the MTA in the receiving SMTP dialog, with a combination of blacklists, sender validation (e.g.DKIM), potentially greylisting (as you deem appropriate) and lastly content scanning with s.th. like amavis+spamassassin. I'd not expect a noticable amount of false positives, and in the rare cases the sender will be notified. The false positives rate of users scanning through a folder of tagged mail will be higher. > A wiki document on how Dovecot helps (or how to help Dovecot) in the > fight against spam, I think, would be helpful. A howto-like page to describe the usage of some dovecot features in an anti- spam context wouldn't hurt, OTOH there is not much anti-spam specific stuff at all at the dovecot side. Rainer
Re: [Dovecot] Sieve GUI
On Tuesday 01 June 2010 20:10:08 Phil Howard wrote: > Looks like I will need to do a lot of reading on Sieve and ManageSieve > to be sure it's safe. For one thing, I want to turn the vacation > feature off unless it can cross check a list of valid senders (user > contacts). No need to turn it off. It is not "turned on", unless you put the directives for it in a script. Rainer
Re: [Dovecot] Sieve GUI
On Tuesday 01 June 2010 20:55:52 Phil Howard wrote: > wrote: > > On 6/1/10 2:10 PM -0400 Phil Howard wrote: > >> On Tue, Jun 1, 2010 at 13:42, e-frog wrote: > >>> This might be helpful: > >>> > >>> http://wiki.dovecot.org/ManageSieve/ > >> > >> Right now only time for a quick look. Looks like yet another server > >> with yet another protocol (via port 4190), rather than integrated into > >> IMAP as an extension. I'm doubting all my email clients have support > >> for this. > > > > You're wrong on it being another server; it does work within IMAP. It is integrated into dovecot (once patched) and does not need to be managed as a separate daemon on the server. But it is a separate protocol on a different port (traditional default: 2000). > In the mean time, I just need a short term solution to divert tagged-as-spam > messages into the INBOX-spam (or something like that) folder. I'll > probably just go ahead and write a shim program in C (as easy for me > as a script is for others) to check for the tag and add the -m option > to deliver as needed. This is absolutely unnecessary. Sieve can be used without letting the users manage their own scripts. There can be a system wide default script. Rainer
Re: [Dovecot] Dovecot aspects of fighting spam
On Tuesday 01 June 2010 17:01:16 Phil Howard wrote: > On Tue, Jun 1, 2010 at 10:45, Rainer Frey wrote: > > I guess you'll have the mental transfer of "fight spam" into "cause > > dovecot to perform this and that action" yourself. The possible actions > > are, in general, documented. > > I cannot determine how deliver with an empty string give to -m would > behave. This is just what I mean: the behavior of deliver -m has absolutely nothing to do with fighting spam. It is the same whether you want to use it for spam- tagged mails or any other reason. Therefore you'll not find the description in thedovecot wiki bysearching for "fighting spam". You'll find it by searching for "deliver" (or LDA). > OK, so a delivery-time sieve. Yes, sieve is mostly (with dovecot: only) used at delivery time (Cyrus IMAP might have support for applying sieve scripts with IMAP, but if so, it is an exception). > > > See http://wiki.dovecot.org/LDA/Sieve > > If you use dovecot 1.2, using the new Dovecot Sieve plugin is highly > > recommended above the old CMUsieve. > > See http://wiki.dovecot.org/LDA/Sieve/Dovecot > > Ubuntu has me at Dovecot version 1.1.11. Then you need to read http://wiki.dovecot.org/LDA/Sieve/CMU It is quite sufficient for your current needs - though I'd upgrade in the long run. CMUSieve (and ManageSieve) are already integrated in the package. > Ubuntu has turned out to be > difficult for managing upgrades when packages it has are instead > compiled from source. This is not my experience. Esp. dovecot and postfix are easily managed from source. Installing the package 'build-essential' and then 'aptitude build-dep dovecot' should provide all you need to compile and install dovecot from source (which is documented in the wiki). Also there is an unsupported archive with current dovecot packages, but AFAIK those are build from source releases instead of daily snapshot (and should thus be quite stable: > I've had periodic high FPs with content detection in the past (on > other mail servers I didn't control). This is why I recommended a combination of different measures. Content detection should come in last in that list, but still can be done at SMTP time (esp. with latest postfix and amavisd-new). Rainer
Re: [Dovecot] Home directories
On Tuesday 24 August 2010 16:57:23 Timo Sirainen wrote: > I've noticed that a lot of people are using e.g.: > > mail_location = maildir:/var/vmail/%d/%n > > Then either they don't have home directory set, or their home directory > is the same as the maildir. http://wiki.dovecot.org/VirtualUsers/Home > explains all the problems of not separate home and mail directories. So all it takes is reading and understanding this short piece of text. Should be manageable by someone who attempts to operate a mail server. > > Also whenever I try to suggest using a separate home and mail directory, > the answer is way too often: "But I'm using virtual users. (They don't > have home directories.)" > > So I started wondering. Maybe simply renaming the "home" to something > else would help here at least some. OTOH you'd need to make distinction between system and virtual users in docs everywhere home is used, like: "mail_location: relative paths are based on $home for system users, and on $vhome for virtual users." IMHO a home dir is a valid and understandable concept for virtual users, and I see more disadvantages than advantages if you change the name. Rainer
[Dovecot] LMTP logging configuration
Hi,
I'm using Dovecot 2.0.1, and I log to a custom syslog facility (local0) in the
main configuration (I want a separate log file, but I want to make use of
rsyslogd's capabilities). I overwrite the syslog facility for LDA (mail) to
have all delivery related stuff in /var/log/mail.log, and that works fine.
I tried to do the same for LMTP with
protocol lmtp {
syslog_facility = mail
}
but this has no effect, LMTP logs to local0. Is this supposed to work, or is
this not implemented at all? If not, is using a logfile in main config, but
syslog in lmtp supported?
Thanks
Rainer
Re: [Dovecot] LMTP logging configuration
On Tuesday 07 September 2010 16:21:35 Timo Sirainen wrote:
> On Tue, 2010-09-07 at 09:23 +0200, Rainer Frey wrote:
> > protocol lmtp {
> >
> > syslog_facility = mail
> >
> > }
> >
> > but this has no effect, LMTP logs to local0. Is this supposed to work, or
> > is this not implemented at all? If not, is using a logfile in main
> > config, but syslog in lmtp supported?
>
> The problem is that all logging goes through log process, which
> currently only supports a single logging destination. But .. I think you
> can make lmtp processes bypass log process by setting:
>
> service lmtp {
> executable = lmtp -L
> }
This has no effect (logging still with global syslog_facility). Thanks anyway
for your assistance. This is a very minor issue for me.
Rainer
Re: [Dovecot] LMTP logging configuration
On Wednesday 08 September 2010 16:11:43 Timo Sirainen wrote:
> On Wed, 2010-09-08 at 14:00 +0200, Rainer Frey wrote:
> > > The problem is that all logging goes through log process, which
> > > currently only supports a single logging destination. But .. I think
> > > you can make lmtp processes bypass log process by setting:
> > >
> > > service lmtp {
> > >
> > > executable = lmtp -L
> > >
> > > }
> >
> > This has no effect (logging still with global syslog_facility). Thanks
> > anyway for your assistance. This is a very minor issue for me.
>
> Looks like there was a bug. Fixed:
> http://hg.dovecot.org/dovecot-2.0/rev/7fef89fea00e
Indeed. Works now with 2.0.2. Thanks.
Rainer
[Dovecot] Location of sieve_global_dir setting
Hi, I'm a bit confused by the Wiki. Do the settings "sieve_dir" and "sieve_global_dir" belong to the lda or the plugin section (Dovecot 1.1.11)? Thanks Rainer
Re: [Dovecot] user unknown with deliver
On Thursday 16 July 2009 15:38:25 Nikolay Shopik wrote:
> Charles Marcus wrote:
> > On 7/16/2009 9:16 AM, Nikolay Shopik wrote:
> >> I'm using GMAIL style saving sent items automatically, so email don't
> >> send twice to server. First when sending via smtp, second when MUA
> >> saving it to IMAP sent folder.
> >
> > Hmmm... interesting idea...
> >
> > Are you having trouble with a working config after an upgrade? Or are
> > you still in the process of trying to get it to work?
>
> Well its working if email address and authentication name are same and I
> use such command line:
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender}
> -m Sent
Are the failing users actually authenticated, or maybe permitted by
mynetworks? in this case ${sasl_username} would be empty.
Other thought: how is the transport used? Perhaps postfix needs a valid
recipient map for the delivery to this transport.
> I can't say its Dovecot problem, I'm just curious if that problem of
> Dovecot or I should post this to Postfix mailing list.
I guess it needs to be fixed in postfix configuration.
Rainer
Re: [Dovecot] Dovecot Versions and Debian
On Monday 27 July 2009 16:21:53 Stephan Bosch wrote: > > or Use any of the packages from: > > Dovecot v1.2 for Debian Testing (binary and source): > > > > deb http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main > > deb-src http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main > > - > >- > > As the WIKI states: do *NOT* use these packages for systems that need to > be *STABLE*! This is rebuilt every hour from repository commits from > Timo and myself and if/when one of us commits a mistake, your setup will > break accordingly upon upgrade. This is for testing purposes only. Do you think the source packages could be adapted to build a stable release source tarball without much modification? Would it make sense to hast that somewhere? > Regards, > > Stephan Rainer
Re: [Dovecot] v2.0 configuration parsing
On Monday 10 August 2009 19:57:53 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".
I generally prefer the "most specific rule wins". If that is not the case, it
should not be possible to specify the same configuration within containers of
different scope. It is not intuitive to have a value in a restricted scope
and in a more general scope, and there are situations when the general value
is used even though the specifiv scope
> 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
> }
This one is easy. It should be foo in any case :-)
Protocol sections that are more specific are an existing and coarse-granular
concept, and AFAIk now it doesn't matter whether the protocol section is
before or after the general setting. This concept should in any case be
retained.
> 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?
Perhaps this should be invalid.
Rainer
[Dovecot] Deliver and file system quota
Hi, what is the quota plugin for deliver supposed to do when using fs quota? With IMAP, and not using noenforcing, a user that is over Soft limit can't copy mails. With deliver, the mail is delivered normally. When hard limit is exceeded, there is an error "rejected: Not enough disk space", just like when I don't use the plugin in lda. Even the lda setting "quota_full_tempfail = yes" works without the plugin configured in lda section. So is there any effect of the quota plugin in lda with file system quota? Thanks Rainer
Re: [Dovecot] Client with SSL client cert support?
On Thursday 19 April 2007 02:23:46 Peter Abrahamsen wrote: > Good day, all, > > I've gleaned that dovecot has support for verifying SSL client certs on > connect. What IMAP clients have people found that support sending a > specific SSL cert? I can't find this feature in Thunderbird, at least. Thunderbird will send a client certificate if there is one in its certificate manager (probably with an email address matching the account address) and the server asks for it. There seems to be no way to configure this though. > Thanks, > > Peter Rainer -- SOFTWARE DEVELOPMENT -- Inxmail GmbH Kaiser-Joseph-Str. 274, 79098 Freiburg, Germany Tel +49 (0)761 29 69 79-0 Fax +49 (0)761 29 69 79-9 Web http://www.inxmail.de Handelsregister Freiburg, HRB 5870 USt-Id DE198371679 Geschäftsleitung Martin Bucher, Peter Ziras NEU: Inxmail Professional 3.5! Jetzt kostenlosen Testzugang anfordern: http://www.inxmail.de/de/produkte-leistungen/unverbindlich-testen.php
Re: [Dovecot] client certs with godaddy ssl cert
On Saturday 27 September 2008 03:43:19 Harondel J. Sibble wrote: > I've read the client ssl cert section in the wiki and it talks about using > a self signed cert, if I am using a commercial cert, in this case godaddy, > how do I implement a self signed cert for the client side and have dovecot > make use of this? I know the mechanics of setting up the self signed ca, > the question is more what configuration changes do I need to make in > dovecot to handle both godaddy and the self signed ca functionality? If I understand you correctly, you're using the godaddy certificate as the server certificate only. This is fine, AFAIK the server certificate can be completely independent from any client certificate. What is important: you can not self-sign each client certificate, but you need a CA with a self-signed root instead. I think you understand that already, just noting that for completeness. Then you simply configure Dovecot as described in http://wiki.dovecot.org/SSL/DovecotConfiguration In short: Put your godaddy SSl certificate, and then the complete hierachy of godaddy CA certificates (I don't know how many levels they have) in (e.g.) /etc/ssl/dovecot.pem, and set ssl_cert_file=/etc/ssl/dovecot.pem. Don't forget to set the path to your private key or add it to the beginning of your cert file. This handles SSL/TLS for the server. Then create the CA root certificate, and any sub-CA certificates if you want to implement a multi-level CA. For each hierarchy level generate a CRL (Certificate Revocation List). Then, from the most specific sub-CA down to the root, concatenate each CA cert and the corresponding CRL to one file, and set this file as ssl_ca_file. The order is important, and needs to be (if existing): * Issuing CA cert * issuing CA crl * Intermediate CA cert * intermediate CA crl * Root CA cert * Root CA crl Then configure client cert verification as described in the last section of above mentioned wiki page. To sum it up: ssl_cert_file is responsible for server side TLS/SSL and needs to contain the complete verification path for the server certificate. It has no influence on client certs. ssl_ca_file is used for client cert verification only, and does not need to cover the server certificate. So you can use commercial server cert and the self-managed client certs. You might want to consider though: your clients need to import the client cert you issue, and your root CA certificate as trusted cert. If *all your SSL/TLS clients* also get a client cert, you can also issue the server cert yourself, a commercial cert provides no extra value in that case. > Thanks Regards Rainer Frey -- Software Developer -- Inxmail GmbH [EMAIL PROTECTED], www.inxmail.de Handelsregister Freiburg, HRB 5870 Ust.-ID: DE198371679 Geschäftsleitung: Martin Bucher, Peter Ziras
Re: [Dovecot] best choice of user database file to wor k with?postfix?
On Thursday 22 April 2010 16:36:33 Thomas Leuxner wrote: > On Thu, Apr 22, 2010 at 01:12:24PM +0200, Rainer Frey wrote: > > Do you define all valid recipients there (e.g. in you example virtual > > file lo...@domain.tld)? > > Yes. So a valid recipient must be in the passwd file and in the postfix virtual alias file? This does not solve the problem of using the same flat-file user database between doevecot and postfix, and of course int that case you can define a virtual_mailbox_map as well, which works well (no kludge like aliasing an address to itself to terminate recursive alias expansion) and is semantically correct. > > But this is at the delivery stage, when the mail has already been > > accepted. This means, if no homedir/mailbox is found, bounce mails are > > sent, to potentially forged senders. That is backscatter. > > > > I'm not talking about aliases, I'm talking about recipient addresses of > > virtual mailboxes. You need to verify whether a mailbox exists for a > > recipient address in the SMTP server before accepting the message. > > Possibly. No, not possibly, but most definitely. Causing backscatter is not acceptable and leads to the server being blacklisted at some sites. > But this could then be fixed by adding another recipient > restriction, is that what is bothering you? But what recipient restriction? There's only: * reject_unlisted_recipient, which needs a non-empty recipient lookup map for the domain class * reject_unverified_recipient, the address verification mentioned below * check_recipient_access, which again needs a postfix lookup table with valid recipients. > > Indeed, but you offered the original poster your solution as one that > > "should be good enough for what you are trying to achieve", but your > > solution leaves out the aspect of the valid recipient list for the > > virtual mailbox domain address class. > > This was not meant to say this is the ultimate one and only solution. > See for recipient_restrictions esspecially, everyone may have different > needs. But at least someone *may* a starting point. Feel free to refine > the setup. Well, it leaves out the *one tricky part* of using a flat file database for virtual users with dovecot and postfix: there is no common format that both understand directly. [ This quotation is missing the doubt whether postfix address verification works with LMTP (or even pipe) ] > > Of course, but it would be a viable alternative to a lookup table for the > > recipients. > > Will look into it, but maybe you can add your thoughts how you would do. If it works, it is a good alternative that is used in similar setups, although mostly with relay_domains and servers like Exchange that speak SMTP. The ADDRESS_VERIFICATION_README details the limitations and drawbacks > Thomas Rainer
Re: [Dovecot] v2.0 configuration parsing
On Tuesday 11 August 2009 15:32:42 Matthijs Kooijman wrote:
> > > 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
> > > }
> >
> > This one is easy. It should be foo in any case :-)
>
> Why? /24 is more specific than /16, but protocol imap is more specific than
> (implicit) protocol any. I assume this is why Timo included this example.
You are right, and I left out half of my thoughts. I think there should be
only a coarse grained concept of "more specific rules" - e.g. a protocol
section is more specific than general config, and a local or remote IP
restriction is more specific than a protocol section. I think that the values
of these context selectors should not define "more specific". Within one of
these levels, either conflicting settings should be invalid, or maybe better
yet, a "last wins" rule should apply.
> Gr.
>
> Matthijs
Rainer
