Re: Broken link on doc.dovecot.org

[Aki Tuomi via dovecot]

Hi!

Sorry missed this, we'll look into it.

Aki

On 10.10.2019 21.00, Karen Woodman via dovecot wrote:
> Hi again,
>
> I wanted to check in and see if you got my note about the broken link
> on your site.
>
> Thanks!
> Karen
>
> On Monday, October 7, 2019 at 5:05 PM, Karen Woodman
> mailto:ka...@getmailbird.co>> wrote:
>
> Hi there,
>
> I noticed that you have a broken link to a website called
> Qmail.org. That site was first published 23 years ago (back in
> 1996!) but unfortunately, it is no longer a working website.
>
> You link to Qmail.org on this
> page: 
> https://doc.dovecot.org/configuration_manual/authentication/checkpassword/
>
> We just published an article that explores what happened to the
> site.  I think it's an interesting story, and it could be useful
> to your readers.
>
> In addition, since all of the original articles are gone, we
> included a curated list of the best Qmail resources and mirrors.
>
> Here's the article if you want to take a
> look: 
> https://www.getmailbird.com/what-resources-are-available-now-that-qmail-org-is-gone/
>
> Would you consider swapping out the broken link for our article?
>
> Please let me know if you have any questions and thank you for
> your time.
>
> Sincerely,
> -Karen
>
> --
> Karen Woodman, Editor
> 5 Ross Rd
> Durham, NH 03824
>
> By the way, if you didn't like getting this email you
> can unsubscribe
> 
> 
>  and
> I won't email you anymore.  :)
>
>

Re: Password issue

[Daniel Miller via dovecot]

On 10/9/2019 6:58 PM, @lbutlr via dovecot wrote:

On Oct 9, 2019, at 5:23 PM, @lbutlr  wrote:

Postfix logs "Client host rejected: Access denied” but as I said, other 
accounts can submit and there’s nothing special in the submission service in 
master.cf.


submission inet  n   -   n   -   -   smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_security_options=noanonymous
-o smtpd_sasl_path=private/auth
-o smtpd_milters=
-o milter_connect_macros=
-o milter_macro_daemon_name=ORIGINATING
-o syslog_name=postfix/submit
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_data_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_helo_restrictions=
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject





I suggest you re-post this to the Postfix as this is a Postfix issue. 
However, before doing so, reference

http://www.postfix.org/DEBUG_README.html

To begin with, I'd suggest adding a "-v" to the smtpd command above, 
followed by a Postfix reload, and test sending again. If that doesn't 
reveal your issue re-post to the Postfix list, and include the output of 
"postconf -n". BTW - I'm assuming the duplicate 
smtpd_recipient_restrictions line at the end is an email artificat.


--
Daniel

Re: Broken link on doc.dovecot.org

[Karen Woodman via dovecot]

Hi again,

I wanted to check in and see if you got my note about the broken link on
your site.

Thanks!
Karen

On Monday, October 7, 2019 at 5:05 PM, Karen Woodman 
wrote:

> Hi there,
>
> I noticed that you have a broken link to a website called Qmail.org. That
> site was first published 23 years ago (back in 1996!) but unfortunately, it
> is no longer a working website.
>
> You link to Qmail.org on this page:
> https://doc.dovecot.org/configuration_manual/authentication/checkpassword/
>
> We just published an article that explores what happened to the site.  I think
> it's an interesting story, and it could be useful to your readers.
>
> In addition, since all of the original articles are gone, we included a
> curated list of the best Qmail resources and mirrors.
>
> Here's the article if you want to take a look:
> https://www.getmailbird.com/what-resources-are-available-now-that-qmail-org-is-gone/
>
> Would you consider swapping out the broken link for our article?
>
> Please let me know if you have any questions and thank you for your time.
>
> Sincerely,
> -Karen
>
> --
> Karen Woodman, Editor
> 5 Ross Rd
> Durham, NH 03824
>
> By the way, if you didn't like getting this email you can unsubscribe
> 
>  and
> I won't email you anymore.  :)
>

Using maldet

[Ignacio García via dovecot]

Hi there.

Sometimes I notice that some malware gets through amavis+clamav+postfix 
and lands in the user's maildir files. I wonder if it would make sense, 
or even if it would be advisable to scan and clean those files using a 
program as maldet


Thanks for your help.

Ignacio

[BUG REPORT] Case sensitivity in :addresses in sieve vacation scripts

[Julian Kippels via dovecot]

Am Tue, 08 Oct 2019 08:13:29 -0400
schrieb James Cassell via dovecot :

