Re: Can I encrypt already existant unencrypted mail before I start using the mail-crypt plugin?
On Tuesday, February 21st, 2023 at 09:54, Aki Tuomi wrote: > > On 16/02/2023 07:18 EET mailinglist-subscriptions > > mailinglist-subscripti...@protonmail.com wrote: > > > > Hi, > > > > I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for > > managing virtual accounts. > > > > I'd like to start using the mail-crypt plugin. However, I'm having a bit > > some difficulty understanding the documentation at > > > > https://doc.dovecot.org/configuration_manual/mail_crypt_plugin > > > > to reach my goal. I plan to ask questions about those issues by starting > > new threads in this mailing list. But before I even come to that, I'd like > > to investigate the following: > > > > The above documentation only addresses a clean install and doesn't seem to > > mention encrypting already existent unencrypted mails, like my server has. > > Is it possible to encrypt those before I start using the mail-crypt plugin, > > such that it will be able to decrypt those messages as well? > > > > If it is, I am assuming that how I would go about achieving that will be > > very dependent on the ultimate configuration I have in mind (pub/priv keys, > > etc.). So I don't expect a full-fledged guide. However, if you could > > perhaps give a general overview of what would be needed to achieve this, I > > would very much appreciate that. > > > > Thank you. > > > It will be easiest to do migration to new server, then the data will get > encrypted while migrating. It is possible to write a script to do this, but > will be much more hassle than migration. > > You might even be able to do it for one user at a time, by doing migration > from maildir to maildir and then moving the new maildir over the old one. > > Aki Thanks for the suggestion. However, migrating sounds like quite the hassle as well. Now, I have next to no knowledge about the synchronization workings of IMAP, so perhaps this is totally infeasible, but could the following work? - Preface I am the only user of the mail server, with one virtual catch-all account for each domain I own. I access these accounts with Thunderbird. - Solution I make a backup of all mail in my Thunderbird accounts. Then I either delete all mails from within Thunderbird, or on the server. Then I configure the mail-crypt plugin. And then I import all backup mails and folders into my Thunderbird accounts again? Could that work? Or would that mess up the synchronization history (message IDs and what not)? And most importantly, if it actually could work, would the messages be properly encrypted then?
Re: Can I encrypt already existant unencrypted mail before I start using the mail-crypt plugin?
Thanks for the link. That sounds like the most hassle-free approach for me (since I don't have much mail yet). I think I'll give that a shot. And I'll be sure to make a backup first. PS: apologies to Aki by the way, for accidentally replying directly to you earlier as well. I can't get protonmail to reply to the mailing list only, without manually adjusting it. Also apologies for answering above the message now, when I answered underneath the message first. Since I don't see a consistent style in this mailing list I'll use my preferred style of answering above messages from now on. On Wednesday, February 22nd, 2023 at 00:49, Ben Burk wrote: > I would definitely get mail-crypt working on your system before worrying > about encrypting existing emails. Iirc dovecot should support both types > of files (encrypted, and non-encrypted) concurrently. So BEFORE you try > anything, make sure via logs, etc that mail is being written to the fs > as an encrypted file and that dovecot is able to decrypt it (i.e. you > are able to view that particular mail file from your email client). > > My specific use case way back was to encrypt a maildir system using this > plugin a year or so ago. I believe there are 2 ways to set mail-crypt > up. Using global keys or folder-specific keys. What you will learn going > through this process using folder-specific keys is that any time mail is > moved (from an IMAP directory to another) the mail becomes effectively > re-encrypted using the destination's folder keys. I imagine how this > works under global keys is that the mail is encrypted once when it is > moved, then never again unless keys change. So all you would need to do > to encrypt existing mail using either method would be to create a temp > imap folder, move mail from each IMAP folder one at a time into this > temp folder, then back to the original IMAP folder. > > I had a few questions at the time in implementing this, so I've linked > here the dovecot mailing list thread so it might provide some context if > needed: > > https://dovecot.org/pipermail/dovecot/2021-July/122469.html > > > On 2/21/23 16:29, Jeremy wrote: > > > On Tuesday, February 21st, 2023 at 09:54, Aki Tuomi > > aki.tu...@open-xchange.com wrote: > > > > > > On 16/02/2023 07:18 EET mailinglist-subscriptions > > > > mailinglist-subscripti...@protonmail.com wrote: > > > > > > > > Hi, > > > > > > > > I am using dovecot 2.3.16, along with postfix and a PostgreSQL database > > > > for managing virtual accounts. > > > > > > > > I'd like to start using the mail-crypt plugin. However, I'm having a > > > > bit some difficulty understanding the documentation at > > > > > > > > https://doc.dovecot.org/configuration_manual/mail_crypt_plugin > > > > > > > > to reach my goal. I plan to ask questions about those issues by > > > > starting new threads in this mailing list. But before I even come to > > > > that, I'd like to investigate the following: > > > > > > > > The above documentation only addresses a clean install and doesn't seem > > > > to mention encrypting already existent unencrypted mails, like my > > > > server has. Is it possible to encrypt those before I start using the > > > > mail-crypt plugin, such that it will be able to decrypt those messages > > > > as well? > > > > > > > > If it is, I am assuming that how I would go about achieving that will > > > > be very dependent on the ultimate configuration I have in mind > > > > (pub/priv keys, etc.). So I don't expect a full-fledged guide. However, > > > > if you could perhaps give a general overview of what would be needed to > > > > achieve this, I would very much appreciate that. > > > > > > > > Thank you. > > > > > > It will be easiest to do migration to new server, then the data will get > > > encrypted while migrating. It is possible to write a script to do this, > > > but will be much more hassle than migration. > > > > > > You might even be able to do it for one user at a time, by doing > > > migration from maildir to maildir and then moving the new maildir over > > > the old one. > > > > > > Aki > > > Thanks for the suggestion. However, migrating sounds like quite the > > > hassle as well. > > > > Now, I have next to no knowledge about the synchronization workings of > > IMAP, so perhaps this is totally infe
Setting up the mail-crypt plugin with virtual accounts that have no home directories
Hi again,
I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for
managing virtual accounts.
After an initial topic from me about encrypting already existent mail, I could
now use some pointers on how to set up the mail-crypt plugin for pure virtual
accounts (i.e. that have no matching system users and/or home directories. I
hope somebody can clarify a few things that are not entirely clear to me yet.
After doing my own research, I believe the following should be possible:
I'd like to use the password of virtual email accounts to let dovecot
encrypt/decrypt the keys needed to encrypt/decrypt the mail in the relevant
folders.
As per the documentation @
https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ I believe this
would be all the configuration I need:
# Config
mail_attribute_dict = file:%h/Maildir/dovecot-attributes
mail_plugins = $mail_plugins mail_crypt
plugin {
mail_crypt_curve = secp521r1 # or some other preferred curve
mail_crypt_save_version = 2
mail_crypt_require_encrypted_user_key = yes # necessary for encrypting keys
with user password
}
# File: /etc/dovecot/dovecot-sql.conf.ext
password_query = SELECT \
email as user, password, \
'%w' AS userdb_mail_crypt_private_password \
FROM virtual_users WHERE email='%u';
My first question is:
Is it possible to configure mail_attribute_dict in such a way as to not use
home directories. Since I only use virtual accounts, without those accounts
having home directories, can I somehow tell dovecot to save the attributes into
the PostsreSQL database, for instance? If not, can you suggest another
approach, without having to create home directories for virtual users?
My second question is:
The documentation warns about not using password directly in the above SQL
query:
> Choosing encryption key
> DO NOT use password directly. It can contain % which is interpreted as >
> variable expansion and can cause errors.
Does this refer to not accidentally substituting '%w' with password? In other
words, if I leave the above query as is, should I be good, even if plain text
passwords of users potentially have % signs in them? Or would I need to take
further measurements? (The passwords in my database are already hashed, by the
way).
I hope somebody can offer some guidance on this. Thanks.
Re: Setting up the mail-crypt plugin with virtual accounts that have no home directories
Hi again,
I was able to solve both questions. I was overthinking things.
A solution to the first question about mail_attribute_dict was simply to use
other available variables to point to the virtual user's maildir paths. Like
so: /var/mail/%d/%u/dovecot-attributes
As for the second question:
When I asked it, I was uncertain if dovecot would be able to cope with a hashed
password for userdb_mail_crypt_private_password. I somehow believed dovecot
required a plain text password there, as per the '%w' in the example
password_query. Turns out this was not the case. Simply providing the already
hashed password of the password field did the trick. So:
password_query = SELECT \
email as user, password, \
password AS userdb_mail_crypt_private_password \
FROM virtual_users WHERE email='%u';
Hope this is of help to others if they stumble upon this question.
--- Original Message ---
On Thursday, February 23rd, 2023 at 08:53, Jeremy
wrote:
> Hi again,
>
> I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for
> managing virtual accounts.
>
> After an initial topic from me about encrypting already existent mail, I
> could now use some pointers on how to set up the mail-crypt plugin for pure
> virtual accounts (i.e. that have no matching system users and/or home
> directories. I hope somebody can clarify a few things that are not entirely
> clear to me yet.
>
> After doing my own research, I believe the following should be possible:
>
> I'd like to use the password of virtual email accounts to let dovecot
> encrypt/decrypt the keys needed to encrypt/decrypt the mail in the relevant
> folders.
>
> As per the documentation @
> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ I believe
> this would be all the configuration I need:
>
> # Config
> mail_attribute_dict = file:%h/Maildir/dovecot-attributes
> mail_plugins = $mail_plugins mail_crypt
>
> plugin {
> mail_crypt_curve = secp521r1 # or some other preferred curve
> mail_crypt_save_version = 2
> mail_crypt_require_encrypted_user_key = yes # necessary for encrypting keys
> with user password
> }
>
> # File: /etc/dovecot/dovecot-sql.conf.ext
> password_query = SELECT \
> email as user, password, \
> '%w' AS userdb_mail_crypt_private_password \
> FROM virtual_users WHERE email='%u';
>
> My first question is:
> Is it possible to configure mail_attribute_dict in such a way as to not use
> home directories. Since I only use virtual accounts, without those accounts
> having home directories, can I somehow tell dovecot to save the attributes
> into the PostsreSQL database, for instance? If not, can you suggest another
> approach, without having to create home directories for virtual users?
>
> My second question is:
> The documentation warns about not using password directly in the above SQL
> query:
>
> > Choosing encryption key
>
> > DO NOT use password directly. It can contain % which is interpreted as >
> > variable expansion and can cause errors.
>
>
> Does this refer to not accidentally substituting '%w' with password? In other
> words, if I leave the above query as is, should I be good, even if plain text
> passwords of users potentially have % signs in them? Or would I need to take
> further measurements? (The passwords in my database are already hashed, by
> the way).
>
> I hope somebody can offer some guidance on this. Thanks.
Re: Setting up the mail-crypt plugin with virtual accounts that have no home directories
Hi,
Yeah, I just realized myself that what I did there was probably not the
smartest thing to do, as I indeed figured dovecot would probably just use that
as a plain text string. ;-) I've now opted to do the following (I'm using
PostgreSQL BTW):
password_query = SELECT \
email as user, password, \
encode(digest('%w', 'sha256'), 'hex') AS userdb_mail_crypt_private_password \
FROM virtual_users WHERE email='%u';
Please advice if you think that this is more sensible.
Also, could you give an overview of in which logs and/or other locations these
passwords might show up? I'd like to clean up after myself.
Thanks in advance.
--- Original Message ---
On Saturday, March 4th, 2023 at 15:38, Aki Tuomi
wrote:
> Hi,
>
> just to mention this. If you use the stored password hash, it equals to using
> a plain text string. Depending on your threat model it might or not be an
> issue that admins have access to the password used to encrypt mails.
>
> Aki
>
>> On 04/03/2023 16:12 EET Jeremy
>> wrote:
>>
>> Hi again,
>>
>> I was able to solve both questions. I was overthinking things.
>>
>> A solution to the first question about mail_attribute_dict was simply to use
>> other available variables to point to the virtual user's maildir paths. Like
>> so: /var/mail/%d/%u/dovecot-attributes
>>
>> As for the second question:
>> When I asked it, I was uncertain if dovecot would be able to cope with a
>> hashed password for userdb_mail_crypt_private_password. I somehow believed
>> dovecot required a plain text password there, as per the '%w' in the example
>> password_query. Turns out this was not the case. Simply providing the
>> already hashed password of the password field did the trick. So:
>>
>> password_query = SELECT \
>> email as user, password, \
>> password AS userdb_mail_crypt_private_password \
>> FROM virtual_users WHERE email='%u';
>>
>> Hope this is of help to others if they stumble upon this question.
>>
>> --- Original Message ---
>> On Thursday, February 23rd, 2023 at 08:53, Jeremy
>> wrote:
>>
>>> Hi again,
>>>
>>> I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for
>>> managing virtual accounts.
>>>
>>> After an initial topic from me about encrypting already existent mail, I
>>> could now use some pointers on how to set up the mail-crypt plugin for pure
>>> virtual accounts (i.e. that have no matching system users and/or home
>>> directories. I hope somebody can clarify a few things that are not entirely
>>> clear to me yet.
>>>
>>> After doing my own research, I believe the following should be possible:
>>>
>>> I'd like to use the password of virtual email accounts to let dovecot
>>> encrypt/decrypt the keys needed to encrypt/decrypt the mail in the relevant
>>> folders.
>>>
>>> As per the documentation @
>>> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ I believe
>>> this would be all the configuration I need:
>>>
>>> # Config
>>> mail_attribute_dict = file:%h/Maildir/dovecot-attributes
>>> mail_plugins = $mail_plugins mail_crypt
>>>
>>> plugin {
>>> mail_crypt_curve = secp521r1 # or some other preferred curve
>>> mail_crypt_save_version = 2
>>> mail_crypt_require_encrypted_user_key = yes # necessary for encrypting keys
>>> with user password
>>> }
>>>
>>> # File: /etc/dovecot/dovecot-sql.conf.ext
>>> password_query = SELECT \
>>> email as user, password, \
>>> '%w' AS userdb_mail_crypt_private_password \
>>> FROM virtual_users WHERE email='%u';
>>>
>>> My first question is:
>>> Is it possible to configure mail_attribute_dict in such a way as to not use
>>> home directories. Since I only use virtual accounts, without those accounts
>>> having home directories, can I somehow tell dovecot to save the attributes
>>> into the PostsreSQL database, for instance? If not, can you suggest another
>>> approach, without having to create home directories for virtual users?
>>>
>>> My second question is:
>>> The documentation warns about not using password directly in the above SQL
>>> query:
>>>
>>>> Choosing encryption key
>>>
>>>> DO NOT use password directly. It can contain % which is interpreted as >
>>>> variable expansion and can cause errors.
>>>
>>> Does this refer to not accidentally substituting '%w' with password? In
>>> other words, if I leave the above query as is, should I be good, even if
>>> plain text passwords of users potentially have % signs in them? Or would I
>>> need to take further measurements? (The passwords in my database are
>>> already hashed, by the way).
>>>
>>> I hope somebody can offer some guidance on this. Thanks.
>
> ---
> Aki Tuomi
Re: Setting up the mail-crypt plugin with virtual accounts that have no home directories
Hi,
Thanks for the notice! But yes, I was aware of this. For future reference
though, would you mind telling me how I would go about doing this? I take it
I'd first have to re-encrypt the user keys, before changing the account
password. So before changing the password for a user in my PostgreSQL database,
I would do the following:
doveadm mailbox cryptokey password -u 'u...@example.com' -o -n
since I am using encode(digest('%w', 'sha256'), 'hex') in the PostgreSQL
password_query.
Can you confirm that this is the correct way to change the user keys' password?
Thanks.
--- Original Message ---
On Saturday, March 4th, 2023 at 16:41, Aki Tuomi
wrote:
> Dovecot tries to hide passwords in logs so you're probably safe.
>
> Remember that there is no automatic password change for mail crypt. If user's
> password is changed, it will require corresponding update for user's master
> key.
>
> Aki
>
>> On 04/03/2023 17:07 EET Jeremy
>> wrote:
>>
>> Hi,
>>
>> Yeah, I just realized myself that what I did there was probably not the
>> smartest thing to do, as I indeed figured dovecot would probably just use
>> that as a plain text string. ;-) I've now opted to do the following (I'm
>> using PostgreSQL BTW):
>>
>> password_query = SELECT \
>> email as user, password, \
>> encode(digest('%w', 'sha256'), 'hex') AS userdb_mail_crypt_private_password \
>> FROM virtual_users WHERE email='%u';
>>
>> Please advice if you think that this is more sensible.
>>
>> Also, could you give an overview of in which logs and/or other locations
>> these passwords might show up? I'd like to clean up after myself.
>>
>> Thanks in advance.
>>
>> --- Original Message ---
>> On Saturday, March 4th, 2023 at 15:38, Aki Tuomi
>> wrote:
>>
>>> Hi,
>>>
>>> just to mention this. If you use the stored password hash, it equals to
>>> using a plain text string. Depending on your threat model it might or not
>>> be an issue that admins have access to the password used to encrypt mails.
>>>
>>> Aki
>>>
>>>> On 04/03/2023 16:12 EET Jeremy
>>>> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> I was able to solve both questions. I was overthinking things.
>>>>
>>>> A solution to the first question about mail_attribute_dict was simply to
>>>> use other available variables to point to the virtual user's maildir
>>>> paths. Like so: /var/mail/%d/%u/dovecot-attributes
>>>>
>>>> As for the second question:
>>>> When I asked it, I was uncertain if dovecot would be able to cope with a
>>>> hashed password for userdb_mail_crypt_private_password. I somehow believed
>>>> dovecot required a plain text password there, as per the '%w' in the
>>>> example password_query. Turns out this was not the case. Simply providing
>>>> the already hashed password of the password field did the trick. So:
>>>>
>>>> password_query = SELECT \
>>>> email as user, password, \
>>>> password AS userdb_mail_crypt_private_password \
>>>> FROM virtual_users WHERE email='%u';
>>>>
>>>> Hope this is of help to others if they stumble upon this question.
>>>>
>>>> --- Original Message ---
>>>> On Thursday, February 23rd, 2023 at 08:53, Jeremy
>>>> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> I am using dovecot 2.3.16, along with postfix and a PostgreSQL database
>>>>> for managing virtual accounts.
>>>>>
>>>>> After an initial topic from me about encrypting already existent mail, I
>>>>> could now use some pointers on how to set up the mail-crypt plugin for
>>>>> pure virtual accounts (i.e. that have no matching system users and/or
>>>>> home directories. I hope somebody can clarify a few things that are not
>>>>> entirely clear to me yet.
>>>>>
>>>>> After doing my own research, I believe the following should be possible:
>>>>>
>>>>> I'd like to use the password of virtual email accounts to let dovecot
>>>>> encrypt/decrypt the keys needed to encrypt/decrypt the mail in the
>>>>> relevant folders.
>>>>>
>>>>> As per the documentation @
>>>&
Re: Setting up the mail-crypt plugin with virtual accounts that have no home directories
Thanks for the reassurance and the other assistance you have provided!
Everything seems to work a treat.
--- Original Message ---
On Sunday, March 5th, 2023 at 18:00, Aki Tuomi
wrote:
> Order does not matter much as long as you do it about same time. But
> otherwise, yes.
>
> Aki
>
>> On 05/03/2023 18:43 EET Jeremy
>> wrote:
>>
>> Hi,
>>
>> Thanks for the notice! But yes, I was aware of this. For future reference
>> though, would you mind telling me how I would go about doing this? I take it
>> I'd first have to re-encrypt the user keys, before changing the account
>> password. So before changing the password for a user in my PostgreSQL
>> database, I would do the following:
>>
>> doveadm mailbox cryptokey password -u 'u...@example.com' -o > sha256-hashed old password> -n
>>
>> since I am using encode(digest('%w', 'sha256'), 'hex') in the PostgreSQL
>> password_query.
>>
>> Can you confirm that this is the correct way to change the user keys'
>> password? Thanks.
>> --- Original Message ---
>> On Saturday, March 4th, 2023 at 16:41, Aki Tuomi
>> wrote:
>>
>>> Dovecot tries to hide passwords in logs so you're probably safe.
>>>
>>> Remember that there is no automatic password change for mail crypt. If
>>> user's password is changed, it will require corresponding update for user's
>>> master key.
>>>
>>> Aki
>>>
>>>> On 04/03/2023 17:07 EET Jeremy
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Yeah, I just realized myself that what I did there was probably not the
>>>> smartest thing to do, as I indeed figured dovecot would probably just use
>>>> that as a plain text string. ;-) I've now opted to do the following (I'm
>>>> using PostgreSQL BTW):
>>>>
>>>> password_query = SELECT \
>>>> email as user, password, \
>>>> encode(digest('%w', 'sha256'), 'hex') AS
>>>> userdb_mail_crypt_private_password \
>>>> FROM virtual_users WHERE email='%u';
>>>>
>>>> Please advice if you think that this is more sensible.
>>>>
>>>> Also, could you give an overview of in which logs and/or other locations
>>>> these passwords might show up? I'd like to clean up after myself.
>>>>
>>>> Thanks in advance.
>>>>
>>>> --- Original Message ---
>>>> On Saturday, March 4th, 2023 at 15:38, Aki Tuomi
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> just to mention this. If you use the stored password hash, it equals to
>>>>> using a plain text string. Depending on your threat model it might or not
>>>>> be an issue that admins have access to the password used to encrypt mails.
>>>>>
>>>>> Aki
>>>>>
>>>>>> On 04/03/2023 16:12 EET Jeremy
>>>>>> wrote:
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> I was able to solve both questions. I was overthinking things.
>>>>>>
>>>>>> A solution to the first question about mail_attribute_dict was simply to
>>>>>> use other available variables to point to the virtual user's maildir
>>>>>> paths. Like so: /var/mail/%d/%u/dovecot-attributes
>>>>>>
>>>>>> As for the second question:
>>>>>> When I asked it, I was uncertain if dovecot would be able to cope with a
>>>>>> hashed password for userdb_mail_crypt_private_password. I somehow
>>>>>> believed dovecot required a plain text password there, as per the '%w'
>>>>>> in the example password_query. Turns out this was not the case. Simply
>>>>>> providing the already hashed password of the password field did the
>>>>>> trick. So:
>>>>>>
>>>>>> password_query = SELECT \
>>>>>> email as user, password, \
>>>>>> password AS userdb_mail_crypt_private_password \
>>>>>> FROM virtual_users WHERE email='%u';
>>>>>>
>>>>>> Hope this is of help to others if they stumble upon this question.
>>>>>>
>>>>>> --- Original Message ---
>>>&g
Re: how to set smtp-client -> submission_relay_host for IPv4 only?
On 16/10/2020 4:04 am, PGNet Dev wrote: 2020-10-15 12:51:45 submission(m...@example.com)<8OJP+rqxuvho7Z95>: Info: Successfully relayed message: from=, size=84, id=LMe...Aw, nrcpt=1, reply=`247 2.0.0 Ok: queued as 4CC0KY1wXNzWf93' not fatal, but wasted effort, and noise in the logs. how/where do I configure (just) the dovecot smtp-client -> submission_relay_host to only connect IPv4? It appears your host has A and records in your DNS. The clients will try IPV6 first if they see an record. If you don't need IPV6 for your host remove the record. All connections will then only use IPV4. If you need IPV6 for some other reason then create an alias DNS A record and point your clients to that instead e.g. myhost A192.0.2.1 2001:db8::1 myhostv4 A 192.0.2.1 you will have to change your certificate to include the alias myhost4
Re: Recommended Protocols?
On 10/11/20 1:52 pm, Nikolai Lusan wrote: Greetings, On Mon, 2020-11-09 at 23:42 -0600, Raymond Herrera wrote: > For several years I have been running the following in a Linux > server. > Dovecot Version: 2.0.9 > *IMAP:* > Connection Security: SSL/TLS > Port: 993 > Authentication Method: Normal Password > *SMTP:* > Connection Security: STARTTLS > Port: 587 > Authentication Method: Normal Password Pretty standard setup. Personally I am using Postfix for SMTP/Submission and Dovecot for IMAP - both with STARTTLS. I use a couple of MX's to actually do the initial recieving of email, so everything auth related (and adress related) is in a multi-master LDAP server on each machine. Using Dovetcot-SASL for SMTP auth too. > The E-mail client is Thunderbird on Windows. I my experience pretty much any client works with this setup. I also use STARTTLS, though I expose that on both IMAP and IMAPS ports, which is consistent with a number of major imap providers. Selection of ciphers is important. I researched this recently and use this stanza in the configuration ssl = required ssl_min_protocol = TLSv1.2 ssl_cipher_list = EECDH+AESGCM:EDH+AESGCM ssl_prefer_server_ciphers = yes The defaults in dovecot are shown commented in conf.d/10-ssl.conf. They are not best practice for security. OpenPGP_0xFABD47B0F98E88C9.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Disallow acces via imap, but keep lmtp running
On 16/12/20 6:16 am, Julian Kippels wrote: Hi all, what is the best way to temporarily disable access to a mailbox via imap, but keep it possible to deliver to the mailbox via lmtp? I want to migrate some mailboxes around and would like to ensure that the users cannot access their mail while doing so. I would like to keep the users from logging in entirely rather than setting ACLs. Thanks in advance Julian Comment out the sections in dovecot.conf that configure the imap service but leave the lmtp service running. Alternatively set an iptables rule to block the imap and imaps ports. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Broken uidlist when using NFS on newer kernels
I know this has been reported in the past, but I think I have some useful new information on the problem. After an OS upgrade from Ubuntu Xenial (4.4.0 kernel) to Ubuntu Focal (5.4.0 kernel) and corresponding upgrade from Dovecot 2.2.27 to 2.3.7.2, we've started seeing broken uidlist files to an extent that's making larger mail boxes nearly unusable because the file is constantly being regenerated. I've also used the 2.3.16-2+ubuntu20.04 version distributed from dovecot.org and the behavior is unchanged. The environment consists of NFS mounts from a NetApp device, with a couple dozen MX servers receiving mail and about a hundred IMAP/POP servers. This is the exact error (note the blank after "invalid data"): Error: Mailbox INBOX: Broken file /mnt/morty/morty2/gravest/x15775549/Maildir/dovecot-uidlist line 373: Invalid data: I've been able to trigger the problem rather easily by piping an email to dovecot-lda in a loop and reading the resulting dovecot-uidlist file on a different server. What it shows is that occasionally we're seeing the last line of the file prepended with a number of null bytes equal to the line that's being written (for example, if the entry is "35322 :1633719038.M516419P3623238.pdx1-sub0-mail-mx202,S=2777,W=2832", we'll have it prepended by 69 null bytes). This then breaks the IMAP process' ability to read the file. My first thought was to extend the retry functionality so the imap proces makes more attempts to read the file when it detects a problem like this, but would love input from someone more familiar with the codebase.
Re: Broken uidlist when using NFS on newer kernels
I looked into LMTP, but reconfiguring our 1.5 million mailboxes just to work around what seems like an obvious bug in the code is a hard sell. I patched maildir-uidlist.c to strip out the leading null bytes and things seem to behave just fine, but it feels wrong and I was hoping to get input from someone more familiar with the codebase. On Tue, Oct 12, 2021 at 8:39 AM Alessio Cecchi wrote: > Hi Jeremy, > > I had the same problem as you. > > We run an email hosting service with Maildir on NetApp NFS, Dovecot > Director and Backend servers for POP/IMAP and messagges deliverd via > dovecot-lda by MXs. After the upgrade from CentOS 6 to CentOS 7 I found the > same issue as you (on dovecot-uidlist). > > After many tests we decided to switch from LDA to LMTP, that was already > in our roadmap, so read and delivery of messagges is always on the same > backend. And the problem was solved. > > I haven't found any others workarounds. > > Swith from LDA to LMTP was not so simple for us since our MX wasn't able > to talk LMTP but we have write some custom C++ code and was done. You > should also consider to add some directors since also incoming emails will > transit from it. > > If you would like to talk about how we solve on MXs side I will happy to > talk with you. > > Ciao > Il 08/10/21 21:01, Jeremy Hanmer ha scritto: > > I know this has been reported in the past, but I think I have some useful > new information on the problem. After an OS upgrade from Ubuntu Xenial > (4.4.0 kernel) to Ubuntu Focal (5.4.0 kernel) and corresponding upgrade > from Dovecot 2.2.27 to 2.3.7.2, we've started seeing broken uidlist files > to an extent that's making larger mail boxes nearly unusable because the > file is constantly being regenerated. I've also used the > 2.3.16-2+ubuntu20.04 version distributed from dovecot.org and the > behavior is unchanged. The environment consists of NFS mounts from a NetApp > device, with a couple dozen MX servers receiving mail and about a hundred > IMAP/POP servers. > > This is the exact error (note the blank after "invalid data"): > Error: Mailbox INBOX: Broken file > /mnt/morty/morty2/gravest/x15775549/Maildir/dovecot-uidlist line 373: > Invalid data: > > I've been able to trigger the problem rather easily by piping an email to > dovecot-lda in a loop and reading the resulting dovecot-uidlist file on a > different server. What it shows is that occasionally we're seeing the last > line of the file prepended with a number of null bytes equal to the line > that's being written (for example, if the entry is "35322 > :1633719038.M516419P3623238.pdx1-sub0-mail-mx202,S=2777,W=2832", we'll have > it prepended by 69 null bytes). This then breaks the IMAP process' ability > to read the file. My first thought was to extend the retry functionality so > the imap proces makes more attempts to read the file when it detects a > problem like this, but would love input from someone more familiar with the > codebase. > > -- > Alessio Cecchi > Postmaster @ http://www.qboxmail.ithttps://www.linkedin.com/in/alessice > >
Re: Broken uidlist when using NFS on newer kernels
I understand switching to Director is suggested, but that's not really
feasible (in a reasonable timeframe, anyway) for a mail cluster like ours
that requires procmail and processes over 1.5 million emails/day. It's
probably worth mentioning that the bug is easily triggered by writing an
email w/ dovecot-lda and the test user is isolated from any imap/pop3
access.
I'm happy to debug further if need be, but even if these null bytes aren't
written by dovecot it seems that this NFS behavior has existed long enough
that it would make sense for dovecot to handle the situation more smartly
than it is.The patch I wrote is little more than an adaptation of what's
already in place for handling extension fields, so it doesn't seem to me
like a crazy change to make.
This snippet of an strace seems to catch the problem the first time it's
encountered, fwiw. The number of null bytes is *always* equal to the number
of bytes in the string LDA is about to write to the uidlist, which implies
to me that it's independent from what any other host might be doing with
the file at the time.
stat("/mnt/dale/dale2/buttersnap/x9508664/Maildir",
{st_mode=S_IFDIR|S_ISGID|0710, st_size=4096, ...}) = 0
chown("/mnt/dale/dale2/buttersnap/x9508664/Maildir", 9508664, -1) = 0
openat(AT_FDCWD,
"/mnt/dale/dale2/buttersnap/x9508664/Maildir/dovecot-uidlist", O_RDONLY) =
13
close(13) = 0
stat("/mnt/dale/dale2/buttersnap/x9508664/Maildir/dovecot-uidlist",
{st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
lseek(11, 0, SEEK_SET) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=10573, ...}) = 0
pread64(11,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
8192, 10510) = 63
pread64(11, "", 8129, 10573)= 0
On Tue, Oct 12, 2021 at 9:20 PM Aki Tuomi
wrote:
> Hi!
>
> LDA should work just fine, as long as you follow the same rules as with
> LMTP, you must only access the user concurrently on one backend. The
> problem usually comes when you accidentically access the user from the
> other backend while the user is active on other backend.
>
> The fix you made might seemingly work, but it's going to break something
> in future. The \0 are not introduced by dovecot.
>
> Aki
>
> > On 12/10/2021 21:45 Jeremy Hanmer wrote:
> >
> >
> > I looked into LMTP, but reconfiguring our 1.5 million mailboxes just to
> work around what seems like an obvious bug in the code is a hard sell. I
> patched maildir-uidlist.c to strip out the leading null bytes and things
> seem to behave just fine, but it feels wrong and I was hoping to get input
> from someone more familiar with the codebase.
> >
> >
> > On Tue, Oct 12, 2021 at 8:39 AM Alessio Cecchi wrote:
> > > Hi Jeremy,
> > > I had the same problem as you.
> > > We run an email hosting service with Maildir on NetApp NFS, Dovecot
> Director and Backend servers for POP/IMAP and messagges deliverd via
> dovecot-lda by MXs. After the upgrade from CentOS 6 to CentOS 7 I found the
> same issue as you (on dovecot-uidlist).
> > > After many tests we decided to switch from LDA to LMTP, that was
> already in our roadmap, so read and delivery of messagges is always on the
> same backend. And the problem was solved.
> > > I haven't found any others workarounds.
> > > Swith from LDA to LMTP was not so simple for us since our MX wasn't
> able to talk LMTP but we have write some custom C++ code and was done. You
> should also consider to add some directors since also incoming emails will
> transit from it.
> > >
> > > If you would like to talk about how we solve on MXs side I will happy
> to talk with you.
> > > Ciao
> > >
> > > Il 08/10/21 21:01, Jeremy Hanmer ha scritto:
> > >
> > > > I know this has been reported in the past, but I think I have some
> useful new information on the problem. After an OS upgrade from Ubuntu
> Xenial (4.4.0 kernel) to Ubuntu Focal (5.4.0 kernel) and corresponding
> upgrade from Dovecot 2.2.27 to 2.3.7.2, we've started seeing broken uidlist
> files to an extent that's making larger mail boxes nearly unusable because
> the file is constantly being regenerated. I've also used the
> 2.3.16-2+ubuntu20.04 version distributed from dovecot.org (
> http://dovecot.org) and the behavior is unchanged. The environment
> consists of NFS mounts from a NetApp device, with a couple dozen MX servers
> receiving mail and about a hundred IMAP/POP servers.
> > > >
&g
local stanza only generated for IPv6
I have a mail server with multiple IP addresses and associated DNS names
In the dovecot configuration I have a listen directive:
listen = mail.example.com.com,mail.otherexample.com,localhost
Multiple local stanzas are of the form:
local mail.example.com {
protocol imap {
ssl_cert =
Re: local stanza only generated for IPv6
Further to my report on stanzas being only generated the IPv6 addresses
I have found a work-around until someone in the development team comes
up with something like inet_listener_6 and inet_listener_4
The workaround is simply to get dovecot to listen in IPv4 and IPv6. It
has no effect on clients who will use ordinary MX records to access the
normal mailserver name
The workaround requires modifying DNS with duplicate A and records
(not CNAME or ALIAS) for the addresses of interest. So in the instance
of one domain:
mail A 192.168.0.1
2001:0db8:85a3:::8a2e:0370:7334
mail4 A 192.168.0.1
mail6 2001:0db8:85a3:::8a2e:0370:7334
Then the dovecot.conf file requires multiple local stanzas. In this case
two domains requires four stanzas
listen =
mail4.example.com,mail6.example.com,mail4.example2.com,mail6.example2.com,localhost
protocols = imap lmtp sieve
ssl_min_protocol = TLSv1.2
ssl_cipher_list = EECDH+AESGCM:EDH+AESGCM
ssl_prefer_server_ciphers = yes
local mail4.example.com {
protocol imap {
ssl_cert =
Re: local stanza only generated for IPv6
On 2/7/20 10:07 am, Benny Pedersen wrote:
> Jeremy Ardley skrev den 2020-07-01 06:50:
>
>> local mail.example.com {
>> protocol imap {
>> ssl_cert = > ssl_key = >
>> service imaps_login {
>> inet_listener imaps {
>> address=mail.example.com
>> }
>
> not using hostname here, it should be either ipv4 or ipv6 not hostname
That makes maintenance difficult. postconf is helpful because it looks
up the IP from the hostname each time the service is started. The issue
is it looks up IPv6 in preference/exclusion to IPv4
>
>> inet_listener imap {
>> address=mail.example.com
>
> does this make sense for ssl ? :=)
Yes, clients can connect on port 143 (imap) but negotiate TLS.
Thunderbird checks port 143 first when scanning a server for TLS
connections.
Re: how to setup IMAPs with letsencrypt
On 22/4/22 7:25 am, al...@coakmail.com wrote:
hello
I have setup website using letsencrypt for certification.
how can I setup IMAP to use this certs as well?
Thank you.
Make entries in /etc/dovecot/conf.d/10-ssl.conf
ssl = required
ssl_cert = You can override the global ssl certificates for specific domains in
/etc/dovecot/dovecot.conf
local special.example.com {
protocol imap {
ssl_cert =
OpenPGP_signature
Description: OpenPGP digital signature
Re: how to setup IMAPs with letsencrypt
On 22/4/22 7:44 am, al...@coakmail.com wrote: On 22/4/22 7:25 am, al...@coakmail.com wrote: Thanks. I will give a try. after enabling SSL, can I disable port 143 entirely? Probably a bad idea. Many clients use STARTTTLS on port 143 rather than TLS on port 993 -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: how to setup IMAPs with letsencrypt
On 22/4/22 7:50 am, Jeremy Ardley wrote: On 22/4/22 7:44 am, al...@coakmail.com wrote: On 22/4/22 7:25 am,al...@coakmail.com wrote: Thanks. I will give a try. after enabling SSL, can I disable port 143 entirely? Probably a bad idea. Many clients use STARTTTLS on port 143 rather than TLS on port 993 I forgot to mention that in /etc/dovecot/dovecot.conf you don't need to specify imaps. Dovecot automatically listens on port 993 and 143 when ssl is specified and applies the ssl directive as indicated. #global # SSL/TLS support: yes, no, required. ssl = required ssl_min_protocol = TLSv1.2 ssl_cipher_list = EECDH+AESGCM:EDH+AESGCM ssl_prefer_server_ciphers = yes ssl_cert = It is possible to generate a wildcard letsencrypt certificate *.example.com but the process is tricky and has unexpected side-effects such as typo.example.com resolves to example.com in DNS -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: how to setup IMAPs with letsencrypt
On 22/4/22 8:24 am, Jeremy Ardley wrote:
local mail.example.com {
protocol imap {
ssl_cert =
My error. The correct example domain override stanza is
#specific domain override
local special.example.com {
protocol imap {
ssl_cert =
OpenPGP_signature
Description: OpenPGP digital signature
Re: how to setup IMAPs with letsencrypt
On 24/4/22 9:14 am, ミユナ (alice) wrote: Richard Hector wrote: otherwise you'll have to use DNS challenge method to support multiple hostnames on the same certificate. do you know how to implement this? the original certificates were issued for domain: sample.com. But this certs can be used for any.sample.com too? There is a procedure for wildcards but it's a little complex. It helps to have your own bind server. For a start: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: how to setup IMAPs with letsencrypt
On 24/4/22 9:22 am, Jeremy Ardley wrote: For a start: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot This may be more helpful https://medium.com/@saurabh6790/generate-wildcard-ssl-certificate-using-lets-encrypt-certbot-273e432794d7 -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Sieve configuration for roundcube
Any pointers to get dovecot configured with sieve for Roundcube filters? Things I’ve found through search seem a bit all over the place. I’m using CentOS 8/Rocky Linux hosts. Thanks signature.asc Description: PGP signature
Re: Sieve configuration for roundcube
Here’s some more information:
When attemtping to load the filters configuration on Roundcube, I see this in
Dovecot’s logs:
Jun 06 23:25:30 mx1.la1.blah.com dovecot[693354]: managesieve-login:
Disconnected: Too many invalid commands. (no auth attempts in 0 secs): user=<>,
rip=192.168.30.48, lip=192.168.30.21, session=<5628p9Xg6oTAqB4w>
I don’t know if user=<> indicates that the username isn’t being passed properly
but it seems like a good guess based on "no auth attempts in 0 secs”.
My Roundcube configuration looks like this:
$config['managesieve_port'] = 4190;
$config['managesieve_host'] = 'ssl://mx1.la1.blah.com';
$config['managesieve_auth_type'] = PLAIN;
$config['managesieve_auth_cid'] = null;
$config['managesieve_auth_pw'] = null;
$config['managesieve_usetls'] = true;
$config['managesieve_conn_options'] = array(
'ssl' => array(
'verify_peer' => false,
'allow_self_signed' => true,
),
);
$config['managesieve_conn_options'] = null;
$config['managesieve_default'] = '/etc/dovecot/sieve/global';
$config['managesieve_script_name'] = 'managesieve';
$config['managesieve_mbox_encoding'] = 'UTF-8';
$config['managesieve_replace_delimiter'] = '';
$config['managesieve_disabled_extensions'] = [];
$config['managesieve_debug'] = true;
$config['managesieve_kolab_master'] = false;
$config['managesieve_filename_extension'] = '.sieve';
$config['managesieve_filename_exceptions'] = [];
$config['managesieve_domains'] = [];
$config['managesieve_default_headers'] = ['Subject', 'From', 'To'];
$config['managesieve_vacation'] = 0;
$config['managesieve_forward'] = 0;
$config['managesieve_vacation_interval'] = 0;
$config['managesieve_vacation_addresses_init'] = false;
$config['managesieve_vacation_from_init'] = false;
$config['managesieve_notify_methods'] = ['mailto'];
$config['managesieve_raw_editor'] = true;
$config['managesieve_disabled_actions'] = [];
$config['managesieve_allowed_hosts'] = null;
My dovecot configuration looks like this:
netstat -tanp | grep 419
tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 693351/dovecot
tcp6 0 0 :::4190 :::* LISTEN 693351/dovecot
from roundcube host to dovecot host:
telnet mx1.la1.blah.com 4190
Trying 192.168.30.21...
Connected to mx1.la1.blah.com.
Escape character is '^]'.
"IMPLEMENTATION" "Dovecot Pigeonhole"
"SIEVE" "fileinto reject envelope encoded-character vacation subaddress
comparator-i;ascii-numeric relational regex imap4flags copy include variables
body enotify environment mailbox date index ihave duplicate mime foreverypart
extracttext"
"NOTIFY" "mailto"
"SASL" ""
"STARTTLS"
"VERSION" "1.0"
OK "Dovecot ready.”
90-sieve.conf:
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
recipient_delimiter = +
}
20-managesieve.conf:
protocols = $protocols sieve
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
protocol sieve {
}
20-lmtp.conf:
protocol lmtp {
mail_plugins = $mail_plugins sieve
}
Postfix config:
mailbox_transport = lmtp:unix:private/dovecot-lmtp
local_transport = lmtp:unix:private/dovecot-lmtp
Thanks for your help.
-jeremy
> On Monday, Jun 06, 2022 at 12:59 AM, Vladislav Kurz
> mailto:vladislav.k...@webstep.net)> wrote:
> Dne 05. 06. 22 v 4:27 Jeremy Hansen napsal(a):
> > Any pointers to get dovecot configured with sieve for Roundcube filters?
> > Things I’ve found through search seem a bit all over the place. I’m
> > using CentOS 8/Rocky Linux hosts.
> >
> > Thanks
> >
> >
> >
>
> managesieve plugin for roundcube should be able to configure sieve
> scripts if you open sieve port on dovecot.
>
> --
> Best regards
> Vladislav Kurz
>
signature.asc
Description: PGP signature
Re: Sieve configuration for roundcube
$config['managesieve_port'] = 4190; $config['managesieve_host'] = 'ssl://mx1.la1.blah.com'; $config['managesieve_auth_type'] = null; $config['managesieve_auth_cid'] = null; $config['managesieve_auth_pw'] = null; $config['managesieve_usetls'] = false; $config['managesieve_conn_options'] = array( 'ssl' => array( 'verify_peer' => false, 'allow_self_signed' => true, ), ); Same error in the logs. I’m actually not seeing a separate log for sieve. Maybe I have to define a log location or something? -jeremy > On Tuesday, Jun 07, 2022 at 12:24 AM, Aleksander Machniak (mailto:a...@alec.pl)> wrote: > On 07.06.2022 08:42, Jeremy Hansen wrote: > > $config['managesieve_host'] = 'ssl://mx1.la1.blah.com'; > > > > $config['managesieve_auth_type'] = PLAIN; > > Try null, and PLAIN should be in quotes. > > > $config['managesieve_usetls'] = true; > > I'd set this option to false, and control the connection type by use of > ssl:// or tls:// prefix in managesieve_host. ssl + tls does not make sense. > > > $config['managesieve_debug'] = true; > > Did you check logs/sieve.log? > > -- > Aleksander Machniak > Kolab Groupware Developer [https://kolab.org] > Roundcube Webmail Developer [https://roundcube.net] > > PGP: 19359DC1 # Blog: https://kolabian.wordpress.com signature.asc Description: PGP signature
Re: Sieve configuration for roundcube
Figured out my issues. Stupid error on my part. I had $config['managesieve_conn_options'] in there twice defeating my SSL preferences. All is well now. Thanks -jeremy On 2022-06-07 00:37, Jeremy Hansen wrote: $config['managesieve_port'] = 4190; $config['managesieve_host'] = 'ssl://mx1.la1.blah.com'; $config['managesieve_auth_type'] = null; $config['managesieve_auth_cid'] = null; $config['managesieve_auth_pw'] = null; $config['managesieve_usetls'] = false; $config['managesieve_conn_options'] = array( 'ssl' => array( 'verify_peer' => false, 'allow_self_signed' => true, ), ); Same error in the logs. I’m actually not seeing a separate log for sieve. Maybe I have to define a log location or something? -jeremy On Tuesday, Jun 07, 2022 at 12:24 AM, Aleksander Machniak wrote: On 07.06.2022 08:42, Jeremy Hansen wrote: $config['managesieve_host'] = 'ssl://mx1.la1.blah.com'; $config['managesieve_auth_type'] = PLAIN; Try null, and PLAIN should be in quotes. $config['managesieve_usetls'] = true; I'd set this option to false, and control the connection type by use of ssl:// or tls:// prefix in managesieve_host. ssl + tls does not make sense. $config['managesieve_debug'] = true; Did you check logs/sieve.log? -- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Issue with one user only, exceeding connections
I keep having this issue with one user, and I have to restart dovecot
several times a day to clear it. What I have is a postfix / dovecot mail
server (Centos 7) and about a dozen users. All mailboxes are imap ssl. I
monitor about 4 mailboxes on my computer and tablet. I use Thunderbird
on the computer (cache connections at 2) and K9 on the tablet, but one
user of the four I keep getting "Maximum number of connections from
user+IP exceeded" and I have the maximum at 50
"(mail_max_userip_connections=50)" so its hard for me to believe I am
actually exceeding it unless dovecot/client is not dropping connections
and keeps starting new ones until it reaches the maximum, but again,
only for one user, even though I am monitoring 4 on the same devices.
Any idea how to troubleshoot this? I don't know if I should be looking
at dovecot or the clients, or what I need to look for. It's been going
on since I put this server in use over a year ago. I also have issues
with Outlook clients disconnecting, just outlook, is there any
recommended settings to make Outlook work smoother?
Thanks! - Jeremy
Config -
# 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-1160.11.1.el7.x86_64 x86_64 CentOS Linux release
7.9.2009 (Core)
# Hostname: ***
auth_mechanisms = plain login
debug_log_path = /var/log/dovecot_debug.log
first_valid_gid = 500
last_valid_gid = 600
last_valid_uid = 600
listen = *
mail_location = maildir:~/Maildir
mbox_write_locks = fcntl
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix = INBOX.
separator = .
}
passdb {
driver = pam
}
pop3_uidl_format = %f
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
process_min_avail = 1
service_count = 0
}
service imap {
process_limit = 1024
}
service lmtp {
unix_listener lmtp {
mode = 0666
}
}
ssl = required
ssl_cert = <***
ssl_cipher_list = ECDHE-RSA-CHACHA20-POLY1305:ALL:!LOW:!SSLv2:!EXP:!aNULL
ssl_key = # hidden, use -P to show it
ssl_prefer_server_ciphers = yes
userdb {
driver = passwd
}
protocol imap {
mail_max_userip_connections = 50
}
Re: Issue with one user only, exceeding connections
Ahhh, Ok, I did not know that and now that makes sense. I did not
realize it held a open connection for each folder. I increased that and
I will see what happens. I wonder if that will also effect the outlook
issues. Thanks! - Jeremy
On 6/8/2022 14:28, Frank-Ulrich Sommer wrote:
I think if IMAP IDLE is used you need one connection per folder. If I
remember correctly at least either Thunderbird or K9 Mail (I'm using
both too) use one connection per selected directory. Simply increasing
the number of connections was the easiest solution as I only have very
few users too.
Regards
Frank
Am 8. Juni 2022 21:14:23 MESZ schrieb Jeremy Schaeffer
:
I keep having this issue with one user, and I have to restart dovecot
several times a day to clear it. What I have is a postfix / dovecot mail
server (Centos 7) and about a dozen users. All mailboxes are imap ssl. I
monitor about 4 mailboxes on my computer and tablet. I use Thunderbird
on the computer (cache connections at 2) and K9 on the tablet, but one
user of the four I keep getting "Maximum number of connections from
user+IP exceeded" and I have the maximum at 50
"(mail_max_userip_connections=50)" so its hard for me to believe I am
actually exceeding it unless dovecot/client is not dropping connections
and keeps starting new ones until it reaches the maximum, but again,
only for one user, even though I am monitoring 4 on the same devices.
Any idea how to troubleshoot this? I don't know if I should be looking
at dovecot or the clients, or what I need to look for. It's been going
on since I put this server in use over a year ago. I also have issues
with Outlook clients disconnecting, just outlook, is there any
recommended settings to make Outlook work smoother?
Thanks! - Jeremy
Config -
# 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-1160.11.1.el7.x86_64 x86_64 CentOS Linux release
7.9.2009 (Core)
# Hostname: ***
auth_mechanisms = plain login
debug_log_path = /var/log/dovecot_debug.log
first_valid_gid = 500
last_valid_gid = 600
last_valid_uid = 600
listen = *
mail_location = maildir:~/Maildir
mbox_write_locks = fcntl
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix = INBOX.
separator = .
}
passdb {
driver = pam
}
pop3_uidl_format = %f
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
process_min_avail = 1
service_count = 0
}
service imap {
process_limit = 1024
}
service lmtp {
unix_listener lmtp {
mode = 0666
}
}
ssl = required
ssl_cert = <***
ssl_cipher_list = ECDHE-RSA-CHACHA20-POLY1305:ALL:!LOW:!SSLv2:!EXP:!aNULL
ssl_key = # hidden, use -P to show it
ssl_prefer_server_ciphers = yes
userdb {
driver = passwd
}
protocol imap {
mail_max_userip_connections = 50
}
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
gesendet.
Re: Issue with one user only, exceeding connections
That was the first thing I tried, I lowered the cache connections in Thunderbird. Actually the max connections was 50, not 500, but I could see why as I do have a lot of folders, but what is odd is I have other mailboxes that have even more folders, but it's only one mailbox that is trowing the error. "# ps -axww | grep imap" does not give me the same results - . 19897 ? S 0:00 dovecot/imap 19900 ? S 0:02 dovecot/imap 19901 ? S 0:00 dovecot/imap 19902 ? S 0:00 dovecot/imap . I wish it did give me the mailbox, is there a option to get it to give me that information? Thanks! - Jeremy On 6/9/2022 6:37, Paul Kudla (SCOM.CA Internet Services Inc.) wrote: ok the idle connection per folder is a factor however in thunderbird i believe it defaults to 2 simultanious connections mine is set to 5 in thunderbird see The solution is to reduce the maximum number of connections in Thunderbird. This can be done from Edit > Account Settings > Server Settings (under the mail account for which the setting should be modified) > Advanced > Maximum Number of server connections to cache. I dont know of anything that would get it to 500? as for outlook idle was not / is not supported past 2010 (if even that) you need to go into file --> options --> advanced --> send/receive all you can change in there is the timing which defaults to 30 minutes, i recommend 3 or 5 I am unaware of how outlook handles physical connections (maybe registery?) and google revieled nothing, outlook since 2010 just does not support imap, microsofts way of forcing everyone onto exchange / outlook 365 377,000 hits last time i googled imap issues in outlook. Best suggestion is to run # ps -axww | grep imap 25500 - S 0:00.57 imap: [p...@hiscomputer.ca 172.97.150.95 IDLE] (imap) 25530 - S 0:00.36 imap: [p...@hiscomputer.ca 172.97.150.95 IDLE] (imap) 26014 - I 0:00.39 imap: [rco...@tnky.ca 172.97.128.227 IDLE] (imap) 26018 - I 0:00.38 imap: [rco...@tnky.ca 172.97.128.227 IDLE] (imap) 26210 - I 0:00.07 imap: [spa...@scom.ca 99.238.154.160 IDLE] (imap) 38911 - S 0:00.17 imap: [marilynla...@scom.ca 142.188.149.199 IDLE] (imap) 38912 - S 0:00.13 imap: [marilynla...@scom.ca 142.188.149.199 IDLE] (imap) 41306 - S 0:00.73 imap: [ed.ha...@dssmgmt.com 204.237.48.37 IDLE] (imap) 41312 - S 0:00.63 imap: [ed.ha...@ekst.ca 204.237.48.37 IDLE] (imap) 45232 - I 0:00.23 imap: [rco...@tnky.ca 172.97.128.227 IDLE] (imap) 55504 - I 0:00.16 imap: [rco...@tnky.ca 172.97.128.227 IDLE] (imap) which shows all imap connections and from where if you are overflowing 500+ connections then it has to show up here. Happy Thursday !!! Thanks - paul Paul Kudla Scom.ca Internet Services <http://www.scom.ca> 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3 Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email p...@scom.ca On 6/8/2022 6:41 PM, Jeremy Schaeffer wrote: Ahhh, Ok, I did not know that and now that makes sense. I did not realize it held a open connection for each folder. I increased that and I will see what happens. I wonder if that will also effect the outlook issues. Thanks! - Jeremy On 6/8/2022 14:28, Frank-Ulrich Sommer wrote: I think if IMAP IDLE is used you need one connection per folder. If I remember correctly at least either Thunderbird or K9 Mail (I'm using both too) use one connection per selected directory. Simply increasing the number of connections was the easiest solution as I only have very few users too. Regards Frank Am 8. Juni 2022 21:14:23 MESZ schrieb Jeremy Schaeffer : I keep having this issue with one user, and I have to restart dovecot several times a day to clear it. What I have is a postfix / dovecot mail server (Centos 7) and about a dozen users. All mailboxes are imap ssl. I monitor about 4 mailboxes on my computer and tablet. I use Thunderbird on the computer (cache connections at 2) and K9 on the tablet, but one user of the four I keep getting "Maximum number of connections from user+IP exceeded" and I have the maximum at 50 "(mail_max_userip_connections=50)" so its hard for me to believe I am actually exceeding it unless dovecot/client is not dropping connections and keeps starting new ones until it reaches the maximum, but again, only for one user, even though I am monitoring 4 on the same devices. Any idea how to troubleshoot this? I don't know if I should be looking at dovecot or the clients, or what I need to look for. It's been going on since I put this server in use over a year ago. I also have issues with Outlook clients disconnecting, just outlook, is there any recommended settings to make Outlook work smoother
Re: Issue with one user only, exceeding connections
Thank you! That worked, I piped the output to a file, grep the username and sure enough there are 60 lines. So I guess going over 50 was a possibility. Learn something new every day. I set the maximum to 100 so I should not have any errors on that anymore. Thanks! - Jeremy On 6/9/2022 10:59, Richard wrote: Date: Thursday, June 09, 2022 10:46:25 -0500 From: Jeremy Schaeffer That was the first thing I tried, I lowered the cache connections in Thunderbird. Actually the max connections was 50, not 500, but I could see why as I do have a lot of folders, but what is odd is I have other mailboxes that have even more folders, but it's only one mailbox that is trowing the error. "# ps -axww | grep imap" does not give me the same results - . 19897 ? S 0:00 dovecot/imap 19900 ? S 0:02 dovecot/imap 19901 ? S 0:00 dovecot/imap 19902 ? S 0:00 dovecot/imap . I wish it did give me the mailbox, is there a option to get it to give me that information? Try "auxw" on your "ps". I.e., add in the "u" which will get you the user detail in the first column, otherwise you just get the process id.
Re: Issue with one user only, exceeding connections
Thanks for the command, that is very useful. That user is actually me, I know why where are so many open. I have my computer, and two tablets, and since I am using server side filtering (procmail) I have to set watch on all the folders that are filtered to or I miss a email. But I am doing the same for about 4 other users accounts I also monitor, so I am not sure why it's just my username that is doing that. I am going to shut down all the clients one at a time and see what client is opening all those connections. Once I close the client, I assume the connection should also close and the count go down, correct? I turned off both tablets and the connection count for my username still is at 60, since I am writing this email with my computer client I will send it and close my client and see what happens. Thanks! - Jeremy On 6/9/2022 11:29, Richard wrote: Date: Thursday, June 09, 2022 11:07:38 -0500 From: Jeremy Schaeffer On 6/9/2022 10:59, Richard wrote: Date: Thursday, June 09, 2022 10:46:25 -0500 From: Jeremy Schaeffer That was the first thing I tried, I lowered the cache connections in Thunderbird. Actually the max connections was 50, not 500, but I could see why as I do have a lot of folders, but what is odd is I have other mailboxes that have even more folders, but it's only one mailbox that is trowing the error. "# ps -axww | grep imap" does not give me the same results - . 19897 ? S 0:00 dovecot/imap 19900 ? S 0:02 dovecot/imap 19901 ? S 0:00 dovecot/imap 19902 ? S 0:00 dovecot/imap . I wish it did give me the mailbox, is there a option to get it to give me that information? Try "auxw" on your "ps". I.e., add in the "u" which will get you the user detail in the first column, otherwise you just get the process id. Thank you! That worked, I piped the output to a file, grep the username and sure enough there are 60 lines. So I guess going over 50 was a possibility. Learn something new every day. I set the maximum to 100 so I should not have any errors on that anymore. Rather than simply upping the limit I think a reasonable question to ask is why/how they are managing to do that. That's a lot of open folders. By the way, the single command: ps auxw | grep imap | cut -d" " -f1 | sort | uniq -c will get you a nice list with the users and their connection counts.
Re: Issue with one user only, exceeding connections
Ok, more information. I closed all my clients and checked the connection count. It was still at 57, so I cleared the user with "doveadm kick", count was then 0. I launched Thunderbird again and the count went to 16, then started my tablet and it when to 3. I am thinking I still have a issue as why when I closed all the clients I still had 57 threads/connections open, and after Thunderbird settled down it dropped its connections to 3, but over time that connection count rises. In the 5 min while writing this the connections jumped to 30. I turned off Wifi on my tablet so the client would use a different IP, the connection list went to 41 Now it went back to 59 open connections. I turned my tablet back off, its staying at 59. I kicked the user again. I am going to keep my tablet off, maybe it's the one causing this. Is there a way to find more information about what is going on in one of the pids? It would seem like one of the clients is opening up a connection and for some reason its not dropping and it keeps just opening up new ones, but there are no errors in the log files. Once I turn off the client the connections are not clearing. - Jeremy On 6/9/2022 11:44, Jeremy Schaeffer wrote: Thanks for the command, that is very useful. That user is actually me, I know why where are so many open. I have my computer, and two tablets, and since I am using server side filtering (procmail) I have to set watch on all the folders that are filtered to or I miss a email. But I am doing the same for about 4 other users accounts I also monitor, so I am not sure why it's just my username that is doing that. I am going to shut down all the clients one at a time and see what client is opening all those connections. Once I close the client, I assume the connection should also close and the count go down, correct? I turned off both tablets and the connection count for my username still is at 60, since I am writing this email with my computer client I will send it and close my client and see what happens. Thanks! - Jeremy On 6/9/2022 11:29, Richard wrote: Date: Thursday, June 09, 2022 11:07:38 -0500 From: Jeremy Schaeffer On 6/9/2022 10:59, Richard wrote: Date: Thursday, June 09, 2022 10:46:25 -0500 From: Jeremy Schaeffer That was the first thing I tried, I lowered the cache connections in Thunderbird. Actually the max connections was 50, not 500, but I could see why as I do have a lot of folders, but what is odd is I have other mailboxes that have even more folders, but it's only one mailbox that is trowing the error. "# ps -axww | grep imap" does not give me the same results - . 19897 ? S 0:00 dovecot/imap 19900 ? S 0:02 dovecot/imap 19901 ? S 0:00 dovecot/imap 19902 ? S 0:00 dovecot/imap . I wish it did give me the mailbox, is there a option to get it to give me that information? Try "auxw" on your "ps". I.e., add in the "u" which will get you the user detail in the first column, otherwise you just get the process id. Thank you! That worked, I piped the output to a file, grep the username and sure enough there are 60 lines. So I guess going over 50 was a possibility. Learn something new every day. I set the maximum to 100 so I should not have any errors on that anymore. Rather than simply upping the limit I think a reasonable question to ask is why/how they are managing to do that. That's a lot of open folders. By the way, the single command: ps auxw | grep imap | cut -d" " -f1 | sort | uniq -c will get you a nice list with the users and their connection counts.
compiled sieve files svbin ?
Hi, I have recently started using claws mail to manage my user sieve scripts using server dovecot-sieve_1%3a2.3.13+dfsg1-2_arm64.deb I originally edited ~/.dovecot.sieve to hold my script and I recall that ~/.dovecot.svbin was automatically generated on first use. (either that or I have forgotten that I had used sievec) Later I used claws mail to generate sieve scripts but they were written into directory ~/sieve/ In experimentation I changed ~/.dovecot.sieve into a link to my principal script ~/sieve/main.sieve The oddity now is that sieve seems to be working when there is no compiled version Should I expect a compiled .svbin version to be generated from claws client? Or generated by first run of the sieve server on the user account? Or should I manage the scripts with claws, but log in to the server later to generate the .svbin versions? In any event what effect does not having a .svbin version have on typical small installation? -- Jeremy
Re: Pigeonhole Sieve Vacation Reply-To peculiarity with inbound AWS-SES
On 7/2/23 22:01, Dr. Rolf Jansen wrote: To begin with, usage of Amazons Simple Email Service (SES) is mandatory for outgoing mails from AWS-EC2 instances. I run AWS-EC2 instances using postfix to send a receive mail. They can send direct assuming I set up suitable SPF, but they typically forward mail to another host under my control that is not on AWS to use as the outgoing server. Jeremy
Re: Pigeonhole Sieve Vacation Reply-To peculiarity with inbound AWS-SES
On 8/2/23 05:08, Dr. Rolf Jansen wrote: Am 07.02.2023 um 17:54 schrieb jeremy ardley: On 7/2/23 22:01, Dr. Rolf Jansen wrote: To begin with, usage of Amazons Simple Email Service (SES) is mandatory for outgoing mails from AWS-EC2 instances. I run AWS-EC2 instances using postfix to send a receive mail. They can send direct assuming I set up suitable SPF, but they typically forward mail to another host under my control that is not on AWS to use as the outgoing server. OK, that’s another use case. Many do use a full fledged Postfix/Dovecot installation. However the outgoing port 25 into the internet is blocked by AWS, and therefore we may either use a third party relay for our outgoing emails or may use SES, which is not that bad - except some unusual peculiarities. This is off topic, but to be precise: - AWS throttles but does not block traffic to a *destination* port 25. - The *origin* port on the EC2 instance is an unprivilged port, not port 25 - If you use a relayhost you typically send from an unprivilged EC2 port to port 587 on the relay host Jeremy
Re: Postfix : root and system user authentication
On 15/3/23 18:32, Odhiambo Washington wrote: On Wed, Mar 15, 2023 at 1:46 AM Aymeric Agon-Rambosson wrote: Hello everyone, From what I understand of the documentation, it is impossible to log in to the dovecot server as root, or as any user not in the interval between first_valid_uid and last_valid_uid. https://doc.dovecot.org/configuration_manual/authentication/master_users/ I understand the most common method of authentication used by dovecot is pam. Pam has no problem with authenticating root. Postfix uses dovecot (and hence pam) to authenticate users If dovecot won't allow root users to access dovecot services directly then that is a dovecot configuration separate from pam or any other authentication method. https://doc.dovecot.org/configuration_manual/authentication/pam/ Jeremy
Re: Postfix : root and system user authentication
On 16/3/23 06:31, Aymeric Agon-Rambosson wrote: I have a solution to my problem. For reference, I am putting it here : A simple way to restrict login based on uids is to modify the file as such : #%PAM-1.0 auth required pam_succeed_if.so uid > 500 quiet @include common-auth @include common-account @include common-session It is possible for dovecot sasl component to use different authorisation back-ends, such as LDAP, GSSAPI, MySQL etc. These do not necessarily have the ability to reject uid < 500. However, generally, these backends can be used by pam as well. In default debian installations: cat dovecot #%PAM-1.0 #auth required pam_faillock.so preauth silent audit #auth [default=die] pam_faillock.so authfail audit @include common-auth @include common-account @include common-session cat common-auth # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. A good practice would be to use postfix --> dovecot/sasl --> pam --> backend server and do the uid vetting in the dovecot pam configuration -- Jeremy
Re: Postfix : root and system user authentication
On 16/3/23 14:53, Aki Tuomi wrote: On 16/03/2023 03:58 EET jeremy ardley wrote: A good practice would be to use postfix --> dovecot/sasl --> pam --> backend server and do the uid vetting in the dovecot pam configuration Dovecot itself can reject uid < 500. Just set first_valid_uid = 500 and first_valid_gid = 500. Is that in the part of dovecot that 'does dovecot' or is that also in the part of dovecot that 'does SASL' Jeremy
[Dovecot] Problem with zlib plugin and flags
Hi, I'm working on enabling the zlib plugin and compressing most of the mail on my mail server, and I've run into a bit of a problem with doing things as described on the wiki's zlib plugin page (here: http://wiki.dovecot.org/Plugins/Zlib). I'm using Dovecot 1.2.15 and maildir as a mailbox format on Debian 5. I have a script that implements the steps listed at the bottom of the wiki page. The problem has to do with step 5, which recommends that you add a 'Z' flag to each email that you compress so that you don't compress it again. The problem that I ran into is that when you move an email to another mail folder, this flag appears to go away. As a result, my script has compressed some emails that were already compressed, rendering them unreadable by Dovecot. I've mostly solved that problem, and my compression script now runs 'file' and looks to see if it's gzipped already for each file that's a candidate for compression. I'm not sure this is the best solution (it's definitely slower than just checking the filename), so I'm open to better alternatives. Reading http://wiki.dovecot.org/MailboxFormat/Maildir, I see that Dovecot supports 'non-standard fields' specified after normal flags and a comma. It seems like that might be a better place to put the 'Z' flag, if Dovecot won't retain it when places with the normal flags. I'm unsure how the filename would look if it doesn't currently have any flags, though. Would there just be two commas in a row, followed by my non-standard flag? If I haven't missed or misconfigured anything and what I said above is correct, the wiki should be changed so others don't run into the same problems I have. I'm happy to do so, but I didn't want to make any changes without making sure I was right about what was going on. Thanks, Jeremy
[Dovecot] Can't receive mail for virtual user
I followed the dovecot instructions (
http://wiki.dovecot.org/HowTo/SimpleVirtualInstall) to create a simple
virtual user installation with the /etc/dovecot/passwd file. However,
whenever I try to send a message to the virtual user, Postfix has a problem
delivering it. Postfix is delivering messages to ~/Maildir, but Dovecot is
trying to use /home/vmail/. How can I get the 2 apps to work together?
I've set up SASL, SSL and Dovecot LDA.
Dovecot version: 1.0.13 (from source)
Postfix version: 2.5.1 (from source)
OS: Fedora Core 4
Here's are my config files:
DOVECOT
# 1.0.13: /usr/local/etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
protocols: imap pop3 imaps pop3s
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
mail_location: maildir:~/Maildir
dotlock_use_excl: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
pop3_uidl_format: %08Xu%08Xv
auth default:
mechanisms: plain login
verbose: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=postfix gid=postfix home=/home/vmail/%u
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /usr/local/var/run/dovecot/auth-master
mode: 384
user: vmail
--
POSTFIX (main.cf)
alias_maps = $alias_database
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = mixermixer3.com
myhostname = mixermixer3.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix/
readme_directory = no
relay_domains = $mydestination
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_timeout = 3600s
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = mixermixer3.com
virtual_transport = dovecot
--
POSTFIX (a few key lines from master.cf)
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
smtp unix - - n - - smtp
# Dovecot LDA
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${recipient}
THANKS,
Jeremy
[Dovecot] Client can't connect to SMTP
I've just installed Dovecot and Postfix and my email client (Mac Mail)
cannot authenticate with the SMTP server. The error I receive says that
"The SMTP server doesn't support SSL (TLS) on port 465" -- yet, I've
installed SSL. Is there any good way to test or debug this?
Setup:
* SSL
* Dovecot SASL
* Dovecot LDA
* Virtual Users (http://wiki.dovecot.org/HowTo/SimpleVirtualInstall)
Client SMTP Setup:
* Use SSL
* Port: 465
* Authentication: Password
By the way, I followed these instructions:
http://wiki.dovecot.org/HowTo/SimpleVirtualInstall
Dovecot version: 1.0.13 (from source)
Postfix version: 2.5.1 (from source)
OS: Fedora Core 4
Here's are my config files:
DOVECOT
# 1.0.13: /usr/local/etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
protocols: imap pop3 imaps pop3s
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
mail_location: maildir:~/Maildir
dotlock_use_excl: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
pop3_uidl_format: %08Xu%08Xv
auth default:
mechanisms: plain login
verbose: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=postfix gid=postfix home=/home/vmail/%u
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /usr/local/var/run/dovecot/auth-master
mode: 384
user: vmail
--
POSTFIX (main.cf)
alias_maps = $alias_database
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = mixermixer3.com
myhostname = mixermixer3.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix/
readme_directory = no
relay_domains = $mydestination
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_timeout = 3600s
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = mixermixer3.com
virtual_transport = dovecot
--
POSTFIX (a few key lines from master.cf)
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
smtp unix - - n - - smtp
# Dovecot LDA
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${recipient}
THANKS,
Jeremy
[Dovecot] Dovecot SASL doesn't seem to be working with Postfix
I've tried to setup Postfix to use SASL, but it still doesn't seem to be
working with Dovecot. I've set things up based on these instructions:
http://wiki.dovecot.org/HowTo/SimpleVirtualInstall
http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
http://wiki.dovecot.org/LDA
I've compiled Postfix with Dovecot SASL and SSL/TLS support. The problems
I'm seeing in Postfix are:
* Virtual users are not being recognized (it'll only delivers mail for
local users)
* For mail it does deliver, it uses the local user permissions ( I want it
to use the vmail user)
* I had to modify 'mail_spool_directory' to get it to use the /home/vmail/
directory
* For mail delivered to local users, it still doesn't come up in my email
client when I check for new mail.
I just keep feeling like the SASL integration is not working. Can anybody
shed some light?
---
DOVECOT config
# 1.0.13: /usr/local/etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
protocols: imap pop3 imaps pop3s
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
mail_location: maildir:~/Maildir
dotlock_use_excl: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
pop3_uidl_format: %08Xu%08Xv
auth default:
mechanisms: plain login
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=postfix gid=postfix home=/home/vmail/%u
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /usr/local/var/run/dovecot/auth-master
mode: 384
user: vmail
POSTFIX main.cf
alias_maps = $alias_database
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_privs = nobody
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mail_spool_directory = /home/vmail/
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = $myhostname
myhostname = mixermixer3.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix/
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_timeout = 3600s
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = $myhostname
virtual_transport = dovecot
POSTFIX master.cf (just the important lines)
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${recipient}
THANKS,
Jeremy
Re: [Dovecot] Dovecot SASL doesn't seem to be working with Postfix
If I setup the virtual users in Dovecot and enable SASL in Postfix, does that mean that Postfix should use Dovecot for authentication and for the virtual user table? Is there anything I need to do outside the following to instruction URLs to make this work? http://wiki.dovecot.org/HowTo/SimpleVirtualInstall http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL I'm reading the ADDRESS_CLASS_README, but it seems like I'll have to mirror the settings from Dovecot to Postfix. That doesn't seem right: http://www.postfix.org/ADDRESS_CLASS_README.html Thanks, Jeremy
Re: [Dovecot] Dovecot SASL doesn't seem to be working with Postfix
w00t. Thanks everyone for all your input. It works now. The key was to set
mydestination to "localhost, localhost.localdomain". From there Postfix
started using Dovecot LDA (deliver) and I was able to track the rest of the
problems down through the log files.
Here's my latest config for anybody interested:
## DOVECOT ##
# 1.0.13: /usr/local/etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
protocols: imap pop3 imaps pop3s
disable_plaintext_auth: no
verbose_ssl: yes
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
mail_location: maildir:~/Maildir
dotlock_use_excl: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
pop3_uidl_format: %08Xu%08Xv
auth default:
mechanisms: plain login
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=postfix gid=postfix home=/home/vmail/%u
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /usr/local/var/run/dovecot/auth-master
mode: 384
user: vmail
group: vmail
## POSTFIX main.cf ##
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_privs = nobody
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mail_spool_directory = /home/vmail/
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = localhost, localhost.localdomain
mydomain = $myhostname
myhostname = mixermixer3.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix/
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_timeout = 3600s
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = $myhostname
virtual_transport = dovecot
## POSTFIX (a few lines from master.cf) ##
smtp inet n - n - - smtpd
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
# Dovecot LDA
dovecot unix - n n - - pipe
flags=DRhu user=nobody:mail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${recipient}
Thanks Everyone!
- Jeremy
[Dovecot] dovecot-antispam plugin and "Failed to call dspam" message
Hi,
I had this working until I recently upgraded Dovecot, and now I'm getting a
message back from
Thunderbird of "Failed to call dspam." when I attempt to move a message into
one of the designated
spam folders.
However, I know from looking at the dspam system.log file, the retraining
actually happens - so it
-does- appear to be calling dspam. It appears that the 'move' operation fails.
Here's my configuration:
dovecot 1.1.16 (built from ports)
dovecot-antispam 1.1 (tried from ports as well as unmodified source)
dspam 3.6.8 (built from ports)
FreeBSD 7.1
Relevant sections from dovecot.conf:
protocol imap {
mail_plugins = antispam
mail_plugin_dir = /usr/local/lib/dovecot/imap
...
}
plugin {
antispam_signature = X-DSPAM-Signature
antispam_spam = SPAM;spam;Junk
antispam_trash = Deleted Messages;Trash;INBOX.Trash
antispam_dspam_binary = /usr/local/bin/dspam
antispam_dspam_args = --deliver=;--user;%u
...
}
.config used by dovecot-antispam:
DOVECOT=/usr/ports/mail/dovecot/work/dovecot-1.1.16
BACKEND=dspam-exec
PLUGINNAME=antispam
DEBUG=syslog
DEBUG_VERBOSE=1
(I've tried it both with and without the DEBUG lines present in .config)
Plugin debug log when I attempt to move a message:
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(SPAM): 0
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(INBOX): 0
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(SPAM): 0
Jun 13 09:29:07 stelleri imap: antispam: mail copy: from trash: 0, to trash: 0
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(INBOX): 0
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(SPAM): 1
Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(INBOX): 0
Jun 13 09:29:07 stelleri imap: antispam: mail copy: src spam: 0, dst spam: 1,
src unsure: 0
Jun 13 09:29:07 stelleri imap: antispam: /usr/local/bin/dspam --source=error
--class=spam
--signature=4a339984859385209328925 --deliver= --user frysco
Associated log from dspam system.log:
1244903347 M 4a339984859385209328925
0.066815frysco Retrained
Any help appreciated,
Thanks,
-jcd
Re: [Dovecot] dovecot-antispam plugin and "Failed to call dspam" message
Harlan Stenn wrote: > It is probably a good idea to figure out the underlying problem instead > of ignoring it. > > I use the following patch... Oh, I agree. The extra logging only produced these extra lines in the logs: > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_unsure(SPAM): 0 > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_trash(INBOX): 0 > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_trash(SPAM): 0 > Jun 13 15:35:18 stelleri imap: antispam: mail copy: from trash: 0, to trash: 0 > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_spam(INBOX): 0 > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_spam(SPAM): 1 > Jun 13 15:35:18 stelleri imap: antispam: mailbox_is_unsure(INBOX): 0 > Jun 13 15:35:18 stelleri imap: antispam: mail copy: src spam: 0, dst spam: 1, > src unsure: 0 > Jun 13 15:35:18 stelleri imap: antispam: /usr/local/bin/dspam --source=error > --class=spam --signature=4a339984859385209328925 --deliver= --user frysco > Jun 13 15:35:18 stelleri imap: antispam: error: dspam returned <57397: > [06/13/2009 15:35:18] query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): > see sql.errors for more details > > Jun 13 15:35:18 stelleri imap: antispam: error: dspam returned <57397: > [06/13/2009 15:35:18] query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): > see sql.errors for more details > Could the plugin be getting hung up on the 'verbose debug' messages that dspam seems to be insistent upon producing? (I'm not sure how to disable the writing to sql.errors) Thanks, -jcd
Re: [Dovecot] dovecot-antispam plugin and "Failed to call dspam" message
Marcin Rzepecki wrote: > Sat, Jun 13, 2009 at 07:34:49AM -0700, Jeremy Doran wrote: >> Hi, >> >> I had this working until I recently upgraded Dovecot, and now I'm getting a >> message back from >> Thunderbird of "Failed to call dspam." when I attempt to move a message into >> one of the designated >> spam folders. >> >> However, I know from looking at the dspam system.log file, the retraining >> actually happens - so it >> -does- appear to be calling dspam. It appears that the 'move' operation >> fails. >> [...] > > Hi Jeremy, > i've tried to figure it out some time ago. As you mentioned, dspam is > called ok, however error is still reported. > I'm applying following patch to avoid reporting error and all is working > great for me. I'm using dspam-devel version, but it should not make no > difference. > This did suppress the error and the move to the 'spam' mailbox succeeded. Though, it would be good to know why it trips over. Thanks, -jcd
Re: [Dovecot] dovecot-antispam plugin and "Failed to call dspam" message
Johannes Berg wrote: > Hi, > >> However, I know from looking at the dspam system.log file, the retraining >> actually happens - so it >> -does- appear to be calling dspam. It appears that the 'move' operation >> fails. > >> Plugin debug log when I attempt to move a message: >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(SPAM): 0 >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(INBOX): 0 >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_trash(SPAM): 0 >> Jun 13 09:29:07 stelleri imap: antispam: mail copy: from trash: 0, to trash: >> 0 >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(INBOX): 0 >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_spam(SPAM): 1 >> Jun 13 09:29:07 stelleri imap: antispam: mailbox_is_unsure(INBOX): 0 >> Jun 13 09:29:07 stelleri imap: antispam: mail copy: src spam: 0, dst spam: >> 1, src unsure: 0 >> Jun 13 09:29:07 stelleri imap: antispam: /usr/local/bin/dspam --source=error >> --class=spam >> --signature=4a339984859385209328925 --deliver= --user frysco >> >> Associated log from dspam system.log: >> 1244903347 M 4a339984859385209328925 >> >> 0.066815frysco Retrained > > I have no idea what's going on, obviously, but please verify that the > above dspam command line > 1) exits with exit code 0 > 2) doesn't print anything to stderr > > Both of these are taken by the plugin as an indication that something > went wrong, because dspam's error reporting was _severely_ lacking at > the time I wrote the plugin. It might have improved in the meantime, I > have no idea. It certainly seems to be the 'verbose debug' information that DSpam prints to stderr that triggers this. After testing with the patches from Marcin Rzepecki and Harlan Stenn, I managed completely disabled these kind of lines from being sent: > Jun 13 15:35:18 stelleri imap: antispam: error: dspam returned <57397: > [06/13/2009 15:35:18] query error: VERBOSE DEBUG (INFO ONLY - NOT AN ERROR): > see sql.errors for more details > I then put in the unaltered FreeBSD ports version of the plugin, and no longer got the "Failed to call dspam" messages. Since these messages - even though non-zero and stating that they aren't an error - are just informational, I'd think that it might be an idea to have the plugin detect and ignore that. Turning on DSpam debugging should not (I should think) break the plugin from working. Thanks, -jcd
[Dovecot] Trying to get DSpam+Dovecot working with Postfix and local/virtual domains
Hi,
I'm hoping that someone might be able to help, as I've been going in
circles with trying to get the right configuration done here. I'm also
not sure whether this is more of a Dovecot or DSpam question, so I'm
posting the same to both mailing lists.
My goal is to have a mail setup that is as follows:
[Incoming email] --> [Postfix] --> [Amavis] --> [DSpam] --> [Dovecot
LDA] -+---(local domain)---> /var/mail/${user}
|
+---(virtual)---> /home/vmail/${domain}/${user}@{domain}
As of right now, I have Postfix successfully feeding into Amavis,
re-injecting into Postfix with a final delivery for the local domain via
procmail, and final delivery for virtual domains via the virtual
transport into maildir (but /home/vmail/${user}@${domain})
Virtual domains are being managed by PostfixAdmin. Dovecot is running as
the IMAP server. Everything (Postfix, PostfixAdmin, Dovecot) is using a
Postgres database as backend for the dynamic maps/authentication.
The problem I've been stumbling over is trying to get DSpam to work
nicely with both a local domain and virtual domains/mailboxes, and the
same for Dovecot, as I would rather like to make use of the Sieve
functionality going forward instead of Procmail. I did have DSpam
working, but was unable to get the Dovecot antispam plugin working to
re-train based on moving mails into/out of a defined 'SPAM' folder, due
to permissions relating to how the antispam plugin was calling DSpam.
I'm really not wanting to make the local domain into a virtual mailbox
domain, because there are users on the system (for that local domain)
that already use the password in /etc/passwd for accessing the server
for other uses. While there are also people who do that who have virtual
mailbox domains, it's a far lower number.
Here's what I have so far.
Postfix 2.11.0
main.cf (via 'postconf -nf'):
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
html_directory = /usr/local/share/doc/postfix
inet_interfaces = all
inet_protocols = ipv4 ipv6
local_recipient_maps = $transport_maps unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_command = /usr/local/bin/procmail -a "$EXTENSION"
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain, $mydomain
mydomain = critter.net
myhostname = cornix.critter.net
mynetworks = 127.0.0.0/8, 46.4.24.15/32, [::1]/128,
[2a01:4f8:131:4263::]/64,
184.73.168.110/32, [2001:470:7:12ba::]/64
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
receive_override_options = no_address_mappings
recipient_delimiter = -
relay_domains = pgsql:$config_directory/Maps/pgsql_relay_domains_maps.cf
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_CAfile = /etc/ssl/certs/Critter.Net_Certificate_Authority.pem
smtp_tls_cert_file = /etc/ssl/certs/smtp.critter.net.pem
smtp_tls_key_file = /etc/ssl/private/smtp.critter.net.pem
smtp_tls_session_cache_database = /var/db/postfix/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_destination, reject_unauth_pipelining,
reject_invalid_hostname, reject_rbl_client zen.spamhaus.org,
check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/certs/Critter.Net_Certificate_Authority.pem
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /etc/ssl/certs/smtp.critter.net.pem
smtpd_tls_key_file = /etc/ssl/private/smtp.critter.net.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
smtpd_use_tls = yes
soft_bounce = yes
tls_random_source = dev:/dev/urandom
transport_maps = pgsql:$config_directory/Maps/pgsql_transport_maps.cf
unknown_local_recipient_reject_code = 450
virtual_alias_maps =
pgsql:$config_directory/Maps/pgsql_virtual_alias_maps.cf
virtual_gid_maps = static:400
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains =
pgsql:$c
Dovecot Pre-Login Scripting
Hello, We are in the process of migrating users from one system that is currently not hosted by our company, to our dovecot 2.2.10 installation. We are planning on doing the dovecot dsync command for copying users mail over to the new installation, but the one snag we are running into is ensuring we are able to get the users credentials stored in our system. We are migrating the email from a Gmail ISP account to our installation as they are discontinuing their support next year. The setup is a multistep process we are hoping to accomplish. When a connection is started to our cluster, it will first check the database to see if the credentials match, if not it will verify against Gmail's servers. If the Gmail test is successful, it would pass the credentials to a script to store them for future login attempts. Once the authentication is verified and stored locally, we would run a post-login script to run dsync to copy the mail down to the new system. The problem we are running into is efficiently and appropriately hooking into the dovecot authentication process. We are unable to find anything regarding PreLogin Scripting to contrast the PostLoginScripting we are currently using, and the only other thing we are currently seeing as a possible option is running a custom authentication socket or password imap-login to a script. This seems like it would be a resource nightmare depending on the server load and are hoping for a more elegant option to be unveiled. Any other options or suggestions are welcome. We are also wondering, if we have to go with the custom authentication setup, if there are any examples out there to base our scripts off in setting it up. Thank you, Jeremy
[Dovecot] Can't send/receive mail from other domain
I've followed the instructions (
http://wiki.dovecot.org/DovecotLDAPostfixAdminMySQL) to setup Dovecot with
MySql and Postfix but cannot receive from (or send mail to) other domains.
FYI: email messages are supposed to be stored under
/var/mail/mozmonkey.com//
Directory Permissions: drwxr-xr-x 5 vmail mail4096 May 10 12:57
mozmonkey.com
OS: Linux, Fedora 4
Dovecot version: 1.0.0
- CONFIG START -
$ sudo dovecot -n
# /etc/dovecot.conf
base_dir: /var/run/dovecot/
protocols: imap pop3 imaps pop3s
ssl_listen: [::]
login_dir: /var/run/dovecot//login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
login_greeting_capability(default): yes
login_greeting_capability(imap): yes
login_greeting_capability(pop3): no
first_valid_uid: 101
last_valid_uid: 101
mail_extra_groups: mail
mail_location: maildir:/var/mail/%d/%u
mail_debug: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
auth default:
mechanisms: plain digest-md5 cram-md5
user: nobody
debug: yes
debug_passwords: yes
passdb:
driver: sql
args: /etc/dovecot/sql.conf
userdb:
driver: sql
args: /etc/dovecot/sql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: vmail
group: mail
master:
path: /var/run/dovecot/auth-master
mode: 384
user: vmail
group: mail
- CONFIG END -
- LOG START (modified email address to prevent spam) -
Jun 10 22:48:23 mozmonkey postfix/smtpd[27592]: connect from
n9.bullet.re3.yahoo.com[68.142.237.94]
Jun 10 22:48:23 mozmonkey postfix/trivial-rewrite[27595]: warning: do not
list domain mozmonkey.com in BOTH mydestination and virtual_mailbox_domains
Jun 10 22:48:23 mozmonkey postfix/smtpd[27592]: C0093210021: client=
n9.bullet.re3.yahoo.com[68.142.237.94]
Jun 10 22:48:23 mozmonkey postfix/cleanup[27599]: C0093210021: message-id=<
[EMAIL PROTECTED]>
Jun 10 22:48:23 mozmonkey postfix/qmgr[27282]: C0093210021: from=<
[EMAIL PROTECTED]>, size=2242, nrcpt=1 (queue active)
Jun 10 22:48:23 mozmonkey postfix/trivial-rewrite[27595]: warning: do not
list domain mozmonkey.com in BOTH mydestination and virtual_mailbox_domains
Jun 10 22:48:23 mozmonkey postfix/local[27600]: warning: dict_nis_init: NIS
domain name not set - NIS lookups disabled
Jun 10 22:48:23 mozmonkey postfix/smtpd[27592]: disconnect from
n9.bullet.re3.yahoo.com[68.142.237.94]
Jun 10 22:48:23 mozmonkey postfix/local[27600]: C0093210021: to=<
[EMAIL PROTECTED]>, relay=local, delay=0.27, delays=0.2/0.03/0/0.04, dsn=
5.2.0, status=bounced (cannot update mailbox /var/mail/jerxyz for user
jerxyz. cannot open file: Permission denied)
Jun 10 22:48:24 mozmonkey postfix/cleanup[27599]: 041A7210033: message-id=<
[EMAIL PROTECTED]>
Jun 10 22:48:24 mozmonkey postfix/qmgr[27282]: 041A7210033: from=<>,
size=4181, nrcpt=1 (queue active)
Jun 10 22:48:24 mozmonkey postfix/bounce[27602]: C0093210021: sender
non-delivery notification: 041A7210033
Jun 10 22:48:24 mozmonkey postfix/qmgr[27282]: C0093210021: removed
Jun 10 22:48:24 mozmonkey dovecot: auth(default): master in: USER
1 [EMAIL PROTECTED] service=deliver
Jun 10 22:48:24 mozmonkey dovecot: auth-worker(default): sql(
[EMAIL PROTECTED]): SELECT concat('/var/mail/', maildir) as home,
concat('maildir:/var/mail/', maildir) as mail, 101 AS uid, 12 AS gid,
concat('dirsize:storage=', quota) AS quota FROM mailbox WHERE (username = '
[EMAIL PROTECTED]' OR simpleuser = '[EMAIL PROTECTED]') AND
active = '1'
Jun 10 22:48:24 mozmonkey dovecot: auth-worker(default): sql(
[EMAIL PROTECTED]): User not found
Jun 10 22:48:24 mozmonkey dovecot: auth(default): master out: NOTFOUND 1
Jun 10 22:48:24 mozmonkey postfix/pipe[27603]: 041A7210033: to=<
[EMAIL PROTECTED]>, relay=dovecot, delay=0.08, delays=0.02/0.03/0/0.03,
dsn=5.1.1, status=bounced (user unknown)
Jun 10 22:48:24 mozmonkey postfix/qmgr[27282]: 041A7210033: removed
- LOG END -
Thanks,
Jeremy
[Dovecot] Can't connect to SMTP outside localhost
I have Dovecot setup with Postfix and can't seem to connect to to the SMTP server (port 25) unless I'm on the server itself (telnet localhost 25). For example, I cannot use my mail client, Thunderbird, to send mail from my laptop -- it cannot even connect to the server. I checked the logs and nothing shows up for the attempted connection. Dovecot version: 1.0.0 Postfix version: 2.3.6 -- START DOVECOT CONFIG -- $ sudo dovecot -n # /etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap pop3 imaps pop3s ssl_listen: [::] login_dir: /var/run/dovecot//login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no first_valid_uid: 101 last_valid_uid: 101 mail_extra_groups: mail mail_location: maildir:/var/mail/%d/%u mail_debug: yes maildir_copy_with_hardlinks: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: mechanisms: plain digest-md5 cram-md5 user: nobody debug: yes debug_passwords: yes passdb: driver: sql args: /etc/dovecot/sql.conf userdb: driver: sql args: /etc/dovecot/sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: vmail group: mail master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: mail -- END DOVECOT CONFIG -- -- POSTFIX CONFIG (main.cf) -- queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix mail_owner = postfix myhostname = mozmonkey.com mydomain = mozmonkey.com inet_interfaces = $myhostname, localhost mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain local_recipient_maps = $virtual_mailbox_maps unknown_local_recipient_reject_code = 550 mail_spool_directory = /var/mail debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.3.6/samples readme_directory = /usr/share/doc/postfix-2.3.6/README_FILES address_verify_map = btree:/var/spool/postfix/address_verify virtual_mailbox_domains = proxy:mysql:$config_directory/mysql_virtual_domains_maps.cf virtual_mailbox_base= /var/mail virtual_mailbox_maps= proxy:mysql:$config_directory/mysql_virtual_mailbox_maps.cf virtual_alias_maps = proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_minimum_uid = 101 virtual_uid_maps= static:101 virtual_gid_maps= static:12 virtual_transport = dovecot dovecot_destination_recipient_limit = 1 smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain= $myhostname smtpd_sasl_exceptions_networks = $mynetworks smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients= yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtp_tls_CAfile = /etc/pki/tls/cert.pem smtp_tls_cert_file = /etc/pki/tls/certs/localhost.crt smtp_tls_key_file = /etc/pki/tls/private/localhost.key smtp_tls_session_cache_database = btree:/var/spool/postfix/smtp_tls_session_cache smtp_tls_security_level = may smtpd_tls_dh1024_param_file = $config_directory/dh_1024.pem smtpd_tls_dh512_param_file = $config_directory/dh_512.pem smtpd_tls_received_header = yes smtpd_tls_ask_ccert = yes smtpd_tls_loglevel = 1 tls_random_source = dev:/dev/urandom relay_domains = proxy:mysql:$config_directory/mysql_relay_domains_maps.cf -- POSTFIX CONFIG END (main.cf) -- -- POSTFIX CONFIG (master.cf) -- smtp inet n - n - - smtpd smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n
Re: Possible hack via doveadm
On 14/5/23 09:14, Daniel L. Miller via dovecot wrote: May 12 15:45:58 cloud1 dovecot: doveadm(194.165.16.78): Error: doveadm client not compatible with this server (mixed old and new binaries?) May 13 03:44:31 cloud1 dovecot: doveadm(45.227.254.48): Error: doveadm client not compatible with this server (mixed old and new binaries?) Since I don't recognize those IPs, the first is out of Panama and the other is Belize, I assume these are hostile attackers trying to exploit something. How can I defend against this? Set up a firewall rule that only allows access from an IP range you control. For any other source, simply drop the connection. You can get really fancy and use port forwarding using ssh to connect from remote but appear as localhost to the server. This access can be configured in dovecot as well as firewall Jeremy ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Possible hack via doveadm
On 14/5/23 23:29, Daniel Miller via dovecot wrote:
I only allow explicit service traffic through. IMAPS, SMTPS, etc. If
doveadm is communicating via the IMAP(S) ports then all I can do via
firewall is block countries. Which of course I can but I'm asking
about any additional hardening for Dovecot itself.
You can set up a doveadm service that requires client certificates
service doveadm {
inet_listener {
port = 12345
}
ssl = yes
ssl_cert = ___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 07:25, Richard Troy wrote:
The relaying only started and stopped when Dovecot was turned on or off.
Isn't it true that Dovecot performs an authentication function for
inbound connect requests, the successful of which then may use the
submission mechanism from what Postfix takes to be an internal
connection to send emails? Is this mistaken?
However, I get your point and I've spent a lot of work on that area.
And, you may well be right that that's where I need to turn - that is,
to Postfix. Thanks for the link.
The problem will likely be postfix.
However if your dovecot SASL is broken, say always permitting access
with or without correct password, then there will be a problem
This is part of my postfix configuration aand my system doesn't relay.
The key lines are all those with
permit_sasl_authenticated
---
relay_domains = $mydestination
unknown_local_recipient_reject_code = 550
unknown_client_reject_code = 550
#home_mailbox = Maildir/
mailbox_transport = lmtp:unix:private/dovecot-lmtp
#transport_maps = hash:/etc/postfix/transport
# Junk controls
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
# reject_rbl_client dnsbl-1.uceprotect.net
# reject_rbl_client cbl.abuseat.org
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_pipelining
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_destination
permit
# reject_rbl_client zen.spamhaus.org
# reject_rbl_client bl.spamcop.net
smtpd_sender_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unknown_sender_domain
reject_unknown_reverse_client_hostname
reject_unknown_client_hostname
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
# Redirect mail
smtp_header_checks = regexp:/etc/postfix/smtp_header_checks
# Reduce the time Postfix will sit idle after a client issues STARTTLS.
smtpd_starttls_timeout = 60s
# Renegotiate TLS sessions every hour.
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
# Enable SMTP AUTH.
# This requires TLS on port 25
smtpd_sasl_auth_enable = yes
# Don't allow anonymous logins. DO NOT add noplaintext here, or
# authentication with saslauthd will become impossible.
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
# Some clients send malformed AUTH commands.
broken_sasl_auth_clients = yes
# Only allow AUTH when a TLS session is active, to reduce the
# possibility for password and message body snooping.
smtpd_tls_auth_only = yes
# Tarpitting
smtpd_error_sleep_time = 50
smtpd_hard_error_limit = 2
smtpd_soft_error_limit = 1
smtpd_junk_command_limit = 10
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mailbox_size_limit = 0
recipient_delimiter = +
inet_protocols = all
compatibility_level = 3.6
policy-spf_time_limit = 3600s
html_directory = /usr/share/doc/postfix/html
# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
smtputf8_enable = no
postscreen_access_list = permit_mynetworks
postscreen_blacklist_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = swl.spamhaus.org*-4
list.dnswl.org=127.0.[0..255].[1..3]*-5
zen.spamhaus.org=127.0.[1..2].[0..255]*3
b.barracudacentral.org*2
bl.spameatingmonkey.net
bl.spamcop.net
postscreen_dnsbl_threshold = 2
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
--
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 09:17, Richard Troy wrote: However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem I DID find a discrepancy: smtpd_helo_restrictions did NOT have permit_sasl_authenticated. I made the change, of course and with that done, am now going to open the ports and renew my vigil for relays! Fingers crossed! Thanks, Jeremy - even if it doesn't work, it's a good clean shot at a fix! And, if that was it, it's easy to see how that could be overlooked. . . Richard smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination Is most useful to you. The defer means reject after a delay - tarpitting This leaves you to verify if the sasl authentication is working correctly. That is a real exercise as it has multiple config elements in dovecot and then PAM /etc/pam.d/dovecot then calls multiple configs in /etc/pam.d and specifically /etc/pam.d/common-auth in my case I am using only the local user database for dovecot grep -v '^#' common-auth auth [success=1 default=ignore] pam_unix.so nullok auth requisite pam_deny.so auth required pam_permit.so It is quite possible to use remote servers such as ldap and kerberos rather than your local user table ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot and postfix, authentication issue
On 6/7/23 10:17, joe a wrote:
Greetings from a new dovecot user.
Have setup dovecot on openSuse 15.4 with postfix as the MTA. Both are
the latest version in that distribution.
Simple virtual user setup using /etc/dovecot/passwd
Dovecot seems to be working and all the defined users are
authenticating well enough for imapsync to migrate files to the
mailboxes.
However, when attempting to send test mail via postfix, only some
users are authenticated and have mail delivered. Using swaks (smtp
toolkit) the failures are: 550 5.1.1 :
Recipient address rejected: User unknown in local recipient table
I'm puzzled, probably some simple thing overlooked. To avoid clutter,
I won't include postfix items unless asked.
dovecot --version 2.3.20 (80a5ac675d)
dovecot -n
# 2.3.20 (80a5ac675d): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.20 (149edcf2)
# OS: Linux 5.14.21-150400.24.66-default x86_64
# Hostname: flitch
auth_verbose = ob-fuskate
disable_plaintext_auth = no
first_valid_uid = 100
info_log_path = /var/log/dovecot-info.log
log_path = /var/log/dovecot.log
mail_location = maildir:~/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart
extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/passwd
driver = passwd-file
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
ssl = no
ssl_cipher_list =
ALL:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH
ssl_options = no_compression
ssl_prefer_server_ciphers = yes
userdb {
driver = passwd
}
userdb {
args = uid=vmail gid=vmail home=/home/vmail/%u
driver = static
}
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
The issue you're experiencing might be due to the fact that you have two
passdb and userdb blocks in your configuration. Dovecot will use the
first passdb and userdb that successfully authenticate a user, and
ignore the rest.
In your configuration, the first passdb block uses PAM for
authentication, and the first userdb block uses the system's passwd
file. The second passdb and userdb blocks, which use a Dovecot-specific
passwd file and static userdb, will only be used if PAM authentication
fails.
If some of your users are defined in the Dovecot passwd file and not in
the system's passwd file, they will not be able to authenticate because
Dovecot will stop at the first passdb and userdb blocks.
To fix this, you could merge your passdb and userdb blocks into single
blocks that use both PAM and passwd-file/static methods. Here's an example:
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/passwd
driver = passwd-file
}
userdb {
driver = passwd
}
userdb {
args = uid=vmail gid=vmail home=/home/vmail/%u
driver = static
}
--
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot and postfix, authentication issue
On 6/7/23 19:15, joe a wrote: If your example was meant to show the correct way, I cannot see any difference between that and what my posted config shows other than the sequential (contiguous?) in your example. Perhaps try the different configuration out? Or even better, stick to one auithentication method only. Jeremy -- ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Fwd: dovecot and postfix, authentication issue
On 6/7/23 20:49, joe a wrote:
On 7/6/2023 8:12 AM, jeremy ardley via dovecot wrote:
On 6/7/23 19:15, joe a wrote:
If your example was meant to show the correct way, I cannot see any
difference between that and what my posted config shows other than
the sequential (contiguous?) in your example.
Perhaps try the different configuration out? Or even better, stick to
one auithentication method only.
Jeremy
Sorry, not to appear dense or argumentative, but I did not see any
difference in your example, vs what exists, other than that in your
example they are grouped together.
Is that what you suggest I try, or are my aging eyes and brain missing
something there?
How about just using PAM?
In dovecot.conf :
auth_mechanisms = plain login
passdb {
driver = pam
}
userdb {
driver = passwd
}
This will then call pam whose config is mainly determined by
cat /etc/pam.d/dovecot
#%PAM-1.0
#auth required pam_faillock.so preauth silent audit
#auth [default=die] pam_faillock.so authfail audit
@include common-auth
@include common-account
@include common-session
Assuming the pam config is defaults then you will get pam authenticating
local users against the local (unix) passwd file. In turn this will
authenticate dovecot users and then postfix users
This may sound complex but it's pretty standard to have postfix -->
dovecot --> pam --> unix_local
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot with Postfix "no SASL authentication mechanisms"
On 4/9/23 14:03, Willy Manga wrote: "fatal: no SASL authentication mechanisms" -- try setting in dovecot auth_debug = yes auth_verbose = yes and then restart both services and check logs when the problem occurs. Also, be aware that dovecot usually 'subcontracts' the auth process to pam, so checking the contents of /etc/pam.d/dovecot could be helpful ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [SOLVED] Dovecot with Postfix "no SASL authentication mechanisms"
On 5/9/23 14:31, Michel Verdier wrote:
dovecot with PAM needs plaintext method. So if postfix disable it they
can't share a method.
You have to be careful to require any plaintext client password to
travel over a TLS secured connection
smtpd_tls_auth_only = yes
More generally, it's good practice to use preferred ciphers and
protocols. This is part of my postfix configuration:
# TLS parameters
tls_random_source = dev:/dev/urandom
smtpd_use_tls = yes
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_security_level = may
smtpd_tls_ask_ccert = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_dh1024_param_file = /etc/pki/tls/private/postfix.dh.param
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtp_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# From Redhat
# Alternat Protocols TLSv1.2 only
smtpd_tls_mandatory_protocols = !SSLv2
smtpd_tls_protocols = !SSLv2
smtp_tls_mandatory_protocols = !SSLv2
smtp_tls_protocols = !SSLv2
# Ciphers
# Currently recommended ciphers, excluding DES-based ciphers to avoid
SWEET32 attack
# and remove SHA1-based ciphers, leaves SHA256 & SHA256 variations
smtp_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2
smtpd_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2
tls_high_cipherlist =
kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!SHA
smtp_tls_ciphers = high
smtpd_tls_ciphers = high
# End from Redhat
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 05:00, joe a wrote: Any known issues with installing/running roundcube and dovecot on the same server? There is a generic issue with doing this. That is if you have roundcube (or any other web mail interface) on the same server as dovecot, a breach of the web interface could be quite serious and allow access to the complete mail store. A better configuration is to run the web mail interface on an isolated server and get it to communicate using TLS imap with a remote dovecot service. For economy, you could do this on the same machine using a small virtual server to run roundcube ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 07:38, dovecot--- via dovecot wrote: Roundcube does not have direct file access to the emails even on the same server. Roundcube opens a connection to dovecot, supplies the user/pass/login credentials to dovecot, and dovecot fetches the email stores and serves it to roundcube. There is nothing a hacker can gain access to by exploiting roundcube that they also couldn't get in the same scenario if roundcube and dovecot were on two different machines. -- The scenario you describe does not consider a breach of the web mail service that allows root access to the file system. If the web service is compromised to that extent then the mail file store is also compromised. If the mail file store is on a different device then an exploit has to not only breach the web service on the interface device, it then has to breach the remote store. This will be extremely difficult compared to simply breaching a web server and locally exploiting it. When the dovecot server is on a remote system and correct firewalls are in place, then the attacker has to breach the imap protocols as well This article describes the concept https://www.fortinet.com/resources/cyberglossary/what-is-dmz ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Roundcube
On 8/9/23 16:24, Marc wrote: Since when does a hacked website gain root? A web search on 'linux web server exploits that gain root' will give many examples. Security design by first principle assumes that an attacker will gain root access. Best practise is to limit the damage that can cause. The usual way to limit it is put all public facing systems in a DMZ and have a very carefully controlled access from them to an internal priavte network. The access control is performed by systems that cannot be controlled by a breached public facing server. e.g. router firewalls,. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Minimum configuration for Dovecot SASL only?
On 6/11/23 03:25, Nick Lockheart wrote: I can't use the real Dovecot IMAP server for auth, because it runs on a separate server, and Postfix does not support TLS connections for SASL. -- You should be able to use ssh with port forwarding to establish a TLS connection between devices. Postfix would see a remote SASL service as a local service. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Minimum configuration for Dovecot SASL only?
On 6/11/23 04:36, jeremy ardley via dovecot wrote: You should be able to use ssh with port forwarding to establish a TLS connection between devices. Postfix would see a remote SASL service as a local service. An alternative and possibly more reliable and easily configured mechanism would be using openVPN to allow postfix to connect to a remote SASL provider through a TLS protected connection. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: How to temporarily make all mailboxes read-only for backup purposes?
On 26/11/23 08:02, Steve Litt wrote: Is the remote vendor going to take the same care in preserving your data as you would? You could buy two 2TB spinning rust external hard drives for seventy bucks each, so if one gets borked you have the other. If you desire offsite, keep one in a bank safe deposit box high off the ground to prevent water damage. As a matter of habit I've kept every hard disk I've ever used since the 1990s. Going back to one after it has been in storage for 5 years has a high probability it won't work. They either won't fire up at all or there will be major problems with the data. As a matter of policy I suggest that you keep moving and aggregating the contents of old drives to the obviously much larger new drives every couple of years. Incidentally, to save me the bother of writing it, is there a program that can scan drives and extract and classify unique copies of 'useful' files such as photos and emails - probably keeping their MD5 and metatdata and in a SQL database - maybe even the binary file blob as well. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [exim] Exim / Dovecot v2.4.0 authentication patch
On 03/02/2025 07:48, Timo Sirainen via Exim-users wrote: It attempted to preserve backwards compatibility by checking client-provided VERSION first before sending data that the client wouldn't handle correctly. Is there documentation available which specifies, for both new and older versions of Dovecot, what sequences of (terminology?) API calls are legitimate? -- Cheers, Jeremy ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
