Re: Replication going away?

[Doug Hardie]

> On Jul 26, 2023, at 05:01, Paul Kudla  wrote:
> 
> 
> I know this might have already been answered
> 
> Can some one give a link to the paid site that does what dovecot project does 
> now 
> 
> more then happy to keep the lights on !
> 
> pls advise link ?
> 

I believe the URL is https://www.open-xchange.com 


-- Doug

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Blacklistd

[Doug Hardie]

> On Apr 20, 2023, at 02:04, Odhiambo Washington  wrote:
> 
> 
> 
> On Thu, Apr 20, 2023 at 9:08 AM Doug Hardie  <mailto:bc...@lafn.org>> wrote:
>> Are there any plans to interface to blacklistd?
>> 
>> -- Doug
> 
> Hi Doug,
> 
> Since blacklistd uses PF, you can already use fail2ban or sshguard 
> <https://www.sshguard.net/> to achieve the same thing you are after.
> Given that blacklistd is just an intermediary like fail2ban, is there a real 
> need for dovecot interfacing with it?

Fail2ban and sshguard are log scanners.  They are a very inelegant approach 
that requires a lot of horsepower to scan logs that are not designed for 
scanning, but for human reading.  Log formats tend to change with time thus 
necessitating updates to the scanners.  Blacklistd places a very short set of 
code to send a small packet to a socket when the decision is made to deny 
access.  There is no real delay in the actual blocking.  Scanning large logs in 
a high traffic environment is expensive.  For a product that is intended for 
high volume environments I find it interesting that a log scanning solution 
would be appropriate.

-- Doug


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Blacklistd

[Doug Hardie]

Are there any plans to interface to blacklistd?

-- Doug

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Backups

[Doug Hardie]

> On Dec 11, 2022, at 12:42 AM, John Tulp  wrote:
> 
> 
> -- 
> John Tulp 
> tulpex
> 
> On Sun, 2022-12-11 at 00:05 -0800, Doug Hardie wrote:
>>> On Dec 10, 2022, at 11:09 AM, John Tulp  wrote:
>>> 
>>> 
>>> 
>>> On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
>>>>> On Dec 4, 2022, at 1:42 PM, Doug Hardie  wrote:
>>>>> 
>>>>>> On Dec 3, 2022, at 11:50 PM, Doug Hardie  wrote:
>>>>>> 
>>>>>> I started to investigate using doveadm backup to backup my mail
>>>>>> system.  I have a small number of users and the mail store is not
>>>>>> large.  It uses maildir format.  I setup a test system that is not
>>>>>> connected to the internet and started up dovecot.  I used the
>>>>>> following command to backup one user:
>>>>>> 
>>>>>> doveadm backup -u ben remote:test
>>>>>> 
>>>>>> ben is the user is in the mail store.  Test is the actual server
>>>>>> name.  That worked just fine.  The maildir was copied completely
>>>>>> (as best as I can tell with ls).  Then I tried the second user:
>>>>>> 
>>>>>> doveadm backup -u jean remote:test
>>>>>> 
>>>>>> This gives 2 error messages:
>>>>>> 
>>>>>> doveadm(jean)[]: Error: Mailbox INBOX:
>>>>>> Failed to get attribute
>>>>>> vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox
>>>>>> attributes not enabled
>>>>>> 
>>>>>> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command
>>>>>> returned error 65: ssh test doveadm dsync-server -ujean -U
>>>>>> 
>>>>>> In addition, the maildir directories are created, but there are no
>>>>>> emails in any of them (e.g., cur).  What is the problem with the
>>>>>> 2nd and why does it behave differently from the first?
>>>>> 
>>>>> I managed to resolve most of the issue.  I use pigeonhole on the
>>>>> primary server.  Apparently not having pigeonhole installed on the
>>>>> test machine caused the errors above.  The test machine was never
>>>>> intended to receive mail hence, no need to install pigeonhole as the
>>>>> LDA would never be used.  However, when the backup was running, it
>>>>> choked on transferring the sieve file.  I have no idea where the
>>>>> mentioned file resides as I couldn't find it anywhere on the primary
>>>>> server.  Installing pigeonhole resolved the issue for all but one
>>>>> user. With that user, I get the following error messages:
>>>>> 
>>>>> doveadm(doug)[]: Panic: file
>>>>> istream-seekable.c: line 238 (read_from_buffer): assertion failed:
>>>>> (*ret_r > 0)
>>>>> Abort
>>>>> 
>>>>> doveadm(doug)[]: Error: read(test) failed:
>>>>> EOF (last sent=mail, last recv=mail_request (EOL))
>>>>> 
>>>>> doveadm(doug)[]: Error: Remote command
>>>>> returned error 134: ssh test doveadm dsync-server -udoug -U
>>>>> 
>>>>> In addition, only a few cur files are transferred in INBOX.
>>>>> Repeating the backup generates the same errors and no additional
>>>>> emails are transferred.  I am wondering if the problem is something
>>>>> in the INBOX.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> I have pretty much reached a dead end.  I am unable to determine the
>>>> cause of this abnormal termination.  The logged messages don't give
>>>> much help.  I can't tell if it is the primary server or test machine
>>>> that is terminating ssh.  I have setup a second test machine.  Both of
>>>> the test machines are raspberry pi 4s.  The real backup machine is
>>>> intel.  On both the test machines, 2 of the three users are backedup
>>>> properly with no errors.  Only one use has the issue.  It builds the
>>>> directory structure correctly then starts transferring the INBOX cur
>>>> files.  Eight files are transferred correctly before it stop.  It is
>>>> the same set of 8 on both test machines.  That leads me to believe
>>>> there is something funny in one of the messages, but which one.  There
>>>> are over 100 messages in that directory

Re: Backups

[Doug Hardie]

