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
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
