Re: [External] IMAP connection lost while sending mail
On 5/6/2022 3:53 AM, Philipp Ewald wrote: we have a strange problem. Costumer use Outlook to connect to our IMAP and SMTP Server. While sending Mails Outlooks reports connection lost. In Mail log there is no reason logged or something else. What i dont understand is that IMAP lose connetion while using SMTP. Outlloks reports problem by moving mails into Send dir. Is that a Outlook problem? i have enables debug logging and cant see any reason :( Network was already testet. Morning Philipp, I would do a couple of things to troubleshoot: 1 - Time it. Is it hitting a specific time and giving up? 2 - Does the email have any specific content? 3 - Do they have anything like A/V software that might be acting to try and proxy / scan the email? 4 - Try putting thunderbird on the same machine for the same account with the same email. Does that work? Regards, KAM
Re: [External] Re: source code doesn't compile
On 1/12/2022 12:14 AM, Ruben Safir wrote: --2022-01-12 00:10:41--https://www.dovecot.org/tmp/wiki2-export.tar.gz Resolvingwww.dovecot.org (www.dovecot.org)... 94.237.12.234, 2a04:3545:1000:720:acc1:5bff:fe5e:4e9 Connecting towww.dovecot.org (www.dovecot.org)|94.237.12.234|:443... connected. OpenSSL: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version Unable to establish SSL connection Looks to me like your installation is too old and you're unable to connect with the ciphers/ssl connection for the download for at least one of the problems. Recommend you look at what happens on the command line when you do just wget -v -d https://www.dovecot.org/tmp/wiki2-export.tar.gz ? I'm going to predict you get Unable to establish SSL connection and likely you have some old versions of wget and perhaps openssl as well that don't support TLS v1.1+ or SNI or something similar. Upgrade your openssl and wget/curl/fetch/whatever tool is downloading the files. Regards, KAM
Re: [External] Re: reconsidering my (your?) current setup
The CentOS community manager is a friend and he understands that they
really missed the mark on the messaging around CentOS8 Stream. In
short, I'm not sure it's going to be that bad of a solution. The doom
and gloom and concerns it would be untested, rawhide-esque solution was
definitely misplaced. Not sure about the container concepts though and
we've been testing with AlmaLinux too!
HTH, KAM
On 10/7/2021 11:39 AM, Michael Peddemors wrote:
AlmaLinux?
On 2021-10-07 1:30 a.m., Marc wrote:
With redhat 'dumping' the support for centos and the availability of
containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by
redhat/centos is more or less 'unavailable'. I thought about using
the repo of dovecot with centos8stream.
--
PCCCLogo <https://www.pccc.com/>
RaptorLogo <https://raptoremailsecurity.com/>
*Kevin A. McGrail
* /CEO Emeritus
/ *Peregrine Computer Consultants Corporation
*
Phone +1.703.798.0171 email
kmcgr...@pccc.com
Globe
www.pccc.comGlobe
www.raptoremailsecurity.com
Location
10311 Cascade Lane, Fairfax, VA 22032
LinkedIn <https://linkedin.com/in/kmcgrail> Twitter
<https://twitter.com/kamcgrail>
Re: [External] Re: What's a Reasonable Inbox Size?
On 5/7/2020 12:56 PM, Asai wrote: > That makes sense. So you're saying that very large inboxes are > generally bad for mobile devices? How are they bad for the servers? I'm saying that large inboxes can be generally bad for MUAs including mobile and desktop. Their just downloading and constantly grinding through data that isn't really being used. Same thing for the server. If you have an inbox with 10K emails, are you reading them all? No, but you are likely checking the inbox every 5 mins. And if you have a 20GB INBOX and you download it on mobile, depending on the MUA and settings, you might be just using a ton of cell data and storage on your phone. Dovecot, of course, has intelligent caching and that helps a ton but overall it's an efficiency thing. Though not that long ago, it was also a way of keeping some MUAs like Outlook from crashing when the PST / OST file got too large. Regards, KAM
Re: [External] Re: What's a Reasonable Inbox Size?
On 5/7/2020 12:43 PM, Asai wrote: > Thanks for your response, > > So, how do those rotation scripts work in concept? > > People are still able to access their old inboxes, but it just moves > them to an archived state? We rotate the folder to another name with the date like INBOX-2020-05-07 with instructions how to refresh their folder list (or even modify the .subscription file for the). We also cull Trash, deleted items, and spam folders automatically as well. Regards, KAM
Re: [External] What's a Reasonable Inbox Size?
On 5/7/2020 11:39 AM, Asai wrote: > What's a reasonable inbox size? Is 20+ GB reasonable and nothing to > worry about? > Great question. At my firm, we wrote rotation tools that work for mbox format to rotate inboxes monthly if they are over a certain size. We also do the sent items folders. We find that large inboxes are bad for the server and bad for the client because the MUAs just don't handle it well either. 1 or 2GBs and you start to see issues. After a little bit of user training, they like it. Part of the routine maintenance they need. Regards, KAM
Re: Mitigation / disable FTS and pop3-uidl plugin was Re: CVE-2019-7524: Buffer overflow when reading extension header from dovecot index files
On 3/28/2019 10:40 AM, Aki Tuomi wrote: > > check for fts in mail_plugins. pop3-uidl is used by pop3_migration > plugin. Sorry if I'm dense but can you be more specific? Are you talking about checking conf files or binary files? For example, does the existence of /usr/local/lib/dovecot/lib20_fts_plugin.so imply an exploitable situation? Are their settings in a conf file that disable those plugins? Regards, KAM
Mitigation / disable FTS and pop3-uidl plugin was Re: CVE-2019-7524: Buffer overflow when reading extension header from dovecot index files
On 3/28/2019 7:42 AM, Aki Tuomi via dovecot wrote: > olution: > Operators should update to the latest Patch Release. The only workaround > is to disable FTS and pop3-uidl plugin. Hi Aki, thanks for the CVE. For quick mitigation, can you confirm how to disable these plugins and what they provide? We'd like to assess if we are using them while we rollout the fix. Regards, KAM
Re: [Dovecot] Compilation Issue on Old Boxes with macro in src/master/main.c
Timo, Thanks, this patch works fine as well. Regards, KAM - Original Message - From: Timo Sirainen t...@iki.fi Anyway, did a cleaner fix: http://hg.dovecot.org/dovecot-1.1/rev/2c7111b2b0d0
[Dovecot] Compilation Issue on Old Boxes with macro in src/master/main.c
I'm throwing an error compiling with a custom-compiled gcc 3.2.3 on one box. The configuration string is CC=/usr/local/gcc3.2.3/bin/gcc CPPFLAGS=-I/usr/local/ssl/include LDFLAGS=-L/usr/local/ssl/lib ./configure --with-ssl=openssl --with-ssldir=/usr/local/ssl/certs --with-pam --with-pop3d --sysconfdir=/etc --localstatedir=/var I've used this to compile on other older boxes with success. And I compared the command lines and they are identical. This is the error I get with src/master/main.c main.c:365:1: directives may not be used inside a macro argument main.c:364:16: unterminated argument list invoking macro printf main.c: In function `print_build_options': main.c:372: syntax error before string constant Changing the function to a simpler function without the ifdef's resolves the issue and dovecot compiles. I would really like to know why two boxes with the same compiler are failing on one but not the other. Perhaps there's some program or library or preprocessor or path or something out of whack. Especially since using gcc 2.96 on the same box works! However, I since this is a simple options output routine and (from my cursory read) there may be some standards issue with this technique, I've also patched the issue. http://www.peregrinehw.com/downloads/dovecot/dovecot-1.1.11-build_options_macro.patch Thoughts? KAM
[Dovecot] Listening on Two Ports on the Same Machine
The docs at http://wiki.dovecot.org/MainConfig?highlight=%28ssl_listen%29 aren't clear but I was wondering if I can have IMAP listening on port 143 and port 144, for example, on the same machine? Regards, KAM
Re: [Dovecot] Follow-up re: gcc 2.96 - Re: PATCH: compile dovecot-1.1.beta14 with gcc 2.95
Well, for me, it's a vast number of boxes deployed and often maintained by others that are running stabling for 8+ years making the nuance of upgrading to a newer version of GCC fairly mute from a lay persons perspective. Seriously, how can you argue with a non-technical user that their box installed in 2001 has a problem when everything is working fine? Plus it annoys Timo and that's just an extra bonus ;-) regards, KAM - Original Message - From: Asheesh Laroia [EMAIL PROTECTED] To: Dovecot Mailing List dovecot@dovecot.org Cc: Kevin A. McGrail [EMAIL PROTECTED]; Sven Anderson [EMAIL PROTECTED] Sent: Wednesday, February 27, 2008 4:35 PM Subject: Re: [Dovecot] Follow-up re: gcc 2.96 - Re: PATCH: compile dovecot-1.1.beta14 with gcc 2.95 On Wed, 27 Feb 2008, Timo Sirainen wrote: On Feb 27, 2008, at 4:22 PM, Kevin A. McGrail wrote: I can't argue with that logic but documenting it in a wiki or INSTALL or including the patches with the distribution might be more agreeable. Why are you people still using so old gcc versions? As an observer, I'd like to remark that it's amazing that twentiety-century known-broken non-releases http://gcc.gnu.org/gcc-2.96.html of GCC are in use in 2008. I'm honestly curious what keeps you guys on them. -- Asheesh. -- Maybe you can't buy happiness, but these days you can certainly charge it.
[Dovecot] Follow-up re: gcc 2.96 - Re: PATCH: compile dovecot-1.1.beta14 with gcc 2.95
As a follow-up on this, these two lines also helped me to compile the 1.1rc1 on gcc 2.96: diff -ru dovecot-1.1.beta13/src/lib/str-find.c dovecot-1.1.beta13.patched/src/lib/str-find.c --- dovecot-1.1.beta13/src/lib/str-find.c Tue Oct 23 16:01:16 2007 +++ dovecot-1.1.beta13.patched/src/lib/str-find.c Thu Jan 17 14:08:03 2008 @@ -12,7 +12,7 @@ unsigned int match_count; int badtab[UCHAR_MAX+1]; - int goodtab[]; + int goodtab[0]; }; static void init_badtab(struct str_find_context *ctx) diff -ru dovecot-1.1.beta13/src/lib-imap/imap-match.c dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c --- dovecot-1.1.beta13/src/lib-imap/imap-match.cSun Dec 9 19:14:27 2007 +++ dovecot-1.1.beta13.patched/src/lib-imap/imap-match.cThu Jan 17 14:09:02 2008 @@ -19,7 +19,7 @@ struct imap_match_pattern *patterns; char sep; - char patterns_data[]; + char patterns_data[0]; }; Regards, KAM - Original Message - From: Sven Anderson [EMAIL PROTECTED] To: dovecot@dovecot.org Sent: Wednesday, January 23, 2008 10:57 AM Subject: [Dovecot] PATCH: compile dovecot-1.1.beta14 with gcc 2.95 Hi, I patched dovecot-1.1.beta14 to compile under gcc 2.95. __builtin_expect and __attribute__((malloc)) are only available since gcc 3.0, and __builtin_types_compatible_p since 3.1. Also the flexible array members (char a[]) are not available for gcc 2.95. So I replaced them with zero-extent arrays (char a[0]), which should also work, but that is gcc specific. A general pointer (char* a) should work as well, I guess. I have attached a patch that fixes all this. It is for beta13 but also works on beta14. BTW.: There is a typo in src/login-common/main.c, it's equivalent, not equilevant. Cheers, Sven -- http://sven.anderson.deBelieve those who are seeking the truth. tel:+49-551-9969285 Doubt those who find it. mobile: +49-179-4939223 (André Gide)
Re: [Dovecot] Possible Caching Bug showing up as a MIME BoundaryIssue
Timo, I continue to deal with this issue where the MIME Boundary appears on the bottom of the email and it is still happening as of Dovecot 1.0.5. Unfortunately, it continues to happen to me ONLY with one email box that I have seen and, of course, the email box has sensitive data in it. I had been hoping the issue would occur with a folder that had something like an email from my mom's brother's cousin sending some forward of some joke that's gone around 200x's but no luck. One update is that I have determined thanks to a colleague that if I move the email to another folder and back, the issue does not reappear so recreating this issue is a bear. Anyway, will *just* the cache file help you because that is information we log anyway and doesn't fall under our privacy issues? Otherwise would you be willing to login to our server via SSH and agree to SAGE's ethics guide and do the research as an administrator under those rules? http://www.sage.org/ethics/ethics_horiz.pdf As an aside, the ethics guideline and SAGE are fantastic for ANY computer professional doing work for other people. Regards, KAM - Original Message - From: Timo Sirainen [EMAIL PROTECTED] Subject: Re: [Dovecot] Possible Caching Bug showing up as a MIME BoundaryIssue When it happens, is it possible that you could send me the mbox file (through http://dovecot.org/tools/mbox-anonymize.pl is fine) and the mailbox's dovecot.index* files? The only problematic file (and the most important one in fixing this) is dovecot.index.cache which could contain email addresses, subjects and other headers.
[Dovecot] Possible Caching Bug showing up as a MIME Boundary Issue
Possible Caching Bug showing up as a MIME Boundary Issue I'm using Dovecot version 1.0.0. I was using Dovecot version 1.0.0 beta3 or alpha4. I upgraded to Dovecot 1.0.0 to make sure that was not the issue. Over the past few weeks on a server running a stable dovecot, I have seem a few emails arriving where the MIME document structure dividers are visible. I've included a screenshot showing this. Using OE6 as client. Have tried adding oe6-fetch-no-newmail per clients wiki but this seems to stop the ability to login at all. I am using two different machines with Outlook Express to access the same email. The same problem will show up on both. Usually, if I delete the .imap cache for the folder, the email comes down correctly. My dovecot -n output is: # /etc/dovecot.conf listen: *:144 ssl_listen: *:994 ssl_cert_file: /usr/local/ssl/certs/stunnel.pem ssl_key_file: /usr/local/ssl/certs/stunnel.pem disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login max_mail_processes: 50 verbose_proctitle: yes default_mail_env: mbox:~/:INBOX=/var/spool/mail/%u mail_location: mbox:~/:INBOX=/var/spool/mail/%u imap_client_workarounds: outlook-idle delay-newmail auth default: passdb: driver: pam userdb: driver: passwd userdb: driver: prefetch The server is on a heavily modified RedHat 7.2 on x86 box with ext3 Thanks in Advance, KAM attachment: mime-boundary-bug.gif