> On Dec 10, 2022, at 11:09 AM, John Tulp  wrote:
> 
> 
> 
> On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
>>> On Dec 4, 2022, at 1:42 PM, Doug Hardie  wrote:
>>> 
>>>> On Dec 3, 2022, at 11:50 PM, Doug Hardie  wrote:
>>>> 
>>>> I started to investigate using doveadm backup to backup my mail
>>>> system.  I have a small number of users and the mail store is not
>>>> large.  It uses maildir format.  I setup a test system that is not
>>>> connected to the internet and started up dovecot.  I used the
>>>> following command to backup one user:
>>>> 
>>>> doveadm backup -u ben remote:test
>>>> 
>>>> ben is the user is in the mail store.  Test is the actual server
>>>> name.  That worked just fine.  The maildir was copied completely
>>>> (as best as I can tell with ls).  Then I tried the second user:
>>>> 
>>>> doveadm backup -u jean remote:test
>>>> 
>>>> This gives 2 error messages:
>>>> 
>>>> doveadm(jean)[]: Error: Mailbox INBOX:
>>>> Failed to get attribute
>>>> vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox
>>>> attributes not enabled
>>>> 
>>>> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command
>>>> returned error 65: ssh test doveadm dsync-server -ujean -U
>>>> 
>>>> In addition, the maildir directories are created, but there are no
>>>> emails in any of them (e.g., cur).  What is the problem with the
>>>> 2nd and why does it behave differently from the first?
>>> 
>>> I managed to resolve most of the issue.  I use pigeonhole on the
>>> primary server.  Apparently not having pigeonhole installed on the
>>> test machine caused the errors above.  The test machine was never
>>> intended to receive mail hence, no need to install pigeonhole as the
>>> LDA would never be used.  However, when the backup was running, it
>>> choked on transferring the sieve file.  I have no idea where the
>>> mentioned file resides as I couldn't find it anywhere on the primary
>>> server.  Installing pigeonhole resolved the issue for all but one
>>> user. With that user, I get the following error messages:
>>> 
>>> doveadm(doug)[]: Panic: file
>>> istream-seekable.c: line 238 (read_from_buffer): assertion failed:
>>> (*ret_r > 0)
>>> Abort
>>> 
>>> doveadm(doug)[]: Error: read(test) failed:
>>> EOF (last sent=mail, last recv=mail_request (EOL))
>>> 
>>> doveadm(doug)[]: Error: Remote command
>>> returned error 134: ssh test doveadm dsync-server -udoug -U
>>> 
>>> In addition, only a few cur files are transferred in INBOX.
>>> Repeating the backup generates the same errors and no additional
>>> emails are transferred.  I am wondering if the problem is something
>>> in the INBOX.
>> 
>> 
>> 
>> 
>> I have pretty much reached a dead end.  I am unable to determine the
>> cause of this abnormal termination.  The logged messages don't give
>> much help.  I can't tell if it is the primary server or test machine
>> that is terminating ssh.  I have setup a second test machine.  Both of
>> the test machines are raspberry pi 4s.  The real backup machine is
>> intel.  On both the test machines, 2 of the three users are backedup
>> properly with no errors.  Only one use has the issue.  It builds the
>> directory structure correctly then starts transferring the INBOX cur
>> files.  Eight files are transferred correctly before it stop.  It is
>> the same set of 8 on both test machines.  That leads me to believe
>> there is something funny in one of the messages, but which one.  There
>> are over 100 messages in that directory.  The order of file transfer
>> is not by date.  
>> 
>> 
>> How do I get doveadm to tell me which file is being transferred when
>> the problem occurs?  
> 
> if the problem is in one of the messages, perhaps change the test set.
> for convenience, can temporarily rename/move things to get them out of
> the way. divide test set in half, then in half again, etc., to zero in
> on the one causing the issue, that'll show if a particular message is
> problem or not.
> 
> once you find a problem message, if the why isn't obvious, i'd try
> looking at it in hex, check permissions, etc.

I have found the cause for the errors:  Somehow I had overlooked the -D 
argument to doveadm.  That is really helpful in diagnosing backup issues.  I 
discovered that there was one email that was 130+ MB.  Doveadm cannot handle 
that.  It appears there is a message size limit somewhere.  I don't know if 
that is changeable or not.  Anyway, removing that email from the mailbox, 
deleting it from the Trash, and purging the account enabled backup to work 
properly.  I don't get too many emails that large, but it does happen 
occasionally.  How do I go about telling dovecot to handle those?

-- Doug

Re: Backups

[Doug Hardie]

Interesting idea.  I am not sure just how to go about that.  Just deleting the 
files from the cur directory still leaves the various indexes unchanged.  I 
don't see any way in doveadm to clean that up.  I believe doveadm backup will 
build a new user that can be used to play around with.  I don't want to delete 
anything from the real user's mailbox.  Unfortunately, I have captured all the 
transmissions between the two systems.  It doesn't show anything of value since 
everything is encrypted.  I tried using the tcp transfer, but couldn't get it 
to work.

-- Doug

> On Dec 10, 2022, at 11:09 AM, John Tulp  wrote:
> 
> 
> 
> On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
>>> On Dec 4, 2022, at 1:42 PM, Doug Hardie  wrote:
>>> 
>>>> On Dec 3, 2022, at 11:50 PM, Doug Hardie  wrote:
>>>> 
>>>> I started to investigate using doveadm backup to backup my mail
>>>> system.  I have a small number of users and the mail store is not
>>>> large.  It uses maildir format.  I setup a test system that is not
>>>> connected to the internet and started up dovecot.  I used the
>>>> following command to backup one user:
>>>> 
>>>> doveadm backup -u ben remote:test
>>>> 
>>>> ben is the user is in the mail store.  Test is the actual server
>>>> name.  That worked just fine.  The maildir was copied completely
>>>> (as best as I can tell with ls).  Then I tried the second user:
>>>> 
>>>> doveadm backup -u jean remote:test
>>>> 
>>>> This gives 2 error messages:
>>>> 
>>>> doveadm(jean)[]: Error: Mailbox INBOX:
>>>> Failed to get attribute
>>>> vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox
>>>> attributes not enabled
>>>> 
>>>> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command
>>>> returned error 65: ssh test doveadm dsync-server -ujean -U
>>>> 
>>>> In addition, the maildir directories are created, but there are no
>>>> emails in any of them (e.g., cur).  What is the problem with the
>>>> 2nd and why does it behave differently from the first?
>>> 
>>> I managed to resolve most of the issue.  I use pigeonhole on the
>>> primary server.  Apparently not having pigeonhole installed on the
>>> test machine caused the errors above.  The test machine was never
>>> intended to receive mail hence, no need to install pigeonhole as the
>>> LDA would never be used.  However, when the backup was running, it
>>> choked on transferring the sieve file.  I have no idea where the
>>> mentioned file resides as I couldn't find it anywhere on the primary
>>> server.  Installing pigeonhole resolved the issue for all but one
>>> user. With that user, I get the following error messages:
>>> 
>>> doveadm(doug)[]: Panic: file
>>> istream-seekable.c: line 238 (read_from_buffer): assertion failed:
>>> (*ret_r > 0)
>>> Abort
>>> 
>>> doveadm(doug)[]: Error: read(test) failed:
>>> EOF (last sent=mail, last recv=mail_request (EOL))
>>> 
>>> doveadm(doug)[]: Error: Remote command
>>> returned error 134: ssh test doveadm dsync-server -udoug -U
>>> 
>>> In addition, only a few cur files are transferred in INBOX.
>>> Repeating the backup generates the same errors and no additional
>>> emails are transferred.  I am wondering if the problem is something
>>> in the INBOX.
>> 
>> 
>> 
>> 
>> I have pretty much reached a dead end.  I am unable to determine the
>> cause of this abnormal termination.  The logged messages don't give
>> much help.  I can't tell if it is the primary server or test machine
>> that is terminating ssh.  I have setup a second test machine.  Both of
>> the test machines are raspberry pi 4s.  The real backup machine is
>> intel.  On both the test machines, 2 of the three users are backedup
>> properly with no errors.  Only one use has the issue.  It builds the
>> directory structure correctly then starts transferring the INBOX cur
>> files.  Eight files are transferred correctly before it stop.  It is
>> the same set of 8 on both test machines.  That leads me to believe
>> there is something funny in one of the messages, but which one.  There
>> are over 100 messages in that directory.  The order of file transfer
>> is not by date.  
>> 
>> 
>> How do I get doveadm to tell me which file is being transferred when
>> the problem occurs?  
> 
> if the problem is in one of the messages, perhaps change the test set.
> for convenience, can temporarily rename/move things to get them out of
> the way. divide test set in half, then in half again, etc., to zero in
> on the one causing the issue, that'll show if a particular message is
> problem or not.
> 
> once you find a problem message, if the why isn't obvious, i'd try
> looking at it in hex, check permissions, etc.
> 
> j
> 