> On Tue, Oct 8, 2019, at 7:58 AM, Julian Kippels via dovecot wrote:
> > Hi,
> > 
> > I have recently updated from Dovecot 2.2 to 2.3. Since I have
> > noticed that vacation responses from sieve are not working the same
> > anymore. For example, my sieve script looks like this:
> > 
> >  vacation :days 1 :addresses
> > ["kipp...@hhu.de","julian.kipp...@hhu.de"]
> > 
> > it used to be that I got a vacation response if I sent a mail to
> > kipp...@hhu.de and kipp...@hhu.de. Now I only get a response for
> > kipp...@hhu.de, not for kipp...@hhu.de.
> > I cant say for sure, but I suppose this behaviour changed with the
> > update. If not, why could this have happened? And in any case, how
> > can I enable case insensitivity?
> >   
> 
> I took a look at the RFCs.  It appears that this change is not in
> accordance with the relevant standards.  SIEVE says 'the
> "i;ascii-casemap" comparator (which treats uppercase and lowercase
> characters in the US-ASCII subset of UTF-8 as the same).  If left
> unspecified, the default is "i;ascii-casemap".'
> https://tools.ietf.org/html/rfc5228#section-2.7.3
> 
> Since there is no mention of comparators in the Vacation RFC, it
> should fallback to case-insensitive:
> https://tools.ietf.org/html/rfc5230
> 
> You could try working around the issue by adding to your `vacation`
> statement: `:comparator "i;ascii-casemap"` -- but in any case, I'd
> file a bug about the non-standard behavior.
> 
> 
> V/r,
> James Cassell
> 
> 
> > Thanks
> > Julian
> > 
> >  

Unfortunately adding the :comparator statement to vacation results in
an error while compiling the script:

managesieve: line 5: error: unknown tagged argument ':comparator' for
the vacation command (reported only once at first occurrence).

Since https://www.dovecot.org/bugreport-mail states that bugs should be
reported to this mailing list, please consider this a bug report.

Obligatory information as follows:
doveconf -n can be found at https://pastebin.com/pjxFNfWr
Dovecot and Pigeonhole version 2.3.7.2 installed from repo.dovecot.org
on CentOS 7.

Kind Regards
Julian

Re: Using attachment_dir with plugin zlib corrupt mails

[Timo Sirainen via dovecot]

Can you test if 
https://github.com/dovecot/core/commit/5068b11e594ad7cc1f7cedf2bd9280520e0e534d.patch
 

 fixes it for you?

> On 10 Oct 2019, at 11.34, MAREN ZUBIZARRETA via dovecot  
> wrote:
> 
> Hello:
>  
>   I have found the same problem reported above by Patrick Cernko affecting 
> our system and corrupting our messages. Even worse, Outlook 2016 will no 
> synchronize and the clients cannot see any message, even if there is only one 
> corrupted mail per mailbox.
>  
>   I cannot figure out a feasible workaround for our system, and I can see 
> that in new version 2.38 the bug is not fixed.
>  
>  Will this issue be treated soon?
>  
>  Thanks a lot
>  
>  Maren Zubizarreta
>  
> 
> WARNING: using attachment_dir with plugin zlib can corrupt mails
> 
> Patrick Cernko pcernko at mpi-klsb.mpg.de 
> 
> Fri Jul 19 17:52:37 EEST 2019
> Previous message: index worker 2.3.7 undefined symbol errors 
> 
> Next message: Address family not supported by protocol 
> 
> Messages sorted by: [ date ] 
>  [ thread ] 
>  [ subject ] 
>  [ author ] 
> 
> Hello list, hello Dovecot developers,
>  
> this week, I discovered a serious bug in Dovecot, that lead to several 
> broken mails on our servers. The bug corrupts the first few characters 
> of the mail header during saving. On our setup, it was almost always 
> only the very first line of text, that was corrupted.
>  
> Depending on the IMAP client (they seem to request different header 
> fields, ... during mail access), the bug causes the imap process to hang 
> up the TCP connection and log errors like this:
>  
> > imap(USERNAME)<4767>: Error: Corrupted record in index 
> > cache file 
> > /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache:
> >  UID 489113: Broken fields in mailbox Trash: 
> > read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))):
> >  FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2 vs 
> > 122
>  
> In our case that finally grabbed my attention, the client was the users 
> iphone that did not display any new messages but his Thunderbird did.
>  
> The bug seems to be triggered by a bad "interaction" of attachment_dir 
> option and zlib plugin. If you use both, you most likely are affected, 
> too, except you only use zlib plugin for reading previously compressed 
> stored mails. That's also the workaround we use now: zlib plugin only 
> enabled in mail_plugins but no plugin/zlib_save set.
>  
> The bug occurs on very specific mails. Due to privacy reasons I could 
> not provide sample mails here. Storing such mails seems to trigger the 
> bug reproducible.
>  
>  
> I attached a very minimal doveconf -n config, that can be used to 
> trigger the bug. If one of the developers is interested, I can try to 
> generate an "anonymized" version of such a specific mail that still 
> causes the issue. I discovered the bug on our productive systems, 
> running latest Dovecot 2.2 release, but the latest 2.3 I used during 
> debugging is affected, too.
>  
> During debugging, I also found one hint, that might help find the bug: 
> If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and 
> then disable the zlib plugin in mail_plugins, you can call
>  
> doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress
>  
> on test's mailbox with only that one broken mail.
> This will display the beginning of the rfc822 mail text until gzip 
> terminates with "gzip: stdin: unexpected end of file", approximately 
> after twice the length of the mail HEADER. This might indicate, that 
> dovecot stores the uncompressed size of the header in it's data 
> structures although the mail is stored compressed.
>  
>  
> I also found a very efficient way to find all affected mails in our setup:
>  
> doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \
>grep -a "^[^ ]+ user=" | \
>grep -avF ' hdr=Return-path: ' | \
>grep -av '.* hdr=[[:print:][:space:]]*$'
> (runtime for ~6M mails on our servers was 20-30min)
>  
> This can be even more optimized if you have a powerful storage system 
> with GNU parallel:
> > doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid 
> > mailbox uid seq flags hdr' all | grep -a '^user=' | grep -avF ' 
> > hdr=Return-path: ' | grep -av '.* hdr=

