Re: Question about sieve language
* Tom Hendrikx via dovecot: > Or in readable sieve: [...] Do you mean to imply that regular expressions are not readable? ;-) All it takes is a little practice. Besides, regex are more efficient. It is well worth learning about them, and regex are really not as bad as some make them out to be. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Question about sieve language
* Lev Serebryakov:
> I need to match all messages sent from some specific domain and all
> its sub-domains.
I prefer using regular expressions for this kind of tests:
if address :regex "From" "[@.]example\.(com|org)$" {...}
This will match all addresses for example.com, example.org and their
respective subdomains.
-Ralph
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: 2 users who are the same user
* Michael Grant via dovecot: > If I have a user in /etc/passwd, for example 'joe' and a user in > /etc/dovecot/users, j...@example.org, and both of these users are in > fact the same user but different password. They use the same inbox > and the same mail files. Do these two share a single user ID, or do they use separate IDs? Think about file/directory ownership and permissions. If user IDs 123 and 234 attempt use the same directory, things will break. User 123 should not be able to delete a file owned by user 234, for example. Perhaps have a look at your setup, and verify that you are matching multiple logins to a single OS user ID only. For example, you can use LDAP login to map an arbitrary login name to a given UID. This works nicely with Dovecot. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Trouble with SMTP, TLS and dovecot.org.
* Aki Tuomi via dovecot: > I updated the settings a bit on the server as well. Maybe it works > better now? Yes, it does indeed: Sep 7 19:33:23 ra postfix/smtp[14429]: Trusted TLS connection established to talvi.dovecot.org[2a04:3545:1000:720:acc1:5bff:fe5e:459]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature ECDSA (secp384r1) client-digest SHA384 Sep 7 19:33:24 ra postfix/smtp[14429]: 1989FBE002A: to=, relay=talvi.dovecot.org[2a04:3545:1000:720:acc1:5bff:fe5e:459]:25, delay=4.3, delays=0.01/0.01/3.6/0.73, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D22D55DEF4) Thank you, Aki. Would you be willing to share what was changed in your server's settings and/or certificates? I am still wondering what exactly caused the issue. By the way, I have reverted all TLS-related changes previously used for testing on my end, returning to Postfix's defaults. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Trouble with SMTP, TLS and dovecot.org.
* Marc Schiffbauer via dovecot: > Wild guess: you need to explicitely allow for example DEFAULT@SECLEVEL=0 > ciphersuite in postfix to make *your* openssl accept this remote sslv3 > connection Thanks, Marc. I had thought about this, and have tried various Postfix parameters related to TLS ciphers and protocols. So far, no dice. In the meantime, I also ran tests using Swaks, and this resulted in a possible different route of investigation: Postfix uses a certificate issued by Let's Encrypt (secp384r1) for both in- and outbound connections with STARTTLS. If I use the same certificate with Swaks, I see the same error as I do with Postfix. If I use Swaks *without* specifying a local TLS certificate, the STARTTLS handshake works: === Trying talvi.dovecot.org:25... === Connected to talvi.dovecot.org. <- 220 talvi.dovecot.org ESMTP Postfix (Debian/GNU) -> EHLO ra.horus-it.com <- 250-talvi.dovecot.org <- 250-PIPELINING <- 250-SIZE 104857600 <- 250-ETRN <- 250-STARTTLS <- 250-ENHANCEDSTATUSCODES <- 250-8BITMIME <- 250-DSN <- 250 CHUNKING -> STARTTLS <- 220 2.0.0 Ready to start TLS === TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 === TLS no local certificate set === TLS peer DN="/CN=talvi.dovecot.org" Looks the combination of certificate ciphers and OpenSSL library versions on my end and on the talvi.dovecot.org end is causing some bother. The original error message points to a protocol issue, not a cipher problem, and how SSLv3 gets into the mix is anybody's guess. Perhaps I'll see clearer after some much needed sleep. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Trouble with SMTP, TLS and dovecot.org.
Hello, I cannot seem to send STARTTLS protected mail to talvi.dovecot.org, and I was wondering if anybody else sees similar problems: Sep 6 22:29:10 ra postfix/smtp[15748]: SSL_connect error to talvi.dovecot.org[94.237.105.223]:25: -1 Sep 6 22:29:10 ra postfix/smtp[15748]: warning: TLS library problem: error:0A000417:SSL routines::sslv3 alert illegal parameter:../openssl-3.0.9/ssl/record/rec_layer_s3.c:1586:SSL alert number 47: Sep 6 22:29:10 ra postfix/smtp[15748]: 1AAE4BE0031: Cannot start TLS: handshake failure Sep 6 22:29:10 ra postfix/smtp[15748]: SSL_connect error to talvi.dovecot.org[2a04:3545:1000:720:acc1:5bff:fe5e:459]:25: -1 Sep 6 22:29:10 ra postfix/smtp[15748]: warning: TLS library problem: error:0A000417:SSL routines::sslv3 alert illegal parameter:../openssl-3.0.9/ssl/record/rec_layer_s3.c:1586:SSL alert number 47: Sep 6 22:29:10 ra postfix/smtp[15748]: 1AAE4BE0031: to=, relay=talvi.dovecot.org[2a04:3545:1000:720:acc1:5bff:fe5e:459]:25, delay=1.6, delays=0.02/0.01/1.6/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) Sep 6 22:30:05 ra postfix/smtpd[15616]: timeout after END-OF-MESSAGE from localhost[127.0.0.1] Sep 6 22:30:05 ra postfix/smtpd[15616]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5 The originating server uses Postfix 3.8.2 and OpenSSL library 3.0.9. To be able to send messages to dovecot.org at all, I had to use Postfix's "smtp_tls_policy_maps" setting to explicitly disable TLS for this destination domain. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: DOvecot requires both IPv4 and IPV6 to start
* TWHG Technical via dovecot: > I hope this is the right place to start. Not really. What you are asking for (changing the default configuration provided by Ubuntu) is something better asked of the Ubuntu package maintainers, should they even agree with your assessment. They might tell you that adapting the packaged configuration manually is a basic requirement, and also that running a server without IPv6 in 2023 is likely to cause some issues. -Ralph ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Unable to write *.sieve files while Dovecot is running
* Alexander Dalloz: > IMHO dovecot only consumes the bytecode sieve filter, not the plain > text source file based on which the bytecode get generated. Quoting the sievec(1) manual page: [...] Dovecot's LDA process will first look for a binary file "dovecot.svbin" when it needs to execute "dovecot.sieve". It will compile a new binary when it is missing or outdated. Changing the *.sieve file has always been sufficient. Manually invoking sievec is just something I do because it will tell me right away if my latest changes introduced a syntactic mistake. > I would be your issue is cause by unix permissions or by MAC systems > like grsecurity, SELinux or Apparmor. That comment of yours got me experimenting today. I stopped Deovecot and messed about with the example.siev e file. Finally, I renamed it to old.sieve, and then used cat old.sieve > example.sieve to create a fresh file with with the old content. I can now once again modify example.sieve while Dovecot is running, and Dovecot recompiles it to example.svbin as necessary. While I don't know how the original *.sieve file got "broken" in terms of permissions or special attributes, it appears that it was indeed a local issue unrelated to Dovecot itself. My apologies, and thanks. -Ralph
Unable to write *.sieve files while Dovecot is running
I noticed lately that I can no longer modify *.sieve files while Dovecot is running. Write operations appear not to be permitted anymore: $ echo >> example.sieve zsh: permission denied: example.sieve Text editors like vim cannot write either. Since I used to be able to modify Sieve source files on the fly, I am wondering if the behaviour I see nowadays is intentional? Doveconf reports the following versions: # 2.3.14.1 (9f0cfb6426): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.14 (1b5c82b2) # OS: Linux 5.17.1-gentoo-r1-x86_64 x86_64 Gentoo Base System release 2.7 -Ralph
Re: email location - files or sql
* Robert Moskowitz:
> What I am seeing is that many of the packages seem to roll the
> messages into some SQL database.
Do they?
> My Dovecot setup uses the /home/vmail/doman/../{cur,new,etc} tree
> structure.
That's the classic Maildir format. Widely supported, works fine if file
system nodes are not a scarce commodity. Dovecot supports other formats
(see https://doc.dovecot.org/admin_manual/mailbox_formats/) as well, but
I still use Maildir because it is required by Notmuch, which is my
software of choice for handling all my mailing list subscriptions.
Personally, I would not use a relational database as a mail store unless
specifically required by the mail system of your choice. Email is not
organised in a way that benefits from a RDB.
> Is there some nice packed mailserver I can drop on a Centos-arm server
> that has Dovecot under the covers and I can easily rsync my current
> mail store to it?
As far as migrating content is concerned, you're better off using some
form of IMAP synchronisation. This method is not dependent on the
underlying mail store format, and it preserves the IMAP flags for your
existing messages.
-Ralph
Re: Strategies for protecting IMAP (e.g. MFA)
* Tyler Montney: > I'm getting the feeling that people don't have an MFA implementation. Probably because it can be complex to set up and maintain, and more would be gained by educating users and in particular by users actually giving a damn about password-discipline and -quality. On a tangent: I personally find your style of quoting a bit irritating, especially because you leave the whole original message intact. Why not quote in a manner we have successfully used for a couple of decades? Thanks! -Ralph
Re: Strategies for protecting IMAP (e.g. MFA)
* Tyler Montney: > Since this is getting increasingly complicated, I wanted to ask before > going further. What do you all do? Any recommendations? Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections. These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link. -Ralph
Re: How to enable LDAP authentication for schema SSHA384
* Stuart Henderson: > you could perhaps use "auth_bind = yes" to have Dovecot attempt a bind > with the user-supplied password [...] Thanks, that sounds like an approach worth investigating to me. Current access control settings for the LDAP server do not permit this method of binding, but I might be able to have the settings changed. -Ralph
Re: How to enable LDAP authentication for schema SSHA384
* Alexander Dalloz: > Don't know about Ubuntu specifics [...] Thank you for the pointers. Am I right to interpret the Dovecot docs as stating that SSHA384 is not supported by the official packages, and that my only recourse might be building from the source code and adding some external code in the process? I do not remember encountering SSHA384 before, but the existing LDAP records use this schema for about half of a huge user base. Telling all affected users to change their passwords is not an option. -Ralph
How to enable LDAP authentication for schema SSHA384
While using LDAP-based authentication, I have come across the message auth: Error: [...] Unknown scheme SSHA384 Based on the docs at [1] I use the dovecot.org packages provided for Ubuntu 20.04 LTS which, as you can see, are not yet documented in the HTML page, put are available via [2]. Specifically, I used apt-get install dovecot-ldap dovecot-sqlite to install Dovecot. What else is needed beyond the two listed packages in order to enable support for SSHA384 password hashes in Dovecot? Am I perhaps missing some required configuration parameter? Your help is appreciated. -Ralph [1] https://doc.dovecot.org/installation_guide/dovecot_community_repositories/ubuntu_packages/ [2] http://repo.dovecot.org/ce-2.3-latest/ubuntu/focal/
automx2 (Re: What imap ssl/auth settings work best with MS Outlook?)
* sebast...@sebbe.eu: > When you enter your email address, it would be TRIVIAL to check the > MX records for the domain and fill those in for the SMTP and IMAP > servers, allowing users to more easily add (if needed) the domain > prefix. As pointed out here before, that approach would not generally work. Many organisations split services over different IP addresses, and the IMAP server need not bear any relationship to MX (inbound) or MTA (outbound). Vendors use different types of autodiscover/autoconfig mechanisms. I have written a service that implements some of them: https://rseichter.github.io/automx2/ It may be overkill for domains with a very small user base with purely static data, but for medium sized organisations upwards or for those who need to lookup email addresses from LDAP (matching an unrelated login name), automx2 provides a means of handing out config data to iOS/macOS Mail, some Outlook versions, Thunderbird, KMail, and more. The documentation I pointed to also includes a description of some of the mechanisms and RFCs behind it, in case you are interested. -Ralph
Re: Feature request.
* Rogier Wolff: > a few days ago my [Let's Encrypt] certificate expired and the > fetchmail deamon running in the background had nowhere to > complain. > [...] > Feature request: check the expiry date on the SSL certificate as it > is being loaded and check for a new certificate if it HAS expired. That's not something Dovecot needs to worry about. You did not specify what mechanism you use to update your certificates, but both certbot and duplicity (likely the most common tools for Linux) support post-update hooks that let you automatically reload/restart Dovecot whenever a certificate update occurs. -Ralph
Re: Login auth strip domain from username
* David Pottage: > is there a setting in dovecot that if it is given an email address as > a login username it strips off the domain part [...] You're probably looking for the 'username_format' configuration parameter. > If you know how to do that for postfix for sending email, then even > better! Assuming you need to configure more than a single MUA, you might find https://gitlab.com/automx/automx2 useful. -Ralph
Re: handling spam from gmail.
* Andreas Born: > I meant the different stages when receiving mails over SMTP [...] I am well aware of the technical details of SMTP. Your comment is unclear to me because the OP did not make any limitations on when he wants to counter spam, so why would we artificially limit ourselves in this discussion? SMTP allows rejecting messages even after the whole body has been received (end of DATA phase in SMTP, EOM phase in the milter protocol). > for many years it was code of practice to send error/rejection codes > latest after the RCPT TO command [...] Can you name examples? I have never used a milter so restricted, nor have I seen one being used. > Rejecting a mail AFTER the DATA command (when the content becomes > available) was discouraged because of incorrect behaving > MTAs. (e.g. generating backscatter, or even treating the mail as > successfully sent) Again I am stumped by what you write. SMTP rejection does not generate backscatter. Frankly, I see no use in discussing broken MTAs or milters, real or imagined. Using milter-regex and other milters with Postfix works fine as I described it. What you wrote therefore makes little sense to me. -Ralph
Re: handling spam from gmail.
* Andreas Born: > There exists one problem: at this stage of mail reception you have no > body content nor header information on which a milter may perform > deeper analysis, only envelope data. I am not sure what you mean by "this stage of mail reception", or what software you are using that may be limited in such a particular manner, but generally speaking you are wrong. For example: Postfix supports both before-queue filters and after-queue filters. Milter-regex[1] supports both multi-header and body checks. The milter protocol itself allows for both header and body manipulation. [1] http://www.benzedrine.ch/milter-regex.html -Ralph
Re: Dovecot /VMWare Boxer
* Sami Ketola: > They do not rely on Date header. Date header is not mandatory and also > it's not written on server side. It is written by the sender. Could you please elaborate on "Date header is not mandatory"? As far as the message format goes, "Date" and "From" are actually the two required headers in every message (see RFC 5322), so I am not quite sure what you mean? -Ralph
Re: handling spam from gmail.
* Marc Roos: > 3. system recognizes as this email never been seen before > 4. auto reply with something like (maybe with a wait time of x hours): >Your message did not receive the final recipient. You are sending >from a known spam provider Generating backscatter is definitely not a good move, and it is even prone to punish yourself. Better to reject the offending message with a 5xx status code and some explanatory text or the URL. The various tests required to come to a decision about accepting or rejecting the message can be executed in a milter. Milter-regex, for example, is lightweight but still powerful enough to perform tests on combinations of various headers and the body content. Beyond that, a custom milter is always an option. -Ralph
Re: handling spam from gmail.
* Hendrik Boom: > I use greylisting with my postfix. On Debian and Devuan th package is > called 'postgrey'. Classical, time-based greylisting like Postgrey is problematic in this age of 2FA and other email-based confirmation codes. Besides, Postfix has its own, superior mechanism called "Postscreen" built in. This has recently been discussed once again, in-depth, on the Postfix mailing list, so I suggest interested parties to check the ML archives. -Ralph
Re: Only show mails within 30 days or 60 days?
* h...@cndns.com: > For example, in the mail client tool, the user clicks the inbox button > and only sees the mail within 30 days. You pretty much answered your own question there. The mail user agent (MUA, what you called "mail client tool") is the one responsible for showing only a subset of available messages. -Ralph
Re: migrating dovecot to new server
* David Mehler: > I'd ideally like to back up all the mails in the maildir location, > copy that over, load in my configuration files, and bring the system > back up. I don't think this qualifies as "ideal" for migration. My recommendation is to set up the new server and configure Dovecot replication (see Wiki). If you configured things correctly, migration will happen without further intervention, and if there is a problem, you can resolve it in your own time, without damaging the existing server and data. -Ralph
Re: sieve question
* mj: > Our autoreply message reads: "Your email has not been read nor > forwarded", which is also the case, forcing the sender to take action. No, it does not. An auto-reply message, even if it is actually read by the sender, can be ignored without penalty. An MTA rejection puts the ball into the sender's court because the message has never been accepted by the recipient's MX. By the way, a rejection is "legally safe", while your catch-all-and-let-messages-rot approach is not, in case you have not considered that. Of course, you can do as you please, but that does not change the facts and mechanics involved. -Ralph
Re: sieve question
* mj: > this means those emails are not actually delivered anymore. Sure. That's how I interpreted your notification text "This message is sent automatically, and your message has NOT been read nor forwarded." If the message is not being read, why accept it in the first place? > For now, I would like them to *be* delivered, so we still have them in > case something important comes in. Speaking for myself: If I send email to a business partner, that email can be a) rejected, so I know I'll have to find another way to reach the intended recipient, or it can be b) accepted, in which case I expect it to be read/processed. What you describe seems to be neither fish nor flesh to me. Using MTA rejects leaves no doubt that the *sender* has to become active. As I understand it, that is you goal, is it not? -Ralph
Re: sieve question
* mj: > Can anyone suggest what to do here? I suggest you don't use Sieve for this, but simply configure Postfix to reject messages to @old.domain.com with the desired message. MTA rejections signal clearly that the message has not been delivered, and you can also include an URL pointing to a web page with more detailed information. -Ralph
Re: replication newbie: some beginner questions
* Stefan G. Weichinger: > does it make sense in this case to set up replication and let the > servers replicate at first while still running on the old server? If you use "dsync over TCP connections" [1], you can set up your new server without users noticing it (with the exception of extra server load for replication). It will take some time to sync all the data, but it takes no manual action once replication is fully set up. [1] https://wiki.dovecot.org/Replication The docs state one should be able to use a "noreplicate" field to limit the accounts, but I was not able to get it to work with a LDAP user DB. Regardless what value I provided in LDAP, replication would happen, and I could not find detailed documentation. > do I have advantages over doing some rsync-jobs? Oh, you know, some small stuff, like data integrity checks, retry on failures, event-driven replication. ;-) -Ralph
Re: got a listener on 993
* Jean-Daniel: > One rational for this is to make sure broken clients don’t send clear > text credential on port 143, even if STARTTLS is required. If clients are broken, they can send clear text credentials to any port and a network sniffer could record the content. Heck, one can do stupid things with "netcat" if one really wants to. The decision to allow STARTTLS or not depends on the clients that need to connect. As long as the protocol is followed, the difference in terms of security is negligible. -Ralph
Re: got a listener on 993
* David Mehler: > Before I get in to my question is ssl on 993 or starttls on 143 better > from a security perspective? On the server side, it makes little difference. STARTTLS just means a number of extra bytes are exchanged while an encrypted connection is being established. If you want to support a wide range of clients, expose both ports. -Ralph
Re: Gmail and POP3
* Yannick SIEGLER: > auth: Debug: auth client connected (pid=21831) > pop3-login: Debug: SSL: where=0x10, ret=1: before SSL initialization Today's announcement[1] about "less secure apps" seems to imply that POP3/IMAP will soon no longer be an option with G Suite accounts. You may be better off searching for alternatives rather than trying to get POP3 to work. [1] https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html -Ralph
Re: [Sieve] Multiple email recipients, how?
* Tom Hendrikx via dovecot: > There are nice tricks you can do with virtual alias maps and pcre > within postfix to split email to specific user accounts, which could > also accommodate other alias schemes than standard subaddressing (such > as yours). Postfix supports sub-addressing out of the box, simply by setting the "recipient_delimiter" configuration parameter[1]. -Ralph [1] http://www.postfix.org/postconf.5.html#recipient_delimiter
Re: [Sieve] Multiple email recipients, how?
* Robert via dovecot: > We use a simple system for routing emails to different email users by > postfixing the addresses with the actual user: xxxJohn@domain; > yyyJohn@domain etc all will be delivered to user John. > (This way John can invent a new email address on-the-fly and that will > be delivered to his email box.) This seems like a strange way achieve flexible email addresses. Are you aware of sub-addressing? It has been around for ages, and is supported by Dovecot (and Gmail, incidentally). Imagine an existing email account . If alice wants to use a subadress, she signs up with , and Dovecot can automatically place incoming mail for that address into INBOX/foo (or just INBOX if INBOX/foo does not exist). Alice can use as many sub-adresses as she needs without anybody making config changes. Frankly, the Sieve-based approach you describe seems pretty complicated in comparison. -Ralph
Re: Perl was: JMAP: Re: http API for IMAP
* Thomas Güttler via dovecot: > https://github.com/guettli/programming-guidelines#regex-are-great---but-its-like-eating-rubbish Thanks for including the disclaimer "It's my personal opinion and feeling. No facts, no single truth." in your 'guidelines' (many of which I disagree with). I just wish you had included the same disclaimer in what you wrote in this thread, instead of presenting your personal opinions and beliefs as facts. Also, this has drifted far away from being related to Dovecot in any useful way. -Ralph
Re: http API for IMAP
* Thomas Güttler via dovecot: > Most people use http based APIs today. And what makes you think that? Who is "most people", exactly? From my experience over the last 35 years in the business, there is no clear indication that HTTP-based APIs will dominate in the future. SMTP and IMAP have been named dead or dying for so long that I forgot to keep track, but they still work today, although modern designs would look different. > Quoting this answer: https://stackoverflow.com/a/46886237/633961 And how is that related? SmtpJS is just one example of how the goal can be achieved if one is hell-bent on using JavaScript. You can write your own proxy service if you like. Check out RFC 6455 et al. This does not make using HTTP a smart choice in my book. If one wants to use a web browser and/or smartphone as a client to access mail, there are various good solutions available. To name just two examples: RoundcubeMail just released version 1.4 with "responsive" UI, and there is SOGo with its AJAX-based UI. To me, rewriting all the functionality in JavaScript, especially when aiming to avoid the protocol specifically designed to access mail storage backends, is just not an idea worth pursuing. > The above line is from you. Should I repeat it? "Frankly, my dear, I don't give a damn." (R. Butler, 1939) :-) -Ralph
Re: http API for IMAP
* Thomas Güttler via dovecot: > Stateless, http and URLs are the future. A bold claim, and not worth anything without proof, which is impossible to provide because you cannot predict the future. > JavaScript running on in browser or mobile phone can't connect to > IMAP/SMTP. That's simply not true. There are JavaScript libraries like SmtpJS, a low-level TCP/UDP socket API, and more. Please do your research before stating obvious falsehoods. -Ralph
Re: File manager or browser for IMAP?
* Steve Litt via dovecot: > Anyone know of such a file manager or browser for IMAP? If by "file" you mean "mail": Every IMAP capable MUA. -Ralph
Re: mdbox to Maildir
* Odhiambo Washington via dovecot: > Is it possible? How do I do it for ALL mailboxes? This has been asked (and answered) recently; see the Dovecot Wiki. -Ralph
Re: sieve setup. no svbin ?
* Voytek Eymont via dovecot: > or where is the extra 'c' from ? > "Unknown column 'mailbox.enablesievec'" sievec is just Pigeonhole's Sieve script compiler. Try "man sievec" in a shell. I suggested you use it because sievec would report possible errors in your sieve scripts. I use script files without any SQL database involved; perhaps somebody else can help you troubleshoot that aspect. -Ralph
Mailman option "Set Reply-To header to list" unavailable
Looking at https://dovecot.org/mailman/options/dovecot I see that the option "Set Reply-To header to list?" does not accept any changes from me. I assume this might be related to DMARC related header mangling that was discussed at length before. While I do not want to open that particular can of worms again, I would like to force Reply-To: dovecot@dovecot.org for my own (!) postings to this mailing list. I actually set this header in my MUA when I post to the Dovecot ML, but it gets overwritten to include my own sender address in Reply-To, which is not what I want. Is there something I can do on my end to ensure that replies get sent to the list only? If not, Is this something the list owners can set for me? Thanks, Ralph
Re: macOS Notes.app IMAP Syncing Not Working
* Steven Smith via dovecot:
> I’m pretty sure it arises from some subtle dovecot configuration
> setting.
Based on your statement that Dovecot does not log connection attempts by
Notes.app, I am not sure this assumption is correct.
> Would you mind posting your `doveconf -n` so that we can compare to
> the non-working and working examples above?
See attachment (I have only obfuscated directories and deleted some
settings related to authentication).
-Ralph
# 2.3.5.2 (38c8f1daf): /path/to/dovecot.conf
# Pigeonhole version 0.5.5 (2483b085)
# OS: Linux 5.1.5-gentoo x86_64 Gentoo Base System release 2.6
auth_mechanisms = plain login
auth_username_format = %Ln
lmtp_save_to_detail_mailbox = yes
mail_location = /path/to/maildir
mail_plugins = notify
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 vnd.dovecot.debug imapsieve vnd.dovecot.imapsieve
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
auto = create
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
auto = create
special_use = \Trash
}
prefix =
separator = /
}
passdb {
args = /path/to/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
imapsieve_mailbox1_before = file:/path/to/report-spam.sieve
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_name = Junk
imapsieve_mailbox2_before = file:/path/to/report-ham.sieve
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_name = *
sieve = /path/to/sieve/%u.sieve
sieve_extensions = +vnd.dovecot.debug
sieve_global = /path/to/sieve/global
sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
sieve_pipe_bin_dir = /path/to/sievepipe
sieve_plugins = sieve_imapsieve sieve_extprograms
}
protocols = imap lmtp
service auth {
unix_listener /path/to/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
}
service dict {
unix_listener dict {
mode = 0666
}
}
service lmtp {
unix_listener /path/to/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
}
userdb {
args = /path/to/dovecot-ldap.conf.ext
driver = ldap
}
protocol lmtp {
mail_plugins = notify sieve
namespace inbox {
location =
mailbox Trash {
autoexpunge = 1 weeks
}
prefix =
}
}
protocol lda {
mail_plugins = notify sieve
}
protocol imap {
mail_plugins = notify imap_sieve
namespace inbox {
location =
mailbox Trash {
autoexpunge = 1 weeks
}
prefix =
}
}
Re: sieve setup. no svbin ?
* Voytek Eymont via dovecot:
> what am I missing, how to check ?
Try runing "sievec -u {your_linux_user} /path/to/whatever.sieve" from a
shell and check the resulting error messages.
> postmaster_address = root
Any fully qualified address (postmas...@yourdomain.com seems like a
logical choice).
-Ralph
Re: macOS Notes.app IMAP Syncing Not Working
* Steven Smith via dovecot: > The issue is that macOS Note.app does not sync with this server. I'm syncing macOS Mojave's Notes.app with Dovecot without problems, so it can be done. Have you made sure that you activated both mail and notes in macOS' Internet Accounts preferences for this particular IMAP account? If so, is that IMAP account listed in the navigation bar of Notes.app (mine shows iCloud and the IMAP account)? -Ralph
Re: Convert Maildir to Dbox?
* David Mehler: > Are there any performance or stability advantages Sdbox over Maildir? Have you read the documentation at all? -Ralph
Re: Convert Maildir to Dbox?
* David Mehler via dovecot: > Any help appreciated. https://wiki.dovecot.org/Migration/MailFormat -Ralph
Re: Sieve matching "size" with user variable?
* Ed W. via dovecot: > How would you generate scripts for some few thousand users? How would > you maintain those thousands of scripts when you make changes to the > template? A dozen or a few thousand, it makes no difference in terms of the mechanics involved. Templates and generator scripts should be version controlled. All part of decent software configuration management. > Now it's a per person script, but I want the user to have a web front > end so they can say if they want (some mangling) to happen to mails > over a certain size? How to read that size in the filter file and act > on it? Are you seriously asking how to use parameters/placeholders when generating text files? -Ralph
Re: Maildirs on AWS EFS
* Rodolfo Gonzalez via dovecot: > I just have a doubt in the technical side: is it safe to have the > email in EFS? "Safe" as in "storing and retreiving will work"? Probably. I would not do it for privacy reasons, unless all data was encrypted on a machine before storing it in any service operated by Amazon, Google, Microsoft, etc. -Ralph
Re: imap ---- LIST "" * The returned mailbox does not display quotes
* lty via dovecot:
> foxmail will not have next step after sending {LIST "" *} command
> action.
Can you please stop this now? If Foxmail is broken, Foxmail needs to be
fixed, not some kludges added to well-behaving Dovecot.
-Ralph
Re: Sieve matching "size" with user variable?
* Ed W. via dovecot: > My goal is that users can set a user configurable setting (in an > external front end) and if the email size is greater than this size > then we will do some processing on it. This particular filter is > actually in a global sieve filter. A global script using per-user parameters? Not what I would choose. I like to generate sieve scripts for individual users (taking their wishes into account of course), because it gives me the ability to perform some sanity checks. -Ralph
Re: Troubles with Dovecot 2.3.3 - mkdir permission denied due to +w perm: /var, dir owned by 0:0 mode=0755)
* Kunal A. via dovecot: > Error: mkdir(/var/vmail/ema...@example.com/Maildir) failed: Permission > denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /var, dir owned > by 0:0 mode=0755) The error message seems pretty clear. User 'vmail' does not have write permissions for /var, which is owned by 'root'. I suggest you create /var/vmail and grant the necessary permissions there. -Ralph
Re: offtopic: rant about thoughtless enabling DMARC checks
* Juri Haberland via dovecot: > Blindly enabling DMARC checks without thinking about the consequences > for themselves should not be the problem of other well behaving > participants. Can you judge if DMARC is enabled "blindly"? No, I thought not. Also, the issue was not on the receiving end, but the reject policy for the originating domain. Personally, I choose to treat "reject" as if it was "quarantine", i.e. affected mail is rerouted to a specific folder. > And Aki, please go back to "munge only if needed" - munging all > messages leads to a really bad "user experience". Only speak for yourself please. -Ralph
Re: doveadm move and create folders for the archive
* Michael Wagner: > Can't open mailbox 'Archiv/debian-user/2018': Mailbox doesn't exist: > Archiv/debian-user/2018 As the manpage for doveadm copy/move states: "The destination mailbox must exist, otherwise this command will fail." -Ralph
Re: BUG: sieve does not set seen-Flag
* Jakobus Schürz: > is anybody else here??? Are my informations to much? Am I alone with > this fucking shit? Are my informations to less??? Why do I have the > feeling, nobody else is interesting in this problem? Members of this mailing list, including the Dovecot authors, are not required care about your problems, let alone offer any assistance whatsoever. Please leave all your entitlement issues at the door. -Ralph
Re: BUG: sieve does not set seen-Flag
* Jakobus Schürz: > Does it matter, if the keyword-files do not match? Possibly. The keyword files define flag<->letter mappings. You have shown two files with mappings (let's call them A and B) with A being a subset of B. If a file is moved from A to B, all is fine. What happens if a file is moved from B to A is for Aki to know. ;-) > 0 $label3 > 1 NonJunk > 2 Junk > 3 redirected > 4 $label2 > 5 $label4 > 6 Seen This does not look right to me. AFAIK, "Seen" should not appear in this list, because it is one of the predefined flags, but that is also a subject I'd like to hear the Dovecot authors talk about. -Ralph P.S.: Unrelated: Please do not top-post, and definitely do not quote the complete message history every time you reply. Thanks.
Re: BUG: sieve does not set seen-Flag
* Jakobus Schürz: > 1543935543.M447415P13997.mymail,S=726,W=748:2,Sa > > Then i move this email to another IMAP-Folder, and then there is the > filename > > 1543935543.M447415P13997.mymail,S=726,W=748:2, > > As expected, the seen-flag disappeared... the same as thunderbird > shows. And what about the "dovecot-keywords" files in both folders? Do they match? The letter "a" seems to indicates that there is at least one non-standard flag defined in the source folder's keywords. By the way, can I assume you move messages only by using Thunderbird/IMAP and not by manipulating the file system? Here's how things look on my server: # On arrival (UNSEEN) 1543968031.M941319P5841.foo,S=1390,W=1422:2, # After reading (SEEN) 1543968031.M941319P5841.foo,S=1390,W=1422:2,S # After being moved to another folder (SEEN) 1543968031.M941319P5841.foo,S=1390,W=1422:2,S I can use IMAP search terms SEEN and UNSEEN as indicated above, and I see the same message state displayed in Notmuch mail (my default, it accesses Dovecot's Maildir storage directly) and various IMAP clients connecting to Dovecot. Things are working just fine here. -Ralph
Re: BUG: sieve does not set seen-Flag
* Jakobus Schürz:
> The \Recent flag ist set and the \Seen-Flag is removed in the new
> folder. So it is not a problem of thunderbird.
Did you mention your data storage format yet? If you use Maildir, Flags
are stored as part of the physical file name. For example, the name
"1539996635.M698476P4944.foo,S=45171,W=45803:2,RS" indicates that the
message was seen ('S') and has been replied to ('R'). Check if the file
names match what you see in your MUA.
Files named "dovecot-keywords" are used to map additional letters to
flags (used to store Thunderbird's "$label1" etc.). If the keywords file
get messed up, it can cause confusion, and because there can be keywords
files with varying content per folder, letters in file names can have
different meanings in different directories. Moving files around can be
therefore be tricky.
Also, I wonder if the delivery mechanism might matter. I use Dovecot's
LMTP.
-Ralph
Re: set seen flag and junk moving a mail manually to JUNK
* Jakobus Schürz:
> addflag "Junk";
> setflag "\\seen";
That's probably not what you want, because the 'setflag' command
replaces all existing flags. In any case, I recommend you use this
method instead:
plugin {
sieve_pipe_bin_dir = /etc/dovecot/sievepipe
# Message moved into Spam folder
imapsieve_mailbox1_name = Junk
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_before = file:/etc/dovecot/sievepipe/report-spam
# Message moved out of Spam folder
imapsieve_mailbox2_name = *
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_before = file:/etc/dovecot/sievepipe/report-ham
}
This was typed from memory, so I hope the syntax is correct.
-Ralph
Re: Mailing list address harvested for spamming
* Ruben Safir: > On Sun, Dec 02, 2018 at 03:58:53AM +0100, Bernd Petrovitsch wrote: > >> Let's hope that people who do not know how to use a tool - e.g. >> like a hammer - doesn't use that tool in the first place > > that is pretty unrealistic and I don't agree with it anyway. The tool metaphor is realistic. In my experience (which dates back to the 1980s), email ist a powerful tool, and people need to learn how to use it properly, with the appropriate software set. Especially in the area of technical mailing lists I see no reason to cater to dumb MUA software. > Email should be intitive If by "intuitive" you mean "used without engaging one's brain", I have to disagree. Using a hammer without thinking can mean flattened thumbs, and moaning about it is inappropriate. -Ralph
Re: Mailing list address harvested for spamming
* Michael A. Peters: > I would wager that over 95% of the time when someone hits the reply > button on a list post, their intent is to reply to the list. You'd lose that wager. This list, like many others, has a "List-Post" header embedded in every single message posted. People need to use smart MUAs (or the proper key combination) to reply to the list. As part of my job, I process literally hundreds of mailing list messages on a nearly daily basis, and never found it taxing or confusing. Existing conventions make it easier for me to handle this load, and I have zero patience for people who refuse to use the right tools for the job. -Ralph
Re: Mailing list address harvested for spamming
* Michael A. Peters: > Netiquette posts are just someone's opinion, and they often don't take > into account the vastly different way different types of minds work. Mailing list netiquette has been around for decades, for good reasons. If Joe User's mind "works differently", Joe needs to make the effort to adapt to existing conventions instead of expecting conventions (and thereby other people) to change. -Ralph
Re: Testing validity of Dovecot config in a script
* Aki Tuomi: > doveconf will reliably fail if config file cannot be parsed. Thanks, that's what I was hoping for. -Ralph
Testing validity of Dovecot config in a script
While trying to determine a given configuration is valid from within a script, I found that the following works with Dovecot version 2.3.2.1: #!/usr/bin/env bash doveconf -n >/dev/null || echo "Config is invalid" However, the return code is not documented in the doveconf manual page, and I wonder if the observed behaviour can be relied on? Is this the recommended method to test configuration validity? Personally, I'd like to have a dedicated call available. Something like # Proposal: "-t" for "test config" doveconf -t [-c config-file] with documented return codes would be ideal. -Ralph
Re: imap authentication - shadow vs mysql
* Konra Wawryn: > I`m searching for some solution which will help me to scale my system > in the future. You provided very little information about your requirements, and "to scale" is just as vague a term. Hence, I recommend an LDAP server, because it works in many scenarios, can accommodate thousands of users, and is basically the default solution for this type of write-seldom- read-often type of user data storage. As for MySQL, I would personally not use it for authentication unless I had no other option. -Ralph
Re: Disable logging for localhost
On 21.10.18 16:23, André Rodier wrote: > How can I disable logging these actions from 127.0.0.1? What you posted looks like syslog output. Add a filter to your syslog configuration to drop or redirect these messages. This is not a Dovecot issue per se. -Ralph
Re: [sieve] Restrict redirects to own domain only
On 16.10.2018 15:43, Yassine Chaouche wrote: > I don't fully understand how could this prevent them from forwarding > to any other domain by other means, for example by using a managesieve- > able client Well, your OP made no mention of your environment. ;-) You posted on the Dovecot mailing list, so I suppose we know what your IMAP server is, but you mentioned nothing beyond that. I made the assumption that your users are allowed to use sieve, based on the subject line, but you did not elaborate on how they use it. Simplest form: Sieve files. If you generate the files, you can screen the content and also keep them read-only for users. If you have important restrictions/conditions, you need to mention them to us. -Ralph
Re: [sieve] Restrict redirects to own domain only
On 16.10.18 12:48, Yassine Chaouche wrote: > I'd like to let my colleagues redirect mail automatically (via a sieve > filter) to other mailboxes within the same domain, but deny redirects > to outside domains [...] Ideas ? Set up a simple internal web application or some other mechanism that allows your colleagues to enter the local address part for forwarding only. Use backend logic to generate a sieve script containing redirect :copy "localp...@yourdomain.tld"; or whatever suits your needs. -Ralph
Re: Struggling to get dovecot working with postfix auth
On 11.10.18 14:02, Laura Smith wrote:
> To me, it seems dovecot is not behaving correctly, because if it is
> not using root to access the directory then it is not going to be able
> to chmod the socket later is it ?
I use the following on several Dovecot-plus-Postfix servers, and they
all work fine:
# /etc/dovecot/conf.d/10-master.conf
unix_listener /var/spool/postfix/private/dovecot-auth {
user = postfix
group = postfix
mode = 0660
}
# /etc/postfix/master.cf
# Remove line breaks on the value-side, I only added them for readability!
submission inet n - n - - smtpd
-o relay_clientcerts=${indexed}relay_clientcerts
-o smtpd_sender_login_maps=${indexed}submission_login_maps
-o smtpd_client_restrictions=permit_mynetworks,permit_tls_clientcerts,
permit_sasl_authenticated,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=permit_mynetworks,permit_tls_clientcerts,
permit_sasl_authenticated,reject
-o smtpd_recipient_restrictions=permit_mynetworks,permit_tls_clientcerts,
reject_sender_login_mismatch,
permit_sasl_authenticated,reject
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_path=private/dovecot-auth
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_security_options=noanonymous
-o smtpd_tls_security_level=may
-o syslog_name=postfix/submission
[...]
Note that this configuration only allows authentication via port 587
(submission), not port 25 (smtp). By convention, that's how it should
be. Also, I allow authentication using either SASL or client-side SSL
certificates, so you could remove all *cert* settings. If you don't use
sender login maps, remove those settings as well.
-Ralph
Re: Struggling to get dovecot working with postfix auth
On 11.10.18 13:21, Laura Smith wrote: > > I suggest using "mode = 0660" instead. > > Makes no difference. That was meant to increase security, not to fix your problem. > > What exactly do the logs show? > > Erm, they show exactly what I posted earlier ? No. Earlier, you posted this: > 2018-10-11T10:17:40.491483+01:00 X postfix-authrelay/smtpd[18312]: > warning: X[X]: SASL PLAIN authentication failed: That's just a warning about an authentication failure. Now this: > 2018-10-11T12:14:15.467791+01:00 X dovecot: master: Error: > bind(/var/spool/postfix-authrelay/private/dovecot-auth) failed: > Permission denied > 2018-10-11T12:14:15.468094+01:00 X dovecot: master: Error: > service(auth): > net_listen_unix(/var/spool/postfix-authrelay/private/dovecot-auth) > failed: Permission denied > 2018-10-11T12:14:15.468216+01:00 X dovecot: master: Fatal: Failed to > start listeners That's a permission error. Somewhere in your directory hierarchy things are off. See Postfix' set-permissions command. -Ralph
Re: Struggling to get dovecot working with postfix auth
On 11.10.18 11:30, Laura Smith wrote:
> unix_listener /var/spool/postfix-authrelay/private/dovecot-auth {
> group = postfix
> mode = 0666
> user = postfix
> }
I suggest using "mode = 0660" instead.
> Dovecot is unable to create the socket ?
What exactly do the logs show?
> postconf -c /etc/postfix-authrelay | fgrep sasl
As described in http://www.postfix.org/DEBUG_README.html please use
"postconf -n".
-Ralph
Re: DMARC mailing list rejections
On 16.01.2018 06:23, Daniel Miller wrote: > I get about a half dozen rejection messages from various servers when > I post to this list. See https://dmarcian.com/dmarc-inspector/amfes.com -- no surprise there, given the 'reject' policy. -Ralph
Re: Dovecot and Letsencrypt certs
On 08.09.2017 19:51, @lbutlr wrote: > How I would do it is IF the certificate is expired, the dovecot should > check if there is a new cert and if so, load it. New cert as in file modification date or checksum changed? Might work. Still, from what I seem to remember, Dovecot loads certificate data before dropping privileges, which is why reloading the data might be problematic without some changes. Not worth spending development effort on, IMO, given that Dovecot can easily be restarted by the external processes that update the cert (like Certbot hook, Ansible, etc.). -Ralph
Re: Dovecot and Letsencrypt certs
On 08.09.2017 16:20, LuKreme wrote: > That is a great solution, but I think it’s probably easier to just > kick dovecot once a month. Certbot hooks are very easy to write, and are only executed when the certificate is updated. In that light, I can see no advantage in "kick dovecot once a month". ;-) > However, it seems like checking the certs is something that dovecot > should be doing on its own. What is Dovecot supposed to do? Keep track of the certificate expiry date? And if that is passed, then what? Automatically shutdown/restart? What if the certificate has not been updated in between? I think that handling certificates is better left to the administrator. -Ralph
Re: disable imap for ldap user
On 08.09.2017 17:11, Markus Rosjat wrote: > I have a LDAP dir with an attribute set to 0 or 1 and in my old setup > (a courier server) I used this attribute to map it to an authoption > called disableimap. This prevent users to access the mailbox with imap > protocol. > > So the question is what should I set in dovecot to get the same > behaviour? You can configure 'pass_filter' to discount entries with your disable- flag. Affected users won't be able to authenticate with Dovecot, which I assume is what you are trying to achieve. -Ralph
Re: Sync mailservera!
On 01.09.17 17:04, nlek...@gmail.com wrote: > I have two servers using dovecot and want to sync them with doveasm .. > I am using usersb as user backend database > > Can anyone help me config them... Is there any use guide about it ? http://lmgtfy.com/?q=dovecot+sync -Ralph
Re: LMTP and Postfix
On 22.08.2017 12:10, Jerry wrote:
> I saw nothing about the Postfix master.cf file. Do I need to make
> and changes to it also?
No need. Assuming that you use a socket, the following combination
should suffice:
# Dovecot
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
user = postfix
group = postfix
mode = 0660
}
}
# Postfix
mailbox_transport = lmtp:unix:private/dovecot-lmtp
If you have further questions or a more exotic setup, you might want to
consider asking on the Postfix mailing list.
-Ralph
Re: is a self signed certificate always invalid the first time
On 20.08.2017 19:50, KT Walrus wrote: > I use Cloudflare (free DNS) and DNS Made Easy (paid DNS). I would never > run my own DNS service except for communicating between my Docker > services internally I run my own nameservers for various reasons, not the least of them being DNSSEC. My zones' signing keys never leave my hands. > If you run your own public DNS service (for your Dovecot domains), you > should pick one that has an API for updating the DNS records from a > script like acme.sh or simply write your own custom hook for acme.sh > to use. Nameservers like BIND or Unbound can use text based config files (zone files), which can be generated on the fly with scripts. Add "rndc reload" to the mix, and changes can be made instantaneously, without any special APIs. What can be a bother is when TTL values are set too high and changes in the zones take too long to propagate, but that's a general issue, and when running your own nameservers you can set these values as low as you require. -Ralph P.S.: All this sure is interesting, but way off-topic in regards to Dovecot. ;-)
Re: is a self signed certificate always invalid the first time?
On 18.08.2017 09:12, voy...@sbt.net.au wrote: > for a public web server where https is becoming mandatory, I'd still > need a certificate from a recognized publisher, to avoid users geting > 'warnings', is that so ? For a certificate to be reported as "valid", an unbroken chain of cryptographic signatures is required. Browsers are released with a set of Root CA and Intermediate CA certificates, as are operating systems. Some use the Mozilla CA Certificate Store[1], for example, others come with their own CA stores, like macOS[2]. [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ [2] https://support.apple.com/en-us/HT202858 Unless your web server certificate's signature chain originates from one of the CAs delivered with a web browser or OS, the end user connecting to your site will either have to manually add the required CAs, or add your server certificate, or be presented with a warning/error message. One could argue that relying on certificate stores is placing personal security concerns in other people's hands. Of course, it would be a potentially funny thing to try and verify the validity of your online banking server's certificate by asking them to send you a letter containing the certificate fingerprint... -Ralph
Re: is a self signed certificate always invalid the first time?
On 18.08.2017 08:58, Michael Felt wrote: > as Ralph mentions in his reply - Let's encrypt certs are only for > three months - never ending circus. I don't consider the 90-day-lifespan a "circus". It is meant as a security feature[1], and Let's Encrypt suggests using automation for certificate renewal. Also, with ACME v2 on the horizon[2], I imagine that more automation tools will become available. [1] https://letsencrypt.org/2015/11/09/why-90-days.html [2] https://letsencrypt.org/2017/06/14/acme-v2-api.html Let's not forget that Let's Encrypt is still a young service, and that it is free. -Ralph
Re: is a self signed certificate always invalid the first time?
On 11.08.2017 11:36, Michael Felt wrote: > This is what Ralph means when he says "have been running a CA for > 15+ years" - not that he is (though he could!) sell certificates > commercially - rather, he is using an initial certificate to sign > later certificates with. Actually, I do sell certificates to my customers. :-) In small numbers, and only for servers to which I have administrative access. I created a root CA and two intermediate CAs (one each for client and server certs, respectively). It would be great to have my CAs added to Mozilla's NSS root certificate store, but alas, the effort to get there is massive. Where possible, I will add my CA certs to the customers' keystores. I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually. > Again, technically, there is no difference in a self-signed 2048-bit RSA > key, and one signed by a "major" CA. However, in the "ease of use" there > may be major differences. In 2015 I rolled out an updated CA which I have used ever since, with 4096 bit keys for root and intermediary CA certs. I also only generate 4096 bit keys for servers these days, so my cert chain is "stronger" than those of some commercial CAs. Also, it is good to know that these certs have never been touched by anybody but myself. I even install my own CA cert chain on my iOS devices. > And, Ralph, I salute you. I have never been able to be disciplined > enough to be my own CA. I encourage you to look into the subject again. With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) -Ralph
Re: Certificate cache on iOS with sending mail
On 10.08.2017 14:57, Alef Veld wrote: > I generated a new certificate for dovecot, and ever since I have this > weird problem that my iPhone can still receive mail but cannot send > using that mailserver. Same for my iMac. Mail is not sent through Dovecot, but through an MTA. Based on your earlier messages I assume that's Postfix, and you should ask on the Postfix mailing list. See http://www.postfix.org/DEBUG_README.html if you want to receive an answer, folks on that ML tend to reply RTFM otherwise. > I'm wondering if there is any cache for a certificate or something Apple Mail uses certificates from the macOS keychain. If you accept a certificate, it will be stored there. -Ralph
Re: is a self signed certificate always invalid the first time?
On 10.08.2017 09:18, Stephan von Krawczynski wrote: > It would be far better to use a self-signed certificate that can be > checked through some instance/host set inside your domain. I have been running a CA for 15+ years, generating certificates only for servers I personally maintain. Since my business is too small to be able to afford all the steps required to have my CA trusted by Mozilla, Apple etc., this approach leaves me with the same problem self-signed certs have: How can I make third party applications like web browsers or MUAs trust the certs I created? For some of my customers, I can add my CA certs (root and intermediary) to their keystores, so the end user does not see a thing. For other customers, I can hand over cert fingerprints so end users can manually accept the connections after checking the fingerprint (guess how many users actually do that). Naturally, this does not work for publicly available services, where there is currently no alternative to using well-known CAs. Of course their certs are not technically better than my own CA's or than self- signed certs, and their processes are sometimes garbage, the fuckups of Symantec being case in point. Symantec even just sold off their whole CA business to DigiCert; it seems they never really recovered from generating fake google.com certificates two years ago: https://security.googleblog.com/2015/09/improved-digital-certificate-security.html To get back on topic: if the OP can live with self-signed certs, that's perfectly fine. If Alef needs people to be able to connect to his Dovecot server without verifying/confirming the certificate, a CA like Let's Encrypt is a better choice. As far as Postfix is concerned, there is hardly any reason to use a well-known CA, because opportunistic TLS for SMTP does not care about trust chains. -Ralph
Re: is a self signed certificate always invalid the first time?
On 09.08.2017 18:18, Alef Veld wrote: > Anyone know of any manual, or can I just replace the certs in the > dovecot and postfix locations with theirs? Do dovecot, postfix and > apache all support .pem format? Google "dovecot letsencrypt" is your friend. ;-) If you have questions about details, we can discuss them of course. Also, please limit your replies to my messages to the mailing list; you keep triggering my spam protection. -Ralph
Re: is a self signed certificate always invalid the first time?
On 09.08.2017 17:49, Alef Veld wrote: > I think let’s encrypt uses certbot though and it can’t do email > certificates (although i’m sure i can convert the cert i get from > let’s encrypt, i’ll look into it. I'm not sure what you mean by "can’t do email certificates"? In any case, Let's Encrypt issues certificates that can be used by Dovecot for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix for SMTP. The certificates are issued for servers, not for specific software or protocols. -Ralph
Re: is a self signed certificate always invalid the first time?
On 09.08.2017 17:20, Alef Veld wrote: > So i’m using dovecot, and i created a self signed certificate with > mkcert.sh based on dovecot-openssl.cnf. The name in there matches my > mail server. > > The first time it connects in mac mail however, it says the certificate > is invalid and another server might pretend to be me etc. This is to be expected for self-signed certificates. The MUA (Apple Mail in your case) cannot know that the certificate is trusted until you confirm it. For certificates signed by third parties, the client (or OS) performs the same checks. If a chain of trust can be established based on the client/OS certificate store, which comes pre-populated with well-known third party CA certificates, allowing to verify certificate signatures, your MUA will trust the presented certificate without you confirming it. I recommend you look into using a free Let's Encrypt certificate (see https://letsencrypt.org/) instead of a self-signed certificate. -Ralph
Re: Replacement for antispam plugin
On 12.02.17 19:05, George Kontostanos wrote: > Actually I think that sa-learn is invoked as user vmail. But of course > I might be wrong. It might depend on system configuration. On my servers, Sieve scripts are definitely executed as the OS user that matches the current IMAP user. > Do you have any suggestions as per the way sa-learn should be executed? Instead of calling sa-learn directly, I use a script to store the piped raw message in the file system, using separate directories for ham and spam. This way, there are no delays. A periodic Cron job, running as my global SpamAssassin user, later collects the files and invokes sa-learn, ensuring that sync operations only happen once per run. -Ralph
Re: Replacement for antispam plugin
On 12.02.2017 17:36, George Kontostanos wrote: > it automatically creates a .spamassassin/ folder in the user That happens because sa-learn is invoked as the user who is logged into IMAP. If you want all users to contribute to a global SpamAssassin database (like I do), you'll need to create your own learning mechanism instead of calling sa-learn directly. -Ralph
Re: Replacement for antispam plugin
On 12.02.2017 13:25, Stephan Bosch wrote: > The "imap.mailbox" environment is the empty string in this case. Why? > Well, the Sieve interpreter does not know about it, since the > "imapsieve" extension is not activated in the require line. Now there's a facepalm moment. ;-) Thank you, with a modified 'require' statement things are working for me. I see that https://wiki.dovecot.org/HowTo/AntispamWithSieve has already been updated, that's nice. > You could debug this with the non-standard "vnd.dovecot.debug" > extension. Thanks again, I will keep this in mind for future debugging. -Ralph
Re: Replacement for antispam plugin
On 10.02.17 20:34, Michael Slusarz wrote:
> When you move a message to a new mailbox, that is a "new message"
> event (a new UID in the target mailbox is created; the message count
> increases). So imap.mailbox is set to the name of the *target* mailbox.
My tests seem to indicate otherwise. Deleting a message currently
located in the Junk folder causes the report-ham.sieve script to be
invoked, which in my case contains the following:
require ["vnd.dovecot.pipe", "copy", "environment"];
if environment "imap.mailbox" "Trash" {
stop;
} elsif environment "imap.mailbox" "Junk" {
pipe :copy "debug-junk";
} else {
pipe :copy "learn-ham";
}
I can see that "learn-ham" is always invoked when a message is deleted
from or moved out of the Junk folder, so my guess is that imap.mailbox
is neither "Trash" nor "Junk" ("debug-junk" is never called, according
to the Dovecot logs). Unfortunately I don't know how to debug this
further.
I don't want "learn-ham" to be run when a message located in the Junk
folder is manually deleted or moved to Trash, and right now I don't know
how to accomplish this.
-Ralph
Re: Replacement for antispam plugin
On 10.02.17 18:34, Michael Slusarz wrote:
> > Can we add an exception for the Trash folder?
>
> This is handled in the sieve script. E.g.:
>
> require "environment";
> if environment "imap.mailbox" "Trash" {
> stop;
> }
This does not work for me, and I don't really expect it to work either.
https://tools.ietf.org/html/rfc6785#section-4.4 states:
The implementation MUST set the Environment [RFC5183] item "imap.mailbox"
to the name of the mailbox that the affected message is in, in the
case of existing messages, or is targeted to be stored into, in the
case of new messages.
The message already exists in the Spam folder, hence imap.mailbox should
be "Spam" instead of "Trash", correct?
Is there perhaps another way to ensure that manually deleted spam is not
erroneously learned as ham?
-Ralph
Re: Replacement for antispam plugin
On 10.02.17 18:22, Zhang Huangbin wrote: > My concern is, will you experience any lag while moving message? I don't use direct calls to sa-learn, but store the piped e-mails on disk, and a periodic cron-job picks them up and invokes sa-learn. This way, there is no noticeable lag. -Ralph
Re: Replacement for antispam plugin
On 10.02.2017 16:09, Darac Marjal wrote: > Check out https://wiki.dovecot.org/Pigeonhole/Sieve/Plugins/IMAPSieve, > which explains that sieve is normally only used at delivery time, but > the sieve_imapsieve plugin runs a *different* sieve script based on > IMAP actions (for example, COPY). Thanks for the pointer, Darac. The following confirms that imapsieve_* is not involved during delivery: "Note that the imapsieve extension can only be used in a Sieve script that is invoked from IMAP. When it is used in the active delivery script, it will cause runtime errors." -Ralph
Re: Replacement for antispam plugin
On 10.02.2017 09:06, Aki Tuomi wrote:
> Since antispam plugin is deprecated and we would really prefer people
> not to use it, we wrote instructions on how to replace it with IMAPSieve.
In my setup, I use the following sieve script globally for all users:
if header :is "X-Spam-Flag" "YES" {
fileinto "Junk";
stop;
}
This allows processing based on spam flags set by Amavis/SpamAssassin.
I wonder if the method shown in
https://wiki.dovecot.org/HowTo/AntispamWithSieve
will cause incoming mail (via LMTP) that is already flagged as spam to
be processed by report-spam.sieve and, in consequence, will be learned
as spam for a second time, which would of course be undesirable?
-Ralph
Re: Mail marked read upon download
On 01.12.2016 21:40, Curtis Vaughan wrote: > Just set up a new server with postfix and dovecot. I don't know why, > but as soon as mail is accessed it is marked read. I'll see emails > momentarily marked unread, but then switch to read later although I > haven't opened them. Accessed how? It is usually the MUA that's signalling the IMAP server to mark messages as read, so I suggest you look there first. Postfix (the MTA) has nothing to do with this. -Ralph
Re: Good email client to use with Dovecot?
On 17.11.2016 08:48, Steve Litt wrote: > What email clients are all of you using to look at your IMAP email? I prefer Mozilla Thunderbird. It runs on Linux, macOS and Windows; works nicely with all sorts of IMAP servers; handles mailing lists well; and the multiple-identity-support (more than one sender address per IMAP account) is very important for me as well. -Ralph
Re: a question about certificates from letsencrypt
On 19.08.2016 14:12, Aki Tuomi wrote: > Depends how your MUA validates the certificate. > > If it just checks CA, then no. Also I don't think the private key > changes, so it should not cause recheck either. Other checks, maybe. Last time I checked, the LetsEncrypt client generated a fresh key pair whenever the user requested a certificate to be renewed, unless the user explicitly opted to use the existing keys (which required some extra configuration). That should not matter much for Dovecot or other IMAP servers, but it is very important for Mail Exchangers when using DANE. -Ralph
Suggested improvement for antispam plugin documentation
Hello,
I struggled a bit with getting the antispam plugin to work, because the
plugin configuration in http://wiki2.dovecot.org/Plugins/Antispam is
incomplete. After some twiddling, I ended up with this:
# /etc/dovecot/conf.d/90-plugin.conf
plugin {
antispam_backend = mailtrain
antispam_mail_spam = spam
antispam_mail_notspam = ham
antispam_mail_sendmail = /path/to/mailtrain/script
antispam_spam = Junk;Spam
antispam_trash = Deleted Messages;Trash
}
I know that the antispam plugin has not yet been officially released,
but I think it might be worth updating the documentation anyway. Your
thoughts?
-Ralph
Re: [Dovecot] Iphone IMAP access
On 26.01.11 15:03, Robert Schetterer wrote: apple has a long tradition of imap bugs, dont by it , dont use it, dont recommend for imap use Sigh... iOS 4.1 works fine with Dovecot (IMAP w/ SSL, use path prefix /). -Ralph
Re: [Dovecot] When should dictionary entries for the expire plugin be added/updated?
On 25.08.10 18:52, Timo Sirainen wrote: So you want to drop the domain? I'm not sure if you can do this on Postfix's side [...] I don't think so, based on the e-mails I received. It has been rightly pointed that LMTP requires fully qualified e-mail addresses. Now I try to find a LDAP-only setup for passdb and userdb. I have experimented with both user_filter = ((objectClass=posixAccount)(uid=%n)) and/or pass_filter = ((objectClass=posixAccount)(uid=%n)) but this only works as long as I enable auth_username_format = %Ln aswell. I was hoping that using %n instead of the default %u would help, but alas, no. It is frustrating that this how-to-drop-the-domain business is only an issue with LMTP. When I use dovecot-lda, auth_username_format is not required. -Ralph
Re: [Dovecot] When should dictionary entries for the expire plugin be added/updated?
On 28.08.10 17:55, Charles Marcus wrote: So... why not just use LDA? I you read the complete thread, you'll find that Timo suggested using LMTP instead of LDA to avoid the need for a world-writeable socket.