Re: Backups

[Doug Hardie]

> On Dec 4, 2022, at 1:42 PM, Doug Hardie  wrote:
> 
>> On Dec 3, 2022, at 11:50 PM, Doug Hardie  wrote:
>> 
>> I started to investigate using doveadm backup to backup my mail system.  I 
>> have a small number of users and the mail store is not large.  It uses 
>> maildir format.  I setup a test system that is not connected to the internet 
>> and started up dovecot.  I used the following command to backup one user:
>> 
>> doveadm backup -u ben remote:test
>> 
>> ben is the user is in the mail store.  Test is the actual server name.  That 
>> worked just fine.  The maildir was copied completely (as best as I can tell 
>> with ls).  Then I tried the second user:
>> 
>> doveadm backup -u jean remote:test
>> 
>> This gives 2 error messages:
>> 
>> doveadm(jean)[]: Error: Mailbox INBOX: Failed to get 
>> attribute vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox 
>> attributes not enabled
>> 
>> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command returned 
>> error 65: ssh test doveadm dsync-server -ujean -U
>> 
>> In addition, the maildir directories are created, but there are no emails in 
>> any of them (e.g., cur).  What is the problem with the 2nd and why does it 
>> behave differently from the first?
> 
> I managed to resolve most of the issue.  I use pigeonhole on the primary 
> server.  Apparently not having pigeonhole installed on the test machine 
> caused the errors above.  The test machine was never intended to receive mail 
> hence, no need to install pigeonhole as the LDA would never be used.  
> However, when the backup was running, it choked on transferring the sieve 
> file.  I have no idea where the mentioned file resides as I couldn't find it 
> anywhere on the primary server.  Installing pigeonhole resolved the issue for 
> all but one user. With that user, I get the following error messages:
> 
> doveadm(doug)[]: Panic: file istream-seekable.c: line 
> 238 (read_from_buffer): assertion failed: (*ret_r > 0)
> Abort
> 
> doveadm(doug)[]: Error: read(test) failed: EOF (last 
> sent=mail, last recv=mail_request (EOL))
> 
> doveadm(doug)[]: Error: Remote command returned error 
> 134: ssh test doveadm dsync-server -udoug -U
> 
> In addition, only a few cur files are transferred in INBOX.  Repeating the 
> backup generates the same errors and no additional emails are transferred.  I 
> am wondering if the problem is something in the INBOX.


I have pretty much reached a dead end.  I am unable to determine the cause of 
this abnormal termination.  The logged messages don't give much help.  I can't 
tell if it is the primary server or test machine that is terminating ssh.  I 
have setup a second test machine.  Both of the test machines are raspberry pi 
4s.  The real backup machine is intel.  On both the test machines, 2 of the 
three users are backedup properly with no errors.  Only one use has the issue.  
It builds the directory structure correctly then starts transferring the INBOX 
cur files.  Eight files are transferred correctly before it stop.  It is the 
same set of 8 on both test machines.  That leads me to believe there is 
something funny in one of the messages, but which one.  There are over 100 
messages in that directory.  The order of file transfer is not by date.  

How do I get doveadm to tell me which file is being transferred when the 
problem occurs?  

Re: Backups

[Doug Hardie]

> On Dec 3, 2022, at 11:50 PM, Doug Hardie  wrote:
> 
> I started to investigate using doveadm backup to backup my mail system.  I 
> have a small number of users and the mail store is not large.  It uses 
> maildir format.  I setup a test system that is not connected to the internet 
> and started up dovecot.  I used the following command to backup one user:
> 
> doveadm backup -u ben remote:test
> 
> ben is the user is in the mail store.  Test is the actual server name.  That 
> worked just fine.  The maildir was copied completely (as best as I can tell 
> with ls).  Then I tried the second user:
> 
> doveadm backup -u jean remote:test
> 
> This gives 2 error messages:
> 
> doveadm(jean)[]: Error: Mailbox INBOX: Failed to get 
> attribute vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox 
> attributes not enabled
> 
> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command returned error 
> 65: ssh test doveadm dsync-server -ujean -U
> 
> In addition, the maildir directories are created, but there are no emails in 
> any of them (e.g., cur).  What is the problem with the 2nd and why does it 
> behave differently from the first?

I managed to resolve most of the issue.  I use pigeonhole on the primary 
server.  Apparently not having pigeonhole installed on the test machine caused 
the errors above.  The test machine was never intended to receive mail hence, 
no need to install pigeonhole as the LDA would never be used.  However, when 
the backup was running, it choked on transferring the sieve file.  I have no 
idea where the mentioned file resides as I couldn't find it anywhere on the 
primary server.  Installing pigeonhole resolved the issue for all but one user. 
 With that user, I get the following error messages:

doveadm(doug)[]: Panic: file istream-seekable.c: line 
238 (read_from_buffer): assertion failed: (*ret_r > 0)
Abort

doveadm(doug)[]: Error: read(test) failed: EOF (last 
sent=mail, last recv=mail_request (EOL))

doveadm(doug)[]: Error: Remote command returned error 
134: ssh test doveadm dsync-server -udoug -U

In addition, only a few cur files are transferred in INBOX.  Repeating the 
backup generates the same errors and no additional emails are transferred.  I 
am wondering if the problem is something in the INBOX.

-- Doug

Backups

[Doug Hardie]

I started to investigate using doveadm backup to backup my mail system.  I have 
a small number of users and the mail store is not large.  It uses maildir 
format.  I setup a test system that is not connected to the internet and 
started up dovecot.  I used the following command to backup one user:

doveadm backup -u ben remote:test

ben is the user is in the mail store.  Test is the actual server name.  That 
worked just fine.  The maildir was copied completely (as best as I can tell 
with ls).  Then I tried the second user:

doveadm backup -u jean remote:test

This gives 2 error messages:

doveadm(jean)[]: Error: Mailbox INBOX: Failed to get 
attribute vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox 
attributes not enabled

doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command returned error 
65: ssh test doveadm dsync-server -ujean -U

In addition, the maildir directories are created, but there are no emails in 
any of them (e.g., cur).  What is the problem with the 2nd and why does it 
behave differently from the first?

-- Doug

Re: Matching Addresses in Sieve

[Doug Hardie]

> On 30 September 2022, at 16:46, Shawn Heisey  wrote:
> 
> On 9/30/22 15:14, Doug Hardie wrote:
>> I have an email with the following header line:
>> 
>> From: 'Thank you!Kohls' 
>> 
>> 
>> I am trying to match that with:
>> if address :contains "from" "Thank you!Kohls"
>> {
>> addflag "\\Seen";
>> fileinto "Junk";
>> stop;
>> }
>> 
>> However, the matching portion of the from address is only the section 
>> between < and >.  Since there are changing sections that are different for 
>> each email, I can't use that.  I wanted to match the stuff before <.  I have 
>> tried numerous formats for the if statement but none of them have worked.  
>> What is the proper way to make that match work?  Thanks,
> 
> I did what looked like the right thing in a sieve plugin for roundcube:
> 
> https://www.dropbox.com/s/abhpc7rf9rokmfl/junk_rule_for_sieve.png?dl=0
> 
> 
> And this is what that created in the script.  Only one word of difference 
> from yours -- it looks at the entire From header and not an address.
> 
> # rule:[testing]
> if header :contains "from" "Testing"
> {
> addflag "\\Seen";
> fileinto "Junk";
> stop;
> }
> 
> Hope this helps.
> 

Thanks.  That was the magic incantation I needed.

-- Doug

Matching Addresses in Sieve

[Doug Hardie]

I have an email with the following header line:

From: 'Thank you!Kohls' 

I am trying to match that with:
if address :contains "from" "Thank you!Kohls"
{
addflag "\\Seen";
fileinto "Junk";
stop;
}

However, the matching portion of the from address is only the section between < 
and >.  Since there are changing sections that are different for each email, I 
can't use that.  I wanted to match the stuff before <.  I have tried numerous 
formats for the if statement but none of them have worked.  What is the proper 
way to make that match work?  Thanks,

-- Doug

Re: Tracing Sieve actions

[Doug Hardie]

Thanks, that's basically the same as the man page.  I finally figured out that 
the way to do it is with:

  sieve-test -t - -Tlevel=tests .dovecot.sieve /xxx

where /xxx is the test message.  That gives the actual line numbers.  I thought 
I tried that combination, but apparently not.  Anyway, I am going to save that 
command line somewhere "in a safe spot" ;-)

-- Doug

> On 19 July 2022, at 23:35, Aki Tuomi  wrote:
> 
> 
>> On 20/07/2022 09:34 EEST Doug Hardie  wrote:
>> 
>> 
>> I encountered an interesting problem that one originator was being dumped 
>> into the Deleted file directly by my sieve.  The sieve file was quite large 
>> and it was not obvious which entry was causing the issue.  I recall there 
>> was a way to get sieve-test to show what is going on and which lines it 
>> used, but I could not replicate it tonight for anything.  I ended up having 
>> to change all the deliver to the Deleted files to something else and test 
>> one at a time to find the offending entry.  It took a long time.  How do you 
>> get sieve-test to show the actual path it took through the file?
>> 
>> -- Doug
> 
> Hi Doug, take a loot at 
> https://doc.dovecot.org/configuration_manual/sieve/configuration/#trace-debugging
> 
> It might help.
> 
> Kind regards,
> Aki

Tracing Sieve actions

[Doug Hardie]

I encountered an interesting problem that one originator was being dumped into 
the Deleted file directly by my sieve.  The sieve file was quite large and it 
was not obvious which entry was causing the issue.  I recall there was a way to 
get sieve-test to show what is going on and which lines it used, but I could 
not replicate it tonight for anything.  I ended up having to change all the 
deliver to the Deleted files to something else and test one at a time to find 
the offending entry.  It took a long time.  How do you get sieve-test to show 
the actual path it took through the file?

-- Doug

Re: doveadm pw

[Doug Hardie]

> On 7 August 2021, at 09:50, Timo Sirainen  wrote:
> 
> On 7. Aug 2021, at 14.07, Alexander Dalloz  <mailto:ad+li...@uni-x.org>> wrote:
>> 
>> Am 07.08.2021 um 08:06 schrieb Doug Hardie:
>>> mail# doveadm pw
>>> Enter new password:
>>> Retype new password:
>>> {CRYPT}$2y$05$oSB6end9V.YumJMzON7lfeOL9N8TXK6jhYqjHOEnPd1NLZ9.QNaTy
>>> I thought the default was supposed to be CRAM-MD5.  I don't find anywhere I 
>>> have entered CRYPT.  There is one reference to it in 
>>> auth-passwdfile.conf.ext, but changing that has no effect.  Is this a bug, 
>>> change, or my mistake?  Thanks,
>> 
>> https://doc.dovecot.org/configuration_manual/authentication/password_schemes/
>>  
>> <https://doc.dovecot.org/configuration_manual/authentication/password_schemes/>
> 
> Looks like both doc.dovecot.org <http://doc.dovecot.org/> and man page are 
> wrong, each in a different way. CRYPT is what is actually the default.
> 

Great.  At least it wasn't something I caused.  Thanks for all the work and 
assistance.

-- Doug

doveadm pw

[Doug Hardie]

mail# doveadm pw
Enter new password: 
Retype new password: 
{CRYPT}$2y$05$oSB6end9V.YumJMzON7lfeOL9N8TXK6jhYqjHOEnPd1NLZ9.QNaTy

I thought the default was supposed to be CRAM-MD5.  I don't find anywhere I 
have entered CRYPT.  There is one reference to it in auth-passwdfile.conf.ext, 
but changing that has no effect.  Is this a bug, change, or my mistake?  Thanks,