Re: Show messages within 60 days

[Sami Ketola via dovecot]

> On 10 Oct 2019, at 9.51, jacky HU via dovecot  wrote:
> 
> Hello,
> 
> Can my inbox be set up, for example, only for messages within 60 days?
> I don't want to create a new virtual mailbox.
> Can anyone help me?

No if you don't want to use virtual mailbox.

Sami

Using attachment_dir with plugin zlib corrupt mails

[MAREN ZUBIZARRETA via dovecot]

Hello:



  I have found the same problem reported above by Patrick Cernko affecting our 
system and corrupting our messages. Even worse, Outlook 2016 will no 
synchronize and the clients cannot see any message, even if there is only one 
corrupted mail per mailbox.



  I cannot figure out a feasible workaround for our system, and I can see that 
in new version 2.38 the bug is not fixed.



 Will this issue be treated soon?



 Thanks a lot



 Maren Zubizarreta


WARNING: using attachment_dir with plugin zlib can corrupt mails
Patrick Cernko pcernko at 
mpi-klsb.mpg.de
Fri Jul 19 17:52:37 EEST 2019

  *   Previous message: index worker 2.3.7 undefined symbol 
errors
  *   Next message: Address family not supported by 
protocol
  *   Messages sorted by: [ date 
] [ thread 
] [ subject 
] [ author 
]



Hello list, hello Dovecot developers,



this week, I discovered a serious bug in Dovecot, that lead to several

broken mails on our servers. The bug corrupts the first few characters

of the mail header during saving. On our setup, it was almost always

only the very first line of text, that was corrupted.



Depending on the IMAP client (they seem to request different header

fields, ... during mail access), the bug causes the imap process to hang

up the TCP connection and log errors like this:



> imap(USERNAME)<4767>: Error: Corrupted record in index 
> cache file 
> /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache:
>  UID 489113: Broken fields in mailbox Trash: 
> read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))):
>  FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2 vs 122



In our case that finally grabbed my attention, the client was the users

iphone that did not display any new messages but his Thunderbird did.



The bug seems to be triggered by a bad "interaction" of attachment_dir

option and zlib plugin. If you use both, you most likely are affected,

too, except you only use zlib plugin for reading previously compressed

stored mails. That's also the workaround we use now: zlib plugin only

enabled in mail_plugins but no plugin/zlib_save set.



The bug occurs on very specific mails. Due to privacy reasons I could

not provide sample mails here. Storing such mails seems to trigger the

bug reproducible.





I attached a very minimal doveconf -n config, that can be used to

trigger the bug. If one of the developers is interested, I can try to

generate an "anonymized" version of such a specific mail that still

causes the issue. I discovered the bug on our productive systems,

running latest Dovecot 2.2 release, but the latest 2.3 I used during

debugging is affected, too.



During debugging, I also found one hint, that might help find the bug:

If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and

then disable the zlib plugin in mail_plugins, you can call



doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress



on test's mailbox with only that one broken mail.

This will display the beginning of the rfc822 mail text until gzip

terminates with "gzip: stdin: unexpected end of file", approximately

after twice the length of the mail HEADER. This might indicate, that

dovecot stores the uncompressed size of the header in it's data

structures although the mail is stored compressed.





I also found a very efficient way to find all affected mails in our setup:



doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \

   grep -a "^[^ ]+ user=" | \

   grep -avF ' hdr=Return-path: ' | \

   grep -av '.* hdr=[[:print:][:space:]]*$'

(runtime for ~6M mails on our servers was 20-30min)



This can be even more optimized if you have a powerful storage system

with GNU parallel:

> doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid mailbox 
> uid seq flags hdr' all | grep -a '^user=' | grep -avF ' hdr=Return-path: ' | 
> grep -av '.* hdr=[[:print:][:space:]]*$' || true"

(runtime for ~6M mails on our servers was ~4min)



The command will give you a list of mails that possibly are affected,

check the full output of



doveadm fetch -u USERNAME hdr guid GUID | less



to verify that the header is really broken.



On our systems I found 39 mails within ~12M mails.



I was able to recover these mails "manually" by reconstructing the

Return-Path