Re: Debian Bookworm packages, please !
With all due respect, you're welcome to disagree with Laura's point, but she does have one. So, please take your ad hominem attacks elsewhere. Regards Simon On Wed, 26 Jun 2024, 21:55 Michael Tokarev via dovecot, wrote: > Can we please stop this thread here? > > Clearly, Laura does not seek solutions, the intention seems to be shouting > at people. > > As they say, don't feed the trolls, - don't give more caises fpr shouting. > Let this thread die in peace. > > Thanks, > > /mjt > > 26.06.2024 22:26, Laura Smith via dovecot wrote: > >> Why do you care about the repo then ? Use the patch locally, > >> publish it, etc. You care about OpenSSL 3.0 compatibility right ? What > >> do you care if it's in the public tree or not. > > > > > > Because Aki has been shouting from the rooftops here that "beware, its > not that easy, Dovecot crashes with OpenSSL 3.0". > > > > Aki has seen the OpenSSL 3 code already present in Debian (and Ubuntu > and Fedora, its the same code) and supposedly that causes crashes. > > > > I'm sure the people who submitted code to the Fedora tree are much > better programmers than I am, and if their efforts are not good enough, > then, well... > > > > So, if we rephrase it, Aki is effectively telling people not to waste > their time trying to patch OpenSSL 3.0 compatibility into 2.3 > > > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org > ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Uppercase username emails are rejected
On Wed, 17 Apr 2024 at 05:42, Peter via dovecot wrote: > > On 17/04/24 00:51, John Stoffel via dovecot wrote: > >> "Peter" == Peter via dovecot writes: > > > >> On 14/04/24 12:09, John Stoffel via dovecot wrote: > >>> I think you need to update both places, so that your username and > >>> password checks are done with lowercase usernames. > > > >> Generally speaking you want auth to be case-sensitive, but go ahead and > >> try it to see if it fixes the issue. > > > > Umm... not for emails you don't. Since the j...@stoffel.org and > > j...@stoffel.org and j...@stoffel.org are all the same email > > address... should they be different logins? Not for email... > > There is a difference between expecting $random_stranger to get the case > correct on an email address and expecting a user to get his own email > address correct for the purpose of logging in, also keeping in mind that > the user will generally get it entered *once* in their MUA and the MUA > will store it for future logins expecting the case to be correct is not > a huge ask in this scenario. > > Also keep in mind that the username is not always going to be the same > as the email address, in fact Dovecot is perfectly capable of having > usernames that are entirely different to the email address that is > associated with them. > > > In general, usernames should NOT be case sensitive, that way leads > > madness. Passwords on the other hand... > > Both usernames and passwords are part of the authentication credentials. > When you allow any authentication credential to be case-insensitive > then you decrease the difficulty of any brute-force attack by quite a > bit. There is no good reason to make usernames case-insensitive and > very good reasons not to. I cannot semantically argue with your wording, they are indeed both "part of the authentication credentials.",but usernames are IDENTIFICATION, not AUTHENTICATION. And in the same way you do not have a case sensitive name, you should not have a case sensitive username. (Society's convention is that your name is capitalised in Proper Noun format, from a information technology perspective, all lowercase is the same convention). Regards Simon ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Anyone Watching Actvity from this network? Attempting Dovecot Buffer Overflows?
On Wed, 15 Nov 2023, 23:25 Michael Peddemors, wrote: There is a network claiming to be a security company, however the activity appears to be a little more malicious, and appears to be attempting buffer overflows against POP-SSL services.. (and other attacks). https://www.abuseipdb.com/check/104.156.155.21 Just thought it would be worth mentioning, you might want to keep an eye out for traffic from this company... Might want to make up your own mind, or maybe someone has more information, but enough of a red flag, that thought it warranted posting on the list. Not sure yet if it is Dovecot, or the SSL libraries they are attempting to break, but using a variety of SSL/TLS methods and connections... They are not interested in dovecot per se. They scan for TLS vulnerabilities, mostly. Anyone with more information? NetRange: 104.156.155.0 - 104.156.155.255 CIDR: 104.156.155.0/24 NetName: ACDRESEARCH NetHandle: NET-104-156-155-0-1 Parent: NET104 (NET-104-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Academy of Internet Research Limited Liability Company (AIRLL) RegDate: 2022-01-07 Updated: 2022-01-07 Ref: https://rdap.arin.net/registry/ip/104.156.155.0 OrgName: Academy of Internet Research Limited Liability Company OrgId: AIRLL Address: #A1- 5436 Address: 1110 Nuuanu Ave City: Honolulu StateProv: HI PostalCode: 96817 Country: US RegDate: 2021-10-15 Updated: 2022-11-06 Ref: https://rdap.arin.net/registry/entity/AIRLL -- See also shadowserver.org, census.io, stretchoid, etc. All of them allegedly reputable, all of them supposedly with opt-out mechanisms, and all of them are blocked for not asking permission. Ymmv. Regards Simon ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Replication going away?
On Wed, 19 Jul 2023 at 20:40, Michael Slusarz via dovecot wrote: > > > On 07/18/2023 9:00 AM MDT Gerald Galster wrote: > > > > While I understand it takes effort to maintain the replication plugin, this > > is especially problematic for small active/active high-availability > > deployments. > > To clarify: replication absolutely does not provide "active/active". > Replication was meant to copy data to a standby server, but you can't have > concurrent mailbox access. This is why directors existed. > > > > I guess there are lots of servers that use replication for just 50 or 100 > > mailboxes. Cloudstorage (like S3) would be overkill for these. > > > > Do you provide dovecot pro subscriptions for such small deployments? > > A 50-100 mailbox user server will run Dovecot CE just fine. Pro would be > overkill. > > All current Dovecot development assumes that storage is decoupled from the > system. Shared (as in network available) storage is what you need if you > want high availability, whether in Pro or CE. That seems like an extraordinary callous and short-sighted decision, but nevertheless does give some technical weight to your earlier statement. Regards Simon ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Replication going away?
On Tue, 18 Jul 2023 at 06:47, Michael Slusarz via dovecot wrote: > > Hello all, > > I want to provide a brief overview regarding various questions surrounding > features that are being removed from Dovecot CE going forward. > > We are currently working on providing updated/improved website info and > documentation that will better explain exactly what is being maintained in > CE. However, the desire to have unified messaging clashes with the > Engineering Team's desire to continue to push code to the open source > repository when it is ready... > > So I want to educate on just a few points here, with the promise that further > information will be provided in the future. > > A reminder that Dovecot is commercial software, and has been since Timo made > this decision 13 years ago. Dovecot is not maintained by a community of > volunteers. We continue to be lucky that Timo remains Dovecot's Chief > Architect today, but there are 20 dedicated Dovecot employees, plus > additional Open-Xchange support staff, that are working on the software > everyday. This is carrier-grade software, which requires significant > resources to maintain. > > Dovecot CE is the open source version of this commercial product (currently, > Dovecot Pro). Dovecot CE is not a separate project - it is maintained as > part of the day-to-day maintenance of Pro. > > Every single person that works for Dovecot/OX is extremely proud and > dedicated to releasing as much software as we can to open source. CE is able > to take advantage of this situation to provide features that would not be > allowed in a purely voluntary project (for example, there are 5 full time QA > people working on what is eventually released as Dovecot CE). > > However, there remains a delicate balance of what we can openly release and > what we need to be able to commercially provide in order to keep the lights > on (which allows us to continue to provide open releases...). This is a > difficult juggling act, and is one that is always prone to recalibration in > any open software product, not just Dovecot. > > Dovecot CE has always been 100% open source, and will continue to be so. > Nothing is changing in the future. Dovecot CE has been, and will always > continue to be, fully compliant with open source principles (see > https://opensource.org/osd/). > > For a variety of software, maintenance, and (yes) business reasons, there > comes a time when decisions need to be made to move beyond existing software. > This is completely normal in software development, and there is no "open > source" duty to continue to maintain software that is no longer useful (or, > is broken or is unmaintained or is not longer best practices or is no longer > commercially viable or is duplicative of other features that exist or ) > That decision is what is being done for a selection of longstanding Dovecot > features. It is time to move on from them. There are valid reasons to do so. > > If you disagree: the software is open source. You can continue to use the > existing software, adapt it to your needs, move to a different solution, or > whatever else. > > To focus development efforts, and to provide extreme clarity for users going > forward, Dovecot CE for the first time has adopted a defined Vision > Statement: "To provide the world's premier open source, standards compliant, > full-featured, single node email backend server." This vision formulation > was made to ensure that CE users continue to receive world class, stable, > tested, modern, secure email software going forward. Maintaining features > that have existed since the mid-2000s (replication, Directors), at the > expense of moving the software forward to adapt to new paradigms (cloud, > containers, storage-layer replication, statelessness) is not the proper > choice. I cannot imagine you will devote any time to justifying this statement, so I won't ask, but for a list of mainly technical participants, I imagine people cleverer than me have issues with the lack of substance. > These Dovecot CE feature decisions are mine. If you are unhappy with them, I > ask that you direct your vitriol directly (and privately) to me. The Dovecot > Team does fantastic work and has provided software, under open source > principles, that runs millions of email servers around the world. They > continue to provide invaluable feedback internally in determining the proper > balance between open and commercial considerations. They deserve to be > thanked by the community, not vilified. Just to be clear, no one - involved with the project, or the commercial operations - should be vilified for any decision taken at a senior level. But from my detached perspective - I do not use the feature - the real failure here is the lack of communication from the senior level. Aki has had to defend this decision for months without your support and communication. Similar to the complete absence
Re: Doveadm Move Query
On Tue, 2 Aug 2022 at 12:58, Paul Kudla (SCOM.CA Internet Services Inc.) wrote: > > > ok u...@domain.com needs to exist before any operations can be done on it. > > I discovered that dovecot does not consider a virtual mailbox active > until it is returned in the user database > > see : doveadm user '*' > > both accounts MUST be returned in the list (user@.net & user@.com) > > from there it should work as expected. > > i went through this with my django email user interface as the user was > not being saved in the database until the django model had completing > saving a new entry, thus when creating the new account i had to put a > delay check in my create email account that continued to loop until > django had finished it's processing, very anoying (not dovecot's issue) > but i think you are facing something similiar? > > > it seems you might be renaming the mbox ? > > again both user@.net & user@.com must exist along the way before the > account(s) can be accessed. > > if renaming the mbox is your intention than add the user@.com account > > move should now work > > then delete the user@.net account. Thanks Paul. I finally got around to looking at this again, and for my own benefit, and perhaps anyone else in the future, the format that eventually worked was: doveadm -Dv move -u u...@destination.com INBOX user user @source.net MAILBOX INBOX ALL However... the -v option does NOT as the man page indicates produce any kind of progress counter. -v Enables verbosity, including progress counter. On a medium mailbox (~1000 messages) it took about 3 minutes, with no indication anything was being done until the prompt returned. Maybe I need -D -v and not -Dv? AND, it moved all the mails from /var/spool/mail/virtual/source.net/user/cur but none of the emails from /var/spool/mail/virtual/source.net/user/new And I have not been able to figure how to move those... Simon
Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)
On Sun, 18 Sept 2022 at 18:34, Jaroslaw Rafa wrote: > > Dnia 18.09.2022 o godz. 10:09:34 Stuart Henderson pisze: > > > > The CA/Browser Forum baseline requirements say that certificates must > > include subjectAlternativeName. This doesn't strictly apply to non-browser > > applications but it does mean that all CA-issued certs can be relied upon > > to have SAN. > > > > RFC 6125 6.4.4 says that clients must not check CN if the identifiers > > used in subjectAlternativeName are present. So for certs following the > > baseline requirements, checking CN is redundant. It also says that > > clients *may* check CN but it's not required. > > > > There are differences in handling of name constraints between certs > > using just CN and those using SAN. Name constraints don't really work > > for certs using CN (by adding dc= components to the Subject, you can > > comply with the directoryNameconstraints that apply to Subject > > while providing a CN that is not in the expected domain). The dNSName > > constraint applicable to SAN doesn't have this problem. > > > > So there's a good reason to avoid using CN when checking the name: it > > gives defence against a CA or sub-CA with a trusted but constrained root > > certificate that goes rogue. > > > > Practically this means you need to make sure that if you use self- > > signed or internal CA certificates you include subjectAlternativeName > > otherwise they won't work with some client software. If you use public > > CA-signed certs you typically don't need to do this yourself because > > the CA adds SAN if missing from the CSR (their only other option is > > to reject issuance). > > I have a question regarding this: > I always understood (maybe wrong) SAN as literally *alternate* DNS names for > the server in addition to its basic, "canonical" DNS name, which was > specified in the CN. > > For example if the server is example.com, but it also can be accessed as > www.example.com (and both names have A records resolving to the same IP > adddress), I put example.com into CN and www.example.com into SAN. > > From what you have written above, I cannot figure out if this is correct, or > maybe should I put both names example.com and www.example.com into SAN (in > addition to example.com being in CN)? As per my previous reply, the CN must now be replicated/duplicated in the SAN. So in you example a valid .csr now contains: CN = example.com SAN.1 = example.com SAN.2 = www.example.com etc. Of course you could also have: CN = www.example.com SAN.1 = www.example.com SAN.2 = example.com Regards Simon
Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)
On Sun, 18 Sept 2022 at 12:53, Goetz Schultz wrote: > > > On 18/09/2022 11:09, Stuart Henderson wrote: > > On 2022-09-14, Goetz Schultz wrote: > >> I had the same issue on TB102. Self-Signed certificates rejected despite > >> having the CA installed correctly as authority. Turns out out that that > >> TB now wants extension "Subject Alt Names". Added that and all works > >> now. Seems another Google pressed issue being introduced (my Chromium > >> had same issues and rejected certs before I added SAN). > > > > It's not just a "Google pressed issue". > > Seems I was a hasty in blaming . > Not necessarily... The CA Browser Forum ad[a|o]pted this partly because Google started showing visible warnings in the Chrome Browser when the CN was not replicated in the SAN field. Regards Simon
Dovecot-lda mysql look ups.
Hallo again. Dovecot is not doing a look up for the MailDirLoc in the mysql database after postfix hands over the mail to dovecot-lda. Postfix knows the right location # postmap -q u...@domain.net mysql:/etc/postfix/Mail-Mailbox.cf domain.com/user/ But apparently this has not worked as intended since I moved from courier to dovecot some years back. The minute I change /etc/dovecot/dovecot-sql.conf postfix starts spitting SASL authentication errors. How can I make Dovecot-LDA query the DB in that file for the delivery location (userdb_mail)? Grateful for any help :) Regards Simon
Doveadm Move Query
I have a production Dovecot problem and although I searched the mailing lists, I could not find an answer and I hope you can give me a quick answer/pointer in the right direction. I have mails for a user (u...@domain.net) under /var/spool/mail/virtual/ domain.net/user and I want to move ALL the mails to /var/spool/mail/virtual/domain.com/user If I use #doveadm -Dv move -u u...@domain.net Maildir:/var/spool/mail/virtual/ domain.net/user Maildir:/var/spool/mail/virtual/domain.com/user ALL I get doveadm(root): Fatal: Unknown argument MAILDIR:/var/spool/mail/virtual/ domain.com/user if I use #doveadm -Dv move -u u...@domain.net Maildir:/var/spool/mail/virtual/ domain.net/user /var/spool/mail/virtual/domain.com/user ALL doveadm(root): Fatal: Unknown argument /var/spool/mail/virtual/ domain.com/user What the hell am I doing wrong!? :) Thanks. Simon
Re: [Dovecot] smartsieve managesieve-login failure with dovecot 2.1.7
On 8 Oct 2013 07:50, Wouter Berkepeis wou...@private-lotus.org wrote: Hello Benny, Thanks for your response. Ingo looks promising to me as a sufficient solution, but on the Ingo site one of the stated prerequisites is : (start quote) To function properly, Ingo *requires* the following: A working Horde installation Ingo runs within the Horde Application Framework http://www.horde.org/apps/horde, a set of common tools for web applications written in PHP. You must install Horde before installing Ingo. (end quote) So, if I can install Ingo without Horde as you say, I would be more then happy. Btw, my remark about the LDAP authentication with Squirrelmail being too tricky to implement maybe wasn't described right. What I meant was it's not worth the efforts installing all this, just to be able to manage sieve filters from inside another program. I have installed Squirrelmail for just being able to look now and then at my e-mail at public places, I don't use it frequently. Anyway, thanks for your little help. :-) A working horde installation is in this case the horde package. If you don't need to install webmail, address book, calendar, tasks, you don't have to. Let alone the wiki, photo gallery, bookmark manager or ticket interface. Just install horde and Ingo and be done. You may find it useful to install imp too -to take care of the authentication, but you don't have to show it to the user. And installing by pear couldn't be easier. Why do you need a debian package? Simon
Re: [Dovecot] Sieve info
On 24 Jul 2013 09:44, Reindl Harald h.rei...@thelounge.net wrote: Am 24.07.2013 09:21, schrieb Stan Hoeppner: Reindl, keep this kind of crap off the list. It benefits nobody here and simply wastes resources. Either send it off list, or better yet, don't sent it at all. You got yourself booted from Postfix-users for this type of behavior no - i got removed because *of you* and your message below which resulted in undersatndable anger Really Reindl, I find myself unable to support you in any of the salient points you make because of your attitude and anger management issues. If the calm, rational email below resulted in understandable anger then you have issues best not dealt with in a public forum. Simon you behaved the same way telling others they have less to zero knowledge with exactly this words and Wietse as well as Viktor did point you that your behavior is not that of a saint in context of provocate me and doing the same Original-Nachricht Betreff: Re: Reject email Datum: Thu, 09 May 2013 09:44:36 -0500 Von: Stan Hoeppner s...@hardwarefreak.com Antwort an: s...@hardwarefreak.com Normally I'd avoid arguing with your Reindl as it simply clutters the list. However you made some invalid points that need to be corrected for those who may browse the archives in the future. On 5/9/2013 7:26 AM, Reindl Harald wrote: if you have a A-record for example.com and you incoming mail-server is on this IP you do not need any MX record and postfix will happily use the A-record to deliver mail When did you last come across a domain configured strictly for fallback to A? While RFC may require it, and some used it in the 70s and 80s, no receivers rely on fallback to A in 2013. Anyone versed sufficiently in SMTP to know of the existence of fallback to A isn't going to rely on it. They'll have proper MX records. another story is if there is a MX-Record but the listed hostname does not resolve and at least for me the intention of if the MX does not exist is not clear enough if it means a) no MX record for the domain b) a MX record with a non-resloving hostname reject b) would be fine Only if the response is 4xx. People fat finger records all the time. reject a) would be stupid If generic and not selective then yes, but not because of fallback to A. The real problem here is legitimate send-only domains, such as some mailing lists, bulk mail campaigns, emergency alert and other notification systems, etc.
[Dovecot] Server shutting down
Hi I recently moved to Debian Wheezy and installed dovecot from apt-get. root@mail:~# dpkg -l | grep dovecot ii dovecot-common 1:2.1.7-7 all Transitional package for dovecot ii dovecot-core 1:2.1.7-7 amd64secure mail server that supports mbox, maildir, dbox and mdbox mailboxes ii dovecot-gssapi 1:2.1.7-7 amd64GSSAPI authentication support for Dovecot ii dovecot-imapd 1:2.1.7-7 amd64secure IMAP server that supports mbox, maildir, dbox and mdbox mailboxes ii dovecot-ldap 1:2.1.7-7 amd64LDAP support for Dovecot ii dovecot-managesieved 1:2.1.7-7 amd64secure ManageSieve server for Dovecot ii dovecot-mysql 1:2.1.7-7 amd64MySQL support for Dovecot ii dovecot-pgsql 1:2.1.7-7 amd64PostgreSQL support for Dovecot ii dovecot-pop3d 1:2.1.7-7 amd64secure POP3 server that supports mbox, maildir, dbox and mdbox mailboxes ii dovecot-sieve 1:2.1.7-7 amd64sieve filters support for Dovecot ii dovecot-sqlite 1:2.1.7-7 amd64SQLite support for Dovecot Having previously been on 1.2 on Debian Squeeze the upgrade went flawlessly (and automatically, as I'd already placed the 1.2 dovecot.conf file before installing 2.1.7). And I've been very happy. However, yesterday the server just just shutdown. /var/log/mail.log.1:42890:Jun 30 17:27:04 mail dovecot: imap: Server shutting down. in=14 out=648 /var/log/mail.log.1:42891:Jun 30 17:27:04 mail dovecot: imap: Server shutting down. in=14 out=648 /var/log/mail.log.1:42893:Jun 30 17:27:04 mail dovecot: imap: Server shutting down. in=14 out=648 /var/log/mail.log.1:42895:Jun 30 17:27:34 mail dovecot: imap: Server shutting down. in=739 out=2081 /var/log/mail.log.1:42896:Jun 30 17:27:34 mail dovecot: imap: Server shutting down. in=1764 out=4027 There's no error|panic|warning|fatal messages in any of the logs. root@mail:~# grep -in dovecot /var/log/syslog | grep '(fatal|error|warning|panic)' root@mail:~# grep -in dovecot /var/log/messages | grep '(fatal|error|warning|panic)' root@mail:~# grep -in dovecot /var/log/daemon.log | grep '(fatal|error|warning|panic)' root@mail:~# grep -inr dovecot /var/log/mail* | grep '(fatal|error|warning|panic)' Although everything should log to mail.log if I set up rsyslog properly. The timestamp is not correlated to any of my cron jobs. How can I find out what caused this? Of course with Dovecot shut down Postfix refused to send mail as there was no auth service available. Simon
Re: [Dovecot] Server shutting down
On 1 July 2013 11:32, Thomas Leuxner t...@leuxner.net wrote: * Simon B simon.buongio...@gmail.com 2013.07.01 10:41: /var/log/mail.log.1:42896:Jun 30 17:27:34 mail dovecot: imap: Server shutting down. in=1764 out=4027 What does the preceding line for the master process say? Jun 29 11:39:24 spectre dovecot: master: Warning: Killed with signal 15 (by pid=11676 uid=0 code=kill) Jun 29 11:39:24 spectre dovecot: imap: Server shutting down. in=556 out=11739 Jun 29 11:39:24 spectre dovecot: imap: Server shutting down. in=7534 out=29257 Hi Thomas, The line before was a regular imap login line. As per my original mail nothing was logged with warning in the entire mail.log. I notice now that I don't have any master logging lines too.. root@mail:~# grep -inr dovecot /var/log/mail* | grep '(fatal|error|warning|panic)' root@mail:~# grep -inr dovecot /var/log/mail* | grep '(fatal|error|warning|panic|master)' root@mail:~# I wonder where master is being logged to and how I can redirect that. Simon
Re: [Dovecot] Safe/preferred way to import old email
On 14 Jun 2013 23:01, Reindl Harald h.rei...@thelounge.net wrote: Am 14.06.2013 22:10, schrieb Ajai Khattri: One small problem (I should have described better): the old server is not available but I've have the maildirs rsynced to the new server. So I have the actual message files but I'm not sure if simply copying them into the new maildirs is a good idea :-) On Friday, June 14, 2013, Reindl Harald wrote: Am 14.06.2013 21:59, schrieb Ajai Khattri: Ive migrated from a qmail+Courier-IMAP setup to a Postfix+Dovecot setup. I'm using maildirs in both places. Is there a safe/preferred way to bring my old messages over without them being marked as new in Dovecot? imapsync well, that must answer people which where in the situation of a not really prepared migration why you *should not* reply off-list! So.. you are rsynced courier imap folders to a new server that has dovecot on it? Hopefully you used the -a flag. Courier-to-dovecot script? Simon
[Dovecot] Turn off IMAPS?
Hi
I've upgraded to 2.1.7 and finally decided to turn off imaps and pop3s
because these days everyone uses tls over 143 anyway. But it's on and
I can't figure out why.
I only have non-ssl versions specified:
protocols = imap pop3
I've stopped and started and the ports are still open and netstat says
dovecot is listening on them..
mail:~# netstat -tulnp | grep dove
tcp0 0 0.0.0.0:993 0.0.0.0:*
LISTEN 29340/dovecot
tcp0 0 0.0.0.0:995 0.0.0.0:*
LISTEN 29340/dovecot
tcp0 0 0.0.0.0:110 0.0.0.0:*
LISTEN 29340/dovecot
tcp0 0 0.0.0.0:143 0.0.0.0:*
LISTEN 29340/dovecot
tcp6 0 0 :::993 :::*
LISTEN 29340/dovecot
tcp6 0 0 :::995 :::*
LISTEN 29340/dovecot
tcp6 0 0 :::110 :::*
LISTEN 29340/dovecot
tcp6 0 0 :::143 :::*
LISTEN 29340/dovecot
Any ideas?
Thanks.
Simon
Here's my doveconf - n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.0 ext3
auth_mechanisms = plain login
auth_verbose = yes
disable_plaintext_auth = no
first_valid_uid = 109
last_valid_uid = 109
log_timestamp = %Y-%m-%d %H:%M:%S
login_log_format_elements = user=%u method=%m rip=%r %c
mail_location = maildir:/var/spool/mail/virtual/%d/%n
mail_privileged_group = mailsystem
maildir_very_dirty_syncs = yes
passdb {
args = /etc/dovecot/dovecot-sql.conf
driver = sql
}
plugin {
quota = maildir
}
protocols = imap pop3
service auth {
unix_listener /var/spool/postfix/private/auth {
group = mailsystem
mode = 0660
user = postfix
}
unix_listener auth-master {
group = mailsystem
mode = 0660
user = mailsystem
}
user = mailsystem
}
ssl_ca = /etc/ssl/keys/ca.crt
ssl_cert = /etc/ssl/keys/mail.net.crt
ssl_key = /etc/ssl/private/mail.net.key
userdb {
driver = prefetch
}
userdb {
args = uid=109 gid=113 home=/var/spool/mail/virtual/%d/%n allow_all_users=yes
driver = static
}
protocol imap {
imap_client_workarounds = delay-newmail
mail_max_userip_connections = 20
mail_plugins = quota imap_quota
}
protocol pop3 {
mail_plugins = quota
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
pop3_save_uidl = yes
pop3_uidl_format = %v.%u
}
protocol lda {
deliver_log_format = msgid=%m: %f: %$
info_log_path =
log_path =
mail_plugins = quota
postmaster_address = postmas...@example.net
}
Re: [Dovecot] Turn off IMAPS?
Thanks everyone :) You'd think I could have found that on Google!
Simon
On 13 June 2013 16:56, InuSasha i...@inusasha.de wrote:
Hi Simon,
Try to add this configuration.
The Port = 0 will disable the listener.
Greats,
Sascha Kuehndel
service imap-login {
inet_listener imap {
#port = 143
}
inet_listener imaps {
port = 0
#ssl = yes
}
}
service pop3-login {
inet_listener pop3 {
#port = 110
}
inet_listener pop3s {
port = 0
#ssl = yes
}
}
Re: [Dovecot] An unconstructive grumble
On 3 Jun 2013 16:49, /dev/rob0 r...@gmx.co.uk wrote: On Mon, Jun 03, 2013 at 06:23:09AM -0700, dd wrote: 5 hours of configuration attempts, error after confusing error, documentation with examples that only show extracts of working configurations. I really feel like throwing in the towel with dovecot. It should not be this hard ... Why not? You're really not in a position to make this claim. But having said that... and frankly almost impossible to understand and configure for such an incedibly simple configuration. /home/vmail/domain.name/username/cur /home/vmail/domain.name/username/new /home/vmail/domain.name/username/tmp 3 virtual users. All I want is a username and password to access my email. ... you complicated things by wanting virtual users. System users would have been much simpler to set up. Also, you missed the fact that virtual users should have a $HOME directory just like system users: I've never understood this antipathy to virtual users. But your knowledge is greater than mine :) http://wiki2.dovecot.org/VirtualUsers http://wiki2.dovecot.org/VirtualUsers/Home I sort of see why for legacy reasons a $home directory might once have been needed. But surely however you word it all you're doing is telling the server where to put the mails, the structure you want and the format of the files. 3 variables... Simon
Re: [Dovecot] Upgrading 1.2 to 2.x
On 24 May 2013 20:08, Benny Pedersen m...@junc.eu wrote: Simon B skrev den 2013-05-24 18:32: In an unscheduled maintenance window next week, I will have the opportunity to upgrade to 2.x should I wish to do and provided I can get it working on stage first. +1, i would have installed 2.x if it was first time install of dovecot, i would keep 1.x until i need a new server, since 1.x is all i need, and wiki page for 1.x still exits so all is fine imho :=) Thanks for the response Benny - the opportunity is that it's a new server :) My questions: I've seen a lot on the list about the rock-solidness of 1.2 but also some people saying that some versions of 2.x better than others. Is there a recommended version - I don't need bleeding edge, I'd prefer stability, or one most of you can agree on? imho its not just a version change, its more then that, mailstore and backend and out support and whole new config layout keeps me away from migradeing it, well when i migraded from curier-imap to dovecot i have both running the same time binded to diff localhost ips, then it was simple to use imapsync to migrade over storages for all mailboxes, but now with dovecot 1.x to 2.x its not that simple anymore What am I missing by not upgrading? if 1.x is working now, then you miss nothing, no matter that dovecot 1.x is nearly not supported in any distros anymore, so i keep my 1.x ebuild on gentoo, just in case i still really need to build it again Yeah, 1.2 is working and I never have to worry about it. The problem is I don't really see a feature list to give me an idea of whether the reward is worth the risk. A few months ago I tried to convert a Dovecot 1.2 config into 2.1 and wasn't very successful. Any tips on how to go about it? its dangoryous to ask that here, most people would just say read the docs or do dovecot -n new.conf with the new dovecot installed, not there fault it ends with single conf like dovecot 1.x had Yes, that's what I did - failed spectacularly. And I've just reread it again. suggested keep 1.x for now Cheers. Unless anyone has anything to add, that is probably what I will do. Simon
[Dovecot] Upgrading 1.2 to 2.x
Hi In an unscheduled maintenance window next week, I will have the opportunity to upgrade to 2.x should I wish to do and provided I can get it working on stage first. My questions: I've seen a lot on the list about the rock-solidness of 1.2 but also some people saying that some versions of 2.x better than others. Is there a recommended version - I don't need bleeding edge, I'd prefer stability, or one most of you can agree on? What am I missing by not upgrading? A few months ago I tried to convert a Dovecot 1.2 config into 2.1 and wasn't very successful. Any tips on how to go about it? Thanks. Simon