mail# doveconf -n
# 2.3.15 (0503334ab1): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.15 (e6a84e31)
# OS: FreeBSD 13.0-RELEASE-p1 amd64  ufs
# Hostname: mail
auth_mechanisms = plain cram-md5
auth_stats = yes
base_dir = /var/run/home_mail/
first_valid_gid = 0
lda_mailbox_autocreate = yes
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k 
session=<%{session}> port=%a
mail_gid = 
mail_home = /var/mail/home_mail/%n
mail_location = maildir:/var/mail/home_mail/%n/Maildir
mail_log_prefix = "%s(%u)[%r]<%{session}>: "
mail_uid = 
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 {
autoexpunge = 5 days
special_use = \Drafts
  }
  mailbox Junk {
autoexpunge = 2 days
special_use = \Junk
  }
  mailbox Sent {
autoexpunge = 1 weeks
special_use = \Sent
  }
  mailbox "Sent Messages" {
autoexpunge = 2 days
special_use = \Sent
  }
  mailbox Trash {
autoexpunge = 2 days
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = scheme=CRYPT username_format=%n /usr/local/etc/dovecot/users
  driver = passwd-file
}
plugin {
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
  mail_log_fields = uid box msgid size from
  sieve = 
file:/var/mail/home_mail/%n/sieve;active=/var/mail/home_mail/%n/.dovecot.sieve
  stats_refresh = 30 secs
  stats_track_cmds = yes
}
postmaster_address = d...@sermon-archive.info
protocols = imap
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
  }
  unix_listener auth-userdb {
group = vmail
mode = 0666
user = vmail
  }
}
service imap-login {
  inet_listener imap {
port = 143
  }
  inet_listener imaps {
port = 993
ssl = yes
  }
  inet_listener imaps2 {
port = 998
ssl = yes
  }
}
service stats {
  unix_listener stats-reader {
group = vmail
mode = 0660
user = vmail
  }
  unix_listener stats-writer {
group = vmail
mode = 0660
user = vmail
  }
}
ssl_cert = 

Re: "no shared cypher", no matter what I try

[Doug Hardie]

Have you tried connecting with openssl c_client, with a cypher list of all?

My suspicion is that one of the pair of programs is only 
using old, weak cyphers [due to age  and the other only strong ones. 


David

Re: "no shared cypher", no matter what I try

[Doug Hardie]

I ran into that error message with a different application and it turned out 
that the server certificate was expired.

-- Doug

> On 8 December 2018, at 12:22, David Gardner  wrote:
> 
> Have you tried connecting with openssl c_client, with a cypher list of all?
> 
> My suspicion is that one of the pair of programs is only 
> using old, weak cyphers [due to age  and the other only strong ones. 
> 
> 
> David

Re: [Sieve] Matches on body content - looking for working example

[Doug Hardie]

> On 19 September 2018, at 12:54, Adam Raszkiewicz  
> wrote:
> 
> I have tried to do something like
>  
> if body :content ["multipart"] :matches ["Original-Message-ID" “*”] { set 
> "Original_Message_ID" "${0}"; }
>  
> but instead getting Original Message ID I’m getting value from previous match 
> which was
>  
> if envelope :matches "From" "*" { set "sender" "${0}"; }
>  
> Is there any example of working :matches matching-type with body?
>  
> Thanks


I have the following that works:

if allof (header :contains "from" "fbl-no-re...@postmaster.aol.com",
body :contains :raw "some text")
{
fileinto "Deleted Messages";
stop;
}

Re: Sieve with LDA

[Doug Hardie]

> On 17 December 2017, at 15:16, Stephan Bosch <step...@rename-it.nl> wrote:
> 
> Op 12/17/2017 om 12:22 PM schreef Doug Hardie:
>>> On 17 December 2017, at 02:42, Jerry <je...@seibercom.net> wrote:
>>> 
>>> On Sat, 16 Dec 2017 18:17:39 -0800, Doug Hardie stated:
>>> 
>>>> I found an email that sieve stored in Deleted Messages incorrectly.  The 
>>>> log
>>>> messages show sieve doing that, but don't give me any indication of which
>>>> sieve rule caused the problem.  I went through it manually, but didn't see
>>>> anything that matched.  I seem to recall that there was a way to use
>>>> sieve-test to show the rules and how they were applied, but I can't seem to
>>>> get it to do that now.
>>>> 
>>> It depends on how much info you want. Read the "man sieve-test" for more 
>>> info.
>>> 
>>> sieve-test -d- "script file" "mail-file"
>>> 
>>> That will give you the most complete info. Omit the "-d-" for an abbreviated
>>> output.
>>> 
>> Thanks.  I got it figured out now.  The man page had me confused for awhile. 
>>  Found the logic error in my script.  Now to figure out how to remember this 
>> months from now...
> 
> If version is recent enough, you can also use:
> https://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration#Trace_Debugging
> 

Thanks, I'll investigate that.

-- Doug

Re: Sieve with LDA

[Doug Hardie]

> On 17 December 2017, at 02:42, Jerry <je...@seibercom.net> wrote:
> 
> On Sat, 16 Dec 2017 18:17:39 -0800, Doug Hardie stated:
> 
>> I found an email that sieve stored in Deleted Messages incorrectly.  The log
>> messages show sieve doing that, but don't give me any indication of which
>> sieve rule caused the problem.  I went through it manually, but didn't see
>> anything that matched.  I seem to recall that there was a way to use
>> sieve-test to show the rules and how they were applied, but I can't seem to
>> get it to do that now.
>> 
> 
> It depends on how much info you want. Read the "man sieve-test" for more info.
> 
> sieve-test -d- "script file" "mail-file"
> 
> That will give you the most complete info. Omit the "-d-" for an abbreviated
> output.
> 

Thanks.  I got it figured out now.  The man page had me confused for awhile.  
Found the logic error in my script.  Now to figure out how to remember this 
months from now...

-- Doug

Sieve with LDA

[Doug Hardie]

I found an email that sieve stored in Deleted Messages incorrectly.  The log 
messages show sieve doing that, but don't give me any indication of which sieve 
rule caused the problem.  I went through it manually, but didn't see anything 
that matched.  I seem to recall that there was a way to use sieve-test to show 
the rules and how they were applied, but I can't seem to get it to do that now.

-- Doug

Re: is a self signed certificate always invalid the first time?

[Doug Hardie]

Having gone through the process to get "approved" certificates a few times, I 
don't believe it would be all that difficult to get a certificate with your 
domain name from several of the "approved" certificate authorities.  The 
process some of them use to "certify" the applicant is pretty easy to spoof.  
Clearly the hackers don't see that as much of an obstacle.

-- Doug

> On 10 August 2017, at 13:41, Frank-Ulrich Sommer <f-...@gmx.net> wrote:
> 
> I can't see any security advantages of a self signed cert. If the keypair is 
> generated locally (which it should) a certificate signed by an external CA 
> can't be worse just by the additional signature of the external CA.
> 
> Better security can only be gained if all users are urged to remove all 
> preinstalled trusted CAs from their mail clients (which seems impractical). 
> Else an attacker could still use a fake cert signed by one of those CAs. 
> Public key pinning could be an (academic) alternative and would still work 
> with a cert signed by an external CA without restrictions.
> 
> If someone tells me to add security exceptions this rings all alarm bells. 
> Users who are not experts should not get used to doing this as they soon will 
> accept everything.
> 
> Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie <bc...@lafn.org>:
>> 
>> 
>>> On 10 August 2017, at 04:37, Alef Veld <alefv...@outlook.com> wrote:
>>> 
>>> I completely agree (having said that I'm pretty new to all this so I
>> might be full of it). 
>>> 
>>> You should run your own CA if you have an active financial interest
>> in your company (say your the owner). No added benefit to have your
>> certificate certified by a third party, why would they care about that
>> one client). Ofcourse people would say "but ofcourse you would verify
>> your own certificate" but in that case they probably don't understand
>> how it all works.
>>> 
>>> Ofcourse once your own company grows large you run the same risk of
>> entropy (incorrect documentation or records, no trained staff, no up to
>> date procedures etc.) large companies have to deal with. Maybe if you
>> had one person working full time on it, or an automated process
>> handling things it would be more secure and reliable.
>>> 
>>> Was diginotar the Dutch company, I think I remember that one.
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 10 Aug 2017, at 08:18, Stephan von Krawczynski <sk...@ithnet.com>
>> wrote:
>>>> 
>>>> On Wed, 9 Aug 2017 08:39:30 -0700
>>>> Gregory Sloop <gr...@sloop.net> wrote:
>>>> 
>>>>> AV> So i’m using dovecot, and i created a self signed certificate
>>>>> AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there
>> matches
>>>>> AV> my mail server.  
>>>>> 
>>>>> AV> The first time it connects in mac mail however, it says the
>>>>> AV> certificate is invalid and another server might pretend to be
>> me etc.  
>>>>> 
>>>>> AV> I then have the option of trusting it.  
>>>>> 
>>>>> AV> Is this normal behaviour? Will it always be invalid if it’s not
>> signed
>>>>> AV> by a third party?  
>>>>> 
>>>>> Yes.
>>>>> The point of a trusted CA signing your cert is that they have steps
>> to
>>>>> "verify" who you are and that you're "authorized" to issue certs
>> for the
>>>>> listed FQDNs. Without that, ANYONE could create a cert, and sign it
>> and then
>>>>> present it to people connecting to your mail server [perhaps using
>> a MITM
>>>>> style attack.] The connecting party would have no way to tell if
>> your cert
>>>>> vs the attackers cert was actually valid.
>>>>> 
>>>>> It would be like showing up at the bank and having this exchange: 
>>>>> 
>>>>> You: "Hey, I'm Jim Bob - can I take money out of his account?"
>>>>> Bank: "Do you have some ID?"
>>>>> You: "Yeah! See, I have this plastic card with my picture and name,
>> that I
>>>>> ginned up in the basement."
>>>>> 
>>>>> Now does the bank say: "Yeah, that looks fine." or do they say "You
>> know we
>>>>> really need ID [a certificate] that's authenticated and issued
>> [signed] by
>>>>> the 

Dovecot Statistics

[Doug Hardie]

I tried to setup statistics as shown on the Statistics wiki page.  I 
encountered a problem with the mail_plugins for imap.  in the protocol imap 
configuration the wiki shows adding imap_stats to mail_plugins.  When I do 
that, dovecot stops authenticating and throwing error messages:

 Jul 15 12:47:46 mail dovecot: imap(doug)[10.0.1.251]: Error: 
Couldn't load required plugin 
/usr/local/lib/dovecot/lib95_imap_stats_plugin.so: Plugin stats must be loaded 
also (you must set: mail_plugins=$mail_plugins stats)
Jul 15 12:47:46 mail dovecot: imap(doug): Error: Internal error occurred. Refer 
to server log for more information.


Changing that line to just add stats to mail_plugins resolves the problem.  
Hopefully that is an error in the wiki...  However, in looking at the stats, I 
don't ever see any values for any of the auth_ values.  They all show zero even 
though there have been numerous authentications by dovecot and postfix.

I also notice that there is a new statistics output about every 3 minutes.  It 
appears that the numbers are only for that 3 minute window.  Is there a way to 
set the statistics so that I can see the last 24 hours, or the previous day?


-- Doug

Re: Sieve not filtering

[Doug Hardie]

> On 17 February 2017, at 08:24, Ben  wrote:
> 
> Hi,
> 
> I have copied accross a known-good sieve file from a working server and its 
> not filtering.  Everything just gets chucked into INBOX.

What I did when encountering a similar issue was to take one of the messages 
from INBOX that should have been moved elsewhere and use sieve-test on it:

sieve-test -Tlevel=matching  

That generates a lot of output as it goes through every line of the sieve file 
and shows the actual values that are used for the tests.  However, it pointed 
out my problem quite clearly.

Re: Problem with Horde "Mailbox does not support mod-sequences"

[Doug Hardie]

> On 13 February 2017, at 01:26, Luca Bertoncello  wrote:
> 
> Hi list!
> 
> I already asked about this problem about two years ago, but I couldn't solve 
> my problem...
> 
> Now I have a new Server, with Debian 8 and Dovecot 2.2.13-12 (from Debian 
> repositories) and Horde 5.2.13.
> 
> When I delete an E-Mail, I always get the error "Mailbox does not support 
> mod-sequences".
> It results in having the E-Mail not moved to Trash and I must update more 
> times the folder to see the E-Mail moved to Trash...
> 
> Could someone help me to add this support for mod-sequences?
> 

A quick search turned up:  
https://dovecot.org/list/dovecot/2015-February/099674.html

Perhaps that will help.

Re: Deletion of mail from Junk mailbox

[Doug Hardie]

> On 4 July 2016, at 13:18, Doug Hardie <d...@sermon-archive.info> wrote:
> 
>> 
>> On 2 July 2016, at 02:29, Noel Butler <noel.but...@ausics.net> wrote:
>> 
>> On 02/07/2016 19:16, Doug Hardie wrote:
>>> I have a pigeon sive running which directs some of my received mail to
>>> the Junk folder.  That works just fine.  However, a couple minutes
>>> later, it is moved to Deleted mailbox and deleted from Junk.  At first
>>> I thought my client was doing that so I shut down the client and it
>>> still happens.  Here are the log entries:
>>> Jul  2 00:36:31 mail dovecot: imap(doug): copy from INBOX: box=Junk,
>>> uid=10842, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>>> from="jnilj" <h...@bjwmt.com>
>>> Jul  2 00:36:31 mail dovecot: imap(doug): delete: box=INBOX,
>>> uid=55719, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>>> from="jnilj" <h...@bjwmt.com>
>>> Jul  2 00:39:33 mail dovecot: imap(doug): copy from Junk: box=Deleted
>>> Messages, uid=31049, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>,
>>> size=3340, from="jnilj" <h...@bjwmt.com>
>>> Jul  2 00:39:33 mail dovecot: imap(doug): delete: box=Junk, uid=10842,
>>> msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340, from="jnilj"
>>> <h...@bjwmt.com>
>>> Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=Junk,
>>> uid=10842, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>>> from="jnilj" <h...@bjwmt.com>
>>> Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=INBOX,
>>> uid=55719, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>>> from="jnilj" <h...@bjwmt.com>
>>> Is this the intended way the Junk maibox is supposed to work?  I
>>> couldn't find any settings that appear to control (or affect) this
>>> behavior.
>>> — Doug
>> 
>> and your dovecot version is?
>> 
>> I suggest you'll also need to show doveconf -n and example of sieve rules, 
>> because it doesnt seem right, certainly does not do that here.
>> 
> 
> 
> After some more experimentation, it seemed like the messages above were 
> created by a MUA and not the LDA.  However, I was not able to identify the 
> MUA that caused that.  I modified logging to include the remote IP address, 
> restarted dovecot with all the MUAs disabled. Now the problem has not 
> reoccurred.  I have been restarting the MUSs one at a time, however I still 
> don't know who did it.  I have only had a couple junk emails in the last few 
> days so its not much of a test yet.  I guess the volume will return to normal 
> tomorrow.
> 
> mail# doveconf -n
> # 2.2.24 (a82c823): /usr/local/etc/dovecot/dovecot.conf
> # Pigeonhole version 0.4.14 (099a97c)
> # OS: FreeBSD 9.3-RELEASE-p43 amd64  ufs
> auth_mechanisms = plain login
> base_dir = /var/run/home_mail/
> first_valid_gid = 0
> lda_mailbox_autocreate = yes
> login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k 
> session=<%{session}> port=%a
> mail_gid = 
> mail_location = maildir:/var/mail/home_mail/%n
> mail_log_prefix = "%s(%u)[%r]<%{session}>: "
> mail_uid = 
> 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 {
>autoexpunge = 5 days
>special_use = \Drafts
>  }
>  mailbox Junk {
>autoexpunge = 2 days
>special_use = \Junk
>  }
>  mailbox Sent {
>special_use = \Sent
>  }
>  mailbox "Sent Messages" {
>special_use = \Sent
>  }
>  mailbox Trash {
>autoexpunge = 2 days
>special_use = \Trash
>  }
>  prefix = 
> }
> passdb {
>  args = scheme=CRYPT username_format=%n /usr/local/etc/dovecot/users
>  driver = passwd-file
> }
> plugin {
>  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
>  mail_log_fields = uid box msgid size from
>  sieve = 
> file:/var/mail/home_mail/%n/sieve;active=/var/mail/home_mail/%n/.dovecot.sieve
> }
> postmaster_address = d...@sermon-archive.info
> protocols = imap
> service auth {
>  unix_listener /var/spool/postfix/private/auth {
>group = postfix
>mode = 0660
>user = postfix
>  }
>

Re: Deletion of mail from Junk mailbox

[Doug Hardie]

> On 2 July 2016, at 02:29, Noel Butler <noel.but...@ausics.net> wrote:
> 
> On 02/07/2016 19:16, Doug Hardie wrote:
>> I have a pigeon sive running which directs some of my received mail to
>> the Junk folder.  That works just fine.  However, a couple minutes
>> later, it is moved to Deleted mailbox and deleted from Junk.  At first
>> I thought my client was doing that so I shut down the client and it
>> still happens.  Here are the log entries:
>> Jul  2 00:36:31 mail dovecot: imap(doug): copy from INBOX: box=Junk,
>> uid=10842, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>> from="jnilj" <h...@bjwmt.com>
>> Jul  2 00:36:31 mail dovecot: imap(doug): delete: box=INBOX,
>> uid=55719, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>> from="jnilj" <h...@bjwmt.com>
>> Jul  2 00:39:33 mail dovecot: imap(doug): copy from Junk: box=Deleted
>> Messages, uid=31049, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>,
>> size=3340, from="jnilj" <h...@bjwmt.com>
>> Jul  2 00:39:33 mail dovecot: imap(doug): delete: box=Junk, uid=10842,
>> msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340, from="jnilj"
>> <h...@bjwmt.com>
>> Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=Junk,
>> uid=10842, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>> from="jnilj" <h...@bjwmt.com>
>> Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=INBOX,
>> uid=55719, msgid=<F3C67E609C1A1BC4DB924CEA5FE12C76@ze>, size=3340,
>> from="jnilj" <h...@bjwmt.com>
>> Is this the intended way the Junk maibox is supposed to work?  I
>> couldn't find any settings that appear to control (or affect) this
>> behavior.
>> — Doug
> 
> and your dovecot version is?
> 
> I suggest you'll also need to show doveconf -n and example of sieve rules, 
> because it doesnt seem right, certainly does not do that here.
> 


After some more experimentation, it seemed like the messages above were created 
by a MUA and not the LDA.  However, I was not able to identify the MUA that 
caused that.  I modified logging to include the remote IP address, restarted 
dovecot with all the MUAs disabled. Now the problem has not reoccurred.  I have 
been restarting the MUSs one at a time, however I still don't know who did it.  
I have only had a couple junk emails in the last few days so its not much of a 
test yet.  I guess the volume will return to normal tomorrow.

mail# doveconf -n
# 2.2.24 (a82c823): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.14 (099a97c)
# OS: FreeBSD 9.3-RELEASE-p43 amd64  ufs
auth_mechanisms = plain login
base_dir = /var/run/home_mail/
first_valid_gid = 0
lda_mailbox_autocreate = yes
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k 
session=<%{session}> port=%a
mail_gid = 
mail_location = maildir:/var/mail/home_mail/%n
mail_log_prefix = "%s(%u)[%r]<%{session}>: "
mail_uid = 
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 {
autoexpunge = 5 days
special_use = \Drafts
  }
  mailbox Junk {
autoexpunge = 2 days
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
autoexpunge = 2 days
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = scheme=CRYPT username_format=%n /usr/local/etc/dovecot/users
  driver = passwd-file
}
plugin {
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
  mail_log_fields = uid box msgid size from
  sieve = 
file:/var/mail/home_mail/%n/sieve;active=/var/mail/home_mail/%n/.dovecot.sieve
}
postmaster_address = d...@sermon-archive.info
protocols = imap
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
  }
  unix_listener auth-userdb {
group = vmail
mode = 0666
user = vmail
  }
}
service imap-login {
  inet_listener imap {
port = 143
  }
  inet_listener imaps {
port = 993
ssl = yes
  }
  inet_listener imaps2 {
port = 998
ssl = yes
  }
}
ssl_cert = 

Feature Request

[Doug Hardie]

I would like to request an additional optional argument for queue-id to 
dovecot-lda.  The intended use for this argument is to include in the logging.  
From what I can tell, the queue-id size is not consistent between the various 
MTAs and so would need to be allocated dynamically when read during 
initialization.  

This element in the log messages would make it easier to find the trace of a 
received email.  Generally I can easily get the queue-id generated by postfix 
(or sendmail - I use both).  One grep would then give me the whole picture 
rather than having to dig out the message-id and doing a secondary grep to 
obtain the lda log messages.

— Doug

I find it interesting that every submission to this list results in a quick 
response that says moderation is required since I "am not a member". However, I 
am a member...

Deletion of mail from Junk mailbox

[Doug Hardie]

I have a pigeon sive running which directs some of my received mail to the Junk 
folder.  That works just fine.  However, a couple minutes later, it is moved to 
Deleted mailbox and deleted from Junk.  At first I thought my client was doing 
that so I shut down the client and it still happens.  Here are the log entries:

Jul  2 00:36:31 mail dovecot: imap(doug): copy from INBOX: box=Junk, uid=10842, 
msgid=, size=3340, from="jnilj" 

Jul  2 00:36:31 mail dovecot: imap(doug): delete: box=INBOX, uid=55719, 
msgid=, size=3340, from="jnilj" 

Jul  2 00:39:33 mail dovecot: imap(doug): copy from Junk: box=Deleted Messages, 
uid=31049, msgid=, size=3340, from="jnilj" 

Jul  2 00:39:33 mail dovecot: imap(doug): delete: box=Junk, uid=10842, 
msgid=, size=3340, from="jnilj" 

Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=Junk, uid=10842, 
msgid=, size=3340, from="jnilj" 

Jul  2 00:50:29 mail dovecot: imap(doug): expunge: box=INBOX, uid=55719, 
msgid=, size=3340, from="jnilj" 


Is this the intended way the Junk maibox is supposed to work?  I couldn't find 
any settings that appear to control (or affect) this behavior.  

— Doug

Re: Mailbox location

[Doug Hardie]

> On 16 June 2016, at 22:53, Doug Hardie <bc...@lafn.org> wrote:
> 
> I am running a small server with a fixed number of users.  Postfix is using 
> dovecot lda so that I can run pigeonhole.  I have setup a user file with the 
> ids and passwords and everything authenticates properly.  Postfix uses that 
> also.  However, mail is consistently delivered to user@domain.  How do I tell 
> it to deliver to just user?  I have tried setting a variety of different 
> things like:
> 
> 10-mail.conf:mail_location = maildir:/var/mail/home_mail/%u
> 
> userdb {
>  driver = static
>  args = uid= gid= home=/var/mail/home_mail/%u
> }
> 
> and a few other things.  None of them affected the mailbox location.  
> Fortunately, this is a test system as I probably have mucked up the config 
> files by now.  
> 
> — Doug

here is config:

root@test:/usr/local/etc/dovecot/conf.d # doveconf -n
# 2.2.22 (fe789d2): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.13 (7b14904)
# OS: FreeBSD 10.3-RELEASE amd64  ufs
auth_debug = yes
auth_debug_passwords = yes
auth_mechanisms = plain login
auth_verbose_passwords = yes
base_dir = /var/run/home_mail/
first_valid_gid = 0
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k 
session=<%{session}> port=%a
mail_debug = yes
mail_gid = 
mail_location = maildir:/var/mail/home_mail/%u
mail_uid = 
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 {
  args = scheme=CRYPT username_format=%u /usr/local/etc/dovecot/users
  driver = passwd-file
}
plugin {
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
  mail_log_fields = uid box msgid size from
}
postmaster_address = d...@sermon-archive.info
protocols = imap
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
  }
  unix_listener auth-userdb {
group = vmail
mode = 0666
user = vmail
  }
}
service imap-login {
  inet_listener imap {
port = 143
  }
  inet_listener imaps {
port = 993
ssl = yes
  }
}
ssl_cert = 

Mailbox location

[Doug Hardie]

I am running a small server with a fixed number of users.  Postfix is using 
dovecot lda so that I can run pigeonhole.  I have setup a user file with the 
ids and passwords and everything authenticates properly.  Postfix uses that 
also.  However, mail is consistently delivered to user@domain.  How do I tell 
it to deliver to just user?  I have tried setting a variety of different things 
like:

10-mail.conf:mail_location = maildir:/var/mail/home_mail/%u

userdb {
  driver = static
  args = uid= gid= home=/var/mail/home_mail/%u
}

and a few other things.  None of them affected the mailbox location.  
Fortunately, this is a test system as I probably have mucked up the config 
files by now.  

— Doug

Re: Dovecot Bulletin

[Doug Hardie]

> On 20 February 2016, at 18:14, Timo Sirainen  wrote:
> 
> On 21 Feb 2016, at 02:50, Kevin Kershner  wrote:
>> 
>> I'd like to revisit and old post if I may, will/does Dovecot support the old
>> qpopper "Bulletin" ability?
>> 
>> Basically I need a simple way of posting bulletins to all domain users.
>> Qpopper maintained a bulletin db for each user and sent them the next
>> bulletin in sequence.
> 
> I guess there could be a plugin that does this check on each login. But would 
> it actually be useful? Why would it be better than simply sending the mail to 
> all the users? For example:
> 
> doveadm save -A < bulletin.txt

The reasons for bulletins as I see it are:

1.  The doveadm save command is undocumented.  It does show a cryptic line in 
the output of the command "doveadm".  However, it doesn't give any clue what it 
does or how to provide the message.  Your note above provides considerably more 
information on that command.   I tested it and it works as you have indicated 
though.

2.  The doveadm save command causes the email to be saved in each user's 
mailbox.  If you have a lot of users, thats a lot of wasted disk space.  
Qpopper's bulletins only kept one copy and every user downloaded from that 
copy.  All that was retained per user was a counter of the last bulletin's 
sequence number that was downloaded.

— Doug

Re: Multiple Domains

[Doug Hardie]

> On 18 January 2016, at 23:37, Steffen Kaiser <skdove...@smail.inf.fh-brs.de> 
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 18 Jan 2016, Doug Hardie wrote:
> 
>> I have Dovecot 2.2.19 running.  However, one client has a rather unusual 
>> need.  There are multiple domains that currently access their mail on the 
>> server.  However, this on domain/client wants to use a different port for 
>> their users to access mail.  Anyone on the standard port trying to download 
>> mail would receive an invalid user error (or whatever the proper error for 
>> that is).  Likewise, only this clients users could access their mail on the 
>> new port.  Is this possible?
> 
> try to use %a in passdb, I'm not sure if "These variables work only in 
> Dovecot-auth" applies to this scenario, though.
> 
> You could run two instances with different configs on the same host.

Thats the best idea I have seen.  Thanks.  Don't know why I didn't think of it 
;-)

Multiple Domains

[Doug Hardie]

I have Dovecot 2.2.19 running.  However, one client has a rather unusual need.  
There are multiple domains that currently access their mail on the server.  
However, this on domain/client wants to use a different port for their users to 
access mail.  Anyone on the standard port trying to download mail would receive 
an invalid user error (or whatever the proper error for that is).  Likewise, 
only this clients users could access their mail on the new port.  Is this 
possible?

— Doug